Comments on: Moderated API contributions for drupal http://blog.menhir.be/2010/04/25/moderated-api-contributions-for-drupal/ The only constant in webdevelopment is change Sat, 19 May 2012 11:25:25 +0000 http://wordpress.org/?v=2.7.1 hourly 1 By: Stalski http://blog.menhir.be/2010/04/25/moderated-api-contributions-for-drupal/comment-page-1/#comment-914 Stalski Mon, 26 Apr 2010 22:10:45 +0000 http://blog.menhir.be/?p=394#comment-914 Great,thx, I'll take the discussion out there. Great,thx, I’ll take the discussion out there.

]]> By: sun http://blog.menhir.be/2010/04/25/moderated-api-contributions-for-drupal/comment-page-1/#comment-913 sun Mon, 26 Apr 2010 21:28:57 +0000 http://blog.menhir.be/?p=394#comment-913 API category on drupal.org: http://drupal.org/node/113412 API category on drupal.org:
http://drupal.org/node/113412

]]> By: Stalski http://blog.menhir.be/2010/04/25/moderated-api-contributions-for-drupal/comment-page-1/#comment-912 Stalski Mon, 26 Apr 2010 20:36:03 +0000 http://blog.menhir.be/?p=394#comment-912 I was not specific enough in my post as well. I saw this a bit like this: When creating a drupal contribution, we have the option to label the project as an API. The only difference would be that this type of module is moderated/managed differently (as severe as several developers together can be). This way ready-to-go modules and even smaller api's that don't want to be labeled this way can still go ahead. The choice should indeed be left to the maintainer. What does the label API do then? Time will tell. Could be a "recommendation"? It sure wouldn't be left without maintainer that easily. Is it this what developers need to make a choice on how to proceed in their own projects, wanting to set a "default api"? The sollution could satisfy both worlds. What i hope would happen is that some maintainers will end up labeling their module as the API to go or new api projects could be created in a collaboration of developers to merge and filter the best of several api's. Maybe i should have taken this discussion at drupal.org ... I was not specific enough in my post as well. I saw this a bit like this: When creating a drupal contribution, we have the option to label the project as an API. The only difference would be that this type of module is moderated/managed differently (as severe as several developers together can be).
This way ready-to-go modules and even smaller api’s that don’t want to be labeled this way can still go ahead. The choice should indeed be left to the maintainer.
What does the label API do then? Time will tell. Could be a “recommendation”? It sure wouldn’t be left without maintainer that easily. Is it this what developers need to make a choice on how to proceed in their own projects, wanting to set a “default api”?

The sollution could satisfy both worlds. What i hope would happen is that some maintainers will end up labeling their module as the API to go or new api projects could be created in a collaboration of developers to merge and filter the best of several api’s.

Maybe i should have taken this discussion at drupal.org …

]]> By: sun http://blog.menhir.be/2010/04/25/moderated-api-contributions-for-drupal/comment-page-1/#comment-909 sun Mon, 26 Apr 2010 19:50:54 +0000 http://blog.menhir.be/?p=394#comment-909 Unlike the others, I agree with your considerations here. We do not need yet another duplicate module that provides the same functionality as module XYZ, just because you added a configuration option for setting Foo. Likewise, we do not need a new "List" module, that is Views, in pink. We opened the review process for new CVS applications some time ago, so everyone is able to help in moderation of (entirely) new projects by new contributors, who actually are guilty for most duplicated projects, modules, and efforts, unfortunately. Everyone can help to review code and point applicants to existing projects in the http://drupal.org/project/issues/cvsapplications However, the fact that we frequently need to point people to existing projects and tell them that their work totally duplicates an existing module and therefore provides zero benefits for the community, means that we failed to provide sufficient measures to allow users and developers to <strong>find</strong> existing projects on drupal.org. Working heavily in core and contrib, my current conclusion and feeling is that we fail to apply Drupal's community idea and Drupal's principles to the sphere of contributions and into the minds of people that did not attend a DrupalCon yet. The principles of joining forces to build better products, collaborating in an open and friendly fashion, thinking both small and big, ... are all not understood. Unlike the others, I agree with your considerations here.

We do not need yet another duplicate module that provides the same functionality as module XYZ, just because you added a configuration option for setting Foo.

Likewise, we do not need a new “List” module, that is Views, in pink.

We opened the review process for new CVS applications some time ago, so everyone is able to help in moderation of (entirely) new projects by new contributors, who actually are guilty for most duplicated projects, modules, and efforts, unfortunately. Everyone can help to review code and point applicants to existing projects in the http://drupal.org/project/issues/cvsapplications

However, the fact that we frequently need to point people to existing projects and tell them that their work totally duplicates an existing module and therefore provides zero benefits for the community, means that we failed to provide sufficient measures to allow users and developers to find existing projects on drupal.org.

Working heavily in core and contrib, my current conclusion and feeling is that we fail to apply Drupal’s community idea and Drupal’s principles to the sphere of contributions and into the minds of people that did not attend a DrupalCon yet. The principles of joining forces to build better products, collaborating in an open and friendly fashion, thinking both small and big, … are all not understood.

]]> By: Stalski http://blog.menhir.be/2010/04/25/moderated-api-contributions-for-drupal/comment-page-1/#comment-903 Stalski Mon, 26 Apr 2010 11:33:35 +0000 http://blog.menhir.be/?p=394#comment-903 Thx for the great replies. That was my point exactly when creating heartbeat. So with your experience in mind, the best way is to let people develop freely without any moderation boundaries. Thx again! Thx for the great replies. That was my point exactly when creating heartbeat. So with your experience in mind, the best way is to let people develop freely without any moderation boundaries.
Thx again!

]]> By: merlinofchaos http://blog.menhir.be/2010/04/25/moderated-api-contributions-for-drupal/comment-page-1/#comment-899 merlinofchaos Mon, 26 Apr 2010 01:53:18 +0000 http://blog.menhir.be/?p=394#comment-899 As the maintainer of the largest contrib module in Drupal, I can tell you that a LOT of people moderate core Drupal and the amount of code and activity in all of contrib is at least a hundred times that. There simply aren't enough resources to moderate all of contrib meaningfully. All that would really happen is that people would move their stuff off-site where they can work more in freedom. Even more, Drupal itself can be community moderated because at least the moderation that happens is because Dries and the branch maintainers share a vision. Can they say that about my module? How are they supposed to know anything about Views? And would Views ever have happened with a moderated contrib? I don't think it would have, at least, not the way it has. Maybe I would've done something offsite, but I would have been so frustrated with the politics of trying to push something through moderation that I feel confident I would've stopped trying and gone elsewhere. As the maintainer of the largest contrib module in Drupal, I can tell you that a LOT of people moderate core Drupal and the amount of code and activity in all of contrib is at least a hundred times that. There simply aren’t enough resources to moderate all of contrib meaningfully. All that would really happen is that people would move their stuff off-site where they can work more in freedom.

Even more, Drupal itself can be community moderated because at least the moderation that happens is because Dries and the branch maintainers share a vision. Can they say that about my module? How are they supposed to know anything about Views?

And would Views ever have happened with a moderated contrib? I don’t think it would have, at least, not the way it has. Maybe I would’ve done something offsite, but I would have been so frustrated with the politics of trying to push something through moderation that I feel confident I would’ve stopped trying and gone elsewhere.

]]> By: Yo http://blog.menhir.be/2010/04/25/moderated-api-contributions-for-drupal/comment-page-1/#comment-897 Yo Mon, 26 Apr 2010 01:08:52 +0000 http://blog.menhir.be/?p=394#comment-897 Boo. If I want to create a module that does something similar to but not the same as another module, I should be allowed to do that rather than told to add it as a feature to some existing monstrously (and unnecessarily) huge API. The Drupal community is about openness. Better to have a wide choice than a poor choice. Boo. If I want to create a module that does something similar to but not the same as another module, I should be allowed to do that rather than told to add it as a feature to some existing monstrously (and unnecessarily) huge API. The Drupal community is about openness. Better to have a wide choice than a poor choice.

]]>