Richard Darst

• HCoop username: rkd

• IRC: MrBeige

If I did run for the board, the statement I would give is below. If I don't run for the board, look at it as "here's how I think hcoop should be".

I have been a HCoop member for about a year. I joined because I felt that something like hcoop would produce better and more reliable services than "rolling my own" would.

I am active in Debian-NYC and an organizer of the DebConf10 conference in New York City. My background working in working in these open source projects helps guide my thoughts on the co-op.

Some of my guiding principles are listed below. The principles listed below are intentionally vague: specifics should be left to the admins to decide and work on. Incidentally, I also think that complete overlap admins and board members is not the best situation, and encourage non-admins to run for the board.

• Openness: All HCoop developments that aren't a password or personal member information should not be locked away. This goes beyond just being visible to members, but to the public at large.
• There should be regular "here's what is going on" announcements to hcoop-discuss anytime there are developments going on. Informed members become active members.
• Documentation: Our wiki should be up to date on current admin practices.
• It should be easy for members to grab our code and contribute patches back. In a related vein, we should help non-admin members maintain services by using version control systems (merged by an admin) or access control lists. Of course, non-admins can maintain custom software like this already. Non-admin maintainers shouldn't be seen as untrusted, but rather "in training".
• The technique above should be used to slowly build the pool of admins/software maintainers as needed.
• It should be easy for non-HCoop members to grab our code, use it, and contribute back.
• Members should like our services enough to encourage their friends to join. We should encourage promotion of HCoop. (I wouldn't promote spending our money on advertising, though.)

To Do

• Ensure openness
  • Everything that isn't a password or personally identifiable information should be made public.

• Clean up AdminArea

  • Hardware / Services /
  • Troubleshooting page
  • Be sure restarting each service is documented
• admins subscribe to admin pages on the wiki
• Work on an admin strategy
  • better documentation for first responders to work out what to do?
• Portal page with member statistics/budget statistics/etc
  • make it public? what portal pages can be public?
  • Member count, active members, monthly income, monthly expenses, ...

CategoryHomepage