FAQ
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?

Search Discussions

  • Andrew Berry at Nov 30, 2009 at 8:22 pm

    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

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 2676 bytes
    Desc: not available
    Url : http://lists.drupal.org/pipermail/development/attachments/20091130/4ee3aa0c/attachment.bin
  • Shai Gluskin at Nov 30, 2009 at 8:50 pm
    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 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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.drupal.org/pipermail/development/attachments/20091130/ca4380e0/attachment.html
  • Martin Stadler at Dec 1, 2009 at 10:29 am
    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
    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
  • Zoltan Varady at Dec 1, 2009 at 11:33 am
    You do know about the "Similar Module Review" group, right?

    http://groups.drupal.org/similar-module-review

    They review similar modules.
  • Jamie Holly at Dec 1, 2009 at 1:46 pm
    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.
  • JT Justman at Dec 3, 2009 at 4:33 pm

    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
  • Nan wich at Dec 3, 2009 at 11:36 pm

    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.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.drupal.org/pipermail/development/attachments/20091203/e6bc43fe/attachment-0001.html
  • Steven Peck at Dec 4, 2009 at 7:04 pm
    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 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 at Dec 4, 2009 at 7:15 pm
    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 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 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
  • Nan wich at Dec 4, 2009 at 9:19 pm

    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.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.drupal.org/pipermail/development/attachments/20091204/ba927e7c/attachment.html
  • Jerad Bitner at Dec 4, 2009 at 9:32 pm
    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 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
  • Nan wich at Dec 4, 2009 at 10:14 pm

    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.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.drupal.org/pipermail/development/attachments/20091204/ab837b77/attachment.html
  • Jerad Bitner at Dec 4, 2009 at 10:32 pm
    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 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
  • Sam Tresler at Dec 4, 2009 at 7:55 pm
    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 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.
  • Jamie Holly at Dec 4, 2009 at 8:11 pm
    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 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.
  • Sivaji j.g at Dec 5, 2009 at 9:02 am

    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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.drupal.org/pipermail/development/attachments/20091205/290e557c/attachment.html
  • Marcel Partap at Dec 8, 2009 at 3:12 am
    [...]
    Totally agree with your analysis but not with the conclusion that creating documentation of duplicate module's differences is a feasible way out. Especially, all problems tied to the fact that there's an individual person who has sole sovereignty over a certain part of the code - ain't tackled a bit. If the maintainer is 'malfunct' (in some way or the other), 'his' module is doomed, even though it's licensed as FOSS. Only way of circumventing the problem is forking - something the Drupal project really, really does not need more of (quite the contrary!).

    Instead, IMHO, the responsibility for contrib code development should move from indiviual people to the collective, i.e. every svn ... uuhm cvs account holder should have commit access to all code. Sounds unmanageable at first but seems to work out very well, f.e. with the KDE project. It's kind of like the shared space 'urban design concept' (http://en.wikipedia.org/wiki/Shared_space) - a lack of strict regulation means individuals have to care a lot more about their interaction with other participants. This way communication _and cooperation_ actually become obligatory to making decisions - consequently a more swarmwork-oriented style of interaction evolves. (..and in contrast to real world shared space traffic, in the rare cases where this process fails and b$ code changes indeed are committed, it's very easy to roll back and rework.)

    So imho Drupal contrib repository should be freed from only-maintainer-writable-restriction to accessible-for-all-devs. The new way of avoiding bogus code commits is not to prohibit developers (who might be perfectly qualified for the task at hand) from changing certain code, but by giving more clearance to everybody. With more power comes more responsibility of course: covert, disagreed code changes are only prevented by social mechanisms, not repository access rights.
    To reiterate: this process works perfectly well for KDE: although i have only done some tiny commits here and there, my SVN account is not limited! Nothing there to prevent me from committing havoc to core kdelibs code straight away, right now... Still - it never happens!

    Proceeding from there, the pitiful situation of duplicate modules with overlapping functionality could be entirely prevented for D7 by
    - identifying with which functionality this has happened in the past
    - collecting ideas for frameworks (such as messaging, search functionality, shopping cart, payment, web questionaires, workflows, file handling - oh wait that one's cared for already) or spotting existing ones most fit to do the job in D7
    - implement frameworks with focus on modularity, customizability
    - port functionality from existing modules to these new interfaces
    - raise the bar on adding new 'isolated' modules

    The switch to D7 is also a good time to introduce these workflow changes, because with the major API restructuring it has seen, most modules will have to change substantially anyways (and be it just to comply with new coding standards) to be in line with HEAD - a good time for converging, tidying up and trashing cruft code constructs from contrib.

    Earlier this year i already tried to win some support for this idea (admittedly a bit differently in form) but for all reasons, failed miserably. Bytes are cheap though so SCNR to bring it up again.

    BTW, using the drupalfr.org GIT mirror for D7 and the infamious tig CLI interface makes the repo really much more friendly to manage - is D7 still not the time to move to a 21st century source control system?

    regards,
    marcel.
    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 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.
    --
    GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT!
    Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
  • Andrew morton at Dec 8, 2009 at 3:22 pm

    On Mon, Dec 7, 2009 at 10:12 PM, Marcel Partap wrote:
    So imho Drupal contrib repository should be freed from only-maintainer-writable-restriction to accessible-for-all-devs. The new way of avoiding bogus code commits is not to prohibit developers (who might be perfectly qualified for the task at hand) from changing certain code, but by giving more clearance to everybody. With more power comes more responsibility of course: covert, disagreed code changes are only prevented by social mechanisms, not repository access rights.
    When I first started working on Drupal back in the 4.6 days that's
    exactly how CVS worked, but we explicitly changed it so that each
    project has a list of approved maintainers. I went back to try to find
    the point on the list where this was discussed but didn't have much
    time. I just wanted to let you know that this was tried and found
    wanting.

    andrew
  • Ken Winters at Dec 8, 2009 at 3:38 pm
    Huge -1 to free-for-all commits in contrib.

    If you want to contribute code to a module, do it by providing a patch
    in the issue queue. The reasons for this are legion:

    * The code needs really needs to go through more than one person
    before it is released to the public. The issue queue is the
    appropriate way to handle that.
    * The maintainer still really should be the only one creating release
    tags, and for that matter is the only one that can edit the project
    page and create the release nodes.
    * Sometimes a change can be great on the surface but have horrible
    consequences. The person who is most likely to know this is the
    maintainer, because they have the most experience with that code.
    Note that core is the extreme of this, with massive interdependence
    and 2 committers.
    * A corollary to the above: the ability to commit is clearly not a
    requirement to contribute, which is clearly evident in the number of
    core contributors.
    * If anything I'd say this would discourage people from contributing a
    module, since other people breaking their code is now a hassle they
    have to deal with. A broken patch file in an issue is neither
    stressful nor urgent.
    * This change doesn't solve any real problem (especially eliminating
    forks). If the maintainer is not doing their job, there is a process
    for replacing them. If that process needs work then fine, but it at
    least mostly works when it is used.

    - Ken Winters

    On Dec 7, 2009, at 10:12 PM, Marcel Partap wrote:
    Instead, IMHO, the responsibility for contrib code development
    should move from indiviual people to the collective, i.e. every
    svn ... uuhm cvs account holder should have commit access to all
    code. Sounds unmanageable at first but seems to work out very well,
    f.e. with the KDE project. It's kind of like the shared space 'urban
    design concept' (http://en.wikipedia.org/wiki/Shared_space) - a lack
    of strict regulation means individuals have to care a lot more about
    their interaction with other participants. This way communication
    _and cooperation_ actually become obligatory to making decisions -
    consequently a more swarmwork-oriented style of interaction evolves.
    (..and in contrast to real world shared space traffic, in the rare
    cases where this process fails and b$ code changes indeed are
    committed, it's very easy to roll back and rework.)

    So imho Drupal contrib repository should be freed from only-
    maintainer-writable-restriction to accessible-for-all-devs. The new
    way of avoiding bogus code commits is not to prohibit developers
    (who might be perfectly qualified for the task at hand) from
    changing certain code, but by giving more clearance to everybody.
    With more power comes more responsibility of course: covert,
    disagreed code changes are only prevented by social mechanisms, not
    repository access rights.
    To reiterate: this process works perfectly well for KDE: although i
    have only done some tiny commits here and there, my SVN account is
    not limited! Nothing there to prevent me from committing havoc to
    core kdelibs code straight away, right now... Still - it never
    happens!
  • Marcel Partap at Dec 9, 2009 at 1:24 am

    I was going to lead this thread die. We had this back in ~2006. It was
    kind of crazy. I don't think it makes sense to go back to it.
    Wait - no, you're right.. The universe is static. Change is impossible, thus reconsidering established practices leads nowhere.
    If someone is interested in following this practice for their own
    module they can do so
    ..how does this improve the issue of 'maintainers' not efficiently cooperating? Where is the incentive to combat feature duplication?
    simply add anyone to the list of maintainers that asks for it.
    Wow, that really sounds so much more like a feasible, well thought through strategic plan...
    Heck what if someone is qualified to _hack_ the code but - not qualified to (co-)'maintain' a module?
    But let's not make a sitewide change without some
    proof that it works well on a few specific projects first.
    Well obviously, KDE doesn't count as an example here - code complexity is drastically lower, little structural fluctuations and it has very few active participants. Not comparable to drupal contrib where a set of independent, highly complicated algorithms has to be professionally maintained by a vast pool of specialists.
    And if the KDE way works well for KDE, this implies nothing for drupal contrib. The fundamental requirements are just too different. Right?
    My personal sense is that when I see more than 3-4 maintainers on a
    project I get concerned that it is probably not architecturally
    consistent and likely poorly maintained (the "everyone thought it
    should be done, anyone can do it, nobody did it" problem).
    This is not about raising the numbers of module maintainers, but about abolishing their sovereignty over code - is this FREE software, or just open? Why do we put code under the GPL in the first place?
    Doing things in a platform framework style sense can be facilitated or blocked by source/development management structures. With current policy, we obviously have not facilitated it enough.
    The Drupal project has grown its very own style regarding code change process, distinct from the development models of other projcts of comparable size and complexity like f.e. the Linux Kernel, WiNE, Xorg , KDE.. You are totally satisfied with it, fine - my opinion is there's room to improve. Anything non-perfect can be done better! :]
    The Wikipedia entry on http://en.wikipedia.org/wiki/Shared_space
    doesn't seem exactly applicable (am I a pedestrian, bicyclist, or
    urban planner in the analogy?)
    whatever you so choose ;-)
    but another apt way to describe an
    environment where anyone can do whatever they please is a "commons" as
    in http://en.wikipedia.org/wiki/Tragedy_of_the_commons
    <cite>
    Tragedy of the commons
    A B-class article from Wikipedia, the free encyclopedia
    The tragedy of the commons refers to a dilemma described in an influential article by that name written by Garrett Hardin and first published in the journal Science in 1968.[1] The article describes a situation in which multiple individuals, acting independently, and solely and rationally consulting their own self-interest, will ultimately deplete a shared limited resource even when it is clear that it is not in anyone's long-term interest for this to happen.[2]
    </cite>
    even with good intent i see no way how this could apply to the drupal open source project. Code is one of the very few things that grows in size if you share it ;)
    PS I ignored the whole "move away from cvs" part of this discussion
    because that is well discussed and well documented at
    http://groups.drupal.org/node/8102 - needs more testers and more code
    first.
    Alright, everybody and his mother is busy doing other stuff. Why don't we put up a huge call for action on the drupal.org frontpage? Theoretically, the pure migration of the repositories should not take more than a few hours, right? If we as the drupal collective don't put it upfront the priority list, obviously it will be completed once hell is (at least half) frozen X-P

    regards,
    marcel
    --
    Preisknaller: GMX DSL Flatrate f?r nur 16,99 Euro/mtl.!
    http://portal.gmx.net/de/go/dsl02
  • Walt Daniels at Dec 9, 2009 at 1:35 am
    Alright, everybody and his mother is busy doing other stuff. Why don't we
    put up a huge call for action on the drupal.org frontpage? Theoretically,
    the pure migration of the repositories should not take more than a few
    hours, right? If we as the drupal collective don't put it upfront the
    priority list, obviously it will be completed once hell is (at least half)
    frozen X-P

    regards,
    marcel
    --

    It's never about the cost of moving the data. It is always about the cost of
    changing the code that uses the data.
  • Cameron Eagans at Dec 8, 2009 at 3:18 pm
    Ooo, huge +1 to both points (contrib free-for-all, and moving to something
    that's not CVS or Subversion). It would be a lot of work to get to that
    point, and would likely not be something that could happen for the Drupal 7
    release, but it sounds like a fair goal for Drupal 8!
    -----
    Cameron Eagans
    Owner, Black Storms Studios, LLC
    http://www.blackstormsstudios.com

    On Mon, Dec 7, 2009 at 8:12 PM, Marcel Partap wrote:

    [...]
    Totally agree with your analysis but not with the conclusion that creating
    documentation of duplicate module's differences is a feasible way out.
    Especially, all problems tied to the fact that there's an individual person
    who has sole sovereignty over a certain part of the code - ain't tackled a
    bit. If the maintainer is 'malfunct' (in some way or the other), 'his'
    module is doomed, even though it's licensed as FOSS. Only way of
    circumventing the problem is forking - something the Drupal project really,
    really does not need more of (quite the contrary!).

    Instead, IMHO, the responsibility for contrib code development should move
    from indiviual people to the collective, i.e. every svn ... uuhm cvs account
    holder should have commit access to all code. Sounds unmanageable at first
    but seems to work out very well, f.e. with the KDE project. It's kind of
    like the shared space 'urban design concept' (
    http://en.wikipedia.org/wiki/Shared_space) - a lack of strict regulation
    means individuals have to care a lot more about their interaction with other
    participants. This way communication _and cooperation_ actually become
    obligatory to making decisions - consequently a more swarmwork-oriented
    style of interaction evolves. (..and in contrast to real world shared space
    traffic, in the rare cases where this process fails and b$ code changes
    indeed are committed, it's very easy to roll back and rework.)

    So imho Drupal contrib repository should be freed from
    only-maintainer-writable-restriction to accessible-for-all-devs. The new way
    of avoiding bogus code commits is not to prohibit developers (who might be
    perfectly qualified for the task at hand) from changing certain code, but by
    giving more clearance to everybody. With more power comes more
    responsibility of course: covert, disagreed code changes are only prevented
    by social mechanisms, not repository access rights.
    To reiterate: this process works perfectly well for KDE: although i have
    only done some tiny commits here and there, my SVN account is not limited!
    Nothing there to prevent me from committing havoc to core kdelibs code
    straight away, right now... Still - it never happens!

    Proceeding from there, the pitiful situation of duplicate modules with
    overlapping functionality could be entirely prevented for D7 by
    - identifying with which functionality this has happened in the past
    - collecting ideas for frameworks (such as messaging, search functionality,
    shopping cart, payment, web questionaires, workflows, file handling - oh
    wait that one's cared for already) or spotting existing ones most fit to do
    the job in D7
    - implement frameworks with focus on modularity, customizability
    - port functionality from existing modules to these new interfaces
    - raise the bar on adding new 'isolated' modules

    The switch to D7 is also a good time to introduce these workflow changes,
    because with the major API restructuring it has seen, most modules will have
    to change substantially anyways (and be it just to comply with new coding
    standards) to be in line with HEAD - a good time for converging, tidying up
    and trashing cruft code constructs from contrib.

    Earlier this year i already tried to win some support for this idea
    (admittedly a bit differently in form) but for all reasons, failed
    miserably. Bytes are cheap though so SCNR to bring it up again.

    BTW, using the drupalfr.org GIT mirror for D7 and the infamious tig CLI
    interface makes the repo really much more friendly to manage - is D7 still
    not the time to move to a 21st century source control system?

    regards,
    marcel.

    --
    GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT!
    Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.drupal.org/pipermail/development/attachments/20091208/58b461b6/attachment.html
  • Greg Knaddison at Dec 8, 2009 at 3:30 pm

    On Tue, Dec 8, 2009 at 8:18 AM, Cameron Eagans wrote:
    Ooo, huge +1 to both points (contrib free-for-all, and moving to something
    that's not CVS or Subversion). It would be a lot of work to get to that
    point, and would likely not be something that could happen for the Drupal 7
    release, but it sounds like a fair goal for Drupal 8!
    I was going to lead this thread die. We had this back in ~2006. It was
    kind of crazy. I don't think it makes sense to go back to it.

    If someone is interested in following this practice for their own
    module they can do so: simply add anyone to the list of maintainers
    that asks for it. But let's not make a sitewide change without some
    proof that it works well on a few specific projects first. My personal
    sense is that when I see more than 3-4 maintainers on a project I get
    concerned that it is probably not architecturally consistent and
    likely poorly maintained (the "everyone thought it should be done,
    anyone can do it, nobody did it" problem).

    The Wikipedia entry on http://en.wikipedia.org/wiki/Shared_space
    doesn't seem exactly applicable (am I a pedestrian, bicyclist, or
    urban planner in the analogy?) but another apt way to describe an
    environment where anyone can do whatever they please is a "commons" as
    in http://en.wikipedia.org/wiki/Tragedy_of_the_commons

    Regards,
    Greg

    PS I ignored the whole "move away from cvs" part of this discussion
    because that is well discussed and well documented at
    http://groups.drupal.org/node/8102 - needs more testers and more code
    first.

    --
    Greg Knaddison | 303-800-5623 | http://growingventuresolutions.com
    Mastering Drupal - http://www.masteringdrupal.com
  • Marcel Partap at Dec 9, 2009 at 2:14 am

    If you want to contribute code to a module, do it by providing a patch
    in the issue queue. The reasons for this are legion:
    Yes, that's the accepted standard approach, and it works well ~90% of the time. But that still means there's a _huge_ number of cases where it _does not work very well_.
    * The code needs really needs to go through more than one person
    before it is released to the public.
    How exactly do you define 'release to the public'? Commiting code to a development branch used only by developers? Or releasing ready-made quality-inspected module packages?
    The issue queue is the appropriate way to handle that.
    Well yes, it is one feasible way to handle it.
    * The maintainer still really should be the only one creating release
    tags, Why?
    and for that matter is the only one that can edit the project
    page and create the release nodes.
    mmh.. What is the key characteristic of the internet project with the hugest growth rate in the last decade? (*)
    * Sometimes a change can be great on the surface but have horrible
    consequences.
    ..ack, had that before ;)
    The person who is most likely to know this is the
    maintainer, because they have the most experience with that code.
    Actually - that's bad for core CMS functionality like messaging, file management, payment, workflow, isn't it? Is it not preferable to have a bigger group of people be involved and familiar to such implementations?
    Note that core is the extreme of this, with massive interdependence
    and 2 committers.
    Yes, but there are more than two people in the project capable of grokking every commit that goes into drupal core. These two 'just' mostly do the (highly critical!) job of judging code readiness (relying heavily of course on opinions voiced on the report thread), plucking the cherries from that big colourful issue queue tree ;==)
    * If anything I'd say this would discourage people from contributing a
    module, since other people breaking their code is now a hassle they
    have to deal with.
    Breaking *whose* code? Is this still free software - or just freeware hosted on a common platform?
    * This change doesn't solve any real problem (especially eliminating
    forks).
    Not by itself, of course.
    We shouldn't do software like some politicians do geopolitics (i.e. 'nicht zuende gedacht' ;)
    If the maintainer is not doing their job, there is a process
    for replacing them.
    Bureaucreacy (how tf is this spelled **g) to solve problems that wouldn't exist without it, we need more of it.
    If that process needs work then fine, but it at
    least mostly works when it is used.
    Might be or not, it is a barrier, putting people off from contributing. And one's persistence to have his work published somewhere on drupal.org might not be correlated to that work's quality (means good sh1t might - instead of automagically being supported - lay stale = double plus bad)..

    regards, marcel.

    * hint: anyone can change any article in wikipedia, anonymously and instantly. That's a NULL height entry barrier.
    --
    GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT!
    Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
  • Daniel F. Kudwien at Dec 9, 2009 at 2:41 am

    How exactly do you define 'release to the public'? Commiting
    code to a development branch used only by developers? Or
    releasing ready-made quality-inspected module packages?
    Almost all projects have development snapshot releases that are repackaged
    every 12 hours. How much more is "public"?

    * The maintainer still really should be the only one
    creating release
    tags,
    Why?
    Because the maintainer is "guilty" for the bugs that users experience,
    regardless of whether its caused by own code, code by co-maintainers, or
    flawed code introduced in patches by contributors. Really, it seems you
    have not maintained any project at all.

    and for that matter is the only one that can edit the project
    page and create the release nodes.
    mmh.. What is the key characteristic of the internet project
    with the hugest growth rate in the last decade? (*)
    You forgot that there is an armada of content moderators in your scenario.
    This armada does not exist, especially not regarding the skill-level. This
    is not about maintaining documentation.

    The person who is most likely to know this is the
    maintainer, because they have the most experience with that code.
    Actually - that's bad for core CMS functionality like
    messaging, file management, payment, workflow, isn't it? Is
    it not preferable to have a bigger group of people be
    involved and familiar to such implementations?
    That's why we have modules, and that's why we promote a proper separation
    between APIs. That's why we have module dependencies. There is no one who
    understands all. But we also don't need someone like that, because it's
    sufficient to understand and focus on a particular sub-system or module.

    Note that core is the extreme of this, with massive
    interdependence and 2 committers.
    Yes, but there are more than two people in the project
    capable of grokking every commit that goes into drupal core.
    These two 'just' mostly do the (highly critical!) job of
    judging code readiness (relying heavily of course on opinions
    voiced on the report thread), plucking the cherries from that
    big colourful issue queue tree ;==)
    Do those other people need to commit? No.

    http://www.unleashedmind.com/en/blog/sun/improving-drupal-cores-development-
    workflow

    * If anything I'd say this would discourage people from
    contributing a
    module, since other people breaking their code is now a
    hassle they have to deal with.
    Breaking *whose* code? Is this still free software - or just
    freeware hosted on a common platform?
    Breaking the code that users want to use.

    If the maintainer is not doing their job, there is a process
    for replacing them.
    Bureaucreacy (how tf is this spelled **g) to solve problems
    that wouldn't exist without it, we need more of it.
    Why would you want to contribute to a project, if you can't establish a
    trust-relationship to the project maintainer? Because, if you can establish
    one, there's little that hinders you from becoming a co-maintainer, or have
    your patches committed quickly.

    Again, we want to encourage contribution and collaboration. Not discourage
    it.


    sun
  • Ken Winters at Dec 9, 2009 at 3:14 am

    On Dec 8, 2009, at 9:41 PM, Daniel F. Kudwien wrote:

    How exactly do you define 'release to the public'? Commiting
    code to a development branch used only by developers? Or
    releasing ready-made quality-inspected module packages?
    Almost all projects have development snapshot releases that are
    repackaged
    every 12 hours. How much more is "public"?
    Exposed to the general public rather than just developers, that is.
    Everyone can download any branch
    of the code regardless, but the recommended releases need to be more
    reliable.

    When someone creates a release node, everyone with update status
    enabled and an older
    version of the module will know about it, and the implication is that
    they should update. Ill-
    advised release creation has caused a lot of grief to a lot of people
    in the past, so this process
    should not be taken lightly. Breaking the devel branch is one thing,
    but breaking the "stable" branch
    and broadcasting is far more disruptive and hardly inspires confidence
    in the module / CMS.

    - Ken Winters
  • Marcel Partap at Dec 9, 2009 at 11:58 pm

    How exactly do you define 'release to the public'? Commiting
    code to a development branch used only by developers? Or
    releasing ready-made quality-inspected module packages?
    Almost all projects have development snapshot releases that are repackaged
    every 12 hours. How much more is "public"?
    Well in that sense, as good as every line of open source software is 'public'. To me 'release to the public' implies a push operation by the developer - post a release statement with download link in some form.
    * The maintainer still really should be the only one
    creating release
    tags,
    Why?
    Because the maintainer is "guilty" for the bugs that users experience,
    regardless of whether its caused by own code, code by co-maintainers, or
    flawed code introduced in patches by contributors.
    Guilt? What's that thinking supposed to be good for.. Personally i much prefer the concept of responsibility.
    Just for example: in the more open KDE development paradigm, for mnst participants, committing to the code means also committing to the quality and success of the code. It actually works(tm).
    Really, it seems you have not maintained any project at all.
    That's correct. I wanted to, but didn't yet get around to.
    and for that matter is the only one that can edit the project
    page and create the release nodes.
    mmh.. What is the key characteristic of the internet project
    with the hugest growth rate in the last decade? (*)
    You forgot that there is an armada of content moderators in your scenario.
    This armada does not exist, especially not regarding the skill-level.
    So how do we loose qualified drupal developers once we take out the only-maintainer-writable? And if we don't, what is the issue here.
    That's why we have modules, and that's why we promote a proper separation
    between APIs. That's why we have module dependencies. There is no one
    who
    understands all. But we also don't need someone like that, because it's
    sufficient to understand and focus on a particular sub-system or module.
    How is anyone forced to come up with greater code insight by merely removing write restrictions on the repository?
    Note that core is the extreme of this, with massive
    interdependence and 2 committers.
    Yes, but there are more than two people in the project
    capable of grokking every commit that goes into drupal core.
    These two 'just' mostly do the (highly critical!) job of
    judging code readiness (relying heavily of course on opinions
    voiced on the report thread), plucking the cherries from that
    big colourful issue queue tree ;==)
    Do those other people need to commit? No.
    Noone _needs_ to - but certain restrictions on who can are also unnecessary.. It's FREE software, is it not?
    http://www.unleashedmind.com/en/blog/sun/improving-drupal-cores-development-
    workflow
    IIUC this post is about CORE development, for which i see NO CHANGE NECESSARY. Core development works just fine the way it is.
    BTW, regarding this core-contrib distinction: i would also count views module to the core area, as it is a vital module but only really understood by very few (so it should be protected from inexperienced eager beavers ;) - and scheduled for inclusion in D8 anyway.
    * If anything I'd say this would discourage people from
    contributing a
    module, since other people breaking their code is now a
    hassle they have to deal with.
    Breaking *whose* code? Is this still free software - or just
    freeware hosted on a common platform?
    Breaking the code that users want to use.
    In a development branch? How awful. None of the other FOSS projects do that.. unstable branches are just named this way to scare people away, not because the code is actually unstable..
    ???
    Release versions should definitely be stable and consistent - but for experimental branches, code breakage is to be expected. Just like with everything that has 6.x-dev in it.
    You didn't actually respond to my main argument btw: the code is ours _as a community_, not the private property of the maintainers - else it would just be freeware, not free software.

    If the maintainer is not doing their job, there is a process
    for replacing them.
    Bureaucreacy (how tf is this spelled **g) to solve problems
    that wouldn't exist without it, we need more of it.
    Why would you want to contribute to a project, if you can't establish a
    trust-relationship to the project maintainer?
    Because i actually and exclusively care about the technical superiority of the code?
    Because, if you can establish one, there's little that hinders you from
    becoming a co-maintainer, or have your patches committed quickly.
    Yes of course. What if it _does not_ work this way. Bugger.
    Again, we want to encourage contribution and collaboration. Not
    discourage it.
    How am i proposing to discourage that, quite the contrary..
    wow this is getting tedious. I really hoped for some more support, but it seems there is only fear from current maintainers that something will be taken away from them. We will probably have the same duplicate modules problem with D7 as with D6, instead of stemming the united effort of consolidating and merging the functionality of thousands of modules into a couple of frameworks and some hundred submodules.

    regards,
    marcel.
    --
    GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT!
    Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
  • Kyle Mathews at Dec 10, 2009 at 12:35 am
    Somewhat of a joke / serious comment -- but if the KDE development process
    is so good -- why does Gnome exist?

    I think some of your ideas Marcel have merit but you're ignoring that a) as
    with everything, there's no silver bullet and b) you're overestimating the
    benefit of your ideas and underestimating the cost in developer time to
    implement the changes and in education to retrain everyone on how drupal
    development happens.

    I think switching to a DCVS-type development would be a great benefit but
    it's not going to happen overnight and it's not going to magically make
    every problem go away.

    --Kyle Mathews

    kyle.mathews2000.com/blog
    http://twitter.com/kylemathews

    On Wed, Dec 9, 2009 at 4:58 PM, Marcel Partap wrote:

    How exactly do you define 'release to the public'? Commiting
    code to a development branch used only by developers? Or
    releasing ready-made quality-inspected module packages?
    Almost all projects have development snapshot releases that are
    repackaged
    every 12 hours. How much more is "public"?
    Well in that sense, as good as every line of open source software is
    'public'. To me 'release to the public' implies a push operation by the
    developer - post a release statement with download link in some form.
    * The maintainer still really should be the only one
    creating release
    tags,
    Why?
    Because the maintainer is "guilty" for the bugs that users experience,
    regardless of whether its caused by own code, code by co-maintainers, or
    flawed code introduced in patches by contributors.
    Guilt? What's that thinking supposed to be good for.. Personally i much
    prefer the concept of responsibility.
    Just for example: in the more open KDE development paradigm, for mnst
    participants, committing to the code means also committing to the quality
    and success of the code. It actually works(tm).
    Really, it seems you have not maintained any project at all.
    That's correct. I wanted to, but didn't yet get around to.
    and for that matter is the only one that can edit the project
    page and create the release nodes.
    mmh.. What is the key characteristic of the internet project
    with the hugest growth rate in the last decade? (*)
    You forgot that there is an armada of content moderators in your scenario.
    This armada does not exist, especially not regarding the skill-level.
    So how do we loose qualified drupal developers once we take out the
    only-maintainer-writable? And if we don't, what is the issue here.
    That's why we have modules, and that's why we promote a proper separation
    between APIs. That's why we have module dependencies. There is no one
    who
    understands all. But we also don't need someone like that, because it's
    sufficient to understand and focus on a particular sub-system or module.
    How is anyone forced to come up with greater code insight by merely
    removing write restrictions on the repository?
    Note that core is the extreme of this, with massive
    interdependence and 2 committers.
    Yes, but there are more than two people in the project
    capable of grokking every commit that goes into drupal core.
    These two 'just' mostly do the (highly critical!) job of
    judging code readiness (relying heavily of course on opinions
    voiced on the report thread), plucking the cherries from that
    big colourful issue queue tree ;==)
    Do those other people need to commit? No.
    Noone _needs_ to - but certain restrictions on who can are also
    unnecessary.. It's FREE software, is it not?
    http://www.unleashedmind.com/en/blog/sun/improving-drupal-cores-development-
    workflow
    IIUC this post is about CORE development, for which i see NO CHANGE
    NECESSARY. Core development works just fine the way it is.
    BTW, regarding this core-contrib distinction: i would also count views
    module to the core area, as it is a vital module but only really understood
    by very few (so it should be protected from inexperienced eager beavers ;) -
    and scheduled for inclusion in D8 anyway.
    * If anything I'd say this would discourage people from
    contributing a
    module, since other people breaking their code is now a
    hassle they have to deal with.
    Breaking *whose* code? Is this still free software - or just
    freeware hosted on a common platform?
    Breaking the code that users want to use.
    In a development branch? How awful. None of the other FOSS projects do
    that.. unstable branches are just named this way to scare people away, not
    because the code is actually unstable..
    ???
    Release versions should definitely be stable and consistent - but for
    experimental branches, code breakage is to be expected. Just like with
    everything that has 6.x-dev in it.
    You didn't actually respond to my main argument btw: the code is ours _as a
    community_, not the private property of the maintainers - else it would just
    be freeware, not free software.

    If the maintainer is not doing their job, there is a process
    for replacing them.
    Bureaucreacy (how tf is this spelled **g) to solve problems
    that wouldn't exist without it, we need more of it.
    Why would you want to contribute to a project, if you can't establish a
    trust-relationship to the project maintainer?
    Because i actually and exclusively care about the technical superiority of
    the code?
    Because, if you can establish one, there's little that hinders you from
    becoming a co-maintainer, or have your patches committed quickly.
    Yes of course. What if it _does not_ work this way. Bugger.
    Again, we want to encourage contribution and collaboration. Not
    discourage it.
    How am i proposing to discourage that, quite the contrary..
    wow this is getting tedious. I really hoped for some more support, but it
    seems there is only fear from current maintainers that something will be
    taken away from them. We will probably have the same duplicate modules
    problem with D7 as with D6, instead of stemming the united effort of
    consolidating and merging the functionality of thousands of modules into a
    couple of frameworks and some hundred submodules.

    regards,
    marcel.
    --
    GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT!
    Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.drupal.org/pipermail/development/attachments/20091209/212a32a4/attachment-0001.html
  • Matt Chapman at Dec 10, 2009 at 1:19 am

    On Wed, Dec 9, 2009 at 4:35 PM, Kyle Mathews wrote:
    Somewhat of a joke / serious comment -- but if the KDE development process
    is so good -- why does Gnome exist?
    Because of licensing religion, but that's a whole 'nother ball of wax...
    I think switching to a DCVS-type development would be a great benefit but
    it's not going to happen overnight and it's not going to magically make
    every problem go away.
    No one claimed to be able to solve EVERY problem. According to the
    thread title, the problem being solved is the duplication of modules.
    And neither a DCVS nor a commit-access free-for-all will ultimately
    solve that. People are going to disagree about what the objectives for
    a module should be, and there going to disagree about what constitutes
    "technical superiority."

    The solution to such roadblocks is social, not technical. Good
    old-fashioned human interaction, communication, deference, and mutual
    respect. "Blessed are the peacemakers...."

    Showing up and demanding that everything change in a workflow that
    you've never participated in... that's not going to win friends and
    influence people, and it's not going to produce better code or fewer
    duplicate modules either.

    Of course, I'm biased, because I think duplicate modules are largely a
    good thing. Let natural selection take it's course, I say.

    One thing is for sure: KDE and Gnome wouldn't be nearly as good as
    they are today if they weren't constantly stealing and improving on
    ideas from one another.

    All the Best,

    Matt






    On Wed, Dec 9, 2009 at 4:58 PM, Marcel Partap wrote:

    How exactly do you define 'release to the public'? Commiting
    code to a development branch used only by developers? Or
    releasing ready-made quality-inspected module packages?
    Almost all projects have development snapshot releases that are
    repackaged
    every 12 hours. ?How much more is "public"?
    Well in that sense, as good as every line of open source software is
    'public'. To me 'release to the public' implies a push operation by the
    developer - post a release statement with download link in some form.
    * The maintainer still really should be the only one
    creating release
    tags,
    Why?
    Because the maintainer is "guilty" for the bugs that users experience,
    regardless of whether its caused by own code, code by co-maintainers, or
    flawed code introduced in patches by contributors.
    Guilt? What's that thinking supposed to be good for.. Personally i much
    prefer the concept of responsibility.
    Just for example: in the more open KDE development paradigm, for mnst
    participants, committing to the code means also committing to the quality
    and success of the code. It actually works(tm).
    Really, it seems you have not maintained any project at all.
    That's correct. I wanted to, but didn't yet get around to.
    and for that matter is the only one that can edit the project
    page and create the release nodes.
    mmh.. What is the key characteristic of the internet project
    with the hugest growth rate in the last decade? (*)
    You forgot that there is an armada of content moderators in your
    scenario.
    This armada does not exist, especially not regarding the skill-level.
    So how do we loose qualified drupal developers once we take out the
    only-maintainer-writable? And if we don't, what is the issue here.
    That's why we have modules, and that's why we promote a proper
    separation
    between APIs. ?That's why we have module dependencies. ?There is no one
    who
    understands all. ?But we also don't need someone like that, because it's
    sufficient to understand and focus on a particular sub-system or module.
    How is anyone forced to come up with greater code insight by merely
    removing write restrictions on the repository?
    Note that core is the extreme of this, with massive
    interdependence and 2 committers.
    Yes, but there are more than two people in the project
    capable of grokking every commit that goes into drupal core.
    These two 'just' mostly do the (highly critical!) job of
    judging code readiness (relying heavily of course on opinions
    voiced on the report thread), plucking the cherries from that
    big colourful issue queue tree ;==)
    Do those other people need to commit? ?No.
    Noone _needs_ to - but certain restrictions on who can are also
    unnecessary.. ?It's FREE software, is it not?
    IIUC this post is about CORE development, for which i see NO CHANGE
    NECESSARY. Core development works just fine the way it is.
    BTW, regarding this core-contrib distinction: i would also count views
    module to the core area, as it is a vital module but only really understood
    by very few (so it should be protected from inexperienced eager beavers ;) -
    and scheduled for inclusion in D8 anyway.
    * If anything I'd say this would discourage people from
    contributing a
    module, since other people breaking their code is now a
    hassle they have to deal with.
    Breaking *whose* code? Is this still free software - or just
    freeware hosted on a common platform?
    Breaking the code that users want to use.
    In a development branch? How awful. None of the other FOSS projects do
    that.. unstable branches are just named this way to scare people away, not
    because the code is actually unstable..
    ???
    Release versions should definitely be stable and consistent - but for
    experimental branches, code breakage is to be expected. Just like with
    everything that has 6.x-dev in it.
    You didn't actually respond to my main argument btw: the code is ours _as
    a community_, not the private property of the maintainers - else it would
    just be freeware, not free software.

    If the maintainer is not doing their job, there is a process
    for replacing them.
    Bureaucreacy (how tf is this spelled **g) to solve problems
    that wouldn't exist without it, we need more of it.
    Why would you want to contribute to a project, if you can't establish a
    trust-relationship to the project maintainer?
    Because i actually and exclusively care about the technical superiority of
    the code?
    Because, if you can establish one, there's little that hinders you from
    becoming a co-maintainer, or have your patches committed quickly.
    Yes of course. What if it _does not_ work this way. Bugger.
    Again, we want to encourage contribution and collaboration. ?Not
    discourage it.
    How am i proposing to discourage that, quite the contrary..
    wow this is getting tedious. I really hoped for some more support, but it
    seems there is only fear from current maintainers that something will be
    taken away from them. We will probably have the same duplicate modules
    problem with D7 as with D6, instead of stemming the united effort of
    consolidating and merging the functionality of thousands of modules into a
    couple of frameworks and some hundred submodules.

    regards,
    marcel.
    --
    GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT!
    Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
  • Marcel Partap at Dec 10, 2009 at 4:35 am

    No one claimed to be able to solve EVERY problem. According to the
    thread title, the problem being solved is the duplication of modules.
    And neither a DCVS nor a commit-access free-for-all will ultimately
    solve that. People are going to disagree about what the objectives for
    a module should be, and there going to disagree about what constitutes
    "technical superiority."
    That might well be. But the most important thing to avoid functionality overlap is to engineer frameworks that are capable of handling as many different, probably conflicting, use cases that could be come up with. Then code not agreed upon can be refactored into submodules for the framework, instead of reimplementing functionality multiple times in conflicting ways.
    The solution to such roadblocks is social, not technical. Good
    old-fashioned human interaction, communication, deference, and mutual
    respect. "Blessed are the peacemakers...."
    The solution is both, of course. Technical utilities that support the social workflow ;)
    The thing is, abolishing individual persons' OWNERSHIP on code in D7 contrib does away with possible prevention of code improvements due to social factors. By itself, it does not solve any problem of course, even giving room to a new one: people at will committing changes NOT coordinated with one another. To prevent that, important thing is to start implementing the potential frameworks ASAP and make sure they can properly be expanded by extensions/submodules. This process will naturally result in a voluntary group of developers doing the job of maintenance.
    Showing up and demanding that everything change in a workflow that
    you've never participated in...
    What does that mean? I have provided patches to at least a dozen modules, and core.
    that's not going to win friends and influence people, and it's not going
    to produce better code or fewer duplicate modules either.
    To put it bluntly, i am not trying to make friends, i am trying to stir up some discussion about the development process i am taking part in.
    Of course, I'm biased, because I think duplicate modules are largely a
    good thing. Let natural selection take it's course, I say.
    For Drupal 6, no disagreement. Everybody and his dog tried his variation of how to implement basic functionality, and it has led to an impressive amount of creative programming work of (partly) high quality.
    But duplication is bad in several ways which already have been mentioned multiple times before. Frameworks with beyond-dispute general structure are a good replacement for obvious reasons, so a development process which facilitates that is an improvement.
    One thing is for sure: KDE and Gnome wouldn't be nearly as good as
    they are today if they weren't constantly stealing and improving on
    ideas from one another.
    Comparing <10KLOC modules with overlapping functionality with two rivaling desktop environments is stretching scales a bit. And with nested frameworks (payment framework -> paypal framework -> submodules) there's still room for competing implementations - the difference it makes is at which API level differences are visible. paypal_framework_1 and paypal_framework_2 might differ in internals and have incompatible submodules, but should both provide same functionality/interface to the payment framework. At the moment, there's no common payment framework, none for shopping carts, none for a variety of other applications, resulting in competing implementations in D6 contrib.

    regards,
    marcel.
    --
    Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
    sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
  • Daniel F. Kudwien at Dec 10, 2009 at 12:42 am

    Again, we want to encourage contribution and collaboration. Not
    discourage it.
    How am i proposing to discourage that, quite the contrary..
    wow this is getting tedious. I really hoped for some more
    support, but it seems there is only fear from current
    maintainers that something will be taken away from them. We
    will probably have the same duplicate modules problem with D7
    as with D6, instead of stemming the united effort of
    consolidating and merging the functionality of thousands of
    modules into a couple of frameworks and some hundred submodules.
    That's the point. You are talking about consolidation and merging without
    considering that any approach on consolidation requires to join forces with
    others. That means to communicate, to talk, and to share vision. And after
    doing so, it means to code, to review, to find compromises, and finally to
    commit. This is how innovation works.

    If you'd want to express this in numbers, then 99% is collaboration and
    contribution, and only 1% (or even only a fragment of that) is committing.

    If we want to decrease duplication, then we need to improve the
    communication.

    sun
  • Cary Gordon at Dec 10, 2009 at 1:04 am
    The bottom line is that with the exception of abandoned modules,
    consolidation needs to be initiated by the module creators and
    maintainers.

    The same is true, for the most part, of module comparison.

    Experience has shown that these work well and virtually every other
    approach fails.

    Cary

    On Wed, Dec 9, 2009 at 4:42 PM, Daniel F. Kudwien
    wrote:
    Again, we want to encourage contribution and collaboration. ?Not
    discourage it.
    How am i proposing to discourage that, quite the contrary..
    wow this is getting tedious. I really hoped for some more
    support, but it seems there is only fear from current
    maintainers that something will be taken away from them. We
    will probably have the same duplicate modules problem with D7
    as with D6, instead of stemming the united effort of
    consolidating and merging the functionality of thousands of
    modules into a couple of frameworks and some hundred submodules.
    That's the point. ?You are talking about consolidation and merging without
    considering that any approach on consolidation requires to join forces with
    others. ?That means to communicate, to talk, and to share vision. ?And after
    doing so, it means to code, to review, to find compromises, and finally to
    commit. ?This is how innovation works.

    If you'd want to express this in numbers, then 99% is collaboration and
    contribution, and only 1% (or even only a fragment of that) is committing.

    If we want to decrease duplication, then we need to improve the
    communication.

    sun


    --
    Cary Gordon
    The Cherry Hill Company
    http://chillco.com
  • Marcel Partap at Dec 10, 2009 at 3:53 am

    The bottom line is that with the exception of abandoned modules,
    consolidation needs to be initiated by the module creators and
    maintainers.
    The same is true, for the most part, of module comparison.
    Yes, and that is the flaw of the current, maintainer-centric workflow. It depends on maintainers being able to be good maintainers. This will never be true for all people coding drupal.
    Experience has shown that these work well
    Everything imperfect can be improved upon. Explicitly including things that work well.
    and virtually every other approach fails.
    How has that been proven?
    It's hard to prove that something cannot be done, even if insurmountable obstacles seem to exist. Take space flight for example ;)

    regards,
    marcel.
    --
    Preisknaller: GMX DSL Flatrate f?r nur 16,99 Euro/mtl.!
    http://portal.gmx.net/de/go/dsl02
  • Marcel Partap at Dec 10, 2009 at 3:45 am

    That's the point. You are talking about consolidation and merging without
    considering that any approach on consolidation requires to join forces
    with others. That means to communicate, to talk, and to share vision.
    And after doing so, it means to code, to review, to find compromises, and
    finally to commit. This is how innovation works.
    If you'd want to express this in numbers, then 99% is collaboration and
    contribution, and only 1% (or even only a fragment of that) is committing.
    If we want to decrease duplication, then we need to improve the
    communication.
    Yes, agree to all. And imho, NOW (i.e. BEFORE a D7 final) is a good time to adapt such a more cooperative contrib development mode. Once all the competing modules have D7 versions, the problem is just prolonged for about two years until D8.
    And at the same time, some tools part of the workflow could be improved, too. Migration to GIT (only the D7 repository!), testing bots, etc. Of course it's a lot of work. Getting it done requires the commitment to do it.
    Again: why don't we put a 'Help D7 migrate to a DCVS call for action' and 'D7 contrib frameworks hackfest invitation' up on the front page for starters.
    regards,
    marcel.
    --
    GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT!
    Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
  • Daniel F. Kudwien at Dec 10, 2009 at 3:58 am

    Yes, agree to all. And imho, NOW (i.e. BEFORE a D7 final) is
    a good time to adapt such a more cooperative contrib
    development mode. Once all the competing modules have D7
    versions, the problem is just prolonged for about two years until D8.
    And at the same time, some tools part of the workflow could
    be improved, too. Migration to GIT (only the D7 repository!),
    testing bots, etc. Of course it's a lot of work. Getting it
    done requires the commitment to do it.
    Change happens by contribution. It seems you are highly interested. So why
    don't you pick your most annoying candidates, do and publish a module
    comparison, contact the maintainers and get them talking to each other to
    get the ball rolling?

    sun
  • Ezra B. Gildesgame at Dec 9, 2009 at 2:47 am

    On Tue, Dec 8, 2009 at 9:14 PM, Marcel Partap wrote:
    * hint: anyone can change any article in wikipedia, anonymously and instantly. That's a NULL height entry barrier.
    I agree with Sun that docs are not really analogous to project code,
    but even disregarding that, it's worth pointing out that many pages on
    Wikipedia are locked to editing from the general public in the
    interest of maintaining a positive experience for the majority of
    readers.

    Regards,

    Ezra

    Ezra Barnett Gildesgame | http://growingventuresolutions.com | http://ezra-g.com
  • Marcel Partap at Dec 10, 2009 at 12:10 am

    I agree with Sun that docs are not really analogous to project code,
    but even disregarding that, it's worth pointing out that many pages on
    Wikipedia are locked to editing from the general public in the
    interest of maintaining a positive experience for the majority of
    readers.
    Unfortunately i couldn't find definite statistics on the amount of locked pages but i doubt it is more than five percent. And most of these pages are locked because of security implications (some templates, scripts).
    Adding to that, as already mentioned in my response to sun, even i support not lifting restrictions on some modules of similar importance, like the views module.

    regards,
    marcel.
    --
    Preisknaller: GMX DSL Flatrate f?r nur 16,99 Euro/mtl.!
    http://portal.gmx.net/de/go/dsl02

Related Discussions

People

Translate

site design / logo © 2022 Grokbase