Consolidating duplicate contrib modules for D7
I know the whole 'duplication in contrib' issue has been discussed to death on this list, so I will try to keep this short. Obviously, the duplication in contrib is something we are working hard as a community to avoid. Nevertheless, in some cases, duplication has still crept in, and this leads to a poorer user experience, and user confusion. One prime example is the node access modules, which all perform nearly identical functions with more or less polish: Node Access: http://drupal.org/project/node_access Nodeaccess: http://drupal.org/project/nodeaccess Content Access: http://drupal.org/project/content_access Now, is there anything we as a community can do to clean up this sort of issue in contrib? I realize that in individual cases, the best policy is to post in the issue queues for the individual projects, but on a larger scale, is it worth starting something along the lines of #D7CX to consolidate the dupes in the name of a better user experience?
On 2009-11-30, at 2:44 PM, Brian Vuyk wrote:
Node Access: http://drupal.org/project/node_access Nodeaccess: http://drupal.org/project/nodeaccess
IMO there should be a CVS policy disallowing namespaces to be differentiated with dashes, underscores, spaces, and so on. This is a perfect example of the confusion this can cause.
is it worth starting something along the lines of #D7CX to consolidate the dupes in the name of a better user experience?
I think that if this is something you want to do, you should try and find some of the more popular maintained modules and try to get one or two sets of projects on board. Once there are a few big projects starting down this path, I think it would really help to encourage the smaller projects to work together. --Andrew
I think the important part is giving users good information. Asking the docs team to write module comparison pieces is a good thing too. But I'm against any plan that tries to put controls on module creation because the freedom to scratch an itch has led to great creativity and ingenuity. But helping module developers know what is already out there, that's always a good thing. When the d.o. re-design launches, I think it is going to be a different world. And I think it will be a lot clearer where energies should be spent on helping site builders and other Drupal constitutents get what they need. Shai Content2zero Web Development <http://content2zero.com> On Mon, Nov 30, 2009 at 3:22 PM, Andrew Berry <andrewberry@sentex.net>wrote:
On 2009-11-30, at 2:44 PM, Brian Vuyk wrote:
Node Access: http://drupal.org/project/node_access Nodeaccess: http://drupal.org/project/nodeaccess
IMO there should be a CVS policy disallowing namespaces to be differentiated with dashes, underscores, spaces, and so on. This is a perfect example of the confusion this can cause.
is it worth starting something along the lines of #D7CX to consolidate the dupes in the name of a better user experience?
I think that if this is something you want to do, you should try and find some of the more popular maintained modules and try to get one or two sets of projects on board. Once there are a few big projects starting down this path, I think it would really help to encourage the smaller projects to work together.
--Andrew
I think the best solution is a comparison of similar modules on the module's project page. Some maintainers do that and it saves you so much time and trouble. It's easy and non-restrictive and there's nothing that's sacrificed. Martin Am 30.11.2009 um 21:50 schrieb Shai Gluskin:
I think the important part is giving users good information. Asking the docs team to write module comparison pieces is a good thing too. But I'm against any plan that tries to put controls on module creation because the freedom to scratch an itch has led to great creativity and ingenuity. But helping module developers know what is already out there, that's always a good thing.
When the d.o. re-design launches, I think it is going to be a different world. And I think it will be a lot clearer where energies should be spent on helping site builders and other Drupal constitutents get what they need.
Shai Content2zero Web Development
On Mon, Nov 30, 2009 at 3:22 PM, Andrew Berry <andrewberry@sentex.net> wrote: On 2009-11-30, at 2:44 PM, Brian Vuyk wrote:
Node Access: http://drupal.org/project/node_access Nodeaccess: http://drupal.org/project/nodeaccess
IMO there should be a CVS policy disallowing namespaces to be differentiated with dashes, underscores, spaces, and so on. This is a perfect example of the confusion this can cause.
is it worth starting something along the lines of #D7CX to consolidate the dupes in the name of a better user experience?
I think that if this is something you want to do, you should try and find some of the more popular maintained modules and try to get one or two sets of projects on board. Once there are a few big projects starting down this path, I think it would really help to encourage the smaller projects to work together.
--Andrew
You do know about the "Similar Module Review" group, right? http://groups.drupal.org/similar-module-review They review similar modules.
That group is very valuable, but it shouldn't be considered a solution for this issue. The biggest complaint of Drupal is the "steep learning curve" and when you read those complaints you commonly see reference to the situation of multiple modules that provide the same basic features. Sure if someone is patient and has the time they can download all similar modules and see which one is the best for their situation, but who really has that time? Also you get the issue of modules that don't fully uninstall, leaving behind things like settings and sometimes tables, so you end up with artifacts in the database. (Though I got to admit, as someone who used to do a lot of work in PHPBB, the process with Drupal is a lot less painful. Nothing like spending hours copying and pasting in core changes to find out it wasn't exactly what you wanted) As Shai pointed out, there is a good side to this. Sometimes modules start out as essential duplicates of other modules, but as they evolve they become something totally different and/or better. We shouldn't really discourage that as a community. I also believe having the doc team keep up with all the modules and doing comparisons would be a very rough situation. I can only imagine going through and finding all the similar modules, documenting the similarities and differences between them, then once done one of those modules get updated with some new features and you got to go back and do it over. I honestly don't think there will be a simple fix to this problem. At the heart, this issue falls under the umbrella of UX, so any solution should come with a lot of debate and ideas. The overall goal should be to make it as easy as possible for the Drupal noob to find the perfect module for their situation and not have to worry about testing multiple modules providing the same functionality. Jamie Holly http://www.intoxination.net http://www.hollyit.net Zoltan Varady wrote:
You do know about the "Similar Module Review" group, right?
http://groups.drupal.org/similar-module-review
They review similar modules.
Jamie Holly wrote:
That group is very valuable, but it shouldn't be considered a solution for this issue. The biggest complaint of Drupal is the "steep learning curve" and when you read those complaints you commonly see reference to the situation of multiple modules that provide the same basic features. Sure if someone is patient and has the time they can download all similar modules and see which one is the best for their situation, but who really has that time? Also you get the issue of modules that don't fully uninstall, leaving behind things like settings and sometimes tables, so you end up with artifacts in the database. (Though I got to admit, as someone who used to do a lot of work in PHPBB, the process with Drupal is a lot less painful. Nothing like spending hours copying and pasting in core changes to find out it wasn't exactly what you wanted)
As a Drupal newbie but OSS veteran, I will say that Drupal's module system is a little frustrating at times, but FAR better than any other platform with such a diverse set of "modules". Generally I decide based on metadata first and foremost: maturity of the module, and activity level of the maintainer(s). Auditioning modules and worrying about uninstall has not been a problem for me, since I run a local development install and going back to a previous database dump only takes a few seconds. I love how flexible Drupal has been in that regard. I do however think that modules whose names are only different because of punctuation are extremely confusing. I've been through this with node access and site maps. Some kind of namespace duplication checking with an informational warning might be nice. However the most helpful thing so far has been the previously mentioned blocks on the module page describing differences to other modules, and for modules lacking that for some concerned party to create a ticket asking the author to describe the differences, like: http://drupal.org/node/583270 Thanks, JT
Shai Gluskin wrote:
Asking the docs team to write module comparison pieces is a good thing too
NO!!! The comparison pieces should be written by the module developers or one of their advanced users. Nancy E.. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
Differences occur because - development happened in a similar time frame. - developers do not play well with each other. - developer B has contempt for developer A's code - and is not courteous in discussions of said codes weakness so does their own project. - modules seem the same but use wildly differing methods to achieve their results. The problem with the 'have the doc team do it' pretends we have assigned people that will magically carry this out. - They will install various modules on clean test sites. - They will have use cases which will allow the evaluation of the modules in questions - They assume the module contributor in question is responsive and that duplication is the result of 'just happened' instead of hostility between developers. - The modules are actually similar enough in function to be accurately compared. - Users will magically find the module comparison page and it will be up to date. Not really going to happen. The best long term suggestion is to have the maintainers clearly document any differences on their project page (preferably the ones who are second should do this by default). People (devs) who have a need for a module and had to evaluate could submit an issue with a request to have an updated 'difference' description added. Suggested sample text would probably help. A module maintainer is not necessarily willing to go download a similar module if theirs already fills their needs. The ones that are not used die out as tracked on the usage page. I would suggest a linked article on how to evaluate a project for use (and suggest how to get description updates) linked to the top of the Projects page description would be more useful. sepeck On Thu, Dec 3, 2009 at 3:36 PM, nan wich <nan_wich@bellsouth.net> wrote:
Shai Gluskin wrote:
Asking the docs team to write module comparison pieces is a good thing too
NO!!! The comparison pieces should be written by the module developers or one of their advanced users.
Nancy E. Wichmann, PMP
Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
I'm wondering if there is a way to get a lot of these stats onto a page automatically - some way to give a project a tag that puts them in the same category - then a page with an argument for that tag that would pull in the project's stats (issue stats, usage stats, maybe some new activity stats). If we could agree on a good way to do this I would be willing to help champion the feature. Just for the record I totally agree that there should not be regulation, but a way to surface the relevant data better in order for people to 1) understand how to evaluate/compare modules and 2) make it easier for them to do so. On Fri, Dec 4, 2009 at 12:04 PM, Steven Peck <sepeck@gmail.com> wrote:
Differences occur because - development happened in a similar time frame. - developers do not play well with each other. - developer B has contempt for developer A's code - and is not courteous in discussions of said codes weakness so does their own project. - modules seem the same but use wildly differing methods to achieve their results.
The problem with the 'have the doc team do it' pretends we have assigned people that will magically carry this out. - They will install various modules on clean test sites. - They will have use cases which will allow the evaluation of the modules in questions - They assume the module contributor in question is responsive and that duplication is the result of 'just happened' instead of hostility between developers. - The modules are actually similar enough in function to be accurately compared. - Users will magically find the module comparison page and it will be up to date.
Not really going to happen.
The best long term suggestion is to have the maintainers clearly document any differences on their project page (preferably the ones who are second should do this by default). People (devs) who have a need for a module and had to evaluate could submit an issue with a request to have an updated 'difference' description added. Suggested sample text would probably help. A module maintainer is not necessarily willing to go download a similar module if theirs already fills their needs.
The ones that are not used die out as tracked on the usage page.
I would suggest a linked article on how to evaluate a project for use (and suggest how to get description updates) linked to the top of the Projects page description would be more useful.
sepeck
On Thu, Dec 3, 2009 at 3:36 PM, nan wich <nan_wich@bellsouth.net> wrote:
Shai Gluskin wrote:
Asking the docs team to write module comparison pieces is a good thing too
NO!!! The comparison pieces should be written by the module developers or one of their advanced users.
Nancy E. Wichmann, PMP
Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
-- ~Jerad Bitner CTO ~ Rapid Waters Development http://rapidwatersdev.com
Jerad Bitner wrote:
pull in the project's stats (issue stats, usage stats, maybe some new activity stats And of what value are these numbers? IMHO, none. For example, look at the issue queue for Views - does the high number mean it's a bad module? I don't think anyone here would agree with that. Then look at a module that has "only" 2000 users - does that mean it can't be trusted? No, and neither does one with only two users. Activity stats has some value, but very minimal as it doesn't take into account maintainers going on vacation or getting sick. I have seen very few proposed metrics that are worthwhile. In the end, it must be the community who poits out to the duplicate (or similar) module maintainers the situation. And then it is the responsibility of the maintainer(s) to investigate and determine if a synergy is possible.
Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
Not to say that these stats are always an accurate measure of a module - but really, they're all we have right now and better than nothing. It's hard to judge a module explicitly by these stats, but they are helpful and do have value IMNSHO. Saying they have no value at all is spitting in the eye of the people who took the time to gather and implement them. They're what we have available and we should use them. Presenting them in a comparable manner and giving some general guidance as to how they should be used, notices that they are not the only way to judge should be part of the guidance provided. On Fri, Dec 4, 2009 at 2:19 PM, nan wich <nan_wich@bellsouth.net> wrote:
Jerad Bitner wrote:
pull in the project's stats (issue stats, usage stats, maybe some new activity stats
And of what value are these numbers? IMHO, none. For example, look at the issue queue for Views - does the high number mean it's a bad module? I don't think anyone here would agree with that. Then look at a module that has "only" 2000 users - does that mean it can't be trusted? No, and neither does one with only two users. Activity stats has some value, but very minimal as it doesn't take into account maintainers going on vacation or getting sick. I have seen very few proposed metrics that are worthwhile.
In the end, it must be the community who poits out to the duplicate (or similar) module maintainers the situation. And then it is the responsibility of the maintainer(s) to investigate and determine if a synergy is possible.
Nancy E. Wichmann, PMP
Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
-- ~Jerad Bitner CTO ~ Rapid Waters Development http://rapidwatersdev.com
Jerad Bitner wrote:
Saying they have no value at all is spitting in the eye of the people who took the time to gather and implement them You are correct, Jerad. That is not the way I intended that to come across. Certainly they have value; for example, the usage stats help me decide when to drop a release or whether to go to a major release number or minor number. But as a yardstick for whether or not I should implement a module it is pretty meaningless. I have even been the first to implement a module because its project page convinced me that it solved my problem. But then, I also jumped in and submitted patches for the parts that didn't do what I wanted; eventually, the author got even with me and made me a co-maintainer. ;-) Issue stats are useful as well, as long as you know what you are looking for. For example is a module with 1000 open issues (e.g. Views) worse than one with no open issues? You just can't tell from that. The recent activity is useful on some modules, but that depends, again, on how the maintainer works the issue queue. I, for example, tend to work one issue at a time and commit the changes when it is solved. Others, such as Earl, work on several issues at a time and commit them all in one large chunk. Is either wrong? Nope, it's primarily a matter of volume and time available; I envy the capacity of people who can keep their focus like that. As a maintainer, I have learned how to read to issue stats and they can help me decide on using one module over another. But the vast majority of the community does not have, and probably never will have, that knowledge. I have just heard, way too many times, people coming to Drupal and saying "I want to install the most popular modules..." For those people, pretty much any metric we might display will be misused. Another message that needs to be repeated is "Don't let the tail wag the dog." A solution should not be installed until a problem has been identified. This is a big danger in any metrics.
Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
I mistook your comment about uselessness, so thanks for clarifying. Your other comments bring up a good point too, and I wonder if there is a metric that can be drawn from number of users/installs vs. number of open issues vs. size of those issues (#comments) vs. ?something else? - I'm not primarily a statistics whiz by any means, so I'm not sure what metrics could be drawn up. Putting actual words to the methods that we as maintainers use to judge modules and subsequently trying to create a process or metric based upon those words and methods would help a lot of other people without the experience maintainers and other people who are good at evaluating modules have. This is really the goal here, I was just pulling the available stats as examples or metric points to at least start somewhere, get the ball rolling per say. For example, there are a lot of carousel type modules out there, and there is a decent comparison that was written up for this purpose. http://drupal.org/node/418616 So if this type of process could be generalized a little more, even automated to some extent as mentioned with tags and similarity and a useful view of the different metrics we use is a worthy goal IMO. Maybe a place in the module project page for listed features so to use the data in comparison charts... On Fri, Dec 4, 2009 at 3:14 PM, nan wich <nan_wich@bellsouth.net> wrote:
Jerad Bitner wrote:
Saying they have no value at all is spitting in the eye of the people who took the time to gather and implement them
You are correct, Jerad. That is not the way I intended that to come across. Certainly they have value; for example, the usage stats help me decide when to drop a release or whether to go to a major release number or minor number. But as a yardstick for whether or not I should implement a module it is pretty meaningless. I have even been the first to implement a module because its project page convinced me that it solved my problem. But then, I also jumped in and submitted patches for the parts that didn't do what I wanted; eventually, the author got even with me and made me a co-maintainer. ;-)
Issue stats are useful as well, as long as you know what you are looking for. For example is a module with 1000 open issues (e.g. Views) worse than one with no open issues? You just can't tell from that. The recent activity is useful on some modules, but that depends, again, on how the maintainer works the issue queue. I, for example, tend to work one issue at a time and commit the changes when it is solved. Others, such as Earl, work on several issues at a time and commit them all in one large chunk. Is either wrong? Nope, it's primarily a matter of volume and time available; I envy the capacity of people who can keep their focus like that.
As a maintainer, I have learned how to read to issue stats and they can help me decide on using one module over another. But the vast majority of the community does not have, and probably never will have, that knowledge.
I have just heard, way too many times, people coming to Drupal and saying "I want to install the most popular modules..." For those people, pretty much any metric we might display will be misused. Another message that needs to be repeated is "Don't let the tail wag the dog." A solution should not be installed until a problem has been identified. This is a big danger in any metrics.
Nancy E. Wichmann, PMP
Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L.. King, Jr.
-- ~Jerad Bitner CTO ~ Rapid Waters Development http://rapidwatersdev.com
I think this is a fairly accurate assessment, however, I am not convinced that there isn't one other alternative long-term solution we could consider. Personally, I'd like to see us develop a cultural feature in the community where we incorporate into 'the Drupal way' collaboration instead of division. (No I'm not saying we don't do this already, I'm saying we could do more). It's almost always easier to whip out a quick custom module to scratch your own itch than it is to collaborate with an existing module owner to patch their code inorder to abstract it. But the end result is frequently better for both parties and thus should be preferred. 1) Don't Hack Core. 2) Meld modules instead of splintering. 3) Code is gold. etc. etc. On Dec 4, 2009, at 2:04 PM, Steven Peck wrote:
Differences occur because - development happened in a similar time frame. - developers do not play well with each other. - developer B has contempt for developer A's code - and is not courteous in discussions of said codes weakness so does their own project. - modules seem the same but use wildly differing methods to achieve their results.
The problem with the 'have the doc team do it' pretends we have assigned people that will magically carry this out. - They will install various modules on clean test sites. - They will have use cases which will allow the evaluation of the modules in questions - They assume the module contributor in question is responsive and that duplication is the result of 'just happened' instead of hostility between developers. - The modules are actually similar enough in function to be accurately compared. - Users will magically find the module comparison page and it will be up to date.
Not really going to happen.
The best long term suggestion is to have the maintainers clearly document any differences on their project page (preferably the ones who are second should do this by default). People (devs) who have a need for a module and had to evaluate could submit an issue with a request to have an updated 'difference' description added. Suggested sample text would probably help. A module maintainer is not necessarily willing to go download a similar module if theirs already fills their needs.
The ones that are not used die out as tracked on the usage page.
I would suggest a linked article on how to evaluate a project for use (and suggest how to get description updates) linked to the top of the Projects page description would be more useful.
sepeck
On Thu, Dec 3, 2009 at 3:36 PM, nan wich <nan_wich@bellsouth.net> wrote:
Shai Gluskin wrote:
Asking the docs team to write module comparison pieces is a good thing too
NO!!! The comparison pieces should be written by the module developers or one of their advanced users.
Nancy E. Wichmann, PMP
Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
Instead of having the doc team do it, or spending hours on a custom code solution maybe a simpler solution would be better. I was just thinking about the "similar by terms" module. That would help out in this case. Have each project page display similar modules based upon their tags. If modules are properly tagged then the most similar/duplicate ones should show up first. Of course that is a big if, but we could even go a step further and institute something along the lines of community tagging. Jamie Holly http://www.intoxination.net http://www.hollyit.net Steven Peck wrote:
Differences occur because - development happened in a similar time frame. - developers do not play well with each other. - developer B has contempt for developer A's code - and is not courteous in discussions of said codes weakness so does their own project. - modules seem the same but use wildly differing methods to achieve their results.
The problem with the 'have the doc team do it' pretends we have assigned people that will magically carry this out. - They will install various modules on clean test sites. - They will have use cases which will allow the evaluation of the modules in questions - They assume the module contributor in question is responsive and that duplication is the result of 'just happened' instead of hostility between developers. - The modules are actually similar enough in function to be accurately compared. - Users will magically find the module comparison page and it will be up to date.
Not really going to happen.
The best long term suggestion is to have the maintainers clearly document any differences on their project page (preferably the ones who are second should do this by default). People (devs) who have a need for a module and had to evaluate could submit an issue with a request to have an updated 'difference' description added. Suggested sample text would probably help. A module maintainer is not necessarily willing to go download a similar module if theirs already fills their needs.
The ones that are not used die out as tracked on the usage page.
I would suggest a linked article on how to evaluate a project for use (and suggest how to get description updates) linked to the top of the Projects page description would be more useful.
sepeck
On Thu, Dec 3, 2009 at 3:36 PM, nan wich <nan_wich@bellsouth.net> wrote:
Shai Gluskin wrote:
Asking the docs team to write module comparison pieces is a good thing too
NO!!! The comparison pieces should be written by the module developers or one of their advanced users.
Nancy E. Wichmann, PMP
Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
The best long term suggestion is to have the maintainers clearly document any differences on their project page
In addition to this, we need to have ranking system integrated to each project. Drupal has to assign ranks based on usage statics, issue count etc. Users can assign ranks based on features, ease of use, documentation, maintainers co-operation etc. This will give a chance to evolve better module and kickoff duplicates from the game. -- Thanks Sivaji
participants (12)
-
Andrew Berry -
Brian Vuyk -
Jamie Holly -
Jerad Bitner -
JT Justman -
Martin Stadler -
nan wich -
Sam Tresler -
Shai Gluskin -
sivaji j.g -
Steven Peck -
Zoltan Varady