Implementing alternatives to CVS applications

I'd support having the review at the point of project creation - we could give a much lighter review for the initial CVS application (which then lets people become co-maintainers, update the API docs, etc) but then a more thorough peer review for a new project.

-1 for putting a barrier in the way of creating new projects -- this punishes the vast majority of people who don't abuse their cvs privs in order to potentially weed out a few people who create most of the hassle.

I'd much rather see more use of unpublishing questionable projects, possibly combined with temporary blocks on cvs rights.

I see this as analogous to hiring; a lot of people interview well, but quality (or lack thereof) only shows itself over time.

We're not concerned about quality. Just duplication and knowledge of proper security coding. To continue your analogy, you're not going to hire someone to do the exact same thing of someone that is already hired when you only want one person.

How often does anyone create a new project? Perhaps a slight need to think twice and justify a new project would be useful.

I don't think that need to justify is in any way punishment any more than it's punishment that for g.d.o you need to go though a moderation queue to start a new group. That process is at least 50% for weeding out duplicates.

bumping this - I really think we should try a modified procedure.

I'm somewhat in favor of this, especially if implemented like discussed in this proposal by Heine.

What do we need?

• A way to put projects into a holding pen where they are not full fledged projects. We also need to decide what limit this places on the project, I think it should be visible, but not able to publish a release.
• A way for the people who are going to weigh-in on this to provide feedback about the project - I guess the issue queue for the project.
• A set of guidelines about reasons why projects will or won't be approved.
• Some high quality template responses: "Your project seems to be a duplicate of...can you explain why it is necessary?" but really well written so that we give people followup actions and keep them motivated about contributing.

I think the reason you get duplicate projects 99/100 times isn't a human problem, it's a technology problem. The vast majority of people do not intentionally duplicate existing projects (who wants to do work when they don't have to?), they simply are unaware of other projects' existence.

Human reviews won't help. We don't seem to have enough manpower to sort through the small trickle of CVS applications, since I always seem to see the same like 3 people on any CVS application. http://drupal.org/taxonomy/term/14 shows between 2-5 new modules, on average, created per day. If these are all waiting on a small handful of people (who also don't really know if a project duplicates others without knowledge of all 5,000+ modules), people are simply going to stop submitting new projects. -100 for placing bureaucracy in front of contributors.

The way to solve this, IMO, is with technology. Write a hook_form_alter() in the d.o customizations module that hooks the project submission form into the Solr index, does a full text search on the title/description/shortname and says:

"
Your project 'SuperFriends' looks similar to the following modules:

* Buddylist
* Buddylist2
* Friendlist
* User Relationships

Please check the module project pages to to ensure you are not creating a duplicate project.
"

This might not be perfect, but we can tweak the algorithm as we go along, and those tweaks will directly benefit our users who are using the same search index to find modules themselves. And we don't tie up tons of human hours doing these searches for people. Win/Win, imo.

@webchick - imho - the biggest problem right now is that we cant' give a user permission to co-maintain a project (i.e. potentially commit to CVS there) without giving them permission to create whatever new projects they wish.

There are several variants of how this could be done - either block project creation, or block creation of releases until there is a review for a new project.

However, looking at admin/project and the permissions assigned to existing roles I think there may be some assumptions coded into project module that we'd need to fix by adding 1 or 2 new permissions or some other new logic (e.g. a flag for each project that releases may be created).

So - sounds like have to revisit this on Wed when dww is back to at least get the best advice on how to proceed.

If I can pipe in as the devil's advocate:

To try to address project duplication by preventing CVS accounts invites politics and could have the effect of discouraging sharing in the community (and could push sharing elsewhere). If a community goal is still to make *.d.o the Drupal community site, and avoid Balkanization of resources scattered willy nilly across the web, then this approach could be extremely counteproductive, imho.

IMHO, duplication of efforts is best addressed by letting the sharing happen — and let's be clear, the sharing usually happens after the development was already done — and then work to combine/improve overlapping projects through the issue queues, wikis, etc.

Having worked with teams confronting the patch-existing-project vs. develop-and-share choice during a client project that has tight deadlines (and don't they all?), making sharing harder is just going to eliminate sharing, and won't have much effect on encouraging people to patch existing projects.

Patches often don't get accepted. They don't get reviewed even, sometimes for days or weeks or months. The reality of commercial development, which drives a huge percentage of community code development, is that time is money and waiting for the slow peer-driven community process to proceed does not answer. Trying to force developers to improve or even refactor an existing module, and get that module's maintainer's approval, rather than share what they developed for their own project needs, seems to me to be misplaced.

One big technical answer to the duplicate modules problem is module ratings across several axes. DrupalModules.com fills a bit of that need. Usage statistics help. So do wikis like the duplicate modules wiki(s) that lay in obscurity here and there. Encouraging a culture of review and assessment will help a do-ocracy much more than a bigger and better gatekeeper process, imho. Let people contribute and get engaged, and then involve them in the collaborative process. Collaboration is a learned skill, and I don't think you make collaborators by cutting off their independent contributions.

If we just removed the hard-coded assumption that a project owner is locked into CVS access for it, people could create project nodes, not be able to commit to them until they get the CVS project access approved.

Just had another new module pop up that is just one major security hole in addition to being a duplicate module. It would be nice if we could automatically search for duplicates on project creation, but its never going to be as good as the knowledge of our community members. Also, people don't read text.

The main point of this proposal is NOT to filter out duplicate projects. The main point is to make the initial CVS application much easier.

Essentially someone who gets that initial approval would be able to join an existing project as a co-maintainer, or take over an abandoned module without having to wait weeks (or months) for a CVS application to be reviewed.

There are various ways to approach the next step - my suggestion was to moderate project nodes. Heine suggests moderating the first release of any project. I'd even be happy if we did both of these. The idea is the same - to push off the kind of code review a few people are doing now for the initial CVS application so that it can be more focused (one project's code) and potentially easier to get more volunteers for (i.e. a lower-risk process for approving one project versus giving someone the keys to create unlimited new projects).

In terms of moderating projects/releases we can debate further what role duplicate reduction should have, but I think that's a side issue.

Why not just have users tag projects with a taxonomy like system, when the cloud of tags get to high in an area it's looked into or marked for review, award points for tagging, more for reviewing, and have people buy things with those points.

User submitted/moderated user logos, badges, links to their site in comments, additions to their profile, customizing its color, paying to show community contributions, paying to add a donate button, etc. some of which like the images could become parts of modules/instant content for people as well.

Encourage the community to moderate itself rather than stifle development, look at google, with their picture tagging, and how they are translating books by making people prove they are hooman.

It is nicer though, when you feel rewarded, and spending points to show how you contribute would be a marriage made in open source heaven.

You could even use it to fund Drupal and make it more game like and donate to double your points for a week *shrug* the possibilities when you have this many people are really limited by thought. Perhaps you get little drupal avatars with health that falls for every miss tag that's voted down and raises for those pushed up.. and you can buy outfits and other such fluff that makes people smile and they post elsewhere in a viral marketing machine. When 2 people are wondering who will lead a project they can battle with their avatars for supremacy!

I for one agree wading through every "mail" module trying to find one that does html mail is enough to make a dyslexics eyes bleed, and I'm probably to old to be thinking about such nonsensical things anyways *shrug* that's my 2 bits.

@ransom off topic: Please focus on the CVS application process. There are several other open issues about making good projects more findable or adding rating for projects.

What problem is this trying to solve?

If anything, state that moderation of new projects can be implemented after the fact, if a user who has cvs access shows a complete disregard for community norms.

We don't need to create a barrier for the vast majority of contributors who work within community norms.

Place structure around those who demonstrate a need for it, and only those who demonstrate the need for it.

The CVS applications process was designed before we had a lot of co-maintainers for projects - kiamlaluno's right that it's much easier to get a CVS account if you want to co-maintain something rather than create a new project, but that you're just as able to create new projects once you have the CVS account - so there's an implicit double standard in the process based on stated intentions rather than what actually happens.

If we had even minimal code review of the first release of each project, it could massively cut down on security announcements for contrib. I think that's also a much better time for code review than before creating a project node at all - gives people time to settle in etc.

The number of initial releases for projects is always going to be lower than the number of new projects by definition, since some projects never get stable releases (or even code committed). So doing it that way would probably allay some of webchick's concerns about workload.

The only issue then, is that existing contributors would have first releases of new projects put into moderation before their first official release went out. That's potentially going to annoy people but it's a pretty rare occasion, even for eaton.

We could also do more to make projects without releases, or only with dev tarballs look even scarier than they are now.

Here's another idea: #713102: Host sandbox Git repositories for any user who wants one

This is a problem still nowadays.

As Kiam suggests, It's really easy from new CVS applicants to realize that applying for co-mantainer roles opens the door instantly to create new modules and projects and they can avoid the process of the application.

I don't see anything wrong on having long application processes and reviews, so there is no duplication of modules and newbies learn the rules. But rules have to be the same for every one. Nobody likes to wait for several months and see all this queue-jumping, true?

I assume than the same problem will happen with the "sandboxes". How long it will take until someone review your module and gives the OK to be a project? Will be a way of skipping it? Then there is no point because people will skip it.

I think needs an alternative and doesn't need to wait for migration to git.

[Disclaimer: I have a pendant CVS application, so probably my point of view is not impartial.]

Any alternative now means rewriting project module or hacking on it so that those only approved as "co-maintainers" can never create project nodes.

If you have time to dig into and understand the code, then please post a patch.

[pwolanin] I don't have a clue what modules or configuration drupal.org uses.
But here goes other one: Ask for co-maintaining and in the next 2 hours open a new project. No shame. http://drupal.org/user/665088/track

"Ask for co-maintaining and in the next 2 hours open a new project. No shame."

Why exactly should that contributor be shameful? Is there a policy somewhere suggesting people shouldn't do this? Should there be? It seems the co-maintainer is acting here as the same sort of community review we get through independent CVS applications. There aren't any bugs open on that project and at first glance it appears to provide new functionality for Drupal.

If the co-maintainer path is a more efficient process that accomplishes the same goals, maybe we should encourage it rather than shun it. And if it is lacking, maybe we should look for ways to improve that rather than treating it as inherently bad. It's really easy to get caught up in process for process' sake without considering results. The results here seem pretty good so far.

I got lost. Same sort of community review? What review has been applied ? (Sincerely, I'm not ironic here)

And yes, there is a new issue http://drupal.org/node/843492

And the issue is that has opened a project/module with the same functionality that other one that already exists. Exactly the kind of stuff that you need to justify and explain when you apply to an CVS account.

Anyway, yes, I went too far, I shouldn't have judge him/her.

Exactly the kind of stuff that you need to justify and explain when you apply to an CVS account.

Right, that's my point. It's getting the same kind of review, but via a different process. Is this really a worse process? If so, why? What happened there actually looks a lot like processes people have been suggesting in this thread (easy access to create projects, with no actual code committed before review), so it seems worth talking about how it works in practice. So far, we have an empty project container for something that may or may not overlap with existing code, and a place to discuss that as well as anything else about the project. This looks like a pretty effective process to me.

No-- the comaintainer here did NOT go through the same process. A quick look at the application doesn't show any module/code attached, which is required for a new project cvs account, and also no code review-- since there was no module. Not to mention the fact that in the new projects issue queue there is already an issue asking why duplicate existing modules instead of contributing.

imo this was definitely a back handed way to get cvs access for a module they probably new would be denied as a duplicated. We definitely need to clarify this process. In the meantime I'm making this a request to revoke this user's access. This type of behavior is already a bad sign from a new 'contributor'.

I am starting to think that the full idea of the CVS application is wrong; it's wrong because, as it is implemented, it cannot guarantee that there would not be duplicated projects, and it requires too many users to implement it.
Maybe it would be better to leave the decision of which module has success to the users. Once a module is not used from anybody, and it doesn't get any issue reports, it could be reported as abandoned.

Good! Glad to hear you say that, because that's what myself and others have been saying repeatedly in #703116: Our CVS account application requirements are obtuse and discourage contributions. Our current process kills enthusiasm from new contributors, causes people to turn to off-site repositories (GitHub, Launchpad, etc.) to contribute their code, and doesn't even stop duplicate module creation anyway, which is almost the whole entire point of it. I agree that when it comes to determining module suitability, a combination of scanning the source code, reading issue queues, and looking at usage statistics is usually how I do it as well. We're kidding ourselves if we think that the current process is stopping similar modules from springing up, because we have 10 years worth of legacy projects that will always make this confusing. We're punishing people for lack of good search tools on drupal.org. And finally, our fearless leader has stated in so many words that he thinks duplicate projects are "A Good Thing," because it allows innovation to happen. Trying to stop this is a waste of time, energy, enthusiasm, and resources, IMO.

The one thing about the current process that is nice, though, is informing new contributors about best practices. I don't mean core-level detailed reviews of nit-picky whitespace things (which just tends to irritate even the most long-term and dedicated contributor), but more informing people that coding standards exist, that your SQL query should use %d and not $nid, and that you should really be running HTML output through the theme system. zzolo and others have stated that this is something they really enjoy about the current process, that they can take a new, budding contributor while they're young and haven't developed bad habits yet, and teach them The Drupal Way.

I think that's great. I also think there are many ways to do this that do not involve halting people altogether from contributing until 11,000 little checkboxes are checked. We could implement this same kind of thing in any number of ways:

- An indicator on http://drupal.org/cvs next to the person's name if they've had cvs access for < 3 months, so folks who wanted to mentor could keep an eye out and file issues against the projects.

- An opt-in checkbox in your CVS user profile that says "I'm new around here, and would love for someone to review my code." This could be fed into a view, and people who want to take that on could review it periodically for new projects.

- A Drupal Developer Newsletter, which is sent out to all CVS account holders, which reminds people about best practices, new tools on the horizon, etc.

- A group on groups.drupal.org called "Development Best Practices", mentioned on the CVS account application form, where new members could sign up and get one-to-one mentoring from someone interested in providing that level of insight.

- Any other way you someone thinks of to handle it.

Finally, I apologize that sometimes I get really heated on these threads. This issue is just really important to me, because it's at the very foundation of who is going to power our community for the next 1, 3, 5, 10, 50 years. We have a contributor-to-user ratio of something like 0.01%. We can't afford to turn people away who want to help, nor should we want to; rather, we should be welcoming them into the Drupal family that we all know and love.

Incidentally, I also think there is value in people who are, for lack of a better term, "Drupal Contrib Maintainers", who do things like scan through http://drupal.org/taxonomy/term/14 for things that are known to be duplicate modules and suggest they merge / collaborate with other maintainers of similar modules. But we have that now, even despite the CVS application process, because of the "Anyone with a CSV account who wants to can create a project of any kind" set-up we have.

I think we have to have a CVS application for one reason and one reason only: to get contributors to agree to contribute their code under Drupal's "GPL v2 or later" license.

I think we have historically had CVS applications for the following reasons:

1. To do a general sanity-check for the overall usefulness of new projects, lest contrib became gigantic mire of code where there are 30,000 projects, 100 of which are good. (But IMO, we're already there, and as demonstrated the CVS application process doesn't help with this problem at all.)

2. To do a general sanity-check of the code, lest the security team become inundated with 100,000 modules ridden with SQL injection, XSS vulnerabilities, etc. This is actually a fairly decent reason to have a CVS application process, albeit one not nearly as intensive as the one we have now.

3. To provide new contributors with some best practice advice before they go diving into being a Drupal coder. We've had mixed results with this, but on the whole I'd say the benefits of this gets overshadowed by the "pain in the ass factor" people feel they have to endure with all the various hoops they have to jump through. So I'd prefer to keep this, but morph it into a different form that wasn't a barrier in front of people contributing (see #29).

In response to this:

Just to make an example, somebody could propose a module that does something that is already done by Views, but differently from Views it requires less memory. Should we say "You can use Views for that", when the module is generic enough to be use for different situations?

I think you can say certainly say "You can use Views for that," and I also think that the "Drupal Contrib Maintainers" should ask the project maintainer to put a note on their project page that says "This module does very simple listing pages, but if you need something fancier, you should use Views," to help ease end-user confusion. I very much stand by our fundamental community tenant of "collaboration over competition," and I think encouraging maintainers to work together is a good and valuable thing.

But I see no reason to outright deny the project. Who knows? Maybe they can come up with a simplistic, high-performance alternative to Views module for large sites? Or maybe over time, it even surpasses Views module in its flexibility. CCK certainly did that to Flexinode, although you'd never have known it at the time when it was just in its beginning phases.

But if all people hear all the time is "No, No, No," then innovation is stifled, people flock off-site into silos away from the central community, and then the entire Drupal community loses out on new projects and resources to help foster the next decades of growth in the Drupal community.

I believe very strongly that "No" on any path to becoming a new contributor of any kind should be used extremely sparingly, about as sparingly as us banning someone's user account (and probably for similar reasons).

As far as what we do with the CVS application process once we have Git? I don't know. That's what this issue is here to figure out.

But my not-so-secret hope is that the "Application" is more-or-less the following:

- Checkbox in the user profile that says "I want to contribute some code!"
- Checkbox in the user profile that says "I agree to only contribute code to drupal.org that matches the Drupal license and not upload douchey things like mp3 or warez."
- Textarea for SSH key (a requirement for Git authentication).

And then, done. You get a sandbox, you start committing stuff, and people can use it or not.

As far as what happens in the project creation process? How about simply an extra validation process that searches for projects that might be similar and says:

"Is your code possibly duplicating these existing projects?

- Views: A module that blargy blarg... [snippet of node teaser]
- Super views: xxxx...
- Super awesome omg views: xxxx....
- Viewsifyication: xxxxx....

If so, please consider collaborating with the maintainer! [link to the page that talks about that]"

And that's it.

And what if our search algorithm sucks and doesn't bring up good related projects? Well that's why duplicate projects are being created right now in the first place! Because people can't find a fricking module that does what they want, so they think they have to write one!

So let's fix it, and fix it for everyone. Not only new code contributors, but also the hapless end user who's trying to find a module that does X.

</rant> :P

I think we have only two alternatives. We review code as now, slowing down the process of having new contributors, or we remove the review part, and we make easier for new contributors to be part of the Drupal community.

I'd be fine with the latter, but don't know if that would fly past killes, who certainly needs to sign off on any change we make to the CVS application process. And someone from the security team, as well.

A possible middle-ground is in what I laid out at #703116: Our CVS account application requirements are obtuse and discourage contributions; keep the review process, but make it much lighter, the point being to only do a general 'sanity check' on the code, rather than a full top-to-bottom code review. We only postpone a CVS application in case of serious problems like XSS/SQL injection that will cause the security team harm. Assuming they're good to go, we approve their account and direct them to a page in the handbook (which probably doesn't exist yet, but should) containing good pointers to good newbie resources like the coding standards, how to write secure code, etc. and then they're on their way.

I don't know, really bad code can certainly be hazardous to your health! :)

Yeah, I can understand that perspective; if you're going to bother doing a review, it should actually have an impact. I'm just really worried about "slippery slope." The fact that you draw a parallel between a CVS application reviewer and a driving test examiner is problematic to me; the point of a driving test examiner is to try and find reasons not to give you a license. We should never be trying to find reasons not to give people additional ways to contribute.

If we're going to keep with the car-related analogies, I would liken the CVS application reviewer more to a clerk who re-issues you a new driver's license once you move to a different state/province/country. You have already written the code (have a driver's license from somewhere); the job of the reviewer is to make sure you basically know what you're doing, and aren't likely to cause harm to the community with your code (just as a clerk gives you a vision check, asks you a couple of questions about your understanding of local traffic laws).

Just as there are a handful of reasons not to allow re-issue of a driver's license (you're blind as a bat, you think that a flashing green light means "drive on the sidewalk"), there may be a handful of reasons to postpone or even outright deny giving someone a CVS account. But I would argue that those reasons should be similarly serious to their "real-life" counterparts, and I don't think "You're missing a newline above your @return" or even "You could use drupal_http_request() here instead" qualifies.

We could probably make a decent list of the top, say, 10 things that almost all new contributors to Drupal get wrong (t(), theme(), SQL placeholders, check_X() functions, and likely some more) that cause actual "harm" either directly (security holes) or to interoperability between Drupal subsystems (translation system, theme system, etc.). Passing these checks indicates a pretty solid understanding of how Drupal works, and at that point I think anything else (drupal_http_request() et al) is "FYI".

It may already be cross-linked from one of these issues, but I still think http://drupal.org/node/484034 is the best place for a moderation queue from a security standpoint.

Ooooh. I hadn't seen that. That sounds lovely. Do we have the actual resources for that though? It seems the security team has its hands full just being the security team.

@webchick: depends on what kind of resources you mean. The security team is swamped because a dozen or so people have to co-ordinate and review every security issue in every module that has a stable release, completely in private. This goes for the most basic SQL injection, xss and crsf to bizarre things like content header ordering, and doesn't matter if the module has 20 or 20,000 users. However if an issue is found in a module which doesn't have a stable release, then issues are handled in the public queue and the security team as such doesn't need to have anything to do with it.

Since review of modules before they have their first stable release could happen in public, then it's a question of whether the community in general (or for that matter coder module for some of the more obvious bugs) would do it. I don't know, but there's an infinitely higher number of potential people than there will ever be in the security team who could do that - missing check_plain(), not using placeholders in queries, no confirm_form() or token etc. etc.

In terms of overall workload, I'm not sure how many modules go from development releases only to stable releases each month, but I'd bet it's less than the number of cvs applications. I've had a cvs account for years, and I've never, ever tagged a stable release of a module on Drupal.org ;) Some people even if they start off with a new project will end up co-maintainers, some will post some code then not maintain it - these would never need to go through the stable release review process.

The worst that can happen is you end up with a massive backlog of projects which are stuck at beta or RC without a stable release, that's a situation a lot of modules are in anyway, and it's a better bottleneck to have than cvs applications IMO. If a module gets through review and still has a security issue in it, then that's a shame, but there's a much smaller window for that reviewing something just before release, than reviewing it just before granting CVS access.

Is this still relevant? I suggest that a new issue be opened if it is since git has changed many parameters.

so be it