new features in D6 core?
Are new features still being considered for Drupal 6 core? I've coded a new "Set language" option for the bulk node update form at admin/content/node. I filed an issue report with a patch and screenshot, at http://drupal.org/node/609262 . But from my reading of other issue reports, it seems that the 6.x API is considered to be frozen at this point. If I understand correctly, that would rule out including my patch, which adds some hooks to the locale module. Can someone please tell me if this is true, or even better, point me to a definitive statement? Thanks, Andrew.
Andrew, The short answer is: No. New features are not added after the code freeze, which is usually months before a stable version is released. Code freeze for Drupal 7 is already behind us. If you want to contribute your code, try to make it into a contrib module. Marc On Fri, 23 Oct 2009 02:54:34 -0400, Andrew Schulman <andrex@alumni.utexas.net> wrote:
Are new features still being considered for Drupal 6 core?
I've coded a new "Set language" option for the bulk node update form at admin/content/node. I filed an issue report with a patch and screenshot, at http://drupal.org/node/609262 .
But from my reading of other issue reports, it seems that the 6.x API is considered to be frozen at this point. If I understand correctly, that would rule out including my patch, which adds some hooks to the locale module. Can someone please tell me if this is true, or even better, point me to a definitive statement?
Thanks, Andrew.
On Friday 23 October 2009 1:54:34 am Andrew Schulman wrote:
Are new features still being considered for Drupal 6 core?
I've coded a new "Set language" option for the bulk node update form at admin/content/node. I filed an issue report with a patch and screenshot, at http://drupal.org/node/609262 .
But from my reading of other issue reports, it seems that the 6.x API is considered to be frozen at this point. If I understand correctly, that would rule out including my patch, which adds some hooks to the locale module. Can someone please tell me if this is true, or even better, point me to a definitive statement?
Thanks, Andrew.
Yes this is true. Once a Drupal version is released it accepts only bug and security fixes while new features are added to the next major version. Drupal 6 is the current stable release and therefore is not taking new features. Drupal 7 actually just went into feature freeze this month, so is not taking new features either while we focus on performance optimization, bug fixes, and UX improvements until it is released, *probably* sometime early next year but that depends on how good a job of we do of tracking down and squishing bugs. (Help is always appreciated!) Once Drupal 7 is released, it will be the stable version and not accept anything but bug and security fixes while development begins on Drupal 8, which will accept all kinds of wacky new stuff during its development cycle until its feature freeze, and the cycle repeats. -- Larry Garfield larry@garfieldtech.com
You could always build it out as a contrib module, though. It sounds pretty useful. ----- Cameron Eagans Owner, Black Storms Studios, LLC http://www.blackstormsstudios.com On Fri, Oct 23, 2009 at 1:12 AM, Larry Garfield <larry@garfieldtech.com>wrote:
On Friday 23 October 2009 1:54:34 am Andrew Schulman wrote:
Are new features still being considered for Drupal 6 core?
I've coded a new "Set language" option for the bulk node update form at admin/content/node. I filed an issue report with a patch and screenshot, at http://drupal.org/node/609262 .
But from my reading of other issue reports, it seems that the 6.x API is considered to be frozen at this point. If I understand correctly, that would rule out including my patch, which adds some hooks to the locale module. Can someone please tell me if this is true, or even better, point me to a definitive statement?
Thanks, Andrew.
Yes this is true. Once a Drupal version is released it accepts only bug and security fixes while new features are added to the next major version. Drupal 6 is the current stable release and therefore is not taking new features.
Drupal 7 actually just went into feature freeze this month, so is not taking new features either while we focus on performance optimization, bug fixes, and UX improvements until it is released, *probably* sometime early next year but that depends on how good a job of we do of tracking down and squishing bugs. (Help is always appreciated!) Once Drupal 7 is released, it will be the stable version and not accept anything but bug and security fixes while development begins on Drupal 8, which will accept all kinds of wacky new stuff during its development cycle until its feature freeze, and the cycle repeats.
-- Larry Garfield larry@garfieldtech.com
You could always build it out as a contrib module, though. It sounds pretty useful.
Thanks. Unfortunately, when I tried that the CVS masters said that my proposed module was "too simple" to justify granting me an account (http://drupal.org/node/606962). It's true, the feature is quite simple. It really should just be integrated into core. But that obviously isn't possible for D6 or 7, which is helpful to know. I'm looking now for another module that could easily integrate the feature, but if I don't find one I'll go back to the CVS masters and try again. Thanks, Andrew.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Schulman schrieb:
You could always build it out as a contrib module, though. It sounds pretty useful.
Thanks. Unfortunately, when I tried that the CVS masters said that my proposed module was "too simple" to justify granting me an account (http://drupal.org/node/606962).
This has been rectified. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkrhkroACgkQfg6TFvELooRo6QCghNFkg/vbqPieZv1ONG2yWWwc tYwAoLwXit3oQNLCYs03OQIbWj7r6URR =XjHq -----END PGP SIGNATURE-----
You could always build it out as a contrib module, though. It sounds pretty useful.
Thanks. Unfortunately, when I tried that the CVS masters said that my proposed module was "too simple" to justify granting me an account (http://drupal.org/node/606962).
This has been rectified.
Cheers, Gerhard
Thank you. Andrew.
A quick observation here, and feel free to flame this mercilessly [1]. As I see it, the purpose of the review of application should be to determine whether the applicant will comply with the d.o requirements regarding licensing, etc -- it should *not* be to judge the merits of the proposed module. In this case, and in others I have seen, people have been unnecessarily hassled during the CVS application process. As a community, we are shooting ourselves in the foot if we hassle/turn away developers, especially when we are turning them away for invalid reasons. If Andrew hadn't posted to the Dev list, his good idea would not have had the opportunity to make it into the community. I wonder how many other good ideas have been lost for the exact same reason. Cheers, Bill [1]. Yes, I know that there are a small number of people triaging a large number of CVS applications. Andrew Schulman wrote:
You could always build it out as a contrib module, though. It sounds pretty useful. Thanks. Unfortunately, when I tried that the CVS masters said that my proposed module was "too simple" to justify granting me an account (http://drupal.org/node/606962).
This has been rectified.
Cheers, Gerhard
Thank you. Andrew.
This is going to be one of those discussions we always have like backwards compatibility between major versions. Yes, the main point is there are way too few people helping review applications. I do agree that whoever is reviewing always needs to be compassionate and be able to justly explain his or her decision, which currently doesn't always happen. Just because someone can follow CVS licensing doesn't mean I should approve a better_views module or a better_cck module. This is also our opportunity to prevent duplicate or unnecessary modules, the latter being a fine line. A small, trivial 10-line customization that runs hook_form_alter() should be approved? This needs effort from all sides: 1. CVS admins/reviewers to always be helpful and make sound decisions since it is usually the applicant's beginning attempt at contributing code. 2. The existing community (the 8 non-CVs admins) to actually care about the new members and help with application review. This only happens where there are problems. If people were looking at the CVS applications and chime in and say "Wow, I've always needed this. This would make a great module," that would make the decision easier for the admins and we probably wouldn't be having this discussion. 3. CVS applicants always submitting thoughtful and thorough application. I think Andrew falls into this case, but there are a lot that don't. Makes the job harder for both 1 and 2. See http://drupal.org/cvs-application/requirements and Dave Reid dave@davereid.net On Fri, Oct 23, 2009 at 4:50 PM, Bill Fitzgerald <bill@funnymonkey.com>wrote:
A quick observation here, and feel free to flame this mercilessly [1].
As I see it, the purpose of the review of application should be to determine whether the applicant will comply with the d.o requirements regarding licensing, etc -- it should *not* be to judge the merits of the proposed module.
In this case, and in others I have seen, people have been unnecessarily hassled during the CVS application process.
As a community, we are shooting ourselves in the foot if we hassle/turn away developers, especially when we are turning them away for invalid reasons.
If Andrew hadn't posted to the Dev list, his good idea would not have had the opportunity to make it into the community. I wonder how many other good ideas have been lost for the exact same reason.
Cheers,
Bill
[1]. Yes, I know that there are a small number of people triaging a large number of CVS applications.
Andrew Schulman wrote:
You could always build it out as a contrib module, though. It sounds
pretty useful.
Thanks. Unfortunately, when I tried that the CVS masters said that my proposed module was "too simple" to justify granting me an account (http://drupal.org/node/606962).
This has been rectified.
Cheers, Gerhard
Thank you. Andrew.
Adding to the potential flame fodder... We've actually encouraged non-developers who will likely never commit anything to CVS to request CVS accounts so we can leverage Project on D.O. as a project management tool. While anyone can take ownership of an issue themselves, the list of people someone with CVS access can assign an issue/task/feature to is limited to the other users with CVS access to the module or theme. We've just started scratching the surface of this functionality, but every person from the Open Media Project who requested a CVS account was approved. - Kevin Reynen On Fri, Oct 23, 2009 at 4:35 PM, Dave Reid <dave@davereid.net> wrote:
This is going to be one of those discussions we always have like backwards compatibility between major versions.
Yes, the main point is there are way too few people helping review applications. I do agree that whoever is reviewing always needs to be compassionate and be able to justly explain his or her decision, which currently doesn't always happen.
Just because someone can follow CVS licensing doesn't mean I should approve a better_views module or a better_cck module. This is also our opportunity to prevent duplicate or unnecessary modules, the latter being a fine line. A small, trivial 10-line customization that runs hook_form_alter() should be approved?
This needs effort from all sides: 1. CVS admins/reviewers to always be helpful and make sound decisions since it is usually the applicant's beginning attempt at contributing code. 2. The existing community (the 8 non-CVs admins) to actually care about the new members and help with application review. This only happens where there are problems. If people were looking at the CVS applications and chime in and say "Wow, I've always needed this. This would make a great module," that would make the decision easier for the admins and we probably wouldn't be having this discussion. 3. CVS applicants always submitting thoughtful and thorough application. I think Andrew falls into this case, but there are a lot that don't. Makes the job harder for both 1 and 2.
See http://drupal.org/cvs-application/requirements and
Dave Reid dave@davereid.net
On Fri, Oct 23, 2009 at 4:50 PM, Bill Fitzgerald <bill@funnymonkey.com>wrote:
A quick observation here, and feel free to flame this mercilessly [1].
As I see it, the purpose of the review of application should be to determine whether the applicant will comply with the d.o requirements regarding licensing, etc -- it should *not* be to judge the merits of the proposed module.
In this case, and in others I have seen, people have been unnecessarily hassled during the CVS application process.
As a community, we are shooting ourselves in the foot if we hassle/turn away developers, especially when we are turning them away for invalid reasons.
If Andrew hadn't posted to the Dev list, his good idea would not have had the opportunity to make it into the community. I wonder how many other good ideas have been lost for the exact same reason.
Cheers,
Bill
[1]. Yes, I know that there are a small number of people triaging a large number of CVS applications.
Andrew Schulman wrote:
You could always build it out as a contrib module, though. It sounds
pretty useful.
Thanks. Unfortunately, when I tried that the CVS masters said that my proposed module was "too simple" to justify granting me an account (http://drupal.org/node/606962).
This has been rectified.
Cheers, Gerhard
Thank you. Andrew.
A quick observation here, and feel free to flame this mercilessly [1].
As I see it, the purpose of the review of application should be to determine whether the applicant will comply with the d.o requirements regarding licensing, etc -- it should *not* be to judge the merits of the proposed module.
In this case, and in others I have seen, people have been unnecessarily hassled during the CVS application process.
As a community, we are shooting ourselves in the foot if we hassle/turn away developers, especially when we are turning them away for invalid reasons.
If Andrew hadn't posted to the Dev list, his good idea would not have had the opportunity to make it into the community. I wonder how many other good ideas have been lost for the exact same reason.
Well, here's my view. Yes, I'm a new contributor to Drupal. I read the new maintainer documents and followed the advice there, but I didn't expect to get it all right the first time. I was disappointed and a little frustrated that my CVS account was denied, mainly because it wasn't clear to me how else I was supposed to get my code out to the community. But the reason for the denial, although very shortly stated, has merit. We don't want a bunch of trivial modules cluttering up Drupal-- I get that. So I asked on the forums and filed a patch against 6.x core, but I didn't get an answer in either place. But those are noisy places, so I just figured I needed to keep trying. Once I wrote to this list, I got an answer right away and a positive result. So in short I'd say: - The reason for denying my account was valid, but it should have considered, or suggested, what the alternative might be for me to make my code available. - A new developer should expect to need some patience in engaging the community about their contribution. If they're serious about contributing, they'll stick to it. It did occur to me, that a person who already had a CVS account could have contributed the same module at their discretion, while I couldn't because I didn't have an account yet. So it seems that CVS approval was being used as a proxy for module approval. But I also agree that new developers should pass a threshold test for making a sound contribution. Anyway, the community came through in the end. I wouldn't worry about it too much. Andrew.
I don't know that I'd agree with the reason for denying it being valid. I'd say that with regards to the question posed earlier, it makes sense to approve a module that has 1 line of code, if that code is going to be use to the community. Denying the community the functionality, or telling several (dozens, hundreds, thousands?) of people to go code it themselves because it's trivial to do, but not trivial enough to add to core, doesn't seem like the right approach. If it's useful, a module makes sense.
Again, how can one person know that one line is useful to the entire community if other people don't speak up about it? It requires the community to be involved in the process and not reacting to just when there are problems. Dave Reid dave@davereid.net On Fri, Oct 23, 2009 at 8:31 PM, Jeff Greenberg <jeff@ayendesigns.com>wrote:
I don't know that I'd agree with the reason for denying it being valid. I'd say that with regards to the question posed earlier, it makes sense to approve a module that has 1 line of code, if that code is going to be use to the community. Denying the community the functionality, or telling several (dozens, hundreds, thousands?) of people to go code it themselves because it's trivial to do, but not trivial enough to add to core, doesn't seem like the right approach. If it's useful, a module makes sense.
Dave Reid wrote:
Again, how can one person know that one line is useful to the entire community if other people don't speak up about it? It requires the community to be involved in the process and not reacting to just when there are problems.
Right, then if one person isn't qualified to know whether it would be useful to the community, let the community decide by downloading it or not.
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? AA On Sat, Oct 24, 2009 at 4:35 AM, Jeff Greenberg <jeff@ayendesigns.com>wrote:
Dave Reid wrote:
Again, how can one person know that one line is useful to the entire
community if other people don't speak up about it? It requires the community to be involved in the process and not reacting to just when there are problems.
Right, then if one person isn't qualified to know whether it would be useful to the community, let the community decide by downloading it or not.
-- Ashraf Amayreh http://aamayreh.org
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.
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
On Wed, 2009-11-18 at 15:30 +0200, Ashraf Amayreh wrote:
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).
It was some kind of joke, don't worry :) I agree with the fact a lot of modules shouldn't even exists. But this MY judgement, and because I'm a simple human, my judgement is not the only one which is right (and is probably wrong btw). It's difficult to define what is a good reasoning, because every man which will review appliances for a new project CVS will have a different opinion about this. My though is that on d.o, it should exist some kind of tag like "core team says YAY! to this module" and "core team totally disapprove this ugly module", which should help users to get stable, maintainable, and non abandoned modules. Pierre.
My though is that on d.o, it should exist some kind of tag like "core team says YAY! to this module" and "core team totally disapprove this ugly module", which should help users to get stable, maintainable, and non abandoned modules.
Pierre.
You are basically arguing for installing Flag module on drupal.org, which would allow this and many other badly needed improvements. So please contribute here: http://3281d.com/projects/improving-subscriptions Thanks. sun
My though is that on d.o, it should exist some kind of tag like "core team says YAY! to this module" and "core team totally disapprove this ugly module", which should help users to get stable, maintainable, and non abandoned modules.
With 5000+ modules it would be impossible for the core team to keep up. Any option to evaluate modules after they've been submitted isn't practical at all. As to stable, maintainable and non-abandoned modules, I'm pretty sure not even the core team has the ability to read into the future :) The only alternative is to catch projects before they are even created by requiring permission per project rather than a CVS account that can create an unlimited number of projects/modules. Not to mention the added benefit of introducing the module on the dev list to everyone which is a huge advantage. A comment period would help with this.
I disagree to this. When CVS owners find they won't be able to upload their modules without getting an administrator's approval they will lean towards introducing the module before writing code which would save on a lot of coding work. Finally, I think we should make it clear to people that if you contribute a
module, you're expected to maintain it, or at least figure out how to get it maintained. I know there are a number of module contributors who have just dropped code into CVS and left it there for ever. Perhaps we should ask them to check a checkbox "I agree to maintain this module".
As nice as it may be, this is simply unrealistic. AA
Finally, I think we should make it clear to people that if you contribute a module, you're expected to maintain it, or at least figure out how to get it maintained. I know there are a number of module contributors who have just dropped code into CVS and left it there for ever. Perhaps we should ask them to check a checkbox "I agree to maintain this module".
As nice as it may be, this is simply unrealistic.
I think it is realistic and reasonable and prudent. IMO, cvs.drupal.org is not a place for code that you want to share briefly and forget about. or at least, lets segregate that out to something other than contrib/modules.
On Wed, Nov 18, 2009 at 3:05 PM, Moshe Weitzman <weitzman@tejasa.com> wrote:
Perhaps we should ask them to check a checkbox "I agree to maintain this module".
As nice as it may be, this is simply unrealistic.
I think it is realistic and reasonable and prudent. IMO, cvs.drupal.org is not a place for code that you want to share briefly and forget about. or at least, lets segregate that out to something other than contrib/modules.
This calls for the set up of an "incubator" repository, where modules can mature and stabilize before getting into the "mainstream" repository. Projects could be promoted from the incubator to the mainstream repository via a review process. After all, we have an handful of modules that are very heavily used and can be considered as critical for the community, and a "long tail" of more targeted, special-cased modules that forms the richness of the community, but that don't have the same quality / support requirements. Between Views (the most used contributed module) and Admin Role (#100 contributed module), there is a 1/20 usage ratio. I think it would make sense that those "high profile" modules (and other modules, the usage is just a data point here, there are obviously other things to consider) comply with higher standards, and be identified as such. Damien Tournoud
I absolutely love Damien's proposal for an incubator repository! And an incubator section on the modules page, or an incubator_modules section, or something of the type. On Wed, Nov 18, 2009 at 10:35 AM, Damien Tournoud <damz@prealable.org>wrote:
On Wed, Nov 18, 2009 at 3:05 PM, Moshe Weitzman <weitzman@tejasa.com> wrote:
Perhaps we should ask them to check a checkbox "I agree to maintain this module".
As nice as it may be, this is simply unrealistic.
I think it is realistic and reasonable and prudent. IMO, cvs.drupal.org is not a place for code that you want to share briefly and forget about. or at least, lets segregate that out to something other than contrib/modules.
This calls for the set up of an "incubator" repository, where modules can mature and stabilize before getting into the "mainstream" repository. Projects could be promoted from the incubator to the mainstream repository via a review process.
After all, we have an handful of modules that are very heavily used and can be considered as critical for the community, and a "long tail" of more targeted, special-cased modules that forms the richness of the community, but that don't have the same quality / support requirements.
Between Views (the most used contributed module) and Admin Role (#100 contributed module), there is a 1/20 usage ratio. I think it would make sense that those "high profile" modules (and other modules, the usage is just a data point here, there are obviously other things to consider) comply with higher standards, and be identified as such.
Damien Tournoud
-- Randy Fay Drupal Development, troubleshooting, and debugging randy@randyfay.com +1 970.462.7450
"This calls for the set up of an "incubator" repository, where modules can mature and stabilize before getting into the "mainstream" repository. Projects could be promoted from the incubator to the mainstream repository via a review process." I think the problem with that is who is going to be in charge of reviewing all these modules. Has anyone looked at the issue queues on d.o? Those alone are full of unresolved issues, even in some of the most used modules and core for that matter. It's not like there is a full time staff of reviewers to look over modules and decide if they are good enough. Not to mention the fact that let's be honest even the most seasoned and smart developers out there simply do not have all the knowledge about all the different modules and their functionality to make a sound decision about what is and isn't a duplicate. Are we going to expect people to set up test installs of the modules just to make sure that one is really different from the other? It's just unrealistic to expect that adding more management work to a community of volunteers is really going to solve this "problem". And on that note, is it really a problem? Wordpress has 7,308 plugins, Joomla has 3651, and we've got roughly 5090(which I had to calculate using the page #'s because we unlike the aforementioned products don't highlight the # of contributions). If you've ever used either of those other two systems then you know that the problem is relegated to Drupal, they both have the same problem with low quality and duplicate contributions. Heck on WP I searched for Google Analytics and got roughly 80 results. On our site with the same search I got 14. Now either our search is way better at filtering out junk (which it is, but I doubt thats the issue), or maybe this isn't as big a problem as we think. Imean half the results for GA on d.o weren't actuall tracking mods, but just things like Ubercart or IMCE that in some way mention GA. I understand that we want to keep the module area clean, and we don't want to have a bunch of junk downoads cluttering it up. I agree that adding a rrating system (Fivestar) to contrib stuff would be a great idea. But I think in the end trying to administer the submission process to death, will do just that, kill contributions. We are an open source project, that means that sometimes we are going to get some junk code and some duplicates, but that's what makes OS great, is that people can code things the way the want and then share that code with others. If we make it more difficult for people to contribute then how is that serving the Drupal project? ----- Adam A. Gregory Blog: AdamAGregory.com Twitter: twitter.com/adamgregory Skype: aagregory2 Cell: 706.761.7375
The only alternative is to catch projects before they are even created by requiring permission per project rather than a CVS account that can create an unlimited number of projects/modules. Not to mention the added benefit of introducing the module on the dev list to everyone which is a huge advantage.
If we don't end up forcing users into anything, at minimum let's give some strong encouragement to post to the dev list. It will at least allow for "have you seen module X?" dupe avoidance. I've noticed that when there is contention on an issue it often results in no progress at all, but we can pull off some easy improvement with nothing but content changes in spite of that (but only if don't just let it drop). - Ken Winters
If we don't end up forcing users into anything, at minimum let's give some strong encouragement to post to the dev list. It will at least allow for "have you seen module X?" dupe avoidance.
Might we all drop off the dev list if it gets any busier? Then we have the same problem. However, I see awfully good quality answers on this list, and it would work great if it didn't wear on the list. On Wed, Nov 18, 2009 at 9:58 AM, Ken Winters <kwinters@coalmarch.com> wrote:
The only alternative is to catch projects before they are even created by
requiring permission per project rather than a CVS account that can create an unlimited number of projects/modules. Not to mention the added benefit of introducing the module on the dev list to everyone which is a huge advantage.
If we don't end up forcing users into anything, at minimum let's give some strong encouragement to post to the dev list. It will at least allow for "have you seen module X?" dupe avoidance.
I've noticed that when there is contention on an issue it often results in no progress at all, but we can pull off some easy improvement with nothing but content changes in spite of that (but only if don't just let it drop).
- Ken Winters
-- Randy Fay Drupal Development, troubleshooting, and debugging randy@randyfay.com +1 970.462.7450
On Nov 18, 2009, at 6:59 AM, Ashraf Amayreh wrote:
With 5000+ modules it would be impossible for the core team to keep up.
A similar bottleneck exists with the current system. Seems like we could use a larger community contributing to the review process.
Any option to evaluate modules after they've been submitted isn't practical at all.
That's an awfully broad rejection. We already evaluate modules after they've been submitted; we just don't collect those evaluations explicitly anywhere. But we do collect them implicitly via usage stats, issue queues, and several blogs dedicated to module reviews. Further, many other code repositories manage to pull off the task of reviewing code after it is submitted, e.g. github (forking), Google code (external), SourceForge (vote up or down). We could probably learn something from those experiences.
The only alternative is to catch projects before they are even created by requiring permission per project rather than a CVS account that can create an unlimited number of projects/modules. Not to mention the added benefit of introducing the module on the dev list to everyone which is a huge advantage.
If we eventually move to distributed version control (as Dries suggested here: http://buytaert.net/8-steps-for-drupal-8 ), managing contribution via access to version control will become impossible. We'll then need some way to accept and reject modules after they already exist in a repository, even if it's not the primary repository. And that sounds a lot like many of the suggestions here.
A comment period would help with this.
I disagree to this. When CVS owners find they won't be able to upload their modules without getting an administrator's approval they will lean towards introducing the module before writing code which would save on a lot of coding work.
That assumes people realize Drupal CVS isn't open to all contributions before they write the code. Because Drupal is relatively rare in evaluating projects before any actual code, it seems entirely reasonable for people to misunderstand this process. And that's exactly what started this discussion. -- Scott Reynen MakeDataMakeSense.com
I agree Pierre, Scott, Greg and others who do *not* want to tighten the module contribution process. I support other ways to deal with the issue of module duplication. Some points that have not been raised: 1. *Issue queue, issue queue, issue queue**. The issue queue is the window into a module*. By studying the issue queue for less than 5 minutes (sometimes 20 seconds) you can determine the quality of maintenance and the level of current activity in terms of new features and future development. *We need to be more explicit in our docs about teaching new people just how to study the issue queue to make these evaluations*. 2. *A**dvertise the module feed**: We need to better advertise the module feed* (http://drupal.org/taxonomy/term/14/0/feed). Why isn't it on the module pages at d.o.? Getting more people to subscribe will help nip problems early if there is clear overlap. It also helps people get people interested in modules and can help develop collaborations etc. 3. *Move dev list to g.d.o.* The dev list is important. And people should be encouraged, but not required, to run ideas by this list. But I've got problems with this list. *Why hasn't this list been replaced by a group at groups.drupal.org?* Try doing a Google search and limiting your results to: http://lists.drupal.org/pipermail/development/. It's pathetic. I don't know what the problem is. But I don't think it is worth fixing other than migrating to g.d.o. I don't think this list should be a requirement for anything. We aren't eating our own dog food on this list. 4. *More stats:* The relatively new usage stats at d.o. are awesome. They provide a nice resource for people evaluating modules. Lets develop some other stats as well. Here is one that I've thought about: Output a percent which is the number of posts and commits in a queue by maintainers divided by the total number of posts on the queue within the last year. It could give a quick sense to folks about the level of participation of the maintainer(s). A stat like that couldn't be used alone to make an evaluation, but in conjunction with other information, it could help. I think there is a lot of data that is sitting on d.o. that we are not leveraging. I'm in favor of developing more stats, which maintain themselves, rather than having some "core group" make evaluations. Shai Shai Gluskin Owner Content2zero Web Development <http://content2zero.com> On Wed, Nov 18, 2009 at 10:10 AM, Scott Reynen <scott@makedatamakesense.com>wrote:
On Nov 18, 2009, at 6:59 AM, Ashraf Amayreh wrote:
With 5000+ modules it would be impossible for the core team to keep up.
A similar bottleneck exists with the current system. Seems like we could use a larger community contributing to the review process.
Any option to evaluate modules after they've been submitted isn't
practical at all.
That's an awfully broad rejection. We already evaluate modules after they've been submitted; we just don't collect those evaluations explicitly anywhere. But we do collect them implicitly via usage stats, issue queues, and several blogs dedicated to module reviews.
Further, many other code repositories manage to pull off the task of reviewing code after it is submitted, e.g. github (forking), Google code (external), SourceForge (vote up or down). We could probably learn something from those experiences.
The only alternative is to catch projects before they are even created by
requiring permission per project rather than a CVS account that can create an unlimited number of projects/modules. Not to mention the added benefit of introducing the module on the dev list to everyone which is a huge advantage.
If we eventually move to distributed version control (as Dries suggested here: http://buytaert.net/8-steps-for-drupal-8 ), managing contribution via access to version control will become impossible. We'll then need some way to accept and reject modules after they already exist in a repository, even if it's not the primary repository. And that sounds a lot like many of the suggestions here.
A comment period would help with this.
I disagree to this. When CVS owners find they won't be able to upload their modules without getting an administrator's approval they will lean towards introducing the module before writing code which would save on a lot of coding work.
That assumes people realize Drupal CVS isn't open to all contributions before they write the code. Because Drupal is relatively rare in evaluating projects before any actual code, it seems entirely reasonable for people to misunderstand this process. And that's exactly what started this discussion.
-- Scott Reynen MakeDataMakeSense.com
I'll throw this in and rest my case. Advantages of making it compulsory for CVS owners (or even first time CVS requestors) to post to dev list and get an approval: 1. Easy to implement on the Drupal site using node limit. CVS admins would only need to increment a counter when a user's dev-list-submitted module is accepted. Virtually no extra effort is required from the CVS admin team. 2. Everyone can be sure that no module will appear on Drupal without having been sent to the dev list first which is definitely better for informing the community of new modules and keeping them up to date. 3. Promoting cooperation between developers because all developers will be informed of a new module idea and can intervene if they find it's a)useless or b)replicates their own modules or have any other valid c)objection/ d)suggestion. 4. Promoting a check-with-list before you code mentality to avoid writing code that is rejected. 5. Reduces useless modules on the long run. The downsides, and let me kill these possible downsides before they arise: 1. Making it more difficult to contribute: Which in essence tells us that posting to the dev list before creating a project node is a "BARRIER" to contributions... Unless there are contributions that must not reach the dev list before becoming projects then I think this is totally non-sense. 2. Requiring huge effort to implement: ... Really! -- AA
Question: I see lots of "increase reviews before project node" proposals here, but did *anyone* of you *ever* review any single CVS application? In case you did: Awesome! However, you then belong to a very small group of people that I can probably count on one hand. This is where such proposals will #fail. Even when the process is totally open for everyone. See http://drupal.org/project/cvsapplications sun
On Wed, Nov 18, 2009 at 9:52 AM, Daniel F. Kudwien <news@unleashedmind.com>wrote:
Question:
I see lots of "increase reviews before project node" proposals here, but did *anyone* of you *ever* review any single CVS application?
...
Even when the process is totally open for everyone.
I had no idea this was open. I've never seen the fact advertised. I've added a new child page (stub) here: http://drupal.org/getting-involved Perhaps you could expand on the procedures and criteria for evaluating applications? Best, Matt
Reviewing CVS applications: I had no idea that it was an issue queue. And it says nothing about the process on the project page. The process is not open, as it's undocumented. The conversation may be open, but the process is not. It's not stated who the decisionmakers are, how one would participate in the process, or any of the other details. Could someone who has the privileges to edit the project page please edit it to include this information, and to mention how exactly the public can participate? Thanks, -Randy On Wed, Nov 18, 2009 at 3:47 PM, Matt Chapman <matt@ninjitsuweb.com> wrote:
On Wed, Nov 18, 2009 at 9:52 AM, Daniel F. Kudwien <news@unleashedmind.com
wrote:
Question:
I see lots of "increase reviews before project node" proposals here, but did *anyone* of you *ever* review any single CVS application?
...
Even when the process is totally open for everyone.
I had no idea this was open. I've never seen the fact advertised.
I've added a new child page (stub) here:
http://drupal.org/getting-involved
Perhaps you could expand on the procedures and criteria for evaluating applications?
Best,
Matt
-- Randy Fay Drupal Development, troubleshooting, and debugging randy@randyfay.com +1 970.462.7450
I used to contribute, but got unpublished or deleted, reason is that i was annoying the webmasters by my comments, I got voted out. This is one example of their valid reason. This is just for everybody's information. On Thu, Nov 19, 2009 at 10:05 AM, Randy Fay <randy@randyfay.com> wrote:
Reviewing CVS applications:
I had no idea that it was an issue queue. And it says nothing about the process on the project page.
The process is not open, as it's undocumented. The conversation may be open, but the process is not. It's not stated who the decisionmakers are, how one would participate in the process, or any of the other details.
Could someone who has the privileges to edit the project page please edit it to include this information, and to mention how exactly the public can participate?
Thanks, -Randy
On Wed, Nov 18, 2009 at 3:47 PM, Matt Chapman <matt@ninjitsuweb.com>wrote:
On Wed, Nov 18, 2009 at 9:52 AM, Daniel F. Kudwien < news@unleashedmind.com> wrote:
Question:
I see lots of "increase reviews before project node" proposals here, but did *anyone* of you *ever* review any single CVS application?
...
Even when the process is totally open for everyone.
I had no idea this was open. I've never seen the fact advertised.
I've added a new child page (stub) here:
http://drupal.org/getting-involved
Perhaps you could expand on the procedures and criteria for evaluating applications?
Best,
Matt
-- Randy Fay Drupal Development, troubleshooting, and debugging randy@randyfay.com +1 970.462.7450
-- Daniel Honrade, Jr. mobile: +63 915 903 3561 alternate email: danielhonrade@gmail.com websites: http://danielhonrade.com http://webtheming.com When you signup for PayPal, you can start accepting credit card payments instantly. As the world's number one online payment service, PayPal is the fastest way to open your doors to over 150 million member accounts worldwide. Best of all, it's completely free to sign up! To sign up or learn more, click here: https://www.paypal.com/ph/mrb/pal=GE47NYP4D94XA
On Wed, Nov 18, 2009 at 6:28 PM, Daniel Honrade <mail@danielhonrade.com>wrote:
I used to contribute, but got unpublished or deleted, reason is that i was annoying the webmasters by my comments, I got voted out. This is one example of their valid reason. This is just for everybody's information.
For anyone wondering about this, the real story is here: http://drupal.org/node/501364 -Matt
On Nov 18, 2009, at 7:05 PM, Randy Fay wrote:
Reviewing CVS applications:
I had no idea that it was an issue queue. And it says nothing about the process on the project page.
I also had no idea that was an issue queue and I'm also really curious about the standards here. After looking through a few of the pending applications, it seems to me first time modules get a level of scrutiny far beyond that given to modules already in contrib I guess that could be a good thing, as people could learn their lessons early, but I also expect Drupal is losing a lot of potential contributors by holding up CVS accounts over relatively minor issues that could better be dealt with in a more public forum after a project is created. Here's a representative example: http://drupal.org/node/622334 I might be missing something (and if I am, maybe my CVS account should be revoked?), but I don't see any issues there that really hurt anything, and I've seen all of that in several modules already in contrib. Is it appropriate to have these discussions in the CVS application issue queue? -- Scott Reynen MakeDataMakeSense.com
Shai Gluskin wrote:
3. *Move dev list to g.d.o.* [...]
I can sympathize with your desire to have a more searchable output for this list, on-line forums such as g.d.o are a huge barrier to participation compared to email lists. So if this list is moved to g.d.o and we want it to still be a useful list with immediate feedback and lots of participants, we would also need to provide a way for people to participate fully via email (i.e. make it so it looks and acts just like an email list). In which case, the threads will look/act/search like email, and I don't think we will have solved anything. --Jennifer -- Jennifer Hodgdon * Poplar ProductivityWare www.poplarware.com Drupal, WordPress, and custom Web programming
Getting a proper balance between a topdown vs. a bottom up approach is never easy. There's surely an issue with the current proliferation of modules on d.o. But the problem is not the numbers per se, but rather that each project page has very sparse information about the module quality. I agree with Shai, more stats is better. It will help people make a better decision about which module to choose when there are several proposing a solution to a given problem. Let the market forces act and all the distributed knowledge contribute to a better d.o and drupal ecosystem. One idea that could improve code quality in contrib would be to have a code evaluation bot so that when you upload a module it runs it through Coder Though Love http://drupal.org/project/coder_tough_love and only after passing the test will be available as a new release in the project page. That's for syntax and code style. For the logic let the community sort it out through their usage of the modules. Better stats and a good UX will catalyze the process of separating the wheat from the chaff. --- appa On 18 Nov 2009 17h06 WET, shai@content2zero.com wrote:
I agree Pierre, Scott, Greg and others who do *not* want to tighten the module contribution process. I support other ways to deal with the issue of module duplication. Some points that have not been raised:
1. *Issue queue, issue queue, issue queue**. The issue queue is the window into a module*. By studying the issue queue for less than 5 minutes (sometimes 20 seconds) you can determine the quality of maintenance and the level of current activity in terms of new features and future development. *We need to be more explicit in our docs about teaching new people just how to study the issue queue to make these evaluations*. 2. *A**dvertise the module feed**: We need to better advertise the module feed* (http://drupal.org/taxonomy/term/14/0/feed). Why isn't it on the module pages at d.o.? Getting more people to subscribe will help nip problems early if there is clear overlap. It also helps people get people interested in modules and can help develop collaborations etc. 3. *Move dev list to g.d.o.* The dev list is important. And people should be encouraged, but not required, to run ideas by this list. But I've got problems with this list. *Why hasn't this list been replaced by a group at groups.drupal.org?* Try doing a Google search and limiting your results to: http://lists.drupal.org/pipermail/development/. It's pathetic. I don't know what the problem is. But I don't think it is worth fixing other than migrating to g.d.o. I don't think this list should be a requirement for anything. We aren't eating our own dog food on this list. 4. *More stats:* The relatively new usage stats at d.o. are awesome. They provide a nice resource for people evaluating modules. Lets develop some other stats as well. Here is one that I've thought about: Output a percent which is the number of posts and commits in a queue by maintainers divided by the total number of posts on the queue within the last year. It could give a quick sense to folks about the level of participation of the maintainer(s). A stat like that couldn't be used alone to make an evaluation, but in conjunction with other information, it could help. I think there is a lot of data that is sitting on d.o. that we are not leveraging. I'm in favor of developing more stats, which maintain themselves, rather than having some "core group" make evaluations.
Shai
Shai Gluskin Owner Content2zero Web Development <http://content2zero.com>
I'd like to make an additional suggestion. I apologize if this has already been discussed in the past. I would like to see somewhere to advertise the --intention-- of creating a module. Not as a requirement. I'm about to take something I did for a client, and spend weeks, maybe months, turning it into a module. It would be nice to have a place to file that intention, so that if someone else is two weeks ahead of me, I don't see the same module pop up on drupal.org after I've put in countless hours of effort. Jeff
On Wed, Nov 18, 2009 at 11:17 AM, Jeff Greenberg <jeff@ayendesigns.com> wrote:
I would like to see somewhere to advertise the --intention-- of creating a module. Not as a requirement. I'm about to take something I did for a client, and spend weeks, maybe months, turning it into a module. It would be nice to have a place to file that intention, so that if someone else is two weeks ahead of me, I don't see the same module pop up on drupal.org after I've put in countless hours of effort.
The exact spot for that is http://groups.drupal.org/contributed-module-ideas Thanks! Greg -- Greg Knaddison | 303-800-5623 | http://growingventuresolutions.com Mastering Drupal - http://www.masteringdrupal.com
On Wed, 2009-11-18 at 12:06 -0500, Shai Gluskin wrote:
1. Issue queue, issue queue, issue queue. The issue queue is the window into a module. By studying the issue queue for less than 5 minutes (sometimes 20 seconds) you can determine the quality of maintenance and the level of current activity in terms of new features and future development. We need to be more explicit in our docs about teaching new people just how to study the issue queue to make these evaluations. 2. Advertise the module feed: We need to better advertise the module feed (http://drupal.org/taxonomy/term/14/0/feed). Why isn't it on the module pages at d.o.? Getting more people to subscribe will help nip problems early if there is clear overlap. It also helps people get people interested in modules and can help develop collaborations etc. 3. Move dev list to g.d.o. The dev list is important. And people should be encouraged, but not required, to run ideas by this list. But I've got problems with this list. Why hasn't this list been replaced by a group at groups.drupal.org? Try doing a Google search and limiting your results to: http://lists.drupal.org/pipermail/development/. It's pathetic. I don't know what the problem is. But I don't think it is worth fixing other than migrating to g.d.o. I don't think this list should be a requirement for anything. We aren't eating our own dog food on this list. 4. More stats: The relatively new usage stats at d.o. are awesome. They provide a nice resource for people evaluating modules. Lets develop some other stats as well. Here is one that I've thought about: Output a percent which is the number of posts and commits in a queue by maintainers divided by the total number of posts on the queue within the last year. It could give a quick sense to folks about the level of participation of the maintainer(s). A stat like that couldn't be used alone to make an evaluation, but in conjunction with other information, it could help. I think there is a lot of data that is sitting on d.o. that we are not leveraging. I'm in favor of developing more stats, which maintain themselves, rather than having some "core group" make evaluations.
Totally agree with points 1, 2 and 4. Pierre.
On Wed, Nov 18, 2009 at 6:42 AM, Pierre Rineau <pierre.rineau@makina-corpus.com> wrote:
My though is that on d.o, it should exist some kind of tag like "core team says YAY! to this module" and "core team totally disapprove this ugly module", which should help users to get stable, maintainable, and non abandoned modules.
The "core team" - it would be nice to meet these mythical folks. Could you make a list of who they are? (point being: maintaining that list is more trouble than it's worth) Duplication is a problem, but removing duplication is only one answer. The other answer is better documentation of the differences. There's lots of great work toward that in http://groups.drupal.org/similar-module-review and http://drupal.org/node/266179 Regards, Greg -- Greg Knaddison | 303-800-5623 | http://growingventuresolutions.com Mastering Drupal - http://www.masteringdrupal.com
I tend to agree with Greg here. And will add that while duplication may be a problem, the answer should not be to make it harder for people to contribute, but to make it easier to figure out why you should use one module over another. It may be a harder way to solve the original problem, but please don't make it harder than it already is for people to contribute. On Wed, Nov 18, 2009 at 7:50 AM, Greg Knaddison <Greg@growingventuresolutions.com> wrote:
On Wed, Nov 18, 2009 at 6:42 AM, Pierre Rineau <pierre.rineau@makina-corpus.com> wrote:
My though is that on d.o, it should exist some kind of tag like "core team says YAY! to this module" and "core team totally disapprove this ugly module", which should help users to get stable, maintainable, and non abandoned modules.
The "core team" - it would be nice to meet these mythical folks. Could you make a list of who they are? (point being: maintaining that list is more trouble than it's worth)
Duplication is a problem, but removing duplication is only one answer. The other answer is better documentation of the differences. There's lots of great work toward that in http://groups.drupal.org/similar-module-review and http://drupal.org/node/266179
Regards, Greg
-- Greg Knaddison | 303-800-5623 | http://growingventuresolutions.com Mastering Drupal - http://www.masteringdrupal.com
-- ~Jerad Bitner CTO ~ Rapid Waters Development http://rapidwatersdev.com
On Wed, 2009-11-18 at 07:50 -0700, Greg Knaddison wrote:
The "core team" - it would be nice to meet these mythical folks. Could you make a list of who they are? (point being: maintaining that list is more trouble than it's worth)
They probably not are human beings (joke), but as many people like to write books about which modules to use in everyday's life, some of them could tag it on d.o "This module rocks say's John doe's book!" :)
Duplication is a problem, but removing duplication is only one answer. The other answer is better documentation of the differences. There's lots of great work toward that in http://groups.drupal.org/similar-module-review and http://drupal.org/node/266179
Removing is not always a solution. I mean sometimes duplicates exists for political reasons, like people making fork of another software. May be because of coding standards, may be because maintainer is a jerk, may be because performance and scalability is not the same, may be because roadmap is not the same. There is hundreds of valid reasons for which duplicates can exists. I don't say this is good, but this is no bad neither. The only bad thing if for end user, because it confuses him. Pierre.
In principle this sounds like a good idea to me, but I wonder who's doing the reviewing, who's doing the approving, and whether it would in fact work as you describe. Would the community enforce the standards you describe? By some kind of informal agreement?
Simply posting to the dev list to open up a dialogue concerning your module will yield a discussion that will probably lean towards a yes or no. So yes, it would be by some kind of informal agreement. Who would give permission to create the project? I would say the same ppl who grant CVS access. It would be a matter of incrementing a counter for the user.
On the other hand, the initial approval makes sure that the developer has a useful and sound contribution to make. After that they're initiated into the community and its standards, and I think it's reasonable to expect them to continue to abide by those standards.
I'm sure we all agree that the module boom is caused by those same developers that were initiated. I'm not trying to avoid duplicates or anything here, I'm simply laying out an option that would force highlighting a potential project before it's magically created without anyone's knowledge or consent. I tend to agree with Greg here. And will add that while duplication
may be a problem, the answer should not be to make it harder for people to contribute, but to make it easier to figure out why you should use one module over another. It may be a harder way to solve the original problem, but please don't make it harder than it already is for people to contribute.
I don't disagree with Greg and I don't see this as an additional barrier at all, rather than creating a project in the dark without anyone's knowledge I simply have to post to dev first to get approval. Is that a barrier? The only person objecting to this would be someone who doesn't want to inform the community before creating his project, this is exactly the person we want to stop by enforcing permission per project rather than one permission per unlimited # of projects. Also note that this change is a very simple one that would require minimum effort with huge benefits, enabling a module such as node limit for the project content type, and creating a little script that would set its value to the current # of projects per user could be all that is required. For CVS admins it's a matter of incrementing the counter for a user if his module suggestion gets approved on the dev list. AA
On Wed, 18 Nov 2009 Pierre Rineau wrote:
My though is that on d.o, it should exist some kind of tag like "core team says YAY! to this module" and "core team totally disapprove this ugly module", which should help users to get stable, maintainable, and non abandoned modules.
http://drupal.org/project/usage The above link should be enough to provide which modules are stable as well as the most useful. The above link is given on the http://drupal.org/project/Modules page. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
On Tue, Nov 24, 2009 at 10:01 AM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
On Wed, 18 Nov 2009 Pierre Rineau wrote:
My though is that on d.o, it should exist some kind of tag like "core team says YAY! to this module" and "core team totally disapprove this ugly module", which should help users to get stable, maintainable, and non abandoned modules.
http://drupal.org/project/usage
The above link should be enough to provide which modules are stable as well as the most useful.
I disagree. The project usage statistics are a simple popularity contest among sites which report statistics. There are lots of sites which do not report statistics. There are high quality modules which have limited audiences, making them less popular. There are even a number of modules which are of poor quality which have high usage, because they meet a high-demand need, but for which no one else has written a high-quality module. Usage statistics are only one approximate measure of good modules.
A comment period would help with this. One problem with all the approval strategies is that there are so many modules nobody has enough bandwidth to pay attention. However, if there were enough bandwidth, I would propose not an approval scheme but just a comment period. If you had to describe your module and then wait 48 hours for comments, (and there were smart people listening) then the issues of duplication might be avoided. Requiring a comment period, rather than requiring "approval" would keep the whole process completely open, but allow some possibility of correction of our current problems. Finally, I think we should make it clear to people that if you contribute a module, you're expected to maintain it, or at least figure out how to get it maintained. I know there are a number of module contributors who have just dropped code into CVS and left it there for ever. Perhaps we should ask them to check a checkbox "I agree to maintain this module". -Randy On Wed, Nov 18, 2009 at 8:30 AM, Ashraf Amayreh <mistknight@gmail.com>wrote:
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
-- Randy Fay Drupal Development, troubleshooting, and debugging randy@randyfay.com +1 970.462.7450
Finally, I think we should make it clear to people that if you contribute a module, you're expected to maintain it, or at least figure out how to get it maintained. I know there are a number of module contributors who have just dropped code into CVS and left it there for ever. Perhaps we should ask them to check a checkbox "I agree to maintain this module".
No harm in that, although as I was doing my reading to prepare to contribute my first module, that message came through amply in the introductory materials.
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).
In principle this sounds like a good idea to me, but I wonder who's doing the reviewing, who's doing the approving, and whether it would in fact work as you describe. Would the community enforce the standards you describe? By some kind of informal agreement?
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.
You can see it either way. You're right that there's an inconsistency. When my original application for a CVS account was denied, it seemed unfair to me that I could have created the same module without any need for approval, if I'd already gotten a CVS account for a different project. On the other hand, the initial approval makes sure that the developer has a useful and sound contribution to make. After that they're initiated into the community and its standards, and I think it's reasonable to expect them to continue to abide by those standards. Andrew.
Before one tries to solve a problem, it would be interesting to prove or provide evidence that it exists. As a module maintainer, I think REALLY HARD before considering creating a new module on CVS, because I know what maintaining a module entails, and I've already worked hard to try and get others involved in my own issue queue. I lean towards looking for duplicate modules cause I want to pair up with people to lessen my own workload. If I post a module, I've already tried to find another module that does something similar, and when possible have tried to float patches against that module to get it to do what I want it to do. Because I KNOW my time is limited. I don't think that I'm alone here. Anecdotes don't count here. If we've got 5000+ modules, how many of these are duplicates posted by maintainers of other modules. My bet is the number is really low, and not worth investing a ton of time in. Show me da numbers.... :) On Nov 18, 2009, at 4:08 AM, 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?
AA
On Sat, Oct 24, 2009 at 4:35 AM, Jeff Greenberg <jeff@ayendesigns.com> wrote: Dave Reid wrote:
Again, how can one person know that one line is useful to the entire community if other people don't speak up about it? It requires the community to be involved in the process and not reacting to just when there are problems.
Right, then if one person isn't qualified to know whether it would be useful to the community, let the community decide by downloading it or not.
-- Ashraf Amayreh http://aamayreh.org
OK. I can't possibly go through all the modules, so what I did was a quick search in the 6.x modules to see what I can find. Note that I'm not saying these are EXACT replica of each other, but I'm sure everyone would agree that it would have been better to collaborate on one and incorporate all features rather than creating new modules to achieve *some* added functionality. The ones I'm not sure about I'm adding a question mark after. Search "Notify" - Comment Notify - Notify - Comment Subscribe - Watchlist (?) - Subscriptions - Notifications Search "Aggregation" - Aggregation (mine) - Content Aggregator - Feeds (the successor of feedAPI? I definitely didn't hear anything about this, was it announced on the dev list? If so, my mistake.) - FeedAPI - Feed Field (?) - KML Parser (FeedAPI addon) - FeedAPI comments (FeedAPI addon) - FeedAPI Data (FeedAPI addon) - ical feed parser (feedAPI addon) - CSV parser (feedAPI addon) - Planet (?) - FeedAPI Image Grabber (feedAPI addon) If we say that there is only ONE module that mimics another (not 6+ as above) then the number of modules will drop to about 2500, if we say TWO modules then it could even fall down to near 1600. If each module developer HAD TO post to the list before being able to create his project the result could have been much better. Currently there's no holding any CVS owner from creating as many new modules without even doing basic research and no one can know it happened or object to it. I'm VERY sure this would be different if they HAD TO post to the dev list first before being able to create their projects. Again, I suggested very reasonable and easily implementable suggestions that no one has really addressed directly yet. If my idea is a problem then I would like to someone to point the drawbacks. Seeing that this will only affect people who already have a CVS account then please don't use the "barrier" argument as a response. Regards, Ashraf Amayreh
On Thu, Nov 19, 2009 at 4:21 AM, Ashraf Amayreh <mistknight@gmail.com> wrote:
Note that I'm not saying these are EXACT replica of each other, but I'm sure everyone would agree that it would have been better to collaborate on one and incorporate all features rather than creating new modules to achieve *some* added functionality. The ones I'm not sure about I'm adding a question mark after.
Search "Notify" - Comment Notify - Notify - Comment Subscribe - Watchlist (?) - Subscriptions - Notifications
Please see: http://groups.drupal.org/node/15928 It explains the difference and is linked from most (if not all) of those project pages. There are substantive differences and good reasons for the duplication (except for comment subscribe, but that was a short-lived dup which is now marked abandoned). If anything this set proves that a review by well meaning but underinformed person will find non-dupes that appear to be dups and that in fact duplication is OK or even valuable.
If each module developer HAD TO post to the list before being able to create his project the result could have been much better. Currently there's no holding any CVS owner from creating as many new modules without even doing basic research and no one can know it happened or object to it. I'm VERY sure this would be different if they HAD TO post to the dev list first before being able to create their projects. Again, I suggested very reasonable and easily implementable suggestions that no one has really addressed directly yet. If my idea is a problem then I would like to someone to point the drawbacks. Seeing that this will only affect people who already have a CVS account then please don't use the "barrier" argument as a response.
This is headed in the wrong direction, I think. We should always strive to make the lives of contributors easier. Putting up barriers to contribution is not a way to maintain or accelerate our projects momentum. Regards, Greg -- Greg Knaddison | 303-800-5623 | http://growingventuresolutions.com Mastering Drupal - http://www.masteringdrupal.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Spotted this that might maybe explain one cause for module number inflation (I too am not convinced number of modules it's actually a problem):- On 19/11/09 12:21, Ashraf Amayreh wrote:
Note that I'm not saying these are EXACT replica of each other, but I'm sure everyone would agree that it would have been better to collaborate on one and incorporate all features rather than creating new modules to achieve *some* added functionality.
Search "Aggregation" (two snipped plus feeds see below) - FeedAPI - Feed Field (?) - KML Parser (FeedAPI addon) - FeedAPI comments (FeedAPI addon) - FeedAPI Data (FeedAPI addon) - ical feed parser (feedAPI addon) - CSV parser (feedAPI addon) (one more) - FeedAPI Image Grabber (feedAPI addon)
All of these ARE modules that work and collaborate together. You actually missed lots of feedapi addons: feedapi_eparser, feedapi_dedupe, feedapi_languagedetect, feedapi_tagger (there are more, sorry for modules I missed, just running off the top of my head). The architecture of FeedAPI means that you don't have do everything in one module. People can add their special functionality in separate modules and share this with other people that might need it. There are an increasing number of good well written extensible modules that are being written. Module inflation here is good :)
- Feeds (the successor of feedAPI? I definitely didn't hear anything about this, was it announced on the dev list? If so, my mistake.)
Can't remember if it was on this list, but there's a great description of why it's the successor of FeedAPI module here http://developmentseed.org/blog/2009/nov/03/good-bye-feedapi-hello-feeds Cheers, -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAksFUGQACgkQR9het8OQC6WpAwCfUVUIS4kCvXBlhiqxHD3aj65P 0qUAnRXTxrCt5YYEog6YuzoEQIVG1rbe =NYVO -----END PGP SIGNATURE-----
Ashraf Amayreh wrote:
If each module developer HAD TO post to the list before being able to create his project the result could have been much better. Currently there's no holding any CVS owner from creating as many new modules without even doing basic research and no one can know it happened or object to it. I'm VERY sure this would be different if they HAD TO post to the dev list first before being able to create their projects. Again, I suggested very reasonable and easily implementable suggestions that no one has really addressed directly yet. If my idea is a problem then I would like to someone to point the drawbacks. Seeing that this will only affect people who already have a CVS account then please don't use the "barrier" argument as a response.
Regards, Ashraf Amayreh
If adding modules to Drupal.org becomes too difficult, people will not bother and will just host them elsewhere, in a dozen different elsewhere's. That's the worst possible scenario, and if anything would make duplication worse because there wouldn't even be a single collection to check for existing modules. --Larry Garfield
Quoting Andrew Schulman <andrex@alumni.utexas.net>:
You could always build it out as a contrib module, though. It sounds pretty useful.
Thanks. Unfortunately, when I tried that the CVS masters said that my proposed module was "too simple" to justify granting me an account (http://drupal.org/node/606962).
It's true, the feature is quite simple. It really should just be integrated into core. But that obviously isn't possible for D6 or 7, which is helpful to know. I'm looking now for another module that could easily integrate the feature, but if I don't find one I'll go back to the CVS masters and try again.
Looks like Kiam's decision was overridden and you now have CVS access. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
On 2009-10-23, at 7:21 AM, Andrew Schulman wrote:
It's true, the feature is quite simple. It really should just be integrated into core.
I wonder if this feature would be best implemented as an action in VBO for D6: http://drupal.org/project/views_bulk_operations
It's true, the feature is quite simple. It really should just be integrated into core.
I wonder if this feature would be best implemented as an action in VBO for D6:
It does seem to sort of fit there. The problem though, is that then it would depend on both views and vbo, which are fairly heavyweight modules. I've looked around for other admin or multilanguage-related modules where this feature might fit, but I haven't found any good candidates yet. I think there were one or two but again they seemed pretty heavyweight for someone who wanted just this small feature. Another option to make the module more worthwhile on its own, would be to expand it to include other bulk node operations. That would be fine, but I don't happen to have any others at present. Anyone know of any other candidates? Any thoughts about the best name for a module that currently just provides a language bulk set operation? * Language bulk set: narrowest and currently most accurate. * Language bulk operations: room to expand. * Node bulk operations: lots of room for future growth, but a bit grandiose for a module that currently only provides one operation. Thanks, Andrew.
It's true, the feature is quite simple. It really should just be integrated into core.
I wonder if this feature would be best implemented as an action in VBO for D6:
VBO works on a different form than admin/content/node, but both forms have bulk update operations, and Dave Reid points out that this feature could go into both places. I'll offer it as a patch for VBO as soon as I can get to it.
participants (33)
-
Aaron Winborn -
Adam Gregory -
Andrew Berry -
Andrew Schulman -
Antonio P. P. Almeida -
Ashraf Amayreh -
Bill Fitzgerald -
Cameron Eagans -
Chris Johnson -
Damien Tournoud -
Daniel F. Kudwien -
Daniel Honrade -
Dave Reid -
David Metzler -
Earnie Boyd -
ekes -
Gerhard Killesreiter -
Greg Knaddison -
Greg Knaddison -
info＠marcvangend.nl -
Jeff Greenberg -
Jennifer Hodgdon -
Jerad Bitner -
Ken Winters -
Kevin Reynen -
Larry Garfield -
larry＠garfieldtech.com
-
Matt Chapman -
Moshe Weitzman -
Pierre Rineau -
Randy Fay -
Scott Reynen -
Shai Gluskin