There is a monthly Hcoop volunteer day where we get together on IRC and work on Hcoop tasks. A good place to start is the category Needs Work. Below there's some tasks that are not directly related to the wiki.

The next Hcoop volunteer day is: TBD

1. Things That Could Be Done

1.1. Improve Documentation

The wiki has a number of pages that could use some love, and improving them is something just about anyone can do. Don't be shy with edits, anyone can fix any mistakes that are introduced.

• Check out CategoryNeedsWork and revise/clean up wiki pages that have been neglected.

• Tag pages CategoryNeedsWork if they clearly need work

• Screenshots showing how to whitelist hcoop announcements on gmail would be helpful on MemberManual/GettingStarted/AccountCreated

• In theory sieve filters work in ~/.forward and we should probably document and encourage using sieve in the email manual

  • They work in practice, too (as of 2019-04-14). However, the fileinto command can only handle absolute paths. This also means the default action (file into inbox) will fail if no rules match, so you must explicitly add a catchall rule, fileinto "/afs/hcoop.net/user/path/to/your_username/Maildir/"; at the end.

• The MemberManual should explain AndrewFileSystem semantics, so that members don't accidentally configure their programs to eat their data

  • mmap+flock+fsync is probably safe, mmap+fcntl+write is safe if only processes on one client access the file but will eat your data if more than one client is accessing the file, mmap+fsync likely has awful performance and using read+write+fsync is probably better ?

• The domtool reference documentation could use some sprucing up

  • Easy: The docstrings could use expansion and updating. All you have to do is edit the comments in the domtool standard library files and send a patch. You can also copy them from /afs/hcoop.net/common/etc/domtool/lib/ and a sysadmin can make a diff against your local revisions if you are unfamiliar with git.

  • It's Complicated: Make the documentation look prettier (aside from pure CSS changes). Requires hacking on some SML.

• MemberManual/TransferringFiles/OpenAFS/Windows and MemberManual/TransferringFiles/OpenAFS/MacOSX likely do not work anymore since the OpenAFS project gave up on maintaining clients for Windows and MacOS due to their signing requirements. Someone might want to document installing the proprietary auristor clients for proprietary platforms. We'd be directing members to proprietary software in that case... but also there is no alternative anymore .

1.2. Improve the wiki

Minor wiki tasks that are not directly related to documentation.

• Adjust colors in the MoinMoin theme's CSS to match our website color scheme

• Help us document our history by locating the images lost to linkrot on https://wiki.hcoop.net/LogoDiscussion (some might be on archive.org), adding them as attachments (don't overwrite existing attachments!) to the page for posterity

• Document transition to virtualized hosting on OurHistory ("HCoop v3" I suppose)

1.3. Improve Member Interaction

We have a members directory featuring any site a member wishes to list, but it's not really being used any more.

• Add your sites to the member website directory!

• Add your weblog to Planet HCoop (by emailing <robin AT hcoop DOT net>)

• It would be nice if the new website had a better member url and location directory. The member url directory / location map are generated from DaemonAdmin/Portal using a shell script. You'll need to either update the portal code that spits these out, or come up with another solution (they are easy database queries and could be done in most any language)

  • Bonus points for the first person to use an open street maps widget for the member location summary

1.4. Administration

• We need mailing list moderators for -discuss, -help, and -sysadmin are needed (right now ClintonEbadi is doing all moderation). Email hcoop-sysadmin to volunteer.

  • Workload is light: when you receive a moderation message either kill it or approve it. Can usually be done once per day or less, especially when multiple people are moderating the lists simultaneously.

1.5. Improve Experience

Lots of things could go here.

1.6. Programmers Wanted

DomTool is a great tool, but it still has rough edges for new users. There are a few easy tasks that could be handled by anyone with even basic familiarity with SML (or as a way to pick up SML).

• DomTool does not have command line help and instead refers users to the wiki docs. A basic overview of available commands for each tool would increase discoverability

  • It would be straightforward: modify domtool's src/main-FOO.sml drivers to spit out useful help on badArgs. Ideally help would be integrated with command processing (domtool just does a case over the command line arguments, a type for storing command line arguments would be nice). No real knowledge of domtool is needed, and you can test it without needing to install a virtual hcoop.

• DomTool could produce "human readable" type errors

  • E.g. "Expected type [Vhost], actual type [Vhost] {Foo}" should hint to the member they need to set the Foo domtool environment variable

More difficult DomTool tasks, but still needed:

• Make domtool easier to build and test locally
  • The makefile doesn't create needed directories during install, there is no testing configuration included, etc.
• We could support more Apache modules and extend our coverage of existing modules. Doing so is reasonably straightforward (and there are tons of examples in the domtool source). Admin coordination is required to install the new modules.

• Write a parser to convert .htaccess files into domtool configuration

  • For directives we support, domtool could parse htaccess files and include their configuration in a domain. This would make setting up most software easier by only requiring that the htaccess files to be used be listed instead of rewritten.

  • Bonus points for making it more general: Apache domtool actions should generate an Apache AST and use a pretty printer to generate the output text, replacing the current Apache output code (which consists of a thousands of TextIO.outf calls and is ugly)

We were previously using the Debian MeetBot to generate meeting minutes for board meetings, but have lost access since RichardDarst is no longer with the coop. Meet bot is written in Python as a supybot plugin. Since we need to set up our own copy, a few new features would be helpful.

• Commands for taking attendance (e.g. #here $hcoop-username)

• Commands for taking votes
  • Call vote, enter vote, close vote

• #action and friends should recognize hcoop usernames (associated with an IRC nick using the proposed roll call commands) in addition to IRC nicks.

KennethPronovici is currently working on a rewrite of MeetBoot in Python 3 that will make it easier to implement these features, so please coordinate with him if you are interested in helping.