Forum OpenACS Q&A: Bootstrapping OpenACS governance

Then we need a persistant virtual space for Core Team decision making. The structure I see, perhaps because I've worked in a bunch of corporate dev. teams, is something like a bug list, where anybody can submit stuff that they think needs Core Team attention. The Core team then meets (virtually) once a week, does TYANN to take care of as much stuff as possible, and then schedules discussion on non-consensus issues. I propose that the Core team decision list reside in a simple table modeled after bugs, and that core team discussion be in a logged irc session.

And I'm volunteering to do management/secretary type tasks to make this happen. No matter what mood I'm in when I wake up, I'm always willing to nag people.

I thought we had a core team already. Peter Marklund recently revamped the contribute page and it's up and going. We can make pages for sub-teams (e.g. Documentation, CMS, ETP, or one for each package for which the maintainer desires more organization).

I'm a bit uncomfortable with the idea of making the OpenACS project behave like a closed-source in-company project, with scheduled meetings that developers must attend to, and other sorts of bureaucracy.

I'm all for organization and documentation, but overdoing it will add bureaucracy and unnecessary work for developers. Anyone that has worked on a common proprietary software company knows that you spend half of your time time in meetings which are most often useless, instead of working on something useful like the software.

We already have the OpenACS weekly chat. We don't need another chat. We have mailing lists, forums and all that where we can discuss and resolve any pressing matter. I agree entirely with Lamar that the PG model is what we should aim at (but it appears we already have been doing that for a long time).

<blockquote>>>
</blockquote>
then they can adopt ground rules and also rules for expanding the core team? Perhaps we can simplify things by having the core team pick itself by fiat but with a six-month limit to re-select itself
<<<

There are ground rules for expanding the core team. They have always been there and you can define it in one word: Meritocracy.

If you make continuous significant contributions to the project, there's no need to say "Hey, can I be in the core team please?". The core team and the community will say (as has happenned in the past): "Gee, what you're doing is pretty cool, and you've been doing it consistently and you work well in groups. We'll give you full CVS access."

This has recently happened with Jeff Davis and Peter Marklund. No elections, virtual paperwork and other sorts of bureaucracy were necessary. Please let's not get into that kind of thing.

<blockquote>>>
</blockquote>
Then we need a persistant virtual space for Core Team decision making.
<<<

I thought that was one of the purposes of the OpenACS-Development forum, which in fact has pretty low volume of messages, so I don't see the need of creating another forum for now.

<blockquote>>>
</blockquote>
The structure I see, perhaps because I've worked in a bunch of corporate dev. teams, is something like a bug list, where anybody can submit stuff that they think needs Core Team attention.
<<<

We have the bug tracker already. Why put yet another thing to tell people about? Isn't the but tracker enough? Anyone in the core team (and most importantly, in the community) can see, ponder and resolve the items there, with the added bonus that others in the community can also see it and submit patches for them.

When something needs discussion, it comes to the forums. Everybody talks about it and a decision is reached by consensus usually. When a consensus isn't reached, someone in the core makes a decision. Isn't this how it was worked so far? Or is it not working anymore?

<blockquote>>>
</blockquote>
The Core team then meets (virtually) once a week, does TYANN to take care of as much stuff as possible, and then schedules discussion on non-consensus issues. I propose that the Core team decision list reside in a simple table modeled after bugs, and that core team discussion be in a logged irc session.
<<<

I'm definitely against this (and I don't even know what TYANN is). I have participated in the OpenACS project since its inception and things always got discussed and solved through mailing lists/forums. Unless shown that this model is terribly inneficient or is not working for the project, I vote to not add this extra layer of bureaucracy (yes, I'm repeating this word a lot because that's how I'm seeing some of these suggestions).

One of the biggest advantages of open source projects is swiftness, simplicity. Please let's not take that away from OpenACS with added levels of things to do, to keep track of, etc.

-Roberto

The volunteers have put in a tremendous amount of effort in the last few years; with a less ad-hoc goverance system we should be able to get more input and more progress from more people with less sweat and tears. The problems with the ad-hoc system are lack of predictability, dependence on a few people, and lack of transparency (even when everything is public, it's hard to find).

So I think we need more formal processes, but I agree with you Roberto that bureaucracy is a risk. I think that's why the TCL rules are so appealing - they seem to have hit a good balance with the rules on paper and in implementing them in real life.

I can think of more details for my suggestions which would address some of Roberto's concerns, but I'd like to hear from other people first. What specifically should we do in the next few weeks and months to formalize decision-making without adding waste?

But I'm not personally beholden to any particular approach to communication among a core group of folks.

I think weekly meetings is not unreasonable to kick-start things, especially this spring where it seems there are loads and loads of important changes (AOLServer 4, Oracle 9i, noquote, I18N, 4.6 merge etc. etc.) and open questions that need to be coordinated and settled and we have an absolutely crucial release this summer.

In addition, I would like to see an openacs.org swat team formed that shapes up our website. There are about a 100 things that I can probably think of that need to get done. Here I'm just thinking about improved content, not the upgrade. Where is the task list, where is the roadmap? Who will head that team?

We definitely need a team to maintain the we site. In Tcl, the core team maintains the web site also, but for OpenACS, we probably need to delegate most of that.