welcome: please sign in

Diff for "RichardDarst"

Differences between revisions 5 and 7 (spanning 2 versions)
Revision 5 as of 2010-03-13 02:20:35
Size: 2841
Editor: RichardDarst
Comment:
Revision 7 as of 2011-09-08 00:23:51
Size: 3311
Editor: RichardDarst
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
 * IRC: !MrBeige  * IRC: !darst
Line 15: Line 15:
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. 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:
Line 19: Line 21:
  * Documentation: Our wiki should be up to date on current admin practices.
  * 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".
  * 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 [[http://err.no/personal/blog/tech/2010-03-27-15-55_why_you_should_publish_your_infrastructure.html|here]], several weeks after I added this point to my outline.
Line 22: Line 24:
  * 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.)
  * 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.

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

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