Forum OpenACS Q&A: RFC: OpenACS Governance

Should education and training issues be included here? I really think so. Also, some real strong documentation guidelines need to be created as well. We have some of that in the package creation guidelines, but not for the whole of oacs. If oacs is to be succesful at a broader level, I can't stress enough how important this is. I'm saying this not only from my own experience so far with oacs, but from feedback from friends who have looked at oacs as well and all made comments about the documentation as well as the questions that keep coming up in the forums. We have some great efforts for docs ongoing, but I think setting some guidelines out is going to be necessary to streamline the whole process moving forward. What does this have to do with governance? Everything! In my experience unless good, clear guidelines are set-out "from the top", documentation efforts will rarely jell together and be consistent in the way that we (the community) need the documentation to jell and be consistent.

In this process, I think that it will be important to consider creating a "best practices" area on the site with easy access to printing and downloading of same. This should be carried out as agreed on by the "governing body" who have been working with OACS longer than probably anyone in the community and have a more intimate knowledge of the framework. This would go a long way towards helping new oacs developers get up to speed quickly and thus be able to pick up more responsibility for the community as well. As one of my professor's says - "a good example is always worth a few hundred lines of code, not to mention a few hundred less explanations to repeat..." Just my two cents worth.... 😊))

A little background for the curious ...

About three months ago Lars, Jeff, Dan and myself began talking about writing down a description of the dotLRN TAB.  Jeff came up with the documents referenced by Peter in his other thread.  Without going into great detail (I think Peter and Malte's notes may cover our Copenhagen discussion about this) we came to realize that it was time to start thinking about adding some formality to the OpenACS project at large, in particular regarding technical stuff.

We decided that the time to do this would be after OpenACS 4.6 and dotLRN 1.0 were released, and when the Copenhagen meeting was organized I proposed we have a post-conference/social meeting to discuss governance on Saturday morning.  We did, and roughly two dozen people attended (quite amazing seeing as some of us didn't get back to our hotels until 3 AM that morning!)

As I said at the meeting, "currently the organization of the OpenACS project depends on my mood when I wake up in the morning", and while that was fine when we were a very small group of implementors, it's not scalable. It's also not entirely accurate, of course, but my joking comment is accurate in that our organization is really just whatever we happen to think it is on any given day.

Among other things we seem to be attracting more and more skilled people to the project.  We've grown and are still growing.  Not only is it not clear to newcomers who the decision makers are or how decision making is done, it's not clear how a newcomer can become a leader in the community.

When reading through the documents, the Tcl TIP document seemed to fit reasonably well for technical governance.  The voting details seem a bit geeky to me and as much as possible I'd like to see our project run by consensus, but it is lightweight and the description fits in a few pages.

As Peter mentions, it's very code centric, but I personally think that getting better organized in this regard would be a very good first step for us as a group.  Getting organized  at large - in Copenhagen we discussed forming a non-profit as a possibility - is important, too, but there's no reason to hold back on talking about our tech organization while we try to figure out the rest.

One of the things I like about the Jarkarta document is that it does a good job of defining roles in the community, including non-tech roles like users.  Folks may want to peek at that.

Anyway, I do hope that Peter and Malte post their meeting notes here (anyone else who took notes is welcome to also, of course) as it was a good discussion.

In terms of the broader view of governance, obviously a much wider range of people will be involved.  It's still hard for me to see us wanting to impose political limitations on who can be part of the leadership group of the project at large.  If someone's contributing as a leader then why wouldn't we want to recognize them as a leader formally?

Of course my experience with non-profit and volunteer organizations has always been at the grass-roots level.  I left the last board I served on when the organization chose to  change the board from being composed of its most influential volunteer leaders to being a board chosen for political reasons.

Joel made an interesting post here about the problem of unresponsive core members and of getting a better influx of contributions to our toolkit. I think it's good that Joel brought this up because I think this is the key issue for us - getting more contribution and a faster progression forward.

My answer to this problem is to be inclusive, to trust people and grant commit rights liberally. For example, I have recently granted Frank Nikolajsen and Jamie Rasmussen commit rights.

With the cvs commit rights come responsibility and a greater sense of ownership and motivation.

We should maybe keep our "how to contribute" page up-to-date with tips and recommendations like the following:

• Do *not* commit new features on the 4.6 branch. 4.6.3 will be a bug-fix release. Commit on cvs head instead. CVS head should stabilize towards summer when we branch off the 5.0 release.
• Use the Bug Tracker as much as possible so that we can keep track record of changes.
• If you are committing a bug fix you need to coordinate with the package maintainer. If you are a maintainer then coordinate with any fellow maintainers.
• If you are to commit a new feature or architecture change (refactoring) you must coordinate with the OpenACS core team first. Also, such changes should have a discussion in the forums to allow for feedback from the whole community.
• If you are changing the data model you *must* provide an upgrade script and bump up the version number of the package.
• Consider any upgradability ramifications of your change. Avoid changing the contract and behaviour of Tcl procedures. If you want to build a new and clean API consider deprecating the old proc and making it invoke the new one.
• Never rush to commit something. Before committing double check with cvs diff what exactly you are committing.
• Always accompany a commit with a brief but informative comment.
• Commit one cohesive bug fix or feature change at a time. Don't put a bunch of unrelated changes into one commit.
• Before you throw out or change a piece of code that you don't fully understand, use cvs annotate and cvs log on the file to see who wrote the code and why. Consider contacting the author.
• The OpenACS cvs web and Jeff's cvs browser are useful tools in understanding what is happening with the code.
• Test your change before committing. Use the OpenACS package acs-automated-testing to test Tcl procedures and the tool Tclwebtest to test pages
• Keep code simple, adhere to conventions, and use comments liberally.
• In general, treat the code with respect, at the same time, never stop to question what you see. The code can always be improved, just make sure you change the code in a careful and systematic fashion.

Here is the message I'm talking about:

<blockquote>>>>>
</blockquote>

Forum: OpenACS Q&A
Thread: RFC: OpenACS Governance
Author: Joel Aufrecht <mailto:joel@aufrecht.org>

Neophytos,
your point about diversity and independence of any individual
organization/company is good - this is one of the key strengths of open source
software. It's exactly because of this that OpenACS is still flourishing today
which is pretty amazing if you consider that the companies that created much of
our toolkit are no longer around.

Given that Lars Pind, Don Baccus, and Jeff Davis all represent different
companies or organizations we already have some diversity. I could imagine that
those three people will start up the core team and then a couple more may be
elected in by the community. Those people are likely to come from different
companies, bee free lancers, or hobby programmers.
<<<<

Anyway, I'll be more careful now...

A key issue to understand when handing out commit rights is that the person who gets commit rights doesn't necessarily need to be very senior. Most important is that the person respects our cvs commit guidelines, understands his own level, and is humble and communicates with the community. I would rather give commit rights to a beginner programmer with all those traits than to the best programmer in the world who doesn't respect our guidelines, can't see things from others point of view and won't compromise.

So far I don't know of any evidence of substantial harm caused by giving out commit rights. On the other hand though, I can give you numerous examples of great code improvements that have not found their way into the toolkit.

As far as commit rights go ... I am going to urge us to continue to be somewhat cautious until we have more people reviewing commits (Jeff eyeballs most of them today, I eyeball a bunch of them, too, does anyone else at the moment?)

Also I want to be somewhat cautious until we have proven ourselves to be able to better test our stuff before release.  On that note I think I'd support giving *anyone* commit rights to a branch of the tree labelled "regression tests" ...

I'd like to point out that we just released 4.6.2 which has one nearly fatal bug in form handling introduced recently by one of our senior hackers (no need to name names since it could've been any of us.)  Empty but required form fields are no longer flagged, as was discovered two days ago (and fixed and will end up in the 4.6.3 release which is forthcoming.)

Rather than point fingers at the person who introduced the bug, I'd like to use this as an example of how pitiful our testing efforts still are.  Much better than they were before 4.5 (and I'd argue better than aD's on average) but no where near good enough.

We've had one case of a committer walking over other people's code to the extent that I was asked to remove their commit rights.  That was early on in the project.  The problem wasn't so much the code they contributed but rather their lack of respect for other people on the project, which was made clear by his refusal to communicate to package porters before changing the code being worked on silently, behind their back if you will.

I don't expect problems of this sort to crop up often so I don't worry about it.

But ... without a better testing process and without more people actively reviewing committed code, I feel more comfortable with newcomers going through the patch submisison process.  This *forces* review before they're applied, that's the main reason I favor it.

On the other hand ... two of the reasons we .LRN TAB folk decided we wanted to push forward on OpenACS governance was to expand the core team in a way that is explicit and recognizable by the community (and doing so should help with the "we need more eyes reviewing commits" problem), and to provide a framework for the kind of mentoring of newcomers mentioned above.

With that framework in place I'd feel a lot more comfortable  dishing out commit rights more freely.

Of course ... we have dished out commit rights quite freely on slices of the tree, and there are a considerable number of people who currently have full commit rights to the tree.

So I don't think we're talking about a black-vs-white comparision, here, simply shades of gray ...

Well, I do not agree with you Peter (not as much about who is in the board). There was a lot of controversy on the *way* the board was formed, i.e. Don posting the names and no one were allowed to question that. (I will post links to the threads if necessary to refresh your memory).

The same thing *will* happen now and I want my disagreement recorded.

<blockquote>>>>
</blockquote>
Either way. Once we have an initial core team, we will use the same procedures used by the Tcl/TK project, I quote:

"The original group of Team members was elected by the Tcl community, but the TCT now handles its own membership according to rules described here. To become a member of the Team you must be nominated by an existing member and voted on by the existing Team; you must receive 2/3 of the votes cast. If you would like to join the Tcl Core Team, you should first demonstrate your development skills and leadership by participating in development projects under the auspices of an existing team member."
<<<<

So if the initial core team (or part of it) can monopolize the vote, then they could do anything that suits them best. And how is the initial core team formed: Peter posts the names, Don approves and then includes Peter in the team -- WOW there is a core team now.

Actually, is it not true that being on the core  team could be a marketing advantage over the rest bidders for a contract? Just for the record, I want to state that I did not make *any* (as in zero) money for my work at OpenACS and my paying job has *nothing* to do with OpenACS.

Don wrote:
<blockquote>>>>
</blockquote>
And I, at least, think that any such claim is absolute bullshit.  Virtue is in the work, not in whether the work is funded or not.
<<<<

Well, again I do not agree with your point of view and that's only my humble opinion. If someone did contribute enough but he's competing with the monopolizers of the vote in the initial core team, he will not make it in no matter how much he contributes and you can quote me on that. Then, why someone contribute in OpenACS and not in some other project. If someone wanted to work for the company(ies) in a coalition that monopolizes the vote then he is better of applying for a job.

How would the clients using OpenACS feel about that -- that I cannot say. Is it not true that a possible coalition that monopolizes the vote in the core team will have a competitive advantage over the rest?

Other issues become serious then, why a possible coalition in the core team would welcome contributions for free (for say the work in a possible contract) when they could get pay for doing the same work.

I do not know the answers to these questions but they really beg for an answer.

"Criticism talks a good deal of nonsense, but even its nonsense is a useful force. It keeps the question of art before the world, insists upon its importance, and makes it always in order." --Henry James

People will either be invited or elected to the core team based on their participation in the community. They will be brought on because they've shown technical insite, leadership and a mature approach to working with others.

The first you've certainly shown. The other two you've left massive amounts to be desired with your petulant, immature behavior. You left *twice* and now you are coming back with the same bullshit that people heard, processed and responded to over a year ago. And they did it respectfully and with appreciation.

Your response was, of course, to withdraw, regardless of whether you lurked or not.

In the meantime, the community has grown a great deal and is on the brink of great success. This is due to the fact that the community ALREADY ACTS IN THE WAY YOU'RE SAYING IT DOESN'T!!!

There are at least two incidents of people getting involved *without* being funded for their work and getting important leadership roles. One is Joel Aufrecht picking up the documentation lead, the other is Jeroen van Dongen picking up the project management lead for dotWRK. Neither is being funded in this position, AFAIK, at least not from any of the TAB companies. But their work could certainly lead to money since they are doing such excellent work.

It's deeply annoying that you seem intent on bringing up this useless argument again. No one here is trying to overtake the community to dominate anyone.

If you want to make noise, stick around for a good 6 months without threats of forks or more withdrawals and then you can bring this stuff up.

Note, I'm not against criticism of the governance proposal, but I am against Neophytos' continuing this year-long troll, left over from the dotLRN governance discussion.

talli

So I'm not going to confirm or deny your hint as to his true identity.  But, no, of course it wasn't you.

As far as co-opting control of OpenACS ... what are you talking about?  Today we have a small self-selected group of people, including me (mostly me, to be honest) who decides who is and who is not part of the core implementation team.

If I wanted to keep personal control I'd just do it, maintaining the status quo.  I don't need to put up with your personal attacks in order to maintain the status quo.  It seems like I have to put up with your personal attacks in order to *broaden* the number of people involved in governance.

That seems mighty strange to me.

I'm not going to participate in another civil war like we had over .LRN last summer.  That was the worst stretch in my life since my divorce in 1988, and I have no desire to relive it.  I almost left the project back then.  You're going to have to find a different target to bomb and shoot this time because I'm going to get the hell out rather than put up with it.

I am not sure what the problem is. It is very clear that the people who have been suggested to be on a core team have, in fact, been acting as the core team. That is, these people have been contributing signifigant time and effort to improving and maintaining OpenACS.

I personally have been a member almost since OpenACS was begun. I do not feel that I should be a core member, because I do not have the time it would take. I do contribute back as much as a can to OpenACS, but I can't commit to being there when its needed.

Am I missing any other criteria that need to be considered? Technical and community leadership seem sufficient.

Neophytos,
it seems to me that there is not much point pursuing further discussion on *who* will be in the core team. The four people from the TAB will be in it and they will elect a few more people as they see fit.

I want this thread to primarily be about the processes that we are putting in place for governing the project (I wanted feedback on the Tcl/Tk document, remember...), not about relative merits of various contributors. If you really must continue the latter discussion, do it in a different thread, or even better, over email.

But since you asked, here are the items that you didn't follow through with regardless of your commitment:

* Release manager
* Migration to tDOM, which Bart picked up. Offering to do so now is too late.
* Making acs-service contract XML based

It's nice that you added code. Other people did too. And they didn't do it with as much attitude or as childishly as you demand to act.

It's quite cute that you dedicated so much of your life to the openacs. So have I. So have *many* people. And they haven't thrown as many petty fits as you have.

Don, or anyone else for that matter, doesn't need to respond to your questions because they were answered a year ago. If there are others in the community who have similar problems, then they should speak up. But they haven't. So maybe you should stop beating a dead horse and offending people?

Or maybe you should answer a question: Are you going to stick around be a responsible contributor even if this discussion doesn't go your way (which it won't)? Or will you disappear *again*?

talli

I've been a small and slow contributer to this project, I've followed it quite a bit and the past few months things have been running very well.  Does that mean it is perfect? No.  Does that mean somebody has the right to point out things that can make it better, yes.  Does it mean that anybody making a suggestion get to have his/her ever word followed? Absolutely not.

But why in the f*ck is this thread still going?

The history of OpenACS has shown that those that contribute, work, and help further the "OpenACS" cause have the oppritunity of "controlling the faith of the project".  There are quite a few people that appear to influence the direction of OpenACS and I say more power to them.

Now, having a core team and some basic "rules" to run the project is a good idea.  Having been involved with many user groups over the years, you need some "adminstration" to handle the tasks.

Don contributions to OpenACS are unquestionable, both in code and in running the project.  If Don wants to create a core team to develop the adminstrative end of the project I think he has earned the right.  Obviously people are going to question it, as they should.  That is their input to the community.  It appears the core team will be working on developing a way to add new people to the core team, indicate package maintainers, etc.

This is a good.

If they would like somebody to help who has done something simular (be it with users groups) I'd be more than willing to help out.

Now this whining about?, well I'm not exactly clear about what the whining is about, but whatever it is about is just silly.

I have an idea:

Why doesn't everybody stop having the pissing match and actually get to contributing to OpenACS, in terms of both code and the adminstravie side.

Ah, I feel better.

Just my thoughts, flame away.

I think the TIP#0 document is pretty close to something OpenACS can work with. We will have to better define how the optional packages fit into this process. Possibly with a limited openacs core, a set of official optional packages, and  a third set of contributed packages that have not been reviewed by the core team, but which are avaiable for download.

One question I have, is if a package is not part of the core openacs, such as forums, survey, wimpy-point, etc, who would approve new features? Would the package maintainer do this, or would the core team also be involved. This is probably the biggest difference between OpenACS and Tcl. In TIP#0 they mention that the core team only works on the Tcl core, which is clearly defined. Because all the packages etc are distributed from openacs.org, and there is a desire to offer a full-featured download of openacs with optional packages, I think we definitely should consider the process for optional packages that will be distributed with a full openacs release also.

The core team should probably decide for themselves how often they need to meet to coordinate the project. Maybe at least once a month, but hopefully more often.

The tcl core team has a mailing list where they conduct their dicussions. From reading the TIP it looks like only the core team can post, but the archives are public. I think this is a good idea for OpenACS also.

Peter asks, where should features/bugs be submitted. We should use the bugtracker, possibly making changes that reflect the processes of new feature approval more closely.

I've been thinking that the core implementation group would serve a gatekeeper role similar to TAB in dotLRN, in terms of being an arbiter of what goes into our supported packages bundle and what goes into contrib.  It would seem that feature negotiation would be part of that, no?

I think we would want to define some written minimal standards for what would go into our supported application package list.  Support for both DBs, documentation, package instance awareness, use of our standard CSS and navigation stuff, etc.