No real propositions here - just observations...but with the popularity of Drupal growing by leaps and bounds the amount of flaky hit and run maintainers/contrib-modules also appears to be growing exponentially. It's annoying. :p - Caleb
Quoting Caleb Gilbert <caleb.gilbert@gmail.com>:
No real propositions here - just observations...but with the popularity of Drupal growing by leaps and bounds the amount of flaky hit and run maintainers/contrib-modules also appears to be growing exponentially.
It's annoying. :p
You can always become the pinch hitter for the module that has annoyed you. ;p There are methods in place to allow you to take over an abandoned module. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
"Hit and run" is one way of characterizing it. Another way is that we have an ecosystem. The ecosystem is getting larger, and the fact that more types of organisms and relationships are in it means the ecosystem is healthy. Symbiosis does not include only mutualism, it also includes commensalism, and even parasitism. You can have a lab environment that is sterile, but it will not be as vibrant as the one that has less than ideal organisms and relationships, warts and all ... So, this is the price of success, and a small one at that ...
how about a simple rating system for for contrib modules On Tue, May 27, 2008 at 4:22 PM, Khalid Baheyeldin <kb@2bits.com> wrote:
"Hit and run" is one way of characterizing it.
Another way is that we have an ecosystem.
The ecosystem is getting larger, and the fact that more types of organisms and relationships are in it means the ecosystem is healthy.
Symbiosis does not include only mutualism, it also includes commensalism, and even parasitism.
You can have a lab environment that is sterile, but it will not be as vibrant as the one that has less than ideal organisms and relationships, warts and all ...
So, this is the price of success, and a small one at that ...
On 5/29/08, David Reed wrote:
how about a simple rating system for for contrib modules
Please see: http://groups.drupal.org/module-metrics-and-ranking http://groups.drupal.org/drupal-org-redesign-analysis
David Reed wrote:
how about a simple rating system for for contrib modules
There is http://drupalmodules.com/ However, last time it was discussed on the #drupal irc channel objections were that the modules are rated by joe user and not by an inner circle of experienced drupalers That said, it looks like a huge task to have proper reviews with all the modules out there Also, a module which is so far badly coded or not as state of the art as it could be can be refactored and improved patch after patch. To me, the multiplication of "we all do the same but better(tm)" modules is more of a problem by far cheers, g
Quoting Gregory 'guardian' Pakosz <guardian@pempek.net>:
David Reed wrote:
how about a simple rating system for for contrib modules
There is http://drupalmodules.com/
However, last time it was discussed on the #drupal irc channel objections were that the modules are rated by joe user and not by an inner circle of experienced drupalers
I would love to see both where the experienced drupalers would rate based on code health and joe user rates based on experience.
That said, it looks like a huge task to have proper reviews with all the modules out there
The rating would have to be relative to the version of the module because a newer version may change the status for the module.
Also, a module which is so far badly coded or not as state of the art as it could be can be refactored and improved patch after patch. To me, the multiplication of "we all do the same but better(tm)" modules is more of a problem by far
We still need to work out the kinks in the take-over-a-module process. If someone is willing and has time to enhance a module then why should he be stopped by the lack of time from the present maintainer to even add the user to the CVS write access. The patches of the one that wants to take-over-a-module must prove to be at least 80% good and if that is the case he should be able to submit a form for that take over. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Thu, May 29, 2008 at 7:10 PM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
We still need to work out the kinks in the take-over-a-module process. If someone is willing and has time to enhance a module then why should he be stopped by the lack of time from the present maintainer to even add the user to the CVS write access. The patches of the one that wants to take-over-a-module must prove to be at least 80% good and if that is the case he should be able to submit a form for that take over.
What kinks? I think http://drupal.org/node/251466 is pretty straightforward. If you have suggestions for improvement, please comment. Michelle
What kinks? I think http://drupal.org/node/251466 is pretty straightforward. If you have suggestions for improvement, please comment.
No kinks. The current process works. However: We should really start to think about i) project maintainership, ii) educating current maintainers, iii) educating new maintainers, and iv) encouraging co-maintainership and joining forces. As with any other thing that grows in the extent like Drupal's user-base, there have to be standards. There are several projects that badly need more co-maintainers. This even includes popular projects, and I don't want to limit this to some examples, because most are affected. If most of the existing projects were maintained, developed, and supported better, we would not have that much new/duplicate/half-baked projects like now. But who wants to grant CVS access to unfamiliar folks? Will a new co-maintainer rewrite your whole module (including API changes) and even commit that thingy to the current branch? Will he/she write clean, secure and documented code, and proper changelog entries and commit messages? We have good Coding Standards. But do we have standards for common processes? (Please don't point me to the handbook pages, I know most of them.) In the handbooks, we're talking about best practices. So a newcomer /can/ adopt these processes. But if he/she does not, will *you* grant CVS access? I don't think so. OTOH, if there was a prepared candidate - would you really grant CVS access? Would you grant access to me? Instead of complaining, let's talk about setting up standards and guidelines to help existing projects and maintainers to evolve. What's missing in contrib is some kind of a /dynamic/ drive. For example, we encourage maintainers to commit patches and credit the contributor(s) using a message of the following syntax: "#12345 by sun: Fixed coding-style." We are parsing the "#12345" bit, but why don't we also parse the "by sun" bit to assign 'contributor credits' to users for the corresponding project? If my username is covered in a certain amount of commits, am I eligible to automatically get CVS access? Maybe? cheerio, Daniel
On Thu, May 29, 2008 at 8:19 PM, Daniel F. Kudwien <news@unleashedmind.com> wrote:
No kinks. The current process works. However:
We should really start to think about i) project maintainership, ii) educating current maintainers, iii) educating new maintainers, and iv) encouraging co-maintainership and joining forces.
That's really a whole different subject than the process of taking over a module.
OTOH, if there was a prepared candidate - would you really grant CVS access? Would you grant access to me?
Me, no. I don't want a co-maintainer on my modules at this point. In general, though, I see people taking on co-maintainers all the time. There's only been one case that I'm aware of where a maintainer wasn't taking care of his module and also refused to allow anyone else access. Most of the time people are willing give access to or even to hand over modules they have no time for. If anything, there's the opposite problem that there's simply not enough people with time to take over struggling modules.
Instead of complaining, let's talk about setting up standards and guidelines to help existing projects and maintainers to evolve.
I wasn't complaining... I was asking him what kinks he found in the process so the document could be improved.
What's missing in contrib is some kind of a /dynamic/ drive. For example, we encourage maintainers to commit patches and credit the contributor(s) using a message of the following syntax:
"#12345 by sun: Fixed coding-style."
We are parsing the "#12345" bit, but why don't we also parse the "by sun" bit to assign 'contributor credits' to users for the corresponding project? If my username is covered in a certain amount of commits, am I eligible to automatically get CVS access? Maybe?
Having that parsed automatically would be nice. I tried putting a link to a UID once and it just made a mess. As for auto CVS access, no way. As long as a maintainer hasn't abandoned their module, they should have say in who gets access. Sure, it's GPL, but it's generally accepted that the person who writes a module "owns" it unless they actively hand it off to someone else. If someone got commit writes to my modules automatically just because they submitted X patches, I'd be quite annoyed. I'm very glad the system doesn't work that way. Michelle
Michelle Cox wrote:
On Thu, May 29, 2008 at 8:19 PM, Daniel F. Kudwien We should really start to think about i) project maintainership, ii) educating current maintainers, iii) educating new maintainers, and iv) encouraging co-maintainership and joining forces.
That's really a whole different subject than the process of taking over a module.
It is. Would be a great set of documentation for the community to have, though. Daniel, are you on the docs team already? If not, post an issue to the Documentation project queue and I can add you tomorrow. I'd love to see someone put some energy into this kind of stuff.
Having that parsed automatically would be nice. I tried putting a link to a UID once and it just made a mess. As for auto CVS access, no way. As long as a maintainer hasn't abandoned their module, they should have say in who gets access. Sure, it's GPL, but it's generally accepted that the person who writes a module "owns" it unless they actively hand it off to someone else. If someone got commit writes to my modules automatically just because they submitted X patches, I'd be quite annoyed. I'm very glad the system doesn't work that way.
Not to mention that it's the *nature* of the patches, not the number of them that are important. If you go by pure numbers, most of us have far more patches in Drupal core than Dries. That definitely does NOT mean we could all be trusted with commit access to it. :P -Angie
On Thu, May 29, 2008 at 11:20 PM, Angela Byron <drupal-devel@webchick.net> wrote:
Michelle Cox wrote:
On Thu, May 29, 2008 at 8:19 PM, Daniel F. Kudwien We should really start to think about i) project maintainership, ii) educating current maintainers, iii) educating new maintainers, and iv) encouraging co-maintainership and joining forces.
That's really a whole different subject than the process of taking over a module.
It is. Would be a great set of documentation for the community to have, though.
Here's one small document to start it off. Sepeck would know better if there were others. I just happened to remember this one. http://drupal.org/node/23789 Michelle
On May 29, 2008, at 6:19 PM, Daniel F. Kudwien wrote:
we encourage maintainers to commit patches and credit the contributor(s) using a message of the following syntax:
"#12345 by sun: Fixed coding-style."
We are parsing the "#12345" bit, but why don't we also parse the "by sun" bit to assign 'contributor credits' to users for the corresponding project?
Because killes said "I think enforcing conventions on cvs committers is a bad idea." and there was a related bikeshed question somewhere about what the syntax should be, so the issue has languished for years: http://drupal.org/node/52285
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Derek Wright schrieb:
On May 29, 2008, at 6:19 PM, Daniel F. Kudwien wrote:
we encourage maintainers to commit patches and credit the contributor(s) using a message of the following syntax:
"#12345 by sun: Fixed coding-style."
We are parsing the "#12345" bit, but why don't we also parse the "by sun" bit to assign 'contributor credits' to users for the corresponding project?
Because killes said "I think enforcing conventions on cvs committers is a bad idea."
Well, we can of course ask nicely. ;) It is probably in the best interest of a module maintainer to play nice with the contributors. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIQrNzfg6TFvELooQRAmXcAJ4tIG99x1SRPPDBSPcQemFDFPnzwACdHiOG BkRu0exRNHWK3cR+sfGX5sU= =hmpY -----END PGP SIGNATURE-----
Another issue I've noticed, is users contributing what amounts to site specific modules, that duplicate another module with small differences, such as would be specific to only a single site. The motive for this seems to be either clients, development companies, or individuals who are seeking credit or trying to improve appearances by having contributed modules in their name. Now for my speculation on the issue, this may be due to the general attitude in the Drupal community that the way to evaluate a members skill, or value, is by CVS commit logs, or core patches submitted. While this is a good way to evaluate, it may be the value placed on such a metric, that causes people to strive to find a way to be visible, without considering quality or consequences to new users in terms of duplicated modules. I for one, know that I have had multiple employers look at my d.o account and cvs log, yet I know that at least one of them did not ever read the code associated with it. I don't know what the real solution to this problem is, but I know that I am guilty of striving to have something committed in CVS, without regard to quality, commitment to maintain it, or overall quality. -Mike __________________ Michael Prasuhn mike@mikeyp.net http://mikeyp.net 503.488.5433 714.356.0168 cell 949.200.7670 fax
Quoting Michelle Cox <shellmultimedia@gmail.com>:
On Thu, May 29, 2008 at 7:10 PM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
We still need to work out the kinks in the take-over-a-module process. If someone is willing and has time to enhance a module then why should he be stopped by the lack of time from the present maintainer to even add the user to the CVS write access. The patches of the one that wants to take-over-a-module must prove to be at least 80% good and if that is the case he should be able to submit a form for that take over.
What kinks? I think http://drupal.org/node/251466 is pretty straightforward. If you have suggestions for improvement, please comment.
The process of finding the documentation would be the kink then. A link to http://drupal.org/node/10259 would be nice on every project page under the "Development" section. BTW, in preparing to answer I found a SPAM post with a .jpg file attached; see http://drupal.org/node/122341 for the issue node. This is the only post the user has and the module only has one release for 4.7. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Thu, May 29, 2008 at 10:45 PM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
The process of finding the documentation would be the kink then. A link to http://drupal.org/node/10259 would be nice on every project page under the "Development" section.
That's up to Sepeck. I agree that making it more prominent would be nice.
BTW, in preparing to answer I found a SPAM post with a .jpg file attached; see http://drupal.org/node/122341 for the issue node. This is the only post the user has and the module only has one release for 4.7.
Deleted. Michelle
Liza Sabater wrote:
David Reed wrote:
how about a simple rating system for for contrib modules +++1
here are the places to jump in and help: http://groups.drupal.org/drupal-org-redesign-analysis http://groups.drupal.org/issue-tracking-and-software-releases
On Jun 1, 2008, at 6:34 PM, Angela Byron wrote:
here are the places to jump in and help:
More specifically: http://groups.drupal.org/node/7191 Enjoy, -Derek (dww)
how about a simple rating system for for contrib modules
Module view and download count would be one of the best measures of popularity. The Project module team's work seems to be almost there - watch/help http://drupal.org/node/165380 Tomáš (Vacilando)
participants (15)
-
Angela Byron -
Caleb Gilbert -
catch56@googlemail.com -
Daniel F. Kudwien -
David Reed -
Derek Wright -
Earnie Boyd -
Gerhard Killesreiter -
Gregory 'guardian' Pakosz -
Khalid Baheyeldin -
Liam McDermott -
Liza Sabater -
Michael Prasuhn -
Michelle Cox -
Tomas J. Fulopp - Vacilando.org