Forum OpenACS Q&A: Drafting the Core Team Governance Document
I've uploaded a draft of the core team document. The document is an edited copy of the Tcl/Tk Core Team Rules document and still needs quite a bit of corrections and additions. I'm a little swamped with work right now and if anybody is interested in helping shape this document up - let me know!Thanks!
Maybe a correction. Is this right?
"The primary mechanism for communicating with the OpenACS Core Team is the mail alias mailto:email@example.com.";
Where should the nuts-and-bolts details go? In the doc, or an appendix, or elsewhere? I mean things like:
Where is the list of pending TIPs?
What is the minimum amount of detail for a valid TIP?
Where is the permanent record of how each TIP was addressed?
How can we tell if a TIP got TYANN?
I guess for TCL this is all in the mailing list? We discussed creating a special bug category for TIPS and keeping them on OpenACS.org. Thoughts?
Where is the list of core members published?
How are membership changes initiated? Through the same TIP process?
What Core Team discussions should be kept private?
Should everything else necessarily be public?
What response time is expected from Core Team members? weekly? monthly?
While I think that having a core geek team is important, I don't think that it's the most critical governance issue facing the community. The reason is that I no longer think that we are "just" a geek community, as the OACS has been up until very recently. Indulge me a moment to make a very generalized explanation.
While aD existed, the OACS community generally consisted of a bunch of volunteers and then small companies who wanted to serve clients that were not necessarily "enterprise class" or "fortune 1000". This was great since we could generally feed off 38M dollars of VC investment and harangue aD for not paying attention to us.
The sites and clients that were using the OACS at that time were relatively small organizations who could be insulated from the geek community by the consultants that they had hired. They had made a commitment to the platform, but not explicitly. That is, they didn't have the bandwidth to participate in the growth and improvement of the community themselves. They left that to their consultant.
Once aD left, those clients who were still committed to ACS Tcl and were considerable institutions joined the OpenACS and have taken a far greater interest in the flourishing of the OpenACS community so that their investment doesn't go the way of aD.
The prime example is, of course, the involvement of Al Essa from Sloan and Carl Blesius and Michael Hebgen of Uni-HD. Neither of these guys are coders, but they are very important decision makers who have joined the community because of their investment. They may be geeks, but not hacker geeks.
There are many other examples of course. Greenpeace, the World Bank, Siemens, Bertelsmann, Delphi Capital, Praesagus are just some of the multi-million dollar organizations that are following the community intently because of deep investments in the OpenACS platform. (I'll try to organize types of constituents and examples of community members below.)
This is not to say that such orgs are not involved in the Tcl community as well, but these orgs are far closer to the end-user. In order to be a Tcl community member, you pretty much have to be a hacker. No end-user who doesn't at least know HTML will care how to fix a threading bug.
An end-user in the OpenACS community, however, can easily participate by pushing for improvements in the way that business logic is developed or the flexibility in adding content to a system. Michael Feldstein has historically been this voice, and Danielle Hickie is getting involved now in the CMS discussions.
As a result, I would like to advocate that we take a further step back and discuss how we can build a governance model that addresses the following issues:
- Real community leadership Communities naturally consist of many different kinds of people with different talents and perspectives. We need to figure out a way to get all sorts of constituencies involved and take leadership roles.
- Total (or as much as humanly possible) transparency I loathe the idea of non-transparent governance (private lists, private chats, etc) I think we would be begging for a fork someday. So far we've been lucky, but we have had our famous problems in the past. One need only look as far as the Gentoo project to see how scaleable a nontransparent community is.
- Promoting participation and new leadership Providing fairly simple and straightforward paths for new people (hacker geeks, non-hacker geeks and losers like talli) to take leadership roles in the community (although we might want to ban losers like talli)
- More beer!
I really think that these issues need to be addressed before defining a technical governance structure that could become the de facto decision governance organization.
This may be a bit hyperbolic, but I sort of feel that a technical governance structure would sort of be like setting up a provisional military government during a transition to civilian rule of law. Sounds like a great idea, but those provisional organizations have a nasty habit of sticking around for a long time.
I should not, of course, that I am not a hacker so I naturally have a different perspective.
This note is already too long, so I'll stop here and post some more thoughts later.
Recently some disillusioned developers from the Gentoo Linux project, a Linux distribution, forked the project due to a lack of transparency in the way the leader of the Gentoo project behaved. The result was a new distribution called Zynot Linux.
The reasons for the fork are very severe, and I do not suggest that anyone currently in the community is behaving in these ways. But I think it is very instructive in how a community can eat itself, so I strongly recommend those with opinions about the governance discussion take a look at this document:
This is, of course, written from one person's perspective. The fact that this perspective was shared by enough other developers, though, to fork a rather large and popular Linux distribution is quite telling.
Note: I'm not involved in the Gentoo community besides lurking the forums now and again. I don't have an opinion on this event besides curiosity in the potential lesson for the OpenACS and other communities.
Thanks for reopening this topic. It's a shame that it withered and died, like so many other threads.
I totally agree that we need to broaden the community leadership to not just geeks. In fact, I'm in complete alignment with all 4 of your stated goals for the governance model.
Now, how can we get something up and running, which is light-weight, working, and alive?
How do we bootstrap it?
An expert hierarchy is needed to meet technical considerations, constraints etc.
External/end-user input is needed to help guide the "value" usefulness/applicability etc to those that the toolbox eventually serves --realizing that developer bias is already built into the expert hierarchy.
Since you mentioned bootstrapping .... We don't have a transparent, consistent, timely decision-making process for OpenACS. That's the basic tool the community needs to address everything else - all of Talli's issues about broader, non-geek involvement and Torben's points about decision making. If there's no focal point for decision-making, everything else fails because people try to participate but have no consistent, reliable mechanism to do so.
We have a core team. We have an "approved-by-nobody-screaming" proposal to using the TCL group's TIP process as our basic decision-making system. So why aren't we already using our own TIP process? They do TIPs on a mailing list. I think we would be better suited with a web-based system, and it could be just a dedicated forum for now and a fancier package now. It needs the following special rules (enforced by technology and moderation) to function:
- The first message of a thread is a full TIP. The title has the tip number, "Proposed", and short description:
"TIP #1 (Proposed): Use packagename/public-resources for non-permission-checked files"
- Thread followups must directly address the TIP
- Approval and Disapproval votes from the Core Team must be clearly marked - the reply title must start with "Approved by XX" or "Disapproved by XX".
- Once we have a final status for a TIP, the original title is edited to reflect that.
"Tip #1 (Approved): Use packagename/public-resources for non-permission-checked files"
- All core team members must subscribe to the forum.
- If a new TIP gets two Approval votes and no Disapproval votes in the first (1 week?), it's Approved. If it gets at least one Disapproval vote, the original poster has to summarize objections and call for a full vote; the TIP then has (2 more weeks?) to accumulate 2/3 Approval of new votes cast (not counting the votes prior to the call for full vote) or else it's Disapproved.
#1 after a decision is made, close the thread. I think forums already supports this. If not, we'll do that later :)
#2 After decsion, a ticket is entered into bugtracker assigned to the party responsible.
It seems to me that an openacs-tips forums would be enough, and we could get it running very quickly.
Using the forum has exposed two problems, one with the medium and one with the process. (And if people see other problems, and they're not Talli, please chime in.) The first problem is that we get off-topic discussions. Perhaps our next system can differentiate between discussion by the OCT and discussion by everybody else.
Second, if a TIP is not perfect the first time, there is no efficient mechanism for tweaking it - we can only withdraw the TIP and start over. Debian addresses this by having amendments - a Debian voter can approve the original item and each amendment independently. They also make "further discussion" an option at every point. So we should maybe flesh that out for our system. (They also have quorums and super-majorities, which I think are more appropriate for large electoral pools than for 9-person teams.)
- opinion seeking
- opinion giving
- information seeking
- information giving
- consensus testing How well are we doing with the current process? Where there are problems, we should try to make the desired activity technically easy.
Initiating is currently iffy. It's open, because anybody can post. But it's not well-advertised, which may be fine because it self-qualifies the initiators. It's not easy to do well because we don't have a template for a good TIP.
Opinion-seeking - has historically been a problem - there are many unanswered forum questions. I think a few TIPs represent premature opinion-seeking.
opinion-giving seems to be happening fairly well - in particular, we have a pretty high signal-to-noise ratio.
information seeking and giving?
Clarifying. Even though the responses represent clarification, we're not getting a filtering because there's no way to condense the responses into a single right answer - you have to read everything and process it. So we do most of the work of clarifying and then sort of drop it. The original TIP rules call for the proposer to summarize the objections after a veto, which we haven't really done. We need to make this easier - ie, whoever is supposed to write a summary needs to know, needs to see what a good summary looks like; the summary needs to be prominent.
Elaborating, summarizing - same remarks as for clarifying
Consensus testing. I think the forum makes this hard, because: it's asynchronous, so someone can agree with a point while someone else is abandoning it or misunderstanding it. Conversations can get too prolonged. The collective opinion of the group of decision-makers is too hard to see. We also have the problem that we have no real means to test the consensus of any broader body than the OCT.
Initiating: My idea would be to use Wimpy Point or ETP for publishing a TIP. As we require (or should) a sponsor of a TIP, it would be fine to limit posting rights only to OCT members.
Opinion Seeking: The newly created TIP is posted in the TIP forum to open up discussion. It is highly recommended, that the initiator and sponsor of the TIP think about discussing a topic *first* on the normal forums before using the TIP one. This should solidify the opinions a little bit *before* makeing it a TIP
Clarifications: The proposer and the sponsor should collect all clarifications in a timely manner and put them up as comments to the original TIP.
Modifications: Modifications to the TIP may happen any time. The moment a TIP has been modified, all approvals or vetoes are nullified (for obvious reason) and the voting starts again (as does the period of one week).
Change of opinion: Any OCT member has the right to change his/her mind during the grace period of one week. The latest vote is the one that will be counted.
Though I agree with Tom, that it should be enough to have six approvals to approve a TIP, we should keep the one week grace period in any case, to allow others to look at the TIP as well and maybe come up with some hidden problems the approvers where not aware of at the time of approval. Furthermore, it prohibits the feeling that the group of OCT members is an exclusive bunch of people making decisions without listening to others opinions. And I don't think, any TIP is so urgent as not to be able to wait one week for implementation.