I've actually read the book--and the same point made in other parts of the thread--and I still think that there is something to be said for making someone who wants to start a new module spend the 20 minutes searching for prior art and explaining why their work is different. Far better for the developer to do it once since they understand exactly what their code does (or they hope it will do), and as a result of the process have a block of text for the project description explaining its purpose. That will save everyone evaulating the module the time of duplicating that research. I support better d.o filtering but I think the best use of that would be directed at module developers who may not be aware of existing projects. I know that I've spent quite a bit of time on projects only to start discussing it on IRC and have someone point me to a finished version of my project. Fortuneatly I didn't post my module, end up with duplication and have to decide if I should keep supporting it or try to migrate everyone over to the other module. I think it's a small, one time, price to pay before unleashing your code on the community. andrew On Mon, Mar 9, 2009 at 9:39 PM, Greg Holsclaw <greg@t2media.com> wrote:
In some good Web2.0 books like Here Comes Everybody: The Power of Organizing Without Organizations (by Clay Shirky, with some open source books also to his name) and others, the concept of Publish then Filter is a main tenant of Open Source and general Internet publishing in general. The old days of print media where 'the professionals' had to filter because all the day's info just couldn't fit into the printed pages of a newspaper are gone.
The whole idea of open source is someone started doing something and put it out there for people to look at.
The main point now is the 'Filter' and publication. Discovering good modules is hard, which is why findability is part of the Drupal.org redesign. I think the effort should be there. Let download counts, peer review and recommendation lists be the filter, not a review prior to publishing a new project.
Publish then Filter, not the other way around.
-Greg
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of andrew morton Sent: Monday, March 09, 2009 6:30 PM To: development@drupal.org Subject: Re: [development] Wasting time and effort
Daniel's proposal to moderate the creation of project nodes is really the only suggestion that I've found compelling in this thread. Having a checkpoint that requires a maintainer to list other similar modules and explain how their module is different from other existing ones would be very helpful.
andrew
On Mon, Mar 9, 2009 at 2:15 PM, Daniel F. Kudwien <news@unleashedmind.com> wrote:
One point of his proposal is valid though: We could do better in preventing duplicated modules and efforts.
We have
- CVS sandboxes for experimental code. (I'd argue that almost no one knows about sandboxes and how to use them)
- Official projects on drupal.org. (With complete release, issue, and versioning systems)
- No "moderation" for new project nodes. (Anyone with a CVS account is able to create anything)
Question:
Would it really hurt the process of evolution and innovation in Drupal when a new project ("request") would go into a "new projects queue" first, where all community members could do a quick review and optionally point to a possible existing project that could benefit from additional man-power, features, and stuff?
Would such a process not even do the opposite - speeding up evolution (by not duplicating efforts)?
I mean, as a developer, I can review a module's code to find out which module is sane to use. Regular Drupal users cannot - they have to blindly choose one of the modules. Whether developer or user, finding out which module to choose is a pain, a "waste of time and effort".
Implementing that process would be fairly easy. So I can only guess that the majority of developers a) either does not know about CVS sandboxes, or b) likes to have duplicate efforts, or that c) I'm on crack.
sun