<br><br><div class="gmail_quote">On Wed, Nov 5, 2008 at 4:01 PM, Thomas Zahreddin <span dir="ltr"><<a href="mailto:tz@it-arts.org">tz@it-arts.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hallo,<br>
<br>
thank you for bringing this topic up.<br>
<br>
Since a long time I'm unsatisfied with this process.<br>
<br>
(@ Dries: this is the e-mail i announced to you in Szeged)<br>
<br>
<br>
> Hello,<br>
><br>
> Having followed this thread for a while, I decided to do my bit, and start<br>
> reviewing patches. I didn't get very far ; I stopped at the first patch.<br>
><br>
> Not because of the code - I could understand what the original code did,<br>
> and what the patched code did - but because there are two decisions to be<br>
> made :<br>
><br>
> 1. In that case - and I guess this is not uncomon - the old behaviour might<br>
> be a bug, but it might have been by design. I have no way of telling.<br>
><br>
<br>
(caution: Ironical!) Oh, I can't count how often i heard: "the code tells it<br>
all!" or "read my code first" or "only code counts, not the words about it" ..<br>
<br>
Yes I can read the code but the question above can not be answered by reading<br>
the code - much more helpful would be a comment what the _aim_ of some lines<br>
of code is.<br>
<br>
And maybe the group working on and with that particular module has a list of<br>
decisions (not a mailinglist) and why they where made - so one could go back<br>
to the original decision (should be referenced in the code) and look up what<br>
the original intention was.<br>
<br>
Do you agree that these information could help a lot in similar situaltions?</blockquote><div><br>This is what proper commenting is for. Compare the two leading lines below.<br><br>// iterate over items and trim away any whitespace.<br>
// trim items, whitespace coming in as a part of user input was breaking sorting later. see #889844<br>foreach($items as $i => $j) {<br> $items[$i] = trim($j);<br>}<br> <br>again something you can't do anything about besides trying to grok the code and comment it or ask the original developer.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> 2. Changing the old behaviour to the new one could break old modules that<br>
> implicitely relied on the old behaviour. Again, this is probably not<br>
> uncomon. How do I weight the importance of the patch vs stability of old<br>
> modules ?<br>
<br>
IMHO persons, interested in a module (like programmers and users of this or a<br>
compatible module), shall have the possiblity to be heard with their<br>
requirements. It is up to the maintainer (or moderater) to listen to all and<br>
their arguments what is urgent and /or important and to come up with<br>
suggestions to which most (if not all) people can agree. The final decision is<br>
up to the maintainer (keeping in mind the long term goals, all persons<br>
interested in the module and the available resources) in cooperation with the<br>
person willing to contribute (e.g. code).<br>
<br>
If the group of persons working on a module keeps a logbook about their<br>
decisions, then everybody is able to follow the decisions regarding a modul.<br>
<br>
A short description of this method of dynamic selfgovernance can be found on<br>
<a href="http://en.wikipedia.org/wiki/Sociocracy" target="_blank">http://en.wikipedia.org/wiki/Sociocracy</a><br>
<br>
or as free pdf<br>
<a href="http://www.governancealive.com/Links/The_Creative_Forces_of_Self_Organization.pdf" target="_blank">http://www.governancealive.com/Links/The_Creative_Forces_of_Self_Organization.pdf</a><br>
<br>
A longer description is in<br>
Buck, John and Sharon Villines (2007). We the People: Consenting to a Deeper<br>
Democracy, A Guide to Sociocratic Principles and Methods. Sociocracy.info<br>
Press. ISBN 978-0-9792827-0-6.<br>
</blockquote><div><br>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.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> So what do I do next ? I don't have a sufficient overview of that part of<br>
> Drupal to make such decisions myself. Should I mark it as reviewed, and add<br>
> as a note what the potential implications are ? Or is there another process<br>
> to follow in such situations ?<br>
<br>
I agree absoluty: We do not have approriate structures in the drupal community<br>
to work efficently, make decissions traceable, keeping the teamspirit up and<br>
stay open for new developers to join.<br>
<br>
I'm aware of: there are ca. one million notes on <a href="http://drupal.org" target="_blank">drupal.org</a>, some IRC-<br>
channels, conferences, <a href="http://groups.drupal.org" target="_blank">groups.drupal.org</a>, mailinglists like this one, a CVS-<br>
Repository ...<br>
- but you can imagin alone by this list how hard it is to follow all relevant<br>
information / decissions.<br>
<br>
So I suggest to read a little about Sociocracy and start discussing our<br>
decision making process.</blockquote><div><br>IMHO: too much overhead , too few concrete suggestions, something that will get talked about a lot and nothing will come of it. <br><br>google + <a href="http://api.drupal.org">api.drupal.org</a> + 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.<br>
<br>.darrel.<br></div></div>