Re: [development] development Digest, Vol 83, Issue 34
Just speaking from personal experience. I don't think I would be as active with Drupal had I not been allowed to submit my modules to get feedback from the community. However, I do think some (alot, okay most) modules, including a couple of my own, are not worthy to be listed on Drupal.org. Instead of taking away the ability to contribute, I do think there should be a minor approval process. I know this adds a layer of complexity but I think most solutions will. I think the following would be a good workflow: 1. Open CVS Repo for anyone to contribute. "Drupal Alpha Repository" 2. Once an Alpha module gains popularity and is approved as unique to existing modules it would then be ported to cvs.drupal.org repo 2a. alternatively, if the code is similar to or heading in the same direction as another module it could then be suggested that the new module developer assist with development on existing module. This may have possibly been suggested before. I apologize if it has, I just re-enabled myself to this mailing list.
From: development-request@drupal.org Subject: development Digest, Vol 83, Issue 34 To: development@drupal.org Date: Wed, 18 Nov 2009 13:59:41 +0000
Send development mailing list submissions to development@drupal.org
To subscribe or unsubscribe via the World Wide Web, visit http://lists.drupal.org/mailman/listinfo/development or, via email, send a message with subject or body 'help' to development-request@drupal.org
You can reach the person managing the list at development-owner@drupal.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of development digest..."
Today's Topics:
1. Re: CVS Approval Policy: was Re: new features in D6 core? (Ashraf Amayreh) 2. Re: CVS Approval Policy: was Re: new features in D6 core? (Pierre Rineau) 3. Re: CVS Approval Policy: was Re: new features in D6 core? (Randy Fay) 4. Re: CVS Approval Policy: was Re: new features in D6 core? (Daniel F. Kudwien) 5. Re: CVS Approval Policy: was Re: new features in D6 core? (Ashraf Amayreh)
----------------------------------------------------------------------
Message: 1 Date: Wed, 18 Nov 2009 15:30:15 +0200 From: Ashraf Amayreh <mistknight@gmail.com> Subject: Re: [development] CVS Approval Policy: was Re: new features in D6 core? To: development@drupal.org, pierre.rineau@makina-corpus.com Message-ID: <a53d1b3b0911180530k57fab7c3h8cfc34ca382f02fb@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1"
It seems you misunderstood my reasoning. I'm simply suggesting this to make it compulsory for any CVS owner to talk about a possible module on the dev list BEFORE being able to create the project node. If the module is new it will get a thumbs up and he would get the go, if it's repetitive, the CVS owner will need to give good reasoning and then could be allowed to post it, and if he can't persuade anyone it would get rejected. Other module developers could suggest teaming up or perhaps point him to modules with similar functionality that he was unaware of as long as he has to post to the dev list before being able to create a new project node (kind of reminds me of the node limit module).
I'm simply suggesting this to make sure modules don't spring up in the dark without anyone's knowledge rather than trying to oppose repetitive modules. Currently, CVS owners are free to add as many project nodes as they want when they get their CVS access. Which sounds wrong given that he got his access for creating one module.
Suggestions? Flames? Thoughts?
AA
On Wed, Nov 18, 2009 at 2:23 PM, Pierre Rineau < pierre.rineau@makina-corpus.com> wrote:
On Wed, 2009-11-18 at 14:08 +0200, Ashraf Amayreh wrote:
I suddenly got this (perhaps silly) idea of only allowing a CVS owner to create one project and require approval by posting to the DEV list when wishing to create another project rather than making this open for all CVS owners. This would definitely help with the repetition problem and module boom.
Posting to the DEV list should at least give other module developers and people interested the opportunity to object to, agree or suggest alternatives to the proposed module rather than suddenly finding a useless/repetitive module springing up here and there because the developer didn't know another one existed.
Suggestions? Flames? Thoughts?
FLAAAAAAAAAAAAAAAAAAAAME! Repetitive modules are good, they always have subtile differences!
Please, project owners, do describe why your module is unique on your project page!
Pierre.
-- Ashraf Amayreh http://aamayreh.org
David Burns wrote:
Once an Alpha module gains popularity and is approved as unique First, how is an "alpha" module shown? We already have users who won't touch dev versions because of the big red X on the project page. Do you propose some other designation that will also tell users not to use it? As for unique, I think there is already considerable agreement that "unique" is not always good. Sometimes a "duplicate" module with [even slightly] different functionality is a least not bad. Let's take an example with which I am intimately familiar: a links page module.. In my search for a good one, I found 5 on DO. I finally decided that Web Links was the closest to what I wanted. Unfortunately, it hadn't been maintained very well to that point (okay, none of them were). At that time, a new maintainer was taking over. I submitted a few patches and convinced the new owner to let me help. Maybe he shouldn't have, because I don't there is a single line of original code left; it has evolved significantly since then. Meanwhile, we added conversion features from the others to give the users the option of switching. Finally one of them became available, so I took it over, made a few fixes, then wrote another conversion and officialy killed that module. While 4 of them still show as available, theer are really only 2 now. We also contributed a comparison page to the handbooks. I don't expect all "duplicates" to follow this model, but I think it is a more sane approach to this problem. As someone said, don't make it harder to contribute modules, make it easier for the adopter to find the one that is right for him/her. And encourage those people to help the next person by contributing comparisons.
Nancy E. Wichmann, PMP (781) 697-6344 Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
participants (2)
-
David Burns -
nan wich