Hi, OK all you wiseasses, now you pissed me off enough to bring these issues into wider public, so tell me what to do in these situations. 1) There is a Drupal module, older than my boots, gets a much needed rewrite by two guys. Comes a third one, and he is, of course, welcome to the party. There is a discussion of what we do and what we not to do. Come next day, said third guy does what we all three agreed not do. Following a debate, he packs his toys and starts a new project. Said third guy contributes heavily to Drupal project for extremely long but quality and quantity does not always correlate. 2) I hand off privatemsg to another maintainer. He wants to go in a direction which neither me nor someone else even higher in the Drupal hierarchy agrees with. We all three come to a happy conclusion and the new maintainer does not go there. Time passes, and another guy, notorious for starting a parallel project, does exactly the thing we agreed on not to do and despite he says it was just experiment with the new Drupal 6 code, the project lives on. NK PS. the project moderation queue would undo Drupal because people would take their not-accepted projects off site. php nuke follows. PS2. 'mob rule' applied to code does not work. Your precious drupalmodules.com which I opposed from day one is an excellent example. captcha rated #2 , cck and views not even in #10, give me a break, this is broken,.
On Tue, Mar 10, 2009 at 3:14 PM, Karoly Negyesi <karoly@negyesi.net> wrote:
so tell me what to do in these situations. 1) There is a Drupal module....he packs his toys and starts a new project
So he started his own project, so what. Move on.
2) I hand off privatemsg to another maintainer...
Your responsibility is over, move on. If you wanted to decide how it was run, you shouldn't have given it up :)
someone else even higher in the Drupal hierarchy lolwat?
Time passes, and another guy, notorious for starting a parallel project, does exactly the thing we agreed on not to do and despite he says it was just experiment with the new Drupal 6 code, the project lives on.
Don't see a big deal here... This circles allllll the way back to what I said a few days ago -- there are modules that are "holy crap, can't live without (cck, views...)" and the rest are handy if you happen to need them. The Holy Crap modules are well maintained and the rest are all over the spectrum. So maybe we need a way to call out "Drupal Seal of Approval" on the "Good" ones (sort of like Nintendo games) In fact, let's do that and charge $150 or something to get reviewed for the seal. Plenty of trusted devs will vet a module for $150. -D
spectrum. So maybe we need a way to call out "Drupal Seal of Approval" on the "Good" ones (sort of like Nintendo games) In fact, let's do that and charge $150 or something to get reviewed for the seal. Plenty of trusted devs will vet a module for $150.
To some degree, chx and I already started that with DrupalToughLove.com. I've entertained the thought of a seal in the past but, unlike video games, one can fix a module to get the seal, then seep back into absolute suckitude. It's not a fair or continued assessment. And we didn't take any money for it (though, my utter lack of time devoted, in turn, to paying things, is what killed the project). -- Morbus Iff ( and i twirled my hair and i popped my gum ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
Morbus, what's your hourly rate on continuing DTL? I am dead serious. And DTL seal would apply only to a given release. I am pretty sure we can get people to actually pay for that. And you know what? I would not say no to a buck or two either. And finally, I am happy to split 30-70, as I know I work less on this project.
spectrum. So maybe we need a way to call out "Drupal Seal of Approval" on the "Good" ones (sort of like Nintendo games) In fact, let's do that and charge $150 or something to get reviewed for the seal. Plenty of trusted devs will vet a module for $150.
To some degree, chx and I already started that with DrupalToughLove.com. I've entertained the thought of a seal in the past but, unlike video games, one can fix a module to get the seal, then seep back into absolute suckitude. It's not a fair or continued assessment.
And we didn't take any money for it (though, my utter lack of time devoted, in turn, to paying things, is what killed the project).
-- Morbus Iff ( and i twirled my hair and i popped my gum ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
----- End Original Message -----
On Tue, Mar 10, 2009 at 3:45 PM, Karoly Negyesi <karoly@negyesi.net> wrote:
Morbus, what's your hourly rate on continuing DTL? I am dead serious. And DTL seal would apply only to a given release. I am pretty sure we can get people to actually pay for that. And you know what? I would not say no to a buck or two either. And finally, I am happy to split 30-70, as I know I work less on this project.
I really liked what I saw on DTL. I would be happy to collaborate, and I'm sure I can get some of the guys in the shop in as well. Feel free to ping me directly with ideas if you'd like -- it's a step in the right direction, at least. -D
Karoly Negyesi wrote:
Morbus, what's your hourly rate on continuing DTL? I am dead serious. And DTL seal would apply only to a given release. I am pretty sure we can get people to actually pay for that. And you know what? I would not say no to a buck or two either. And finally, I am happy to split 30-70, as I know I work less on this project
How about a chip-in bucket and and system for voting on modules to be reviewed apart from maintainer requests? Can we expect a review of Notifications module? ;-) -Matt
On 10-Mar-09, at 6:41 PM, Morbus Iff wrote:
To some degree, chx and I already started that with DrupalToughLove.com.
DTL looked to be very promising. I found the reviews done to be practical in that even though they weren't my modules, they still had good suggestions to apply elsewhere. I was disappointed not to see more reviews. If you had a donation widget set up I think it would get some use, especially if it allowed those donating to vote on a module(s) to be reviewed. --Andrew
On Tue, 10 Mar 2009 22:24:05 -0400 Andrew Berry <andrewberry@sentex.net> wrote:
On 10-Mar-09, at 6:41 PM, Morbus Iff wrote:
To some degree, chx and I already started that with DrupalToughLove.com.
DTL looked to be very promising. I found the reviews done to be practical in that even though they weren't my modules, they still
Jumping in here... not strictly related to these 2 posts. There are thousands modules. If you restrict your interest to 3 or 4 to evaluate a review is useful. If you can't even find the best candidates to compare, a review is like someone donating you a Ferrari and leaving it in an unknown place in Atacama. What I'd find useful would be - better categorisation system and better search system on categories - a flag to check if a module provides an API or is just an application - an activity index (average lines of code changed/time) - a issue queue index (how many issues open, how much people subscribed to them, % of issues closed) Asking developers to list similar modules is asking for good will. Asking for good will generally is not enough, rewarding good will is better. If developers could classify better their modules it would be easier to search for similar modules and developers could make easier to find their own creatures too. Coming up with a good categorisation system isn't easy. I think debtag is trying to achieve a similar target, but I don't know how successfully and how much of their efforts we could share. In each project page there is a link to statistics... but if you're comparing projects you've to open one more page for comparing and the statistics aren't synthetic enough. What I generally end up doing is open 2 to 4 categories, skim through the modules, open several other tabs, read the description of the modules I've opened, shrink the selection as much as possible... download the modules and look at the code, README etc... if really forced install the survivors. Somehow once I have few candidates even if a review of the module may be helpful the decision is going to be based on details that hardly could be expressed synthetically and are very "context" sensitive (specific to the situation I'm trying to solve). At this level you just have to hope the maintainer of the project spent some time to describe what makes its creature special to select further before testing/looking at the code. I don't think developers find very rewarding adding descriptions, maybe they would find more rewarding adding feature lists. Still developers may write modules for very different reasons. I think having a community that *may* support your module *could* be a good reason to promote the diffusion of your module... but it may not be the case... and still you may be contributing in a valuable way to drupal community. Maybe we could let people (other than the maintainers) to "categorise" the project. After all every user have to read the list of projects before choosing one, compare them etc... this efforts are collectively repeated thousands time. It's a pity they get wasted. Use cloud tagging for similarity and categories. And this is rewarding for users... they are going to search through modules more than one time... if they could tag them they would lower their efforts the next time. I hope that every module developer started as a potential module user so he searched at least once in the projects to see is something was fit for its need. Even if I'm planning to start a "duplicate" I'm interested to know other people's approach to my similar problem. I really don't see duplication as a problem. If you've bad developers... even if they could easily find similar modules they may find silly reasons to start new ones. But there may be thousands good reasons for duplication: - a maintainer is not willing to accept changes - framework modules vs. ready to use modules - deadlines - ... A successful project is not determined by "code quality" alone and not every time developers may have common interests. Determining if there is no real good reason for duplicating the functionality of a project is not an easy task. There may be time when the developer is just an asshole... in that case I doubt you can direct his efforts to a more valuable target convincing him to submit patches to another project. So the cost/missed return of one more project developed by an asshole is just the cost in searching through modules, not the sum of the cost of searching through modules and the missed contribution of one more developer to an existing project. On the other hand if you're not dealing with an asshole, he may have had his good reasons to start a new project. Consider that there are modules you could write in an hour and it may take more than an hour to search through the project list and learn how certain modules have to be used... and even when you may find one that nearly fit your needs, it may not just fit your needs as much the one you may write. Of course this is going to happen for the very simplest modules but still the effort of looking through all the list of available modules impact the community much more than having few duplicates of small modules. Lowering the cost of searching and comparing will lower the duplicates. Furthermore... how can you cheaply know if a new module is a duplicate without good search tools? Let alone evaluating if a duplicate will negatively impact the community. Every *effort* to regulate duplication of modules have to pass through better tools to search through modules. Every *effort* to regulate duplication is an *effort* and sincerely the return looks dubious. -- Ivan Sergio Borgonovo http://www.webthatworks.it
Maybe we could let people (other than the maintainers) to "categorise" the project.
Mail, mails, mailing, notify, notifies, notification, subscribe, subscriptions, subscribes and I am sure we will have a few more variations...
On Thu, Mar 12, 2009 at 12:00 PM, Karoly Negyesi <karoly@negyesi.net> wrote:
Maybe we could let people (other than the maintainers) to "categorise" the project.
Mail, mails, mailing, notify, notifies, notification, subscribe, subscriptions, subscribes and I am sure we will have a few more variations...
If only there was a way to make taxonomy synonyms..................
On Thu, Mar 12, 2009 at 12:00 PM, Karoly Negyesi <karoly@negyesi.net> wrote:
Maybe we could let people (other than the maintainers) to "categorise" the project.
Mail, mails, mailing, notify, notifies, notification, subscribe, subscriptions, subscribes and I am sure we will have a few more variations...
If only there was a way to make taxonomy synonyms..................
And a bunch of people to make use of them... though we seem have a nice amount of site maintainers these days... Maybe, maybe.
... and a module which automatically resolved synonyms to real terms. Oh HAI! http://drupal.org/project/synonym_collapsing
Maybe we could let people (other than the maintainers) to "categorise" the project.
Mail, mails, mailing, notify, notifies, notification, subscribe, subscriptions, subscribes and I am sure we will have a few more variations...
If only there was a way to make taxonomy synonyms..................
And a bunch of people to make use of them... though we seem have a nice amount of site maintainers these days... Maybe, maybe.
On Thu, 12 Mar 2009 20:00:50 +0100 (CET) "Karoly Negyesi" <karoly@negyesi.net> wrote:
Maybe we could let people (other than the maintainers) to "categorise" the project.
Mail, mails, mailing, notify, notifies, notification, subscribe, subscriptions, subscribes and I am sure we will have a few more variations...
test_drupal=# select * from to_tsvector('pg_catalog.english', 'Mail, mails, mailing, notify, notifies, notification, subscribe, subscriptions, subscribes'); to_tsvector ------------------------------------------------------------------ 'mail':1,2,3 'notif':6 'notifi':4,5 'subscrib':7,9 'subscript':8 This could be one solution. This dictionary is not configured to use synonyms, but it's just a matter of configuration for PostgreSQL. There should be precooked solutions for MySQL as well. After all if you're making taxonomies searchable term AND term (term OR term) and (term OR term) you're going to solve this problem anyway. Another solution could be to restrict terms to a selection. Collect terms from the community for let's say one week, filter them, post-edit the result and use it. Auto-completion may help avoiding duplicates. Just most "voted" terms may appear. If you expect high load... the project is a success, still the load of collecting terms should be negligible compared to all the other things required to drupal.org. If you don't expect high load... there is no need to worry about performance of a dictionary. To add tags people will have to login. Load to filter synonyms should be tolerable. If spammers use similar techniques they should have a good ROI. Now we have ~40 categories. Reach 400 and the categorisation system will work much better. BIC [1] should have ~6000 leaves. I could do some research about tools available for mysql. drupal.org recently moved to solr, solr has support for synonyms. [1] http://www.bic.org.uk/ -- Ivan Sergio Borgonovo http://www.webthatworks.it
From my perspective, one of the reasons why the question of duplication has been an issue lately is that the community of developers has grown dramatically in the last few years. For many of us, when we started working with drupal we basically knew every module that was in the CVS repo- I'm not sure this is even possible anymore. I think that the question of duplication is maybe the wrong question- for me, I'd like to frame things more in the vein of "how do we help contrib modules have better apis, larger support base, and better functionality?". The Drupal Tough Love project I think is one aspect to how we do this- strong peer review can be a really good foundation to build upon. Secondly, I think we've seen groups of developers gathering around specific functionality which has created at team people helping push contrib code toward core. I would like to see this model expanded- not specifically to push code toward core, but to address areas of functionality that need more coordination. For example, myself, Aaron Winborn, Alex UA, Darrell O'Pry, Roger Lopez, Drewish, Travist and a number of other folks have started a very active conversation of how to address the issue of rich media in drupal as a whole. While each of us maintains multiple projects, some of which very much duplicate aspects of one another's work, we are attempting to create a common set of tools which will enrich all of our projects. We know there are going to be edge cases and duplication of effort here and there- this is completely fine- the point of our work, however, is to provide a common tool kit for developers who want to build off of the joint work and have better integration with the common code and each other's projects. We are actively trying to get as many developers on board with this project so that people who are currently doing work can plan for this functionality as well as help direct the project. For me, I don't want to tell people what to do or how to work. I do however, want to help provide the tools and community that can help people develop high quality work that benefits the entire drupal community. --------------------------------------------------- arthur@24b6.net On Mar 10, 2009, at 10:24 PM, Andrew Berry wrote:
On 10-Mar-09, at 6:41 PM, Morbus Iff wrote:
To some degree, chx and I already started that with DrupalToughLove.com.
DTL looked to be very promising. I found the reviews done to be practical in that even though they weren't my modules, they still had good suggestions to apply elsewhere. I was disappointed not to see more reviews. If you had a donation widget set up I think it would get some use, especially if it allowed those donating to vote on a module(s) to be reviewed.
--Andrew
----- Start Original Message ----- Sent: Tue, 10 Mar 2009 15:37:14 -0700 From: Domenic Santangelo <domenic@workhabit.com> To: development@drupal.org Subject: Re: [development] Duplicated modules
On Tue, Mar 10, 2009 at 3:14 PM, Karoly Negyesi <karoly@negyesi.net> wrote:
so tell me what to do in these situations. 1) There is a Drupal module....he packs his toys and starts a new project
So he started his own project, so what. Move on.
Aye and then I hear until eternity that why does subscriptions and notifications exist. I do not know whether I was right. I wish I knew! I dont. I love when I can code whatever I want because people review it and then someone else makes the decisions. I hate making decisions and living with the responsibility. And even so sometimes we err -- db_rewrite_sql, I look at you... (gone in D7, thanks god)
Time passes, and another guy, notorious for starting a parallel project, does exactly the thing we agreed on not to do and despite he says it was just experiment with the new Drupal 6 code, the project lives on.
Don't see a big deal here...
I would not either if people would not write so passionately against module duplication...
You asked for a suggestion, here are my thoughts: Am Dienstag, den 10.03.2009, 15:14 -0700 schrieb Karoly Negyesi:
Hi,
OK all you wiseasses, now you pissed me off enough to bring these issues into wider public, so tell me what to do in these situations.
1) There is a Drupal module, older than my boots, gets a much needed rewrite by two guys. Comes a third one, and he is, of course, welcome to the party. There is a discussion of what we do and what we not to do. Come next day, said third guy does what we all three agreed not do. Following a debate, he packs his toys and starts a new project. Said third guy contributes heavily to Drupal project for extremely long but quality and quantity does not always correlate.
So what can we learn form this (and many other stories)? My answer to all three examples: we need a better way to make decisions, since this sounds like the third one does not agree in the end and to lay the responsibility in the hand of teams: team members should not only be developers of the module, also developers interested in cooperating / interacting (e.g. via an API) with this module and _users_ of this module and maybe developers of drupal core (since this is also a 'module' that will interact with a contrib module). I want to call this circle decision board. These boards / circles follow the principles of decisioning by sociocracy (no crazy people - a practical approach for some European companies) feel free to ask for more details and / or check http://en.wikipedia.org/wiki/Sociocracy . Means e.g. all decisions are made in consent. Means in difference to consensus: although I'm not very happy with a decision, I'm able to agree, because the decision supports the goals of the community as a whole and the goals of my circle. Each decision is monitored after a period the circle sets (e.g. one year, with next release ...) Each team member (or interested party) can bring up new arguments (e.g. bugs, performance measurements ..) and can ask to decide again over this topic - which can be rejected or accepted - the team decides over it's own topics autonomous. There shall be a hierarchy (!sic) of circles, with drupal core at the top and the 'right' to set the principles for the community as a whole. All circles are interconnected through members, all teams keep public logbooks with their decisions...(and so on). The system of sociocracy ensures, that all voices will be heard, decisions are made based on facts and arguments, also all decisions are evaluated on a regular basis. So if some 'bugs' show up, there is the possibility to fix them. Sociocracy can only be taken as a algorithm, which was invented long before the times of the Internet and open source communities - so if we would want to use it for the drupal community is will be necessary to adopt it to our needs and ability to use the technology. To all: So please don't start a flame war why it would not work, I'm aware of some obsolete aspects of this model – because it was not invented for the drupal community. Can you imagen such a system for the drupal community? I know from using it, that it works. Central is all participants agree to the goals of the community and are willing to (at least) test the system. And in my opinion the groups.drupal.org are a step in this direction – but the groups lag (at least) of clear decisioning, a logbook of all decisions and the evaluation of all decisions. So I ask who is willing to join a group to discuss the principles of decisioning and to test the model of sociocracy in this group? Best Thomas Zahreddin
2) I hand off privatemsg to another maintainer. He wants to go in a direction which neither me nor someone else even higher in the Drupal hierarchy agrees with. We all three come to a happy conclusion and the new maintainer does not go there. Time passes, and another guy, notorious for starting a parallel project, does exactly the thing we agreed on not to do and despite he says it was just experiment with the new Drupal 6 code, the project lives on.
NK
PS. the project moderation queue would undo Drupal because people would take their not-accepted projects off site. php nuke follows. PS2. 'mob rule' applied to code does not work. Your precious drupalmodules.com which I opposed from day one is an excellent example. captcha rated #2 , cck and views not even in #10, give me a break, this is broken,.
On Tuesday 10 March 2009 19:23:15 Thomas Zahreddin wrote:
Means e.g. all decisions are made in consent. Means in difference to consensus: although I'm not very happy with a decision, I'm able to agree, because the decision supports the goals of the community as a whole and the goals of my circle.
Can you imagen such a system for the drupal community?
While I'd need to think hard the appropriateness of decisionmaking support systems for this specific purpose, I'd agree (surprise surprise!) that these types of systems could be a Really Good Thing for the community. If we don't go overboard with it. Hell, I even pulled together a KDI proposal to this effect :) http://groups.drupal.org/node/14775 cheers Sam
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Zahreddin schrieb:
You asked for a suggestion, here are my thoughts:
Am Dienstag, den 10.03.2009, 15:14 -0700 schrieb Karoly Negyesi:
Hi,
OK all you wiseasses, now you pissed me off enough to bring these issues into wider public, so tell me what to do in these situations.
1) There is a Drupal module, older than my boots, gets a much needed rewrite by two guys. Comes a third one, and he is, of course, welcome to the party. There is a discussion of what we do and what we not to do. Come next day, said third guy does what we all three agreed not do. Following a debate, he packs his toys and starts a new project. Said third guy contributes heavily to Drupal project for extremely long but quality and quantity does not always correlate.
So what can we learn form this (and many other stories)?
My answer to all three examples:
we need a better way to make decisions, since this sounds like the third one does not agree in the end and to lay the responsibility in the hand of teams: team members should not only be developers of the module, also developers interested in cooperating / interacting (e.g. via an API) with this module and _users_ of this module and maybe developers of drupal core (since this is also a 'module' that will interact with a contrib module). I want to call this circle decision board.
These boards / circles follow the principles of decisioning by sociocracy (no crazy people - a practical approach for some European companies) feel free to ask for more details and / or check http://en.wikipedia.org/wiki/Sociocracy .
"Sociocracy is a system of governance using consent-based decision making among equivalent individuals and an organizational structure based on cybernetic principles. " The problem in Open Source Software development is that the individuals are usually not equivalent. This is either explicit (one is the maintainer of the project and the other isn't) or implicit (one is longer with the project or whatever).
Means e.g. all decisions are made in consent. Means in difference to
Ponies for everybody...? Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkm3GwYACgkQfg6TFvELooSWMgCfXwGTw/dlKEH624V128qFfEAg TbUAn3Kl/55LXwerQqKDoW0+SdOfvwiy =wrUU -----END PGP SIGNATURE-----
oooooh ponies! On Tue, Mar 10, 2009 at 7:59 PM, Gerhard Killesreiter < gerhard@killesreiter.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thomas Zahreddin schrieb:
You asked for a suggestion, here are my thoughts:
Am Dienstag, den 10.03.2009, 15:14 -0700 schrieb Karoly Negyesi:
Hi,
OK all you wiseasses, now you pissed me off enough to bring these issues into wider public, so tell me what to do in these situations.
1) There is a Drupal module, older than my boots, gets a much needed rewrite by two guys. Comes a third one, and he is, of course, welcome to the party. There is a discussion of what we do and what we not to do. Come next day, said third guy does what we all three agreed not do. Following a debate, he packs his toys and starts a new project. Said third guy contributes heavily to Drupal project for extremely long but quality and quantity does not always correlate.
So what can we learn form this (and many other stories)?
My answer to all three examples:
we need a better way to make decisions, since this sounds like the third one does not agree in the end and to lay the responsibility in the hand of teams: team members should not only be developers of the module, also developers interested in cooperating / interacting (e.g. via an API) with this module and _users_ of this module and maybe developers of drupal core (since this is also a 'module' that will interact with a contrib module). I want to call this circle decision board.
These boards / circles follow the principles of decisioning by sociocracy (no crazy people - a practical approach for some European companies) feel free to ask for more details and / or check http://en.wikipedia.org/wiki/Sociocracy .
"Sociocracy is a system of governance using consent-based decision making among equivalent individuals and an organizational structure based on cybernetic principles. "
The problem in Open Source Software development is that the individuals are usually not equivalent.
This is either explicit (one is the maintainer of the project and the other isn't) or implicit (one is longer with the project or whatever).
Means e.g. all decisions are made in consent. Means in difference to
Ponies for everybody...?
Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkm3GwYACgkQfg6TFvELooSWMgCfXwGTw/dlKEH624V128qFfEAg TbUAn3Kl/55LXwerQqKDoW0+SdOfvwiy =wrUU -----END PGP SIGNATURE-----
I'm fairly new to the Drupal community and I'm also still getting over having my gallbladder removed so if I make no sense or come across in a way that offends you it is not intentional. I think duplicated modules suck. They dilute the water and make it more difficult to determine what to do if you have no experience with the software. There is no easy solution to this problem. It's something that requires one of the parties to accept that the work they have done should be undone which is a hard thing to do. Feedback from experienced users and developers ala DTL is awesome to us noobs. I dove headlong into the process and took over a module that is critical to a project that I'm working on. I took over another module at the request of others who wanted to see it ported to D6. After doing so I discovered that there was another module that does about the same thing. I'm still waiting to see what the port of it looks like before I decide whether or not they are actually duplicates. I've considered submitting patches for the menu system to enhance it's permissioning but have yet to do so due to a lack of time. Introducing bureaucracy and paperwork into the process will reduce the number of people who are willing to spend time on Drupal and will degrade it's value. I spend my day trying to convince others that as a CMS Drupal is our best choice because it is open source and because of the community that keeps it alive. People like chx, webchick, and morbus are the very reason that I am still using Drupal and still pushing for it's usage in the projects that I'm involved in. Core addresses the basics and stays out of the way when I need to do more. And since it isn't heard enough, THANK YOU, to everyone who contributes to Drupal. Your work, energy, and time have made it easier for me to do my job. Jonathan Dale (aka Darthclue) Karoly Negyesi wrote:
Hi,
OK all you wiseasses, now you pissed me off enough to bring these issues into wider public, so tell me what to do in these situations.
1) There is a Drupal module, older than my boots, gets a much needed rewrite by two guys. Comes a third one, and he is, of course, welcome to the party. There is a discussion of what we do and what we not to do. Come next day, said third guy does what we all three agreed not do. Following a debate, he packs his toys and starts a new project. Said third guy contributes heavily to Drupal project for extremely long but quality and quantity does not always correlate.
2) I hand off privatemsg to another maintainer. He wants to go in a direction which neither me nor someone else even higher in the Drupal hierarchy agrees with. We all three come to a happy conclusion and the new maintainer does not go there. Time passes, and another guy, notorious for starting a parallel project, does exactly the thing we agreed on not to do and despite he says it was just experiment with the new Drupal 6 code, the project lives on.
NK
PS. the project moderation queue would undo Drupal because people would take their not-accepted projects off site. php nuke follows. PS2. 'mob rule' applied to code does not work. Your precious drupalmodules.com which I opposed from day one is an excellent example. captcha rated #2 , cck and views not even in #10, give me a break, this is broken,.
Personally, I think duplication in modules is fine. The modules that are useful will get used, the modules that aren't useful will eventually fall off. Sure, time and effort is being duplicated but - this is the developer's choice to duplicate the effort. And sometimes new ideas or methods of doing things can arise from duplications that can be incorporated into other modules or places. -- John Fiala
That would be good, unless we don't have ratings for modules, so no one knows what's good. And drupalmodules.com just doesn't work (see chx's comment above). Dmitri On Mar 10, 2009, at 9:48 PM, John Fiala wrote:
Personally, I think duplication in modules is fine. The modules that are useful will get used, the modules that aren't useful will eventually fall off. Sure, time and effort is being duplicated but - this is the developer's choice to duplicate the effort. And sometimes new ideas or methods of doing things can arise from duplications that can be incorporated into other modules or places.
-- John Fiala
On Wed, Mar 11, 2009 at 4:59 AM, Dmitri Gaskin <dmitrig01@gmail.com> wrote:
That would be good, unless we don't have ratings for modules, so no one knows what's good.
A count of how many sites use that module would be very helpful indeed, I have downloaded modules and then discarded them so download count isn't very helpful. I know there are ethical issues with this, but the update module knows what is in use and given a site owners permission could log that on drupal.org. -- Martin Tomes martin@tomes.org.uk
A count of how many sites use that module would be very helpful indeed, I have downloaded modules and then discarded them so download count isn't very helpful. I know there are ethical issues with this, but the update module knows what is in use and given a site owners permission could log that on drupal.org.
You mean like this? http://drupal.org/project/usage
On Wed, Mar 11, 2009 at 8:57 AM, Nathaniel Catchpole <catch56@googlemail.com
wrote:
A count of how many sites use that module would be very helpful indeed, I
have downloaded modules and then discarded them so download count isn't very helpful. I know there are ethical issues with this, but the update module knows what is in use and given a site owners permission could log that on drupal.org.
You mean like this? http://drupal.org/project/usage
Yes:-) -- Martin Tomes martin@tomes.org.uk
Quoting Martin Tomes <martin@tomes.org.uk>:
On Wed, Mar 11, 2009 at 4:59 AM, Dmitri Gaskin <dmitrig01@gmail.com> wrote:
That would be good, unless we don't have ratings for modules, so no one knows what's good.
A count of how many sites use that module would be very helpful indeed, I have downloaded modules and then discarded them so download count isn't very helpful. I know there are ethical issues with this, but the update module knows what is in use and given a site owners permission could log that on drupal.org.
The update module has no idea how many production sites are using a module. I for one disable the module for production sites. There are others that do the same. Then there are the development sites that try out the module and may never use them. How is that different from the download count? The download count is just a measure of how many looked at the possibility of using the module. And then their are the stupid noobs (me included) who download modules just for the hell of it, try it out and then toss it aside. It was a learning process to discover what Drupal is about. -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://www.4offer.biz/
participants (18)
-
Andrew Berry -
arthur -
bamlhs＠hotmail.com -
Darth Clue -
Dmitri Gaskin -
Domenic Santangelo -
Earnie Boyd -
Gerhard Killesreiter -
Ivan Sergio Borgonovo -
John Fiala -
Karoly Negyesi -
Martin Tomes -
Matt Chapman -
Morbus Iff -
Nathaniel Catchpole -
Patrick Teglia -
Sam Boyer -
Thomas Zahreddin