[...] Totally agree with your analysis but not with the conclusion that creating documentation of duplicate module's differences is a feasible way out. Especially, all problems tied to the fact that there's an individual person who has sole sovereignty over a certain part of the code - ain't tackled a bit. If the maintainer is 'malfunct' (in some way or the other), 'his' module is doomed, even though it's licensed as FOSS. Only way of circumventing the problem is forking - something the Drupal project really, really does not need more of (quite the contrary!).
Instead, IMHO, the responsibility for contrib code development should move from indiviual people to the collective, i.e. every svn ... uuhm cvs account holder should have commit access to all code. Sounds unmanageable at first but seems to work out very well, f.e. with the KDE project. It's kind of like the shared space 'urban design concept' (http://en.wikipedia.org/wiki/Shared_space) - a lack of strict regulation means individuals have to care a lot more about their interaction with other participants. This way communication _and cooperation_ actually become obligatory to making decisions - consequently a more swarmwork-oriented style of interaction evolves. (..and in contrast to real world shared space traffic, in the rare cases where this process fails and b$ code changes indeed are committed, it's very easy to roll back and rework.) So imho Drupal contrib repository should be freed from only-maintainer-writable-restriction to accessible-for-all-devs. The new way of avoiding bogus code commits is not to prohibit developers (who might be perfectly qualified for the task at hand) from changing certain code, but by giving more clearance to everybody. With more power comes more responsibility of course: covert, disagreed code changes are only prevented by social mechanisms, not repository access rights. To reiterate: this process works perfectly well for KDE: although i have only done some tiny commits here and there, my SVN account is not limited! Nothing there to prevent me from committing havoc to core kdelibs code straight away, right now... Still - it never happens! Proceeding from there, the pitiful situation of duplicate modules with overlapping functionality could be entirely prevented for D7 by - identifying with which functionality this has happened in the past - collecting ideas for frameworks (such as messaging, search functionality, shopping cart, payment, web questionaires, workflows, file handling - oh wait that one's cared for already) or spotting existing ones most fit to do the job in D7 - implement frameworks with focus on modularity, customizability - port functionality from existing modules to these new interfaces - raise the bar on adding new 'isolated' modules The switch to D7 is also a good time to introduce these workflow changes, because with the major API restructuring it has seen, most modules will have to change substantially anyways (and be it just to comply with new coding standards) to be in line with HEAD - a good time for converging, tidying up and trashing cruft code constructs from contrib. Earlier this year i already tried to win some support for this idea (admittedly a bit differently in form) but for all reasons, failed miserably. Bytes are cheap though so SCNR to bring it up again. BTW, using the drupalfr.org GIT mirror for D7 and the infamious tig CLI interface makes the repo really much more friendly to manage - is D7 still not the time to move to a 21st century source control system? regards, marcel. > Differences occur because > - development happened in a similar time frame. > - developers do not play well with each other. > - developer B has contempt for developer A's code > - and is not courteous in discussions of said codes weakness so does > their own project. > - modules seem the same but use wildly differing methods to achieve > their results. > > > The problem with the 'have the doc team do it' pretends we have > assigned people that will magically carry this out. > - They will install various modules on clean test sites. > - They will have use cases which will allow the evaluation of the > modules in questions > - They assume the module contributor in question is responsive and > that duplication is the result of 'just happened' instead of hostility > between developers. > - The modules are actually similar enough in function to be accurately > compared. > - Users will magically find the module comparison page and it will be > up to date. > > Not really going to happen. > > The best long term suggestion is to have the maintainers clearly > document any differences on their project page (preferably the ones > who are second should do this by default). People (devs) who have a > need for a module and had to evaluate could submit an issue with a > request to have an updated 'difference' description added. Suggested > sample text would probably help. A module maintainer is not > necessarily willing to go download a similar module if theirs already > fills their needs. > > The ones that are not used die out as tracked on the usage page. > > I would suggest a linked article on how to evaluate a project for use > (and suggest how to get description updates) linked to the top of the > Projects page description would be more useful. > > sepeck > > > On Thu, Dec 3, 2009 at 3:36 PM, nan wich <[email protected]> wrote: > > Shai Gluskin wrote: > >> Asking the docs team to write module comparison pieces is a good thing > too > > > > NO!!! The comparison pieces should be written by the module developers > or > > one of their advanced users. > > > > > > Nancy E. Wichmann, PMP > > > > Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. > King, > > Jr. > > > > -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
