- HCoop username: rkd
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.
- Availability of code and configurations: 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".
- Availability of code and configurations: 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.)
- 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, ...