welcome: please sign in

Diff for "RichardDarst"

Differences between revisions 6 and 7
Revision 6 as of 2010-04-05 02:57:36
Size: 3313
Editor: noway
Revision 7 as of 2011-09-08 00:23:51
Size: 3311
Editor: RichardDarst
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
 * IRC: !MrBeige  * IRC: !darst

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, ...


RichardDarst (last edited 2011-09-08 00:23:51 by RichardDarst)