Forum OpenACS Q&A: Re: RFC: OpenACS Governance

Collapse
8: Re: RFC: OpenACS Governance (response to 1)
Posted by Peter Marklund on 04/26/03 10:26 AM

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
15: Re: RFC: OpenACS Governance (response to 8)
Posted by Oscar Bonilla on 04/26/03 05:24 PM
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
41: Re: RFC: OpenACS Governance (response to 15)
Posted by Christian Brechbuehler on 11/08/06 07:38 PM
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.