← Revision 7 as of 2011-09-08 00:23:51 → ⇥
|Deletions are marked like this.||Additions are marked like this.|
|Line 7:||Line 7:|
|* IRC: !MrBeige||* IRC: !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.
- 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, ...