Forum OpenACS Q&A: Re: Bootstrapping OpenACS governance

Collapse
Posted by Roberto Mello on
<blockquote>>>
</blockquote>
something like the TCL core approach is how we want to organize ourselves.
<<<

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

Collapse
Posted by Roberto Mello on
Let me add a suggestion that I think would make the biggest impact without much more work.

Joel, instead of being a "secretary", you can write an "OpenACS Weekly News" mailing, where you'd summarize what happened in the project that week.

Anyone with suggestions could e-mail them to you, and the rest you'd gather from the OpenACS forums, which you already follow anyways.

I find the Debian Weekly News extremely useful. It lets the entire community know what's going on at large, decisions are mentioned, suggestions told. All in a simple, easy to read weekly post.

-Roberto