Wasting time and effort
I've noticed an increasing number of "meta discussions" and I'd like to try to refocus our collective efforts if possible. All of these discussions about regulating contribution module development or only releasing core when the top X modules are upgraded, are more distracting then they are productive in my opinion. It is a dearth of labor not a lack of ideas that is the bottleneck of this project and almost every one of the issues raised could be fixed by more work in place of increased regulation. The ordinary folks who review and create patches on issues are our lifeblood and engine. While it might not be as glorifying as re-imagining the contribution module ecosystem or as easy as writing an email, we notice and value your effort for the real contribution that it is. We dont need more regulation, we need more contribution. So lets pick up our shovels instead of our pens and get to work (myself included). If you don't know how and want to learn how just ask in channel and I'll be happy to help you personally. -mf
here here! On Mon, Mar 9, 2009 at 9:53 AM, Michael Favia <michael@favias.org> wrote:
I've noticed an increasing number of "meta discussions" and I'd like to try to refocus our collective efforts if possible. All of these discussions about regulating contribution module development or only releasing core when the top X modules are upgraded, are more distracting then they are productive in my opinion. It is a dearth of labor not a lack of ideas that is the bottleneck of this project and almost every one of the issues raised could be fixed by more work in place of increased regulation.
The ordinary folks who review and create patches on issues are our lifeblood and engine. While it might not be as glorifying as re-imagining the contribution module ecosystem or as easy as writing an email, we notice and value your effort for the real contribution that it is. We dont need more regulation, we need more contribution. So lets pick up our shovels instead of our pens and get to work (myself included). If you don't know how and want to learn how just ask in channel and I'll be happy to help you personally. -mf
On Mon, Mar 9, 2009 at 12:53 PM, Michael Favia <michael@favias.org> wrote:
I've noticed an increasing number of "meta discussions" and I'd like to try to refocus our collective efforts if possible. All of these discussions about regulating contribution module development or only releasing core when the top X modules are upgraded, are more distracting then they are productive in my opinion. It is a dearth of labor not a lack of ideas that is the bottleneck of this project and almost every one of the issues raised could be fixed by more work in place of increased regulation.
The ordinary folks who review and create patches on issues are our lifeblood and engine. While it might not be as glorifying as re-imagining the contribution module ecosystem or as easy as writing an email, we notice and value your effort for the real contribution that it is. We dont need more regulation, we need more contribution.
Amen to that! Well said ... -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
Thanks for this! On Mon, Mar 9, 2009 at 1:00 PM, Khalid Baheyeldin <kb@2bits.com> wrote:
On Mon, Mar 9, 2009 at 12:53 PM, Michael Favia <michael@favias.org> wrote:
I've noticed an increasing number of "meta discussions" and I'd like to try to refocus our collective efforts if possible. All of these discussions about regulating contribution module development or only releasing core when the top X modules are upgraded, are more distracting then they are productive in my opinion. It is a dearth of labor not a lack of ideas that is the bottleneck of this project and almost every one of the issues raised could be fixed by more work in place of increased regulation.
The ordinary folks who review and create patches on issues are our lifeblood and engine. While it might not be as glorifying as re-imagining the contribution module ecosystem or as easy as writing an email, we notice and value your effort for the real contribution that it is. We dont need more regulation, we need more contribution.
Amen to that!
Well said ... -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
-- Ezra Barnett Gildesgame http://growingventuresolutions.com http://ezra-g.com
First, of course i agree discussing doesn't create good code, coding creates good code. However if we are not taking decisions to more tightly channel module development, i bet we will see the porting of _all_ notifications and _all_ advanced questionnaire modules without any reconsolidation, which would be a great opportunity wasted. But if I am the only one who thinks we will benefit from changing the process a bit, very well, i'll just continue contributing however i can and watch the shit to hit the fan. regards marcel. -- "Obstacles are those frightful things you see when you take your eyes off your goal." -- Henry Ford (1863-1947) Change the world! Vote: http://hfopi.org/vote-future
Marcel Partap wrote:
First, of course i agree discussing doesn't create good code, coding creates good code. However if we are not taking decisions to more tightly channel module development, i bet we will see the porting of _all_ notifications and _all_ advanced questionnaire modules without any reconsolidation, which would be a great opportunity wasted. It is only an opportunity if the authors and users of the module agree it is one. This is something you wont discover on this list. Open an issue, or create a patch and you'll get a much better response from the authors and the community using the module in question. I agree with reducing duplication of effort where possible and I know for a fact that most module developers share our point of view if you're willing to lend a hand.
Additionally, while it does require extra effort, competition is not a bad thing or a waste. It encourages innovation and offers alternative ways to approach the same problem. As common approaches to similar problems develop, projects frequently begin to share a common code base or break out the shared functionality into an API module to reduce duplication of effort. Our attitude towards healthy competition has gotten us this far in open source I'd hate to abandon it now and try to dictate a solution instead.
But if I am the only one who thinks we will benefit from changing the process a bit, very well, i'll just continue contributing however i can and watch the shit to hit the fan. Every patch and review is appreciated by me at least. Thank you. -mf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marcel Partap schrieb:
First, of course i agree discussing doesn't create good code, coding creates good code. However if we are not taking decisions to more tightly channel module development, i bet we will see the porting of _all_ notifications and _all_ advanced questionnaire modules without any reconsolidation, which would be a great opportunity wasted. But if I am the only one who thinks we will benefit from changing the process a bit, very well, i'll just continue contributing however i can and watch the shit to hit the fan.
Your attitude does not match your contribution level to the Drupal project. Maybe consider gracing another project with your presence. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkm1V2YACgkQfg6TFvELooRYQwCfRfq4O991Sse9QkKqTjTrlVl3 exkAoLxdO/HUJtZfswEIEIDvVo5lklfW =BOYm -----END PGP SIGNATURE-----
On Mon, Mar 9, 2009 at 1:52 PM, Gerhard Killesreiter < gerhard@killesreiter.de> wrote:
Marcel Partap schrieb:
First, of course i agree discussing doesn't create good code, coding creates good code. However if we are not taking decisions to more tightly channel module development, i bet we will see the porting of _all_ notifications and _all_ advanced questionnaire modules without any reconsolidation, which would be a great opportunity wasted. But if I am the only one who thinks we will benefit from changing the process a bit, very well, i'll just continue contributing however i can and watch the shit to hit the fan.
Your attitude does not match your contribution level to the Drupal project.
Maybe consider gracing another project with your presence.
gerhard Please stop eating noobz. You will get indigestion. marcel, the translation is : "this is a doocracy, and people will listen more to your argument as you get involved more and have contributions to show". -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
Your attitude does not match your contribution level to the Drupal project. How can you tell. Because i only committed something two times with my CVS account? Not going to waste my time defending myself but a) i'm not a no0b and b) i spent a lot more time fixing issues and creating patches (and learning to code) than you think. rgds marcel.
-- "Obstacles are those frightful things you see when you take your eyes off your goal." -- Henry Ford (1863-1947) Change the world! Vote: http://hfopi.org/vote-future
I don't agree. It can be frustrating that the same meta subjects come up every six months or so, but the fact that they always stir up such a firestorm of interest means there are lots of people that care and haven't yet found a better way to channel there energy. Maybe it would be better for them to search through the list archives, but I don't think so. Drupal changes fast. Some things that were central orthodoxy a year ago have changed, while some seem to be eternal. And Drupal lives because people are passionate about it. Of course, it does seem to be an eternal Drupal tradition that after every outbreak of passionate meta discussion, someone has to say "Everyone stop talking and get back to work". And who am I to argue with tradition :) cheers, -tao Michael Favia wrote:
I've noticed an increasing number of "meta discussions" and I'd like to try to refocus our collective efforts if possible. All of these discussions about regulating contribution module development or only releasing core when the top X modules are upgraded, are more distracting then they are productive in my opinion. It is a dearth of labor not a lack of ideas that is the bottleneck of this project and almost every one of the issues raised could be fixed by more work in place of increased regulation.
The ordinary folks who review and create patches on issues are our lifeblood and engine. While it might not be as glorifying as re-imagining the contribution module ecosystem or as easy as writing an email, we notice and value your effort for the real contribution that it is. We dont need more regulation, we need more contribution. So lets pick up our shovels instead of our pens and get to work (myself included). If you don't know how and want to learn how just ask in channel and I'll be happy to help you personally. -mf
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
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. It's c). We're on crack. Clearly it's those who want everything to stay as is who have clear vision.
-- "Obstacles are those frightful things you see when you take your eyes off your goal." -- Henry Ford (1863-1947) Change the world! Vote: http://hfopi.org/vote-future
On 9-Mar-09, at 2:15 PM, Daniel F. Kudwien wrote:
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?
I think this is a good idea. I was having this conversation with some at DC; we all noted that for our very first contribution, we did a great deal of thinking, planning, and so on, but for subsequent modules they tend to go in without as much attention. I'm sure I'm not the only one who's written code only to discover after that someone else did it under a different name. No one I think really likes duplication without reason. Long term, I think the solution is for search on d.o to continue to improve so that it is easy to tell within a few searches if another module exists. Until then, a "does this exist" queue or mailing list could serve quite nicely. --Andrew
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Andrew Berry Sent: Monday, March 09, 2009 2:38 PM To: development@drupal.org Subject: Re: [development] Wasting time and effort On 9-Mar-09, at 2:15 PM, Daniel F. Kudwien wrote:
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?
I think this is a good idea. I was having this conversation with some at DC; we all noted that for our very first contribution, we did a great deal of thinking, planning, and so on, but for subsequent modules they tend to go in without as much attention. I'm sure I'm not the only one who's written code only to discover after that someone else did it under a different name. No one I think really likes duplication without reason. Long term, I think the solution is for search on d.o to continue to improve so that it is easy to tell within a few searches if another module exists. Until then, a "does this exist" queue or mailing list could serve quite nicely. --Andrew There are new modules listed at http://drupalmodules.com/new-modules/feed. Also, many times before people have used this list to announce new modules, or inquire if someone is already working on something which leads exactly to the feedback that was suggested. But I am against the 'request' verbiage that was used in this idea. Gives the impression that an idea or module has to be approved before being worked on, and that is not an open source ideal at all. In Drupal and other open source projects, the hurdle to success or failure should be as low as possible, and even parallel modules more adequately search the solution space of a problem. All are good things. And yes, the module list has grown from hundreds at 4.7, to thousands now, but that problem will persist as long as Drupal is leading the pack. Greg
There are even new modules listed on drupal.org http://drupal.org/taxonomy/term/14/0/feed http://drupal.org/node/63589 Steven On Mon, Mar 9, 2009 at 2:49 PM, Greg Holsclaw <greg@t2media.com> wrote:
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Andrew Berry Sent: Monday, March 09, 2009 2:38 PM To: development@drupal.org Subject: Re: [development] Wasting time and effort
On 9-Mar-09, at 2:15 PM, Daniel F. Kudwien wrote:
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?
I think this is a good idea. I was having this conversation with some at DC; we all noted that for our very first contribution, we did a great deal of thinking, planning, and so on, but for subsequent modules they tend to go in without as much attention. I'm sure I'm not the only one who's written code only to discover after that someone else did it under a different name. No one I think really likes duplication without reason.
Long term, I think the solution is for search on d.o to continue to improve so that it is easy to tell within a few searches if another module exists. Until then, a "does this exist" queue or mailing list could serve quite nicely.
--Andrew
There are new modules listed at http://drupalmodules.com/new-modules/feed. Also, many times before people have used this list to announce new modules, or inquire if someone is already working on something which leads exactly to the feedback that was suggested.
But I am against the 'request' verbiage that was used in this idea. Gives the impression that an idea or module has to be approved before being worked on, and that is not an open source ideal at all. In Drupal and other open source projects, the hurdle to success or failure should be as low as possible, and even parallel modules more adequately search the solution space of a problem. All are good things. And yes, the module list has grown from hundreds at 4.7, to thousands now, but that problem will persist as long as Drupal is leading the pack.
Greg
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Berry schrieb:
On 9-Mar-09, at 2:15 PM, Daniel F. Kudwien wrote:
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?
I think this is a good idea. I was having this conversation with some at DC; we all noted that for our very first contribution, we did a great deal of thinking, planning, and so on, but for subsequent modules they tend to go in without as much attention. I'm sure I'm not the only one who's written code only to discover after that someone else did it under a different name. No one I think really likes duplication without reason.
There is already a RSS feed of new projects. Everybody who wants to help new authors (and I guess many would appreciate that. Or should, at least.).
Long term, I think the solution is for search on d.o to continue to improve so that it is easy to tell within a few searches if another module exists. Until then, a "does this exist" queue or mailing list could serve quite nicely.
We are trying to improve "findability" as part of the redesign. Everybody who wants to help with this is welcome and should study the drafts from Marc Boulton. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkm1kFYACgkQfg6TFvELooSxwACgkt7yxy8OLe8HlvQJHg4FXLl9 LNQAoL68gj2hTfkubnHSfOHVCQFeaOr6 =5ryQ -----END PGP SIGNATURE-----
On 9-Mar-09, at 5:55 PM, Gerhard Killesreiter wrote:
There is already a RSS feed of new projects. Everybody who wants to help new authors (and I guess many would appreciate that. Or should, at least.).
Thanks - I didn't know that "modules" was in the taxonomy system. The only way I could get a link to it though was through Google. What would it take to have a link to http://drupal.org/taxonomy/term/14/0 placed under Contributor Links, and as a note under node/add/project? --Andrew
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Berry schrieb:
On 9-Mar-09, at 5:55 PM, Gerhard Killesreiter wrote:
There is already a RSS feed of new projects. Everybody who wants to help new authors (and I guess many would appreciate that. Or should, at least.).
Thanks - I didn't know that "modules" was in the taxonomy system. The only way I could get a link to it though was through Google. What would it take to have a link to http://drupal.org/taxonomy/term/14/0 placed under Contributor Links, and as a note under node/add/project?
I guess something like this is already part of the redesign and we'll wait a few weeks longer untill that is finished. If it isn't part of it, please add an issue for it and tag it with "drupal.org redesign". Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkm1quoACgkQfg6TFvELooTj7QCeKRUtdz4BP+SuKkVPYkxWOHTg oIUAoLrXbSo5sVSOSl+hEeRXsl92gYPx =7P9L -----END PGP SIGNATURE-----
On 9-Mar-09, at 7:48 PM, Gerhard Killesreiter wrote:
I guess something like this is already part of the redesign and we'll wait a few weeks longer untill that is finished. If it isn't part of it, please add an issue for it and tag it with "drupal.org redesign".
For anyone interested: http://drupal.org/node/396760 --Andrew
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
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
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
andrew morton wrote:
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.
As has already been pointed out, we already require an application for CVS access. The picture is being painted like anyone off the street can just start committing to the repo, and that's just not the case. Even this level of moderation has it's drawbacks, and here's my true story to prove it: My very first Drupal module was a simple integration with a third party service. I applied for my CVS account, and in the meantime, someone else who already had a CVS account coded and published a practically identical module. Wasted time and effort on their part, because they didn't know about my module because I didn't have permission to publish it yet. To be clear: I'm not arguing against reviewing CVS applicants; this situation almost certainly would only occur with modules as trivial as the one under discussion. I'm just making the point that even the little filtration we have now can be counter-productive. We certainly shouldn't be adding further restrictions. Best, Matt
On Mon, Mar 9, 2009 at 9:52 PM, Matt Chapman <Matt@ninjitsuweb.com> wrote:
As has already been pointed out, we already require an application for CVS access. The picture is being painted like anyone off the street can just start committing to the repo, and that's just not the case.
I think that's really the problem in a lot of cases. New devs get screened but existing ones don't bother. I know in my case I've often done a cursory search but since I know what code I'd need to write, I just jump right in.
Even this level of moderation has it's drawbacks, and here's my true story to prove it:
My very first Drupal module was a simple integration with a third party service. I applied for my CVS account, and in the meantime, someone else who already had a CVS account coded and published a practically identical module. Wasted time and effort on their part, because they didn't know about my module because I didn't have permission to publish it yet.
I think this bit of unused work is really not that large a price to pay for having multiple duplicate modules sprung out on the community with no clear differentiation. It's hard to unbreak the egg. Once there's people using the module you can't really take it back. andrew
On Mon, Mar 9, 2009 at 9:52 PM, Matt Chapman <Matt@ninjitsuweb.com> wrote:
As has already been pointed out, we already require an application for CVS access. The picture is being painted like anyone off the street can just start committing to the repo, and that's just not the case.
I think that's really the problem in a lot of cases. New devs get screened but existing ones don't bother. I know in my case I've often done a cursory search but since I know what code I'd need to write, I just jump right in.
Which prove the findability angle exacty! Many justifications for this filter is to decrease wasted effort (increase collaboration), but if a review board upon release of your new module discovers a prior module, you have already wasted your time (and that of the review board). The only real gain is less module congestion (which is partially solve every major version of Drupal through module die-off), but not removal of wasted energy. Being able to find modules ASAP solves both issues, and thus with limited resources seems the better place for our energies. -Greg
As has already been pointed out, we already require an application for CVS access. The picture is being painted like anyone off the street can just start committing to the repo, and that's just not the case.
It is. And I made the best example myself. If you ever happen(ed) to be in the need for a Lightbox on your web site, then you are faced with two duplicate, I mean, really duplicate modules: Lightbox2 and jLightbox. The latter I am guilty for. And there is nothing I would regret more today. jLightbox was created "overnight", because Lightbox2 was incompatible with something else at that time. What I did not know was: There was already a new branch with a complete rewrite of Lightbox2 in CVS that mostly resulted in being the same as jLightbox. Today, I am still trying to find some time to merge some minor changes back into Lightbox2, and more importantly, write a migration path from jLightbox to Lightbox2. This is just one tiny example for the annoying mess of senseless module duplication on drupal.org. Causes for duplication: - Developer did not search. - Developer did search, but existing module uses different lingo. - Developer did search, but did not realize that existing module does the same in an abstracted way. - Developer was not able to imagine that his contribution would be accepted in existing module. [<-- jLightbox] - Maintainer of existing module did neither accept the contribution nor accept developer as co-maintainer. - Developer was too lazy to grasp the API of existing module, better write a new one. - Developer spent weeks of coding in private, now he must release, even if it's 100% duplicate (ego). - Developer wants to attract clients (ego). - Developer does not know how to patch, just learned how to use CVS from the handbooks. Possibly more. Filtering already published projects will get you the same duplicated results like now, which you still have to research and possibly test. The real issue is, however, that there are many projects that would happily accept contributions, improvements, extensions, and also new co-maintainers. But instead of trying hard to let developers join forces, we allow silly duplication, Drupal users have to suffer from in the end. sun
On Mon, 09 Mar 2009 11:53:32 -0500 Michael Favia <michael@favias.org> wrote:
and get to work (myself included). If you don't know how and want to learn how just ask in channel and I'll be happy to help you personally. -mf
I'd like to know how. I've tons of questions that will make my work better, faster and more drupal friendly. I'm coding and I would like to be able to just concentrate on coding. But I'm not coding in the hyperuranium, we are coding for a project in a community. Is really IRC the best place where to share this knowledge? I just guess there are thousands way to get more productive in the "drupal environment". I'm still catching up while I'm making my mammoth module ready for public consumption. It finally saw the light 3-4 weeks ago (in production on 2 websites) but for a long series of reasons it's not ready for public consumption and I'm scared there are so many things to clean up to make it of "general" use that I won't be able to catch up with the community changes once put it in public consumption. One thing is writing your own stuff for your own itch, one thing is being productive inside a community project. I've been lucky enough I ran in very few problems in drupal code. I'm on the old stable and I reported the few glitches I came across sometimes with snippet of code. Other than IRC is there a place where to learn how to set up a development and testing environment? How do you guys: - check out HEAD, install it, test a patch or write one systematically? - how to work with [dvcs] and drupal csv? - how to monitor commit to core? - how to maintain dev, staging and production? - etc... There are docs on this kind of topic but I think people are running much more functional infrastructure for their development. I'd say this kind of topics should be discussed on a ml and then find their way in the docs. The advantage over IRC is you can keep up, there is an archive on which you can distil the documentation to push to drupal.org and while no one find the time to distil docs you can still make the discussion searchable through google. Michael your offer was very appreciated. I'll try at least to lurk on IRC more. [BTW] sorry for the previous badly trimmed post. I was supposed to 'save to draft' and re-edit later... but my finger slip. I wasn't even sure it was meant to be sent. -- Ivan Sergio Borgonovo http://www.webthatworks.it
On 9-Mar-09, at 3:55 PM, Ivan Sergio Borgonovo wrote:
On Mon, 09 Mar 2009 11:53:32 -0500 Michael Favia <michael@favias.org> wrote:
and get to work (myself included). If you don't know how and want to learn how just ask in channel and I'll be happy to help you personally. -mf
I'd like to know how. I've tons of questions that will make my work better, faster and more drupal friendly.
I'm coding and I would like to be able to just concentrate on coding. But I'm not coding in the hyperuranium, we are coding for a project in a community.
Is really IRC the best place where to share this knowledge?
I just guess there are thousands way to get more productive in the "drupal environment".
I'm still catching up while I'm making my mammoth module ready for public consumption. It finally saw the light 3-4 weeks ago (in production on 2 websites) but for a long series of reasons it's not ready for public consumption and I'm scared there are so many things to clean up to make it of "general" use that I won't be able to catch up with the community changes once put it in public consumption.
One thing is writing your own stuff for your own itch, one thing is being productive inside a community project.
I've been lucky enough I ran in very few problems in drupal code. I'm on the old stable and I reported the few glitches I came across sometimes with snippet of code.
Other than IRC is there a place where to learn how to set up a development and testing environment?
The http://drupal.org/getting-involved section of the handbook has most of the information centralized. I would suggest reading through the "Contribute code" subsection (http://drupal.org/node/10259) and either editing pages directly or creating issues in the Documentation queue for places where things are unclear. -Angie
Tao Starbow wrote:>Drupal changes fast. Some things that were central orthodoxy a year ago have changed, while some seem to be eternal. And Drupal lives because people are passionate about it. Michael Favia wrote: > It is a dearth of labor not a lack of ideas that is the bottleneck of this
project
This snippet from Michael eloquently communicated the intellectual vibrancy (and resulting bottleneck) of our community: We have more (often great) ideas than we can there are person-hours spent implementing them. I found this generally motivational rather than a reason to mute any discussion about improving the methods and tools that we use to collaborate with one another. Regards, Ezra -- Ezra Barnett Gildesgame http://growingventuresolutions.com http://ezra-g.com
I respectfully disagree completely. Software development is not all about solving the latest coding problem. In fact, the so-called "meta discussions" are really the largest and most important part, in a sense. Signal to noise on this list is probably the biggest problem in my view, where noise is defined (by me) as any reply that doesn't add new information or stake a out a different position (hence, most +1 and similar remarks are pretty much noise -- on rare occasion where the temperature of the community needs to be gauged they can be useful). Attempts to squelch opposing views is generally counter-productive, as well. If one is not interested in the topic, delete it. It will save you tons of time and consternation. ..chris On Mon, Mar 9, 2009 at 11:53 AM, Michael Favia <michael@favias.org> wrote:
I've noticed an increasing number of "meta discussions" and I'd like to try to refocus our collective efforts if possible. All of these discussions about regulating contribution module development or only releasing core when the top X modules are upgraded, are more distracting then they are productive in my opinion.
participants (16)
-
Andrew Berry -
andrew morton -
Angela Byron -
Chris Johnson -
Daniel F. Kudwien -
Ezra B. Gildesgame -
Gerhard Killesreiter -
Greg Holsclaw -
Ivan Sergio Borgonovo -
Jerad Bitner -
Khalid Baheyeldin -
Marcel Partap -
Matt Chapman -
Michael Favia -
Steven Peck -
Tao Starbow