Home
The Toolkit for Online Communities
17516 Community Members, 0 members online, 1973 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Q&A : RFC: OpenACS Governance

Forum OpenACS Q&A: RFC: OpenACS Governance

Icon of envelope Request notifications

Collapse
Posted by Peter Marklund on

I started talking about where we are headed in terms of governance in my previous thread but I am starting this thread so that we have a separate place for governance discussions.

The document that I would like to base this discussion on is TIP #0: Tcl Core Team Basic Rules which describes the governance used in the Tcl/Tk project. I also just found a Tcl Core Team Interview where the core team talks about how they wanted to encourage contribution whilst maintaining a high quality level of the code, the strengths of Tcl (not relevent here I know...) etc.

Here are a few of the key concepts in Tcl/Tk project that I think we should consider for OpenACS:

  • Project - a feature change or a bug fix. Can also be an update to the project website (in our case openacs.org)
  • Maintainer - someone who has taken primary responsibility for a piece of the code (in the case of OpenACS probably a package). The maintainer arranges (by delegation if necessary) for bugs to be fixed in his/her area and reviews modications of others to the code.
  • Feature changes require approval by the core team. The proposer is responsible for the implementation. Before the code is committed the maintainer reviews it.
  • Bug fixes do not require approval by the core team but must be reviewed by the maintainer.

Here are a couple of questions for discussion:

  • How many members should be in the core team? It seems the Tcl core team has 15 members. It is pretty clear to me that the members of the .LRN TAB (Technical Adviosory Board) should be in the core team (Don Baccus, Jeff Davis, Lars Pind, and Dan Wickstrom). There are a number of people who have cvs commit rights who are probably candidates. There are certainly other active members in the community to consider as well. Note that in Tcl/Tk the core team members have commit rights on the whole tree and can admin the website.
  • How often should the core team meet and how are decisions communicated to the community? I think the weekly IRC meetings of the TAB seem appropriate here. Maybe the OpenACS meeting could be right before the .LRN one as there will mostly be the same people in both meetings. I think that if the core team doesn't want to publish the chat log it must have the discipline to summarize the meeting and publish it in a public place.
  • Where should projects (feature changes / bug fixes) be submitted? Probably in the Bug Tracker accompanied by any discussion necessary in the forums.

The Tcl/Tk document is very code centric and doesn't cover important topics such as road maps, visions, and marketing (areas where open source projects have traditionaly not been very strong). I'm not sure which of these should fall within the responsibilies of the core team and which should be taken care of by other groups in the OpenACS community. The .LRN project has three groups - the executive group that should do marketing/evangelizing, visions/road-map, a user group that should coordinate users needs, and a technical group (core team). I think that a user group for OpenACS would make a lot of sense and I think Caroline Meeks is interested in an initiative in that area as well.

Collapse
Posted by Randy Ferrer on

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

Collapse
Posted by Malte Sussdorff on
Hi Peter, could you post the notes you took from the governance meeting here as well. I think this was a really valuable discussion. I will submit mine hopefully later today or next week.
Collapse
Posted by Don Baccus on
Yes, it would be great to see the notes Peter and Malte took at the Copenhagen meeting.  I talked a lot but didn't write anything down :)

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.

Collapse
Posted by Neophytos Demetriou on
For those of you who wonder or are suspicious for my revived interest in participating in this community it should not be a surprise since I did say in my messages during the dotlrn governance discussion that I would be back when openacs decided to have a formal structure.

So that you won't have to hold your breath too long I'm not interested in being a member of the core group or whatever it might be called. If the people who would form the group afterwords decide that I did contribute enough in OpenACS and my work had impact on the project and would like to invite me in (as addressed in the tcl document) that is another story.

Having said that, I would like to contribute my 2 cents in this discussion. I believe that most good examples of consortiums/organizations of this form have one basic principle that I strongly believe should also be a fundamental rule for any future governance body that will be formed:

<em>No single company or a coalition of interests should be able to control the faith of the project.</em>

What I'm saying is that the governance body, *IMHO*, should be formed of a variety of people with no common interests (in the sense of funding and so on) so that the project won't shift away based on the interests of that one entity or coalition.

With all the good faith, Neophytos.

Collapse
Posted by Don Baccus on
When it comes to the core technical team, I think it's clear that the only criterion for membership will be one's technical skill and contributions to the project.  I can't see us using political criteria ("is this person funded by XYZ? Does this person own a consulting company?") in this process.

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.

Collapse
Posted by Peter Marklund on
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 good 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, be free lancers, or hobby programmers.

Collapse
Posted by Peter Marklund on

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.
Collapse
Posted by Oscar Bonilla on
Peter said:

  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.

I'd say that there needs to be a policy on how you get commit privs. Most people who contribute patches don't want/need commit privs. Most people who ask for commit privs don't do anything with them. I'd say maintainers should nominate users for commit privs. The scenario would work something like this:

1. A user goes and fixes something. He either submits a bug report, posts it on a mailng list or contacts the author of the package directly. Either way, the maintainer gets the fix.

2. The maintainer (who obviously has commit privs) commits the fix and acknowledges the user who submitted it.

3. The maintainer realizes this is the Nth fix this user has submitted and starts to get annoyed by having to review and commit all his changes.

4. The maintainer requests commit privs for the new user (after asking the user if he wants them).

5. The new user is given commit privs on the package or packages on which he's worked.

6. A "Commiter's Guide" (of which you seem to have the first draft of) is automatically mailed to the new commiter.

I'd say the maintainer who asked for commit privs for a user should act as a "mentor" for the new commiter. That way, you get a personal relationship between two developers.

I don't think liberally giving commit privs is a good idea. It can cause a lot of overhead if people liberally commit stuff they think is right but has not been properly reviewed or approved by the community at large.

Comments?

Regards,

-Oscar

Collapse
Posted by Christian Brechbuehler on
Oscar, the scenario sounds nice, but it breaks down in step 2.

Known bugs go into the bug tracker. Often patches are supplied, too. And there they rest, for months or years. The contributions don't get acknowledged -- not as much as "bad idea" or "we'll get to that later".

As Joel Aufrecht pointed out, people are active for certain periods of time. The scenario should account for that. One possible amendment: If the maintainer doesn't approve or reject a patch within X days, jump to step 5.

Collapse
Posted by Neophytos Demetriou on
>>>>
When it comes to the core technical team, I think it's clear that the only criterion for membership will be one's technical skill and contributions to the project.  I can't see us using political criteria ("is this person funded by XYZ? Does this person own a consulting company?") in this process.
<<<<

I do not agree. Having a diversity of people in the core team *is* fundamental. I'm having the feeling that I'm trying in vain here. Ever since I reappeared the only argument against my so called candidacy to the core team has been a political argument and not a technical one.

Judging from a technical point of view I did contribute much more to the core than most people in this community have. I did wrote the service contracts package which judging from its wide usage I would say that had the most impact after the aD released packages. So that I do not have to post these things here again. Here is the thread that Peter started (btw, I see that not many have claimed their packages yet):
http://openacs.org/forums/message-view?message_id=94670

As far as persons go, I did not intend to post names. But, since Peter posted names I will do as well. I do not want to suggest that these people are interested to join such a group but only my personal recognition to their contributions in the project (other than the people Peter posted about, order not important):

* Roberto Mello: He has been here forever...

* Dan Wickstrom: He has been here forever...

* Jon Griffin: He has been here as far as I remember and he also contributed more packages than anyone else (I'm talking about packages which were not derived from funded projects). He is also a security expert.

* Tom Jackson: aolserver core team member with contributions to the project, namely cronjob etc

* Dave Bauer

* Malte Sussdorff

and probably others that slip my mind. I am not trying to degrade Lars or Jeff's contributions to the project but these people have been around long before Lars and Jeff became active (IIRC) and they did contribute to the project.

Collapse
Posted by Neophytos Demetriou on
Peter, how come the message you've posted above, quoted below, is signed here in the forums with your name (Peter Marklund) and the one I got from the notifications is signed by Joel Aufrecht?

Here is the message I'm talking about:

>>>>>

Forum: OpenACS Q&A
Thread: RFC: OpenACS Governance
Author: Joel Aufrecht <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.
<<<<

Collapse
Posted by Joel Aufrecht on
Looks like a forum bug.  I clicked the Post a Message link at the top of the page when I meant to click the reply link.  So my message went to a new thread, but apparently left some sort of mark on this thread, causing notifications for the next message to go out with my name.
Collapse
Posted by Ola Hansson on
Ever since I reappeared the only argument against my so called candidacy to the core team has been a political argument and not a technical one.
Neophytos, I interpreted what you said before in this thread as saying you did *not* want to candidate. (What will it be?)


Yes, you as well as others have contributed a lot of very useful stuff and AFAICT most, if not all, community members recognize that!

You suggest a few people as candidates (which I say nothing against) and when you come to Jon Griffin you say:

Jon Griffin: He has been here as far as I remember and he also contributed more packages than anyone else (I'm talking about packages which were not derived from funded projects). He is also a security expert.
Honestly, speaking of technical arguments, what the heck has funded project or not got to do with technical skills?? Had his code been derived from funded projects (which it might), would it have made him less skilled or suitable as a candidate?

I will give you the benefit of a doubt, however ;-):

I think it *is* appropriate to distinguish between those contributions (code/documentation/administration, etc.) that have been funded and those that have been strictly voluntary.

That is important from the point of view of gratitude. In a funded project the funder is the one to feel grateful toward. And in a "non-funded" project it is actually the volunteering developer who's "funding" it ...

However, the _source_ of funding says nothing about technical skills of the developer.

In one of our central package listings we might consider stating who the volunteer is, or, if it's a funded project, who funded it _and_ who implemented it. That way both the funder and the developer get credit...

Just my two cents.

Collapse
Posted by Peter Marklund on
Ola and Neophytos,
let's avoid a heated discussion with speculation on who should and should not be in the core team.

I don't think there was any controversy about Lars Pind, Jeff Davis, Don Baccus, and Dan Wickstrom being in the TAB for .LRN, and hardly anyone would object to these people being in the core team for OpenACS.

In the interest of being able to form the initial core team quickly I propose that this group of four TAB people will be the initial members.

Alternatively, and this would be fine too, we can make a community vote. If someone proposes a vote though, that person shall also take on full responsibility for administering the vote and for making sure that the vote is reliable and perfectly transparent. We want the voting results soon (1-2 weeks). An issue with voting is to determine who is allowed to vote. Anybody registered on OpenACS.org? Regardless of activity and contribution? I'm not convinced this is guaranteed to yield a better result. For reliablity we would have to check every single vote individually for validity.

It's like a catch-22 situation - you can't make a decision before you have a deciding body, and you can't have a deciding body before you decide on one. Even though we don't formally have a deciding body though, informally we already do, and it's essentially the four people that I have mentioned.

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

Collapse
Posted by Peter Marklund on
Concerning me posting previously as Joel (two posts in different threads) I truly apologize about that mistake. It has happened before - at the social I posted as Don :-) When I realized my mistake I updated the user_id for the forums messages in the openacs.org database but I didn't take care of the notifications (don't know how quickly they go out).

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

Collapse
Posted by Peter Marklund on
Oscar, I agree with the spirit of what you are saying and the process that you are laying out. I also like your idea about mentorship a lot.

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.

Collapse
Posted by Don Baccus on
Much of Jon's work has been funded, Neophytos.  Just because you're not aware of this doesn't mean it's not true.

If this becomes a pissing contest over the comparative virtues of those who have gotten paid for some of their work versus those who haven't, I'm out of here.  I'm serious.  Life is too short to put up with bullshit of this sort.

As I said earlier I left my last non-profit board position when the organization decided to judge merit based on political criteria rather than  one's contribution to the organization.

I've given up nearly all of my volunteer efforts in conservation in order to have time to volunteer for the OpenACS project over the last three or so years.  I could easily give up volunteering for the OpenACS project and go back to volunteering as a conservation biologist for goals which are arguably more important than the writing of a piece of software.

As far as unpaid contributions to the community, I think I can safely state that no current active member of the community has come even close to putting in the amount of unpaid time that Dan Wickstrom, Roberto Mello and myself have put in (I don't include Ben only because he's chosen to drop out of the community).

So if anyone has the right to claim that unpaid contributions are somehow more virtuous than contributions that are funded, I'd say it's the three of us.

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.

Collapse
Posted by Don Baccus on
Peter, you're going to be stuck being on the core team, I'm afraid, why do you think I asked you to start this discussion during our meeting in Copenhagen? :)

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

Collapse
Posted by Neophytos Demetriou on
>>>>

_ Ever since I reappeared the only argument against my so called candidacy to the core team has been a political argument and not a technical one. _

Neophytos, I interpreted what you said before in this thread as saying you did *not* want to candidate. (What will it be?)

<<<<

Ola, my first message was clear enough. I'm not fancying any position on this board unless I were invited in after the board is formed. Note that I said "so called" -- in another thread one claimed that eventhough my contributions are great that the community should be careful because there was an ongoing governance debate.

Replies to the rest follow.

Collapse
Posted by Neophytos Demetriou on
>>>>
I don't think there was any controversy about Lars Pind, Jeff Davis, Don Baccus, and Dan Wickstrom being in the TAB for .LRN, and hardly anyone would object to these people being in the core team for OpenACS.
<<<<

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.

Collapse
Posted by Neophytos Demetriou on
Joel wrote:
>>>>
Looks like a forum bug.  I clicked the Post a Message link at the top of the page when I meant to click the reply link.  So my message went to a new thread, but apparently left some sort of mark on this thread, causing notifications for the next message to go out with my name.
<<<<

Come on :)

Peter wrote:
>>>>
Concerning me posting previously as Joel (two posts in different threads) I truly apologize about that mistake. It has happened before - at the social I posted as Don :-) When I realized my mistake I updated the user_id for the forums messages in the openacs.org database but I didn't take care of the notifications (don't know how quickly they go out).
<<<<

Peter, I'm not sure I understood your explanation. Do you say that you have posted as Joel, then realized your mistake, then connected to the database and manually changed the user_id in the forum messages table but not the notifications table? And that, then you did the same mistake again and followed the procedure for the "Using tDOM instead of ns_xml" thread?

Collapse
Posted by Neophytos Demetriou on
I'm quoting Peter, who quoted the Tcl/TK project guidelines:

>>>>
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:
>>>>
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

Collapse
Posted by Talli Somekh on
Neophytos, I have no idea what the hell you are talking about.

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

Collapse
Posted by Neophytos Demetriou on
>>>>
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.
<<<<

Just to make it clear that this person was not me but someone whose name start with "Dom......".

Collapse
Posted by Neophytos Demetriou on
Talli, that certainly qualifies for a flame war but I'm not participating in it. No need to insult if you have run out of arguments. Today is the biggest holiday for our religion but I'll get back to the replies when I come back from church this evening (after midnight).
Collapse
Posted by Don Baccus on
Neophytos, I in no way implied that you were the person who walked over other people's code.  Could you try to lower your paranoia to a level consistent with reality?  I saw no reason to mention the person by name, he's no longer part of the community but what would be the point in posting a potentially embarassing comment about him here?  Someone might look his name up in Google and find the post, after all.

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.

Collapse
Posted by Neophytos Demetriou on
>>>>
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.
<<<<

Don, no personal attacks. I honestly tell you so. But, unless we discuss as we do now, unresolvable differences will remain like a shadow over the project.

OTOH, to accuse me (not necessarily you) that by posting my criticism/concerns I'm looking into serving a ultimate goal that is paranoia.

Anybody, find me a motive for posting here my criticism other than that I have contributed three years of my life in this project and I want to have a say when things don't seem right to me and then but only then judge me guilty. Yes, I do not like it when I have volunteered three years of my life in a project and did some great work (which anybody can confirm reading the forums here) and someone comes along and tries to tell me to keep quite one way or another.

Collapse
Posted by Dave Bauer on
Neophytos,

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.

Collapse
Posted by Don Baccus on
I do not like it when I have volunteered three years of my life in a project and did some great work (which anybody can confirm reading the forums here)
Sorry, Neophytos, but you've not contributed for three years. You have, as Talli correctly points out, left the project in anger twice during that period of time, each time after having made commitments to complete work which you failed to follow through on. In terms of actual work you've put in perhaps a year.

You've also been a divisive force, accusing me and others repeatedly of somehow trying to monopolize the project for our personal gain. I'm tired of it, and won't put up with it. The facts don't back up your claims.

The project has been really great these past few months. People have been getting along. People have been stepping forward, volunteering to take on leadership roles and following through (look at the role Peter's taking on by starting this thread.) New blood's been coming into the project. A lot of great work's been done on the code itself.

And now, out of the blue, here comes Neophytos tossing bombs and grenades into the our peaceful and productive community.

I respectively ask you to knock it off.

Collapse
Posted by Peter Marklund on
With all due respect for the personal discussion that has ensued here and the feelings involved I would kindly like to ask people to stay on topic and be brief and constructive.

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.

Collapse
Posted by Neophytos Demetriou on
I cannot leave ambiguities unanswered:

>>>>
Sorry, Neophytos, but you've not contributed for three years.
<<<<

Maybe dedicated would have been a more proper word. I apologize for not clarifying it more for you. Still, did I not wrote acs-service-contract, search, openfts-driver, ported acs-workflow 4.3 to postgresql (one of the biggest packages in the repository) and work on bringing up any ramifications to speed, applied patch fixes, etc?

>>>>
You have, as Talli correctly points out, left the project in anger twice during that period of time, each time after having made commitments to complete work which you failed to follow through on. In terms of actual work you've put in perhaps a year.
<<<<

What commitments and why I left? I'm sure you do not have much to say about the first time I decided to withdraw from the team rather than confronting the crowds like I do now. What commitments did I leave behind the second time around? The release manager position, hah, and then having to put up with people who were practically insulting me like you do now.

>>>>
You've also been a divisive force, accusing me and others repeatedly of somehow trying to monopolize the project for our personal gain. I'm tired of it, and won't put up with it. The facts don't back up your claims.
<<<<

Who did I divide? Back up your claims. Was it me that Ben Adida had "unresolving differences" when he left? For the curious I was not around when Ben left as it has perfectly been addressed here today.

>>>>
A lot of great work's been done on the code itself.
<<<<

Did I say otherwise?

>>>>
And now, out of the blue, here comes Neophytos tossing bombs and grenades into the our peaceful and productive community.
<<<<

It was clear that I did not agree with your agenda, sorry my mistake that I withdraw so that I would not have to accept the very things I disagreed with. How did that harm the project (I mean by withdrawing)? We were supposed to have the OpenACS governance discussion in September, why are we having it now?

>>>>
I respectively ask you to knock it off.
<<<<

I respectively ask you not to provoke me and then I *will* knock it off.

Finally, how do your postings answer to the criticism/questions I have posted above? And still, I provoke you to post what motive I have for posting here other than that I contributed to this project and I want to have a say when things seem so wrong to me (Dave this is what my problem is). I have clearly stated that I'm not interested in a position for a board. I started  posting on the package inventory thread quite peacefully and only answered when I was provoked. The questions are there either you like it or not.

Collapse
Posted by Talli Somekh on
Neophytos, no one even mentioned you and the board in the same breathe. Except for you, of course.

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

Collapse
Posted by Neophytos Demetriou on
Talli, I won't bother with your flame fest but I want to post the following that you said from the chat logs two days ago.

Talli wrote:
>>>>
Neophytos, no one even mentioned you and the board in the same breathe. Except for you, of course.
<<<<

Talli also wrote (in the chat logs):
"i'm all for getting him [Neophytos] back in the community and letting him maintain whatever he wants "

Collapse
Posted by Mat Kovach on
Okay, maybe I'm a bit slow (and that may well be an understatement) but I'm failing to see the point of this continuing discussion.  The notifications seem to be filling up my inbox, but basically what the heck is this all about?

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.

Collapse
Posted by Talli Somekh on
ahem. the next line i said was.

<talli> as long as we're sure he understands no taking off

you still haven't set yourself up as anything but a troll on this issue, Neophytos.

Collapse
Posted by Don Baccus on
Just in case it's not clear from my original post, most of my motivation for wanting to formalize governance of the project is to continue down a path I've been pushing for some time now: I want the project to be less dependent on me.

My request to chair a meeting about governance in Copenhagen wasn't about my increasing my own role in the project, quite the opposite.  I don't want to manage this project the rest of my life, I want other people to step up and help out and at some point I might want to fade off and do nothing more than introduce creative new bugs into the code from time-to-time :)  I want new people to see just how they can become part of the leadership team.  I want transparency and visibility.  I want people who act like leaders (such as Peter, who's been acting more and more like a leader with every passing day) to be recognized as leaders in an unambiguous way.  I like the notion of a committee of peers including folks like Jeff and Lars and Roberto and Dan and others who the community recognizes as being key tech members taking responsibility in a visible and explicit way.  We've done this in a de facto way all along but it shouldn't be simply a matter of whim on the part of myself and a handful of others.

So the personal attacks are not only distracting, but absolutely mischaracterize my motives.

Mat - the best way to help out is to review the TIP doc and to think about how it fits into our project, and equally important how it doesn't fit.  Our project is less monolithic then Tcl/Tk(we have the core, and lots of supported packages which can be managed somewhat independently yet we need implementation standards and coordination, etc.)  How does this impact the kind of governance process we should adapt - or does it at all?

Or if you are aware of another governance approach that's documented that you think would work better ... propose it, and we'll all take a look at it.

Those are the kind of questions we should be discussing here.

Collapse
Posted by Dave Bauer on
Responding to Peter's original request for comments:

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.

Collapse
Posted by Dave Bauer on
I forgot, I also think the TYTYANNOTT: Two Yesses And No No's Or Two Thirds concept is good, possibly to be adapted to OpenACS in some way
Collapse
Posted by Don Baccus on
Dave, your comments about core vs. supported application packages is touching on the point I was trying to raise.  This  is where, as you point out, the more monolithic Tcl project and OpenACS part ground.

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.

Collapse
Posted by Neophytos Demetriou on
I'm still here posting, am I not? I'm here unconditionally. End of story.