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.
The PostgreSQL core does this; virtually all discussion, even amongst core members, happens on the pgsql-hackers mailing list. It is archived and searchable.
And if Joel wants to be secretary, let him at it...every team needs a good nag 😊.
However, formal weekly meetings may or may not be the best idea. I personally like the PostgreSQL style best; yet I understand that it's not the best fit for all people. That style is very much a spontaneous style, with decisions happening at all hours. But then again, the PostgreSQL community is global in scope, with people in many varied timezones (but that also describes the OpenACS community, no?). Asynchronous meetings are a good fit for such a widespread community, and mailing lists or web forums are two ways of making such a meeting happen. IRC and other chat systems are far too synchronous for this sort of thing. But that's just my opinion, YMMV.
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).
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.
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.
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?
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.
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.
thanks for continuing the discussion on governance. Here are some ideas and clarifications:
1) We should produce a governance document as soon as possible that resembles the Tck/TK document.
2) The /contribute page lists the members of the core team. The /projects/openacs/4.7/package_inventory page lists the package maintainers. I added a sentence today in the cvs guidelines that I think might clarify cvs commit rules to people:
"Before committing to cvs you must submit a bug report and patch to the OpenACS bug tracker. The only exceptions to this rule are for package maintainers committing in a package they are maintaining and for members of the core team."
So having commit rights doesn't mean you are entitled to commit at will - only under certain restricted circumstances.
3) My idea regarding meetings was that the core team would meet right before the .LRN meeting since its basically the same people. I don't think the meetings should be public as sensitive issues may be discussed, but I think we should require that a brief report be blogged from each meeting. It shouldn't be too much to ask to have one of the core team members do this (I for one volunteer).
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?
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 isn't really true, Roberto. Generally what happens is that *I'm* asked if so-and-so can have commit rights to the tree. I'm the person who decided to give Lars and Peter and Jeff not only commit rights to the tree, but access to the server so they to can grant commit rights to others.
My main reason for wanting to introduce a little formalism is that I think the community has grown to a point where it's not healthy to be so dependent on me. Of course I've already done that by continuing to delegate to folks like Lars etc. But we're still dependent on my dependably continuing to do so.
Regardless ... the designation of "gatekeepers" many moons ago was itself a kind of formalism, was it not?
Yes, you and Dan are both original gatekeepers but in practice I'm the person who is here every day putting in the time, so in practice decisions about such delegation fall upon my shoulders (also I'm the person in the "project manager" role) You and Dan are frequently busy with other things.
The PG model does involve some formalism, too, Roberto, though Lamar would know better than me. I do believe that they vote on new core team members, for instance, and the core team can vote to kick people off the mailing lists, to get rid of their commit rights, etc. I believe they try to work by consensus but I believe that in some circumstances votes do, in actuality, take place.
I don't think the Tcl core approach is bureaucratic. The "two yesses and no no" approach is really a way to reach decisions quickly - silence under this approach is taken to be consensus. It works well when folks are on vacation or otherwise unavailable, too.
As far as how we work, I'd personally prefer we continue to discuss things in the forums as we do now, with a private forum and private e-mail used when privacy seems necessary or perhaps even efficient ("lars: be sure to read this thread and comment" - it's OK to say that in private, isn't it?)
I'd prefer this over weekly IRC chat because my experience with the TAB hsa been that it's hard to schedule four people at one time. As you say, we have the normal OpenACS weekly chat. Perhaps our core team only meets by chat when an IRC meeting is requested, something like that. I'm not personally beholden to any particular model of communication, though, clearly core team people get to decide themselves, right?
But we do need transparency, that's clear.
But I'm not personally beholden to any particular approach to communication among a core group of folks.
I do agree with Joel that sometimes what could have easily been resolved with a vote becomes personal. I have seen, however, where the vote itself became personal (from my news.admin days of running a Usenet site). And I have seen people react very strongly to being voted down.
But I have also seen things be very civil, particularly in the PostgreSQL community (which is the community I know best). There is of course some vitriol sometimes; but it is infrequent (at least until the next discussion on 'why not GPL?' or 'Upgrading PostgreSQL hosed my database!')....
But having a simple 'this was the vote of the core team' be the end of it does have a certain finality that an informal approach cannot match. And this is a definite balancing act -- one I believe the PostgreSQL, Tcl, and AOLserver Core Teams are doing well at for their respective communities. Along these lines, to prevent it from becoming personal, I would like to see an adaptation of the Survey module be employed to take these votes, with the results being anonymous. Yes, anonymous.
Joel, Peter, and especially Don; thank you for bringing this to the community in this way. This discussion is quite fascinating, in that it elucidates what has been the operating mode for some time.
I think the forums are great for dicsussion and exchange of ideas. The problem is that too often there is no closure. When there is closure it is implicit - somebody goes off and does something, or then again, maybe not... Who exactly is doing what right now in the OpenACS project? Nobody can answer that question AFAIK.
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?
I guess there are two kinds of 'private'. Will the core team have a 'private list' so that all core members can keep up-to-date in a simple way? Then the kind you gave an example of where one member just wants to nudge another member to look at something. Maybe the comment from Lars would be done on the private list.
It might be helpful if all substantive discussion could be followed on the private list. If emails pass between a Core member and a community member, maybe the private list should be cc:d, so that when decision time comes, no time is lost trying to give the gist of how the decision was made to the other Core members.
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.
- Anybody can put stuff (name, description, links, etc) on the list
- Anybody can see the status of anything on the list
- The core team can act asynchronously on the list. This probably includes voting yes, voting no, marking stuff inappropriate (dupe, newbie question in the wrong place)
- Things that get a no vote, or don't get any attention at all, get discussed and voted on within a week or two.
- The list can be searched and browsed.