I think that by allowing a  larger group of people in, we get more done
and have _better_ services. But there's definitely a balancing act,
between stability and more hands.  I don't want to see it balanced too
much toward stability 'guarantees' though. Letting in people we trust to
know what they know and what they dont' know and only touch the stuff
they are volunteering to be responsible for I think can do that.

For instance, I'm happy to be responsible for the planet. And not much
else.  Just being responsible for the planet, I'd be 'wasting' a 'slot'
if we only allowed 2-3 people in---plus I'm not really an experienced
sysadmin!  But I'm willing to manage the planet, and if I weren't doing
it, someone else would have to. I suppose if we can really find 2-3
experienced sysadmin willing to spend a lot of time on code4lib for
free...  but isnt' spreading out the work more a better idea?

As far as the 'formalization' idea---if what you want is a small group
of people deciding who gets shell access, you can have that without
bylaws and a board. Just create the small group of people. Two seperate
questions. If a junta in charge of code4lib sysadmining is a good idea,
create one.

So maybe that's the answer right there. We find 2-3 people to take
_primary_ app-level responsibility for code4lib.org (ryan ordway still
has primary OS-level responsibility), and they are the junta. If someone
else (like me) wants access to do some smaller part, the junta approves
him or her (and the junta can revoke them).  That makes sense to me.
Anyone volunteering to be that junta?   :)

Jonathan

Kevin S. Clarke wrote:
> On Fri, Mar 21, 2008 at 11:13 AM, Jonathan Rochkind <[log in to unmask]> wrote:
>
>>  Pre-OSU hosting, code4lib
>>  was hosted by a defined group of code4libbers who chipped in for hosting
>>  fees, and were the only ones who had shell access. If you wanted shell
>>  access, as I understand it, you'd have to talk to them about becoming a
>>  member of their 'cooperative', and they'd decide whether that would
>>  happen or not.
>>
>
> Well, there wasn't much of a decision.  If folks wanted in they were
> welcome... we weren't turning anyone away or anything.  :-)
>
> Also, just to quibble with the above, the previous machine had more
> than code4libbers on it (some who aren't involved in or that
> interested in code4lib); it was just a working environment that
> volunteered to host the domain for awhile.  It was (and still is) just
> a dev machine... a play space.
>
>
>>  Now, with OSU hosting... what should happen? It probably
>>  doesn't make sense that any Joe Schmoe that nobody's heard of can just
>>  email Ryan and automatically get shell access. So ruling that out....
>>  any ideas?    Maybe if you want shell access to manage a particular
>>  application, you email the code4lib listserv, and....   then what?  Not
>>  sure.
>>
>
> I think one of the reasons of going to OSU was to make the machine a
> production oriented machine.  In my opinion, it should be locked down
> and not be as open as the anvil machine was/is.  I think there should
> be two or three experienced folks who volunteer to do the sysadmining
> (this aligns with the talk of structuring code4libcon).  If there is a
> project that someone wants to start in the code4lib domain that
> benefits the code4lib community, then they should discuss it on the
> mailing list and build up some community support.  If that happens
> (e.g., they get enough volunteers and build an organization structure
> for the project), they should get access to a shell account to bring
> it into production (only after it has been developed and the bugs
> worked out on another machine).
>
> For all the other non-production stuff (experiments with new services,
> etc.), people should use their own machines or form cooperatives
> (formal or informal) to share the costs.  I'm sure Ed could set it up
> so that whatever subdomain they want gets resolved to their machine
> (e.g., freakflag.code4lib.org).  This could be used for testing or
> even for just perpetual projects that are never meant to go
> production.  I see he just sent an email saying that he could :-)
>
> My 2c anyway....
>
> Kevin
>
> --
> There are two kinds of people in the world: those who believe there
> are two kinds of people and those who know better.
>
>

--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu