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!

Maybe a correction.  Is this right?

"The primary mechanism for communicating with the OpenACS Core Team is the mail alias mailto:tcl-core@lists.sourceforge.net.";

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.

talli

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?

/Lars

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.

It seems to me that an openacs-tips forums would be enough, and we could get it running very quickly.

-Roberto

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.)

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.