Re: Infrastructure, was: Proposal: New web site maintainers

[Luke <..hidden..>]

On Mon, 4 Oct 2010, Chris Travers wrote:

> However there is also a  basic question to the community:
>
> What can we do to facilitate cooperation and contribution from the community?

Bluntly, and hopefully without offense: Get out of the way.

> I have a few basic ideas, still very poorly formed, but worth
> discussing openly in the spirit of peer review:
>
> 1)  Would it be helpful to have a list for moderators of the web site?

I think not.

If the site managers need to communicate beyond simple email, they can 
sort it out among themselves.  Why should you have to worry about that in 
the startup phase?  Don't lay so much groundwork that they only have one 
path to follow, and you end up holding hands to the extent that nothing 
has changed.

Appoint a couple core people to run web issues, and then trust them to do 
what you've tasked them to do.
If you don't like the result, advise them.  If you still don't like it, 
fire them and find somebody else.  But the "management by central 
committee" approach has not really worked to date, so why should a version 
of it with a few extra people work now?

That aside, a (protected) forum on the site itself for site issues seems 
like a more logical approach.

> (Actual moderator status would, I think, need to be invite-only, but
> it would give people a chance to get involved and show themselves
> before we make such a decision.)

I think the way this is normally handled in community building sites, is 
to let people's behavior recommend themselves to the existing moderators. 
If the admins who observe them approve them, they are given greater 
authority--such as moderating a specific forum, moderating the whole site, 
editing info pages, etc..

You don't need to have an all or nothing structure here--from user to full 
admin at one shot.  There are various levels of incremental promotion 
possible in drupal.

 > 2)  Would it be helpful to have a list for people interested and able
> to contribute to the management of the infrastructure?  Actual ability

I don't think so, not right now anyway.
What infrastructure is there, other than git, the website and the lists? 
Of these, only one requires creative management at the current level of 
involvement.

I am a detail oriented person.  I write bylaws and contracts for fun, and 
am usually all about structure.  However, I think in this case, you are 
putting the cart before the horse, the driver, the passengers, and maybe 
even the road.

Start with a few initial full admins, tell them the results you want, and 
sit back to watch them do it.  Keep the "core committee" out of it as much 
as possible.  If you need to ask the user list what the desired result is 
first, then do that, but don't set up any new working groups, committees, 
development conferences, or try to describe the entire project from start 
to finish before it is even born.  Let it grow with a minimum of initial 
restrictions.

I would withhold the power to create full admins, but allow the admins you 
appoint to delegate any lesser authority as they find necessary in daily 
operations.

Otherwise, you're just putting an abstraction layer between day to day 
operations and yourselves, that will still result in you having an 
alarming quantity of responsibility for the site.

> Part of what I'm wondering is if it wouldn't be better to try to push
> the role of the core committee closer to that of pure governance

Probably reasonable.

> matters and try to open up some of the infrastructure management to a
> wider community.  Maybe we could have other committees for managing
> the web site and other pieces of infrastructure on a day-to-day level
> and free us up a bit.

If it only frees you up "a bit", it has failed in its purpose.  From where 
will you get the people to compose all of these committees?
Some responsibilities (I.E. running low traffic lists, managing 
infrequently used repositories, etc.) are better done by one, or at most 
two, people anyway.

Honestly, there is not enough of an involved community, to support this 
level of bureaucracy.  Maybe later such things will make sense, but this is 
a case when creating the structure for expansion before the thing that is 
going to expand, is going to make it too complicated to bother with.

One core committee member, and two or three non-core-committee members, 
with full administrative rights, and the core committee with control over 
the DNS settings, should be enough to maintain control over what those 
full admins do.  Let the site promote in-house, with a structure it 
develops as fitting its needs as they evolve.

> Maybe this is a bad idea or maybe it is a good one.  But I figured it
> seems like a good time to float it and see what other people think.

It has elements of a good idea.:)  Obviously the large structure 
centralized management model is not appealing to me in  this case.

The core committee has tried hands on, and it hasn't worked.  Instead of 
worrying about "how", shouldn't it be worrying about "what" and "who"?

That is: instead of worrying about how the site is managed on a day to day 
basis, how subordinate authority is delegated within the site structure, 
how often and by what means the site admins communicate internally, and so 
on; it should instead worry about what the ultimate goals of the site 
are; and who should be intrusted to build the team that reaches 
those goals.

Regards,

Luke
P.S.
A minor matter of terminology, while I'm ranting: why is it a core 
committee, and not a core team, as 
with many open source projects?