Earnie Boyd wrote:

the pinch hitter for the module that has annoyed you. ;p

He can become a batsman promoted up the batting order to score quick runs? That's a bizarre analogy. :)

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 ...

how about a simple rating system for for contrib modules

How about co-maintaining some modules?

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/

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

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

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

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

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)