[development] Reviewing patches and making decisions -> Sociocracy could be a way to go!

Darrel O'Pry darrel.opry at gmail.com
Thu Nov 6 14:34:28 UTC 2008

On Wed, Nov 5, 2008 at 4:01 PM, Thomas Zahreddin <tz at it-arts.org> wrote:

> Hallo,
> thank you for bringing this topic up.
> Since a long time I'm unsatisfied with this process.
> (@ Dries:  this is the e-mail i announced to you in Szeged)
> > Hello,
> >
> > Having followed this thread for a while, I decided to do my bit, and
> start
> > reviewing patches. I didn't get very far ; I stopped at the first patch.
> >
> > Not because of the code - I could understand what the original code did,
> > and what the patched code did - but because there are two decisions to be
> > made :
> >
> > 1. In that case - and I guess this is not uncomon - the old behaviour
> might
> > be a bug, but it might have been by design. I have no way of telling.
> >
> (caution: Ironical!) Oh, I can't count how often i heard: "the code tells
> it
> all!" or "read my code first" or "only code counts, not the words about it"
> ..
> Yes I can read the code but the question above can not be answered by
> reading
> the code - much more helpful would be a comment what the _aim_ of some
> lines
> of code is.
> And maybe the group working on and with that particular module has a list
> of
> decisions (not a mailinglist) and why they where made - so one could go
> back
> to the original decision (should be referenced in the code) and look up
> what
> the original intention was.
> Do you agree that these information could help a lot in similar
> situaltions?

This is what proper commenting is for.  Compare the two leading lines below.

//  iterate over items and trim away any whitespace.
//  trim items, whitespace coming in as a part of user input was breaking
sorting later. see #889844
foreach($items as $i => $j) {
  $items[$i] = trim($j);

again something you can't do anything about besides trying to grok the code
and comment it or ask the original developer.

> 2. Changing the old behaviour to the new one could break old modules that
> > implicitely relied on the old behaviour. Again, this is probably not
> > uncomon. How do I weight the importance of the patch vs stability of old
> > modules ?
> IMHO persons, interested in a module (like programmers and users of this or
> a
> compatible module), shall have the possiblity to be heard with their
> requirements. It is up to the maintainer (or moderater) to listen to all
> and
> their arguments what is urgent and /or important and to come up with
> suggestions to which most (if not all) people can agree. The final decision
> is
> up to the maintainer (keeping in mind the long term goals, all persons
> interested in the module and the available resources) in cooperation with
> the
> person willing to contribute (e.g. code).
> If the group of persons working on a module keeps a logbook about their
> decisions, then everybody is able to follow the decisions regarding a
> modul.
> A short description of this method of dynamic selfgovernance can be found
> on
> http://en.wikipedia.org/wiki/Sociocracy
> or as free pdf
> http://www.governancealive.com/Links/The_Creative_Forces_of_Self_Organization.pdf
> A longer description is in
> Buck, John and Sharon Villines (2007). We the People: Consenting to a
> Deeper
> Democracy, A Guide to Sociocratic Principles and Methods. Sociocracy.info
> Press. ISBN 978-0-9792827-0-6.

Maintainers are already pressed for time... at least in contrib, I seriously
doubt you will convince maintainers to keep such a list separate from inline

> So what do I do next ? I don't have a sufficient overview of that part of
> > Drupal to make such decisions myself. Should I mark it as reviewed, and
> add
> > as a note what the potential implications are ? Or is there another
> process
> > to follow in such situations ?
> I agree absoluty: We do not have approriate structures in the drupal
> community
> to work efficently, make decissions traceable, keeping the teamspirit up
> and
> stay open for new developers to join.
> I'm aware of: there are ca. one million notes on drupal.org, some IRC-
> channels, conferences, groups.drupal.org, mailinglists like this one, a
> CVS-
> Repository ...
> - but you can imagin alone by this list how hard it is to follow all
> relevant
> information / decissions.
> So I suggest to read a little about Sociocracy and start discussing our
> decision making process.

IMHO: too much overhead , too few concrete suggestions, something that will
get talked about a lot and nothing will come of it.

google + api.drupal.org + inline comments + test cases  should provide
sufficient information to make most of your decisions. Nothing can replace a
solid understanding of the code you're reviewing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081106/6e259dc3/attachment.htm 

More information about the development mailing list