On Wednesday 05 November 2008 15:01:32 Thomas Zahreddin 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?
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_Organizati on.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.
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.
http://groups.drupal.org/node/14775 The implementation of the API described in that proposal is considerably more heavy-duty than what's being talked about here, but that (will be) the beauty of the API - slim-down versions would be quite possible, too. It's a good thing that the Decisionmaking API hasn't gotten started yet, though, because I do think that there'd need to be quite a bit of discussion first about what people would actually want/use, and how to know when such a system begins to hinder more than it helps. cheers sam
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.
Best
Thomas Zahreddin cofounder of http://VoiceHero.net
Best, Anselm