[development] Wasting time and effort

andrew morton drewish at katherinehouse.com
Tue Mar 10 01:51:10 UTC 2009


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 at 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 at drupal.org [mailto:development-bounces at drupal.org]
> On Behalf Of andrew morton
> Sent: Monday, March 09, 2009 6:30 PM
> To: development at 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 at 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
>>
>>
>
>


More information about the development mailing list