[development] Duplicated modules
tz at it-arts.org
Wed Mar 11 00:23:15 UTC 2009
You asked for a suggestion, here are my thoughts:
Am Dienstag, den 10.03.2009, 15:14 -0700 schrieb Karoly Negyesi:
> OK all you wiseasses, now you pissed me off enough to bring these
> issues into wider public, so tell me what to do in these situations.
> 1) There is a Drupal module, older than my boots, gets a much needed
> rewrite by two guys. Comes a third one, and he is, of course, welcome
> to the party. There is a discussion of what we do and what we not to
> do. Come next day, said third guy does what we all three agreed not
> do. Following a debate, he packs his toys and starts a new project.
> Said third guy contributes heavily to Drupal project for extremely
> long but quality and quantity does not always correlate.
So what can we learn form this (and many other stories)?
My answer to all three examples:
we need a better way to make decisions, since this sounds like the third
one does not agree in the end and to lay the responsibility in the hand
of teams: team members should not only be developers of the module, also
developers interested in cooperating / interacting (e.g. via an API)
with this module and _users_ of this module and maybe developers of
drupal core (since this is also a 'module' that will interact with a
contrib module). I want to call this circle decision board.
These boards / circles follow the principles of decisioning by
sociocracy (no crazy people - a practical approach for some European
companies) feel free to ask for more details and / or check
Means e.g. all decisions are made in consent. Means in difference to
consensus: although I'm not very happy with a decision, I'm able to
agree, because the decision supports the goals of the community as a
whole and the goals of my circle.
Each decision is monitored after a period the circle sets (e.g. one
year, with next release ...)
Each team member (or interested party) can bring up new arguments (e.g.
bugs, performance measurements ..) and can ask to decide again over this
topic - which can be rejected or accepted - the team decides over it's
own topics autonomous.
There shall be a hierarchy (!sic) of circles, with drupal core at the
top and the 'right' to set the principles for the community as a whole.
All circles are interconnected through members, all teams keep public
logbooks with their decisions...(and so on).
The system of sociocracy ensures, that all voices will be heard,
decisions are made based on facts and arguments, also all decisions are
evaluated on a regular basis. So if some 'bugs' show up, there is the
possibility to fix them.
Sociocracy can only be taken as a algorithm, which was invented long
before the times of the Internet and open source communities - so if we
would want to use it for the drupal community is will be necessary to
adopt it to our needs and ability to use the technology.
To all: So please don't start a flame war why it would not work, I'm
aware of some obsolete aspects of this model – because it was not
invented for the drupal community.
Can you imagen such a system for the drupal community?
I know from using it, that it works. Central is all participants agree
to the goals of the community and are willing to (at least) test the
And in my opinion the groups.drupal.org are a step in this direction –
but the groups lag (at least) of clear decisioning, a logbook of all
decisions and the evaluation of all decisions.
So I ask who is willing to join a group to discuss the principles of
decisioning and to test the model of sociocracy in this group?
> 2) I hand off privatemsg to another maintainer. He wants to go in a
> direction which neither me nor someone else even higher in the Drupal
> hierarchy agrees with. We all three come to a happy conclusion and the
> new maintainer does not go there. Time passes, and another guy,
> notorious for starting a parallel project, does exactly the thing we
> agreed on not to do and despite he says it was just experiment with
> the new Drupal 6 code, the project lives on.
> PS. the project moderation queue would undo Drupal because people
> would take their not-accepted projects off site. php nuke follows.
> PS2. 'mob rule' applied to code does not work. Your precious
> drupalmodules.com which I opposed from day one is an excellent
> example. captcha rated #2 , cck and views not even in #10, give me a
> break, this is broken,.
More information about the development