Richard Darst

• HCoop username: rkd
• IRC: !darst

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.

I think there should be a logical separation between admins and the board: specifics should be left to the admins to decide and work on, with the board setting overall policy goals and answering strategic questions the admins may have. Incidentally, I also think that complete overlap admins and board members is not the best situation, and would encourage non-admins to run for the board (by the way, from this standpoint, I'm not the best person to elect).

Some of my guiding principles are listed below:

• 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. The board should really push this, and it's a useful talk for admins in training.

• 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". I saw example of this idea on on a blog syndicated on Planet Debian here, several weeks after I added this point to my outline.

• The technique above should be used to slowly build the pool of admins/software maintainers as needed.
• Members should like our services enough to encourage their friends to join. We should encourage promotion of HCoop (add a link to HCoop from your personal website now!). 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