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

[Darrel O'Pry]

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

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

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