72011-09-08 00:23:51RichardDarst62010-04-05 02:57:36noway.chem.columbia.edu52010-03-13 02:20:35RichardDarst42010-03-12 18:25:55RichardDarst32010-03-12 06:34:27RichardDarst22010-03-11 08:58:08RichardDarst12010-03-09 22:15:06RichardDarst

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.

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