Our CVS account application requirements are obtuse and discourage contributions

Completely agree and +1 on the proposed text changes and the proposed process changes. We can definitely do this before we decide on #645470.

I'm afraid I went MIA from the whole approval process when it went public but as someone who used to work in this process I'm +1 to your re-written docs. It seems to have gotten harder and harder to get an account unless you know someone. Frankly, if I had to go through all that with my first module there's a good chance I wouldn't have bothered. Learning CVS was enough of a challenge! ;)

Michelle

I think Apply for contributions CVS access has become the page as it is now because who reviews CVS applications started to find similar issues in the CVS applications, and thought to get some shortcuts to avoid review hundreds of similar applications made from users who didn't understand why and how to apply for a CVS application, or who didn't read carefully the requirements.
I have changed the content of that page to make clearer some of the reported points (or to make them more explicit), and to report some details that were reported for some cases, but not for others (it was not clear to me why who wants to contribute modules was reminded to upload the archive with the code, but the same was not done for who wants to contribute themes).

I agree that the actual system is keeping away potential contributors, and I also agree that we need to think of the end users, to avoid they find hundreds of modules with similar purpose. Keeping a balance in this is extremely difficult sometimes, and requires efforts that would be avoided if applicants would better describe the project they think to commit, and maintain in Drupal.org.

Looking at the CVS application requirements page, the first defect I notice is that it's a static page. Users start to read, but then they get tired to read it, and pass to the bottom of the page were they find the link they need to create a CVS application (I guess that denying the CVS account to who didn't clearly read the requirements page is a way to force users to read it).
The solution to this could be a more interactive page, where the users are guided through the process step by step. There would not be a unique page with a link that allows to create a CVS application at the bottom; there would be a page similar to a wizard page where users would insert the information required, which would then change the content of the next page. The effect of such pages would be

1. Users would not read more information than they need; if users want to get a CVS account to contribute a module, then they don't need to know anything about contributing documentation, nor do they need to know anything about contributing translations. In this way, users would not find a wall of words, which could also be in a language that is not their first language (English is not my first language, in example).
2. Users could not simply jump to the end of the page, and directly click on the final link; they would be forced to read all the intermediate pages, and give the information required them (which would simply change the output of the next page).
3. The page would be interactive, and this would make the process less boring, or requiring too much attention (for the fact users would be presented few easy information at each step).

Such wizard pages should be output from a module, and we have already a module that serves that purpose; adding the code for that pages would not require too much effort, and any effort taken in coding that pages would save efforts in the process of approving CVS accounts.

what are the biggest real, actual problems that have occurred from people applying for CVS accounts?

The biggest real problem is that people don't seem to read the requirements. ;-)

Jokes apart, I can list some of the most problems I report about a CVS application (I had to create snippets for the most common problems I had to report). I am not sure it's what you are asking, though.

#3 is problematic because there's no consensus on it. There's a group of us that feels duplication is a bad thing because of end user confusion and another that feels just as strongly that competition is a good thing. :(

Michelle

My list is the following.

1. Code suffers of security issues.
   The code doesn't call drupal_rewrite_sql(), use placeholders in SQL queries, check the input obtained from the user, etc.
2. License issues.
3. The module duplicates the functionality of another module, or doesn't integrate with existing modules.
4. Code doesn't respect the coding standards.
   There are parts of the coding standards that describe how module functions should be named, which names to give to Drupal variables initialized from the module, which names to give to global variables; if a module doesn't follow those coding standards, then it is going to cause problems to other modules installed in the same Drupal site.
   There are then parts of the coding standard that describe how the code should be formatted. I consider those parts important because using a common format allow users to be able to create patches to resolve a problem present in a module they use; making more difficult for users to contribute to resolve a problem they found means to make that module die because few users will contribute patches.
   I normally report this issue when there are other issues already present in the code (in example, when a module doesn't use Drupal functions and the code doesn't follow the coding standards); I also report this issue when the code is made of few lines.
   IMO, not writing the code following the coding standard means the user has not taken the time to read the documentation about how to write a module, and it could also means the user didn't read the documentation about how to write secure code, or how the code for a specific purpose should be written in Drupal (although this is not always true, nor could it be the case for a specific user).
5. Code doesn't use Drupal core functions when it should.
   A module doesn't use taxonomy terms when it should, or it uses custom code when there is already a function made available from Drupal, or it uses a PHP function when there is an equivalent Drupal function that is more secure or is able to handle cases not handled from the PHP function.

_{[Edited by kiamlaluno to merge two points, and add the licensing problem point]}

I tried helping out in the CVS application queue a couple of times, and even from my unaffected POV I got discouraged on behalf of the applicants after a few passes of strict code-style criticisms. It just rapidly became not very much fun.
I consider "showing willing" enough, and after pointing out that we care about code style and API usage, I think that's enough to give them the sandbox to apply what they've actually done.

Perhaps the sometimes-discussed "verified" vs "badlands" modules approach would allow us to open up a bit more, and allow the good developers to 'level up' into full recommended module status.

@webchick: I consider coding style important because a consistent coding style throughout the project facilitates easy reading of code and thus to actually judge if there are things like security holes. So if code deviates so much from our standard that it is a burden for me to read it, I'd tell the applicant to reformat it. I'd not argue over minor issues, though.

If code generally does not follow the coding standards, it becomes very hard for me to read what's going on. I can't scan the code for the major problems. Granted, I'm not talking about a missed comma or spaces between concatenation kinda thing. It has to be bad. And we do see it quite often.

I totally agree that bad code style makes the rest of the review really hard, and maybe that's why it turns into such a big issue and sticking point.
If we can't see what they are trying to do, then the code will get a no-pass.
If it hurts out eyes, we're not going to be very positive about it.
In some ways it's inevitable, so some sane code style becomes a huge sticking point. Which in turn seems pedantic and picky.

One thing I think that slows it down is the whole : if you haven't got a CVS account yet, then you can only show us the code with a tarball upload. That takes an extra couple of steps and really slows down my ability/desire to review the thing.
If the code was already in a VCS, then we could review the diffs, confirm that it was heading in the right direction, and push them on. Without change control over the review code, reviewing it is a pain. And when things are a pain, we may produce overly negative feedback. I don't know if there is a fix for that, just an observation.

Still, I think there should be a way to lighten up on the 'gatekeeper' role. Just entering a dialog and saying 'these are things you should know about, and should do' would often have been enough. Even asking them to show that they've gone away and done what we told them before we even provided them with the workspace may be asking a bit much..
"OK, you've been told what you should do. You understand that now. Go ahead and do it."

Instead there seem to be a lot of applications dead in the water because it was just too much damn hassle, and presumably some good code and contributors that aren't playing with us. And a lot of bad also ...

I mostly just want to subscribe to this, but I also have one small suggestion: I think the "Why?" link should to point to http://drupal.org/node/422996, the page on 3rd party libraries rather than the page on GPL.

From a perspective of someone who had instant CVS approval, I have to admit I was a bit taken aback after reviewing the CVS application issues thread a few weeks ago (mainly because a co-worker was having a hard time getting an account approved).

I don't at all pretend to assume to know the work involved reviewing piles of modules, and can imagine the repetition would get rather taxing after awhile, and want to make it clear that I appreciate greatly anyone who is willing to take on tasks like these.

That being said, there seems to be a lot of issues with the current process. I'm definitely not a big fan of strict adherence to the rules, for many of the same reasons webchick lists. There's a line (fuzzy, I'll admit) between code that is just unreadable, and code that isn't "Drupal core approved". After reading a number of the open CVS issues over the last few weeks, it seems that there is little distinction made between those two ends.

Beyond that, I'm troubled by the tone a lot of these applications take. I realize tone is a hard thing to discern through posts in an issue queue, which is a bigger reason to make sure our communications are more pleasant. Ultimately, this is likely the first major step a lot of people who will eventually become important contributers to Drupal take. To be honest, had I had to go through this process (not that I've made a lot of important contributions thus far :) ), I can imagine how it would have been easier to just forget about it all and pick another project.

I've seen quite a few instances of people asking for direction as to their next steps, to get one line replies to read such and such a page, or repetition of the same argument that they are asking clarification for. In addition, there are instances of people asking for updates (after weeks of no response!) as to the status of their application. I find both of these regrettable, and a poor reflection on the good parts of the Drupal community.

Ultimately, a lot of the issues being raised can be sorted out in the project's issue queue, and in my opinion, don't represent reasons to put a CVS application on hold. Someone who has shown willingness to adopt Drupal standards will take the time to look for Drupal core functions if they are pointed out. And when it comes down to it... a "Hi, thanks for applying for CVS access!" goes a long way.

Just to report something really happened, two different users didn't notice something that was reported in the first 14 text lines, in a section that was well identified by a title written in bold. The first user didn't notice it, and the second user didn't notice it after I reported the application could not be accepted because it was not following the requirements.
This could be explained from the fact the page contains too much information, but I would expect users to carefully read at least the first 20 lines with attention, especially if those lines are marked with a title that makes clear they are specific for their case.

I agree that the requirements page needs to be changed to make users know what they really need to know; the problem is that without to know what the users already know or for which reason they are applying for a CVS account, it is not possible to decide what they needs to read. It's true that the requirements page should avoid the creation of duplicate projects, but is also true it should avoid somebody applies for a CVS account without to know what it is required to do (and then not doing it). I closed many CVS applications because users didn't attach any code for review (and they were not applying for a CVS account in order to become co-maintainers), when they received an email inviting them to upload the code for the review.

IMO, the problem is with that page, but is also with what surrounds that page. Users who want to contribute with new modules should be guided to the information they need to know before to start to contribute (and in this case, they would not probably find a wall of words in the requirements page).
Before I started to effectively write code, I looked for information about how to write a module, which functions Drupal made available, and only after I started to write code; it's clear that knowing PHP doesn't mean to know how to write a Drupal module, nor does knowing how to write a plugin for Wordpress. I find than rather strange that a user registered an account 1 week before, and he wants now to get a CVS account to be able to commit a code in CVS (especially when he shown to not perfectly understand what reported in the requirements page).

I'm still +1. People don't read walls of text and there's plenty of links there for more info if they need it.

Michelle

+1000 at #23.

No insult intended to the folks that worked so hard on the current version, but as a former documentation tester (for some of the first cell phones no less-- you want funny, watch grandmas trying to use a cell phone for the first time with an encyclopedia for a user guide, lol) I can say with complete confidence that the current page is a really bad #fail. No one considering volunteering their time or contributions is going to read that page. It may be unpleasant to admit, but sadly it's true.

webchick's proposal is a ginormous improvement-- my only other suggestion is white space, lots of white space. Space out the bullets and maybe even make the font size bigger.

The text is good. I have just two notes to make.

• I would avoid to report how much time the procedure last; one week is not the average time took for a CVS application to be approved, and reporting that in about a week the application will be approved could lead somebody to think that they start a CVS application, and after one week they have their CVS account (when maybe somebody reviewed the code, and the status of the application has been changed to needs work). The time to approve an application depends also from the time taken from the applicant; if the applicant is busy with something else and doesn't reply to the requests to change the code, then the time becomes more than two weeks.
• If the requirements page is changed, then another page must be changed to reported what is done when the proposed module is the duplicate of another existing module; what we do one week after the applicant opened a CVS application, but didn't upload the code archive; what we do when two weeks are passed, and the OP didn't updating the code basing on the given suggestions. there have been already critics about the process not being open, when it's clearly stated what we do in each cases.

The text is perfectly good; it points out that the review is done by volunteers, and that because other refinements the CVS application could not be approved (or take more time than normally required to get approved); in this way, the users are also referred to other requirements that are not reported in that page.

About the second point, there is already a page that can be used for the parts left out from the requirements page (CVS applications review, what to expect). For some of the terms expressed in the requirements page that are going to be moved (how much time needs to pass before an application is closed because the OP didn't upload any code, or because the OP didn't upload new code after a review suggested a change), I would much prefer that somebody would express an opinion about them, to avoid to hear the current process has been built from a user with the only purpose of avoiding new contributions.

Lovely text.
Throwing out the "reasons your application may get delayed" = "probably things you didn't do right" is enough of a nudge towards the detailed requirements.

I cannot exactly quantify it, but the order is correct (from the project type with more applications, to the one with less applications): modules, themes, others.

Considering there is localize.drupal.org, the reference to translations could probably be removed; applying for a CVS application to fix the documentation could also be removed. IMO, it doesn't make sense to give a CVS account that would allow to create a project without the applicant shown the code wanted to add in CVS; it creates a disparity between who applies to add a new module, and who applies for other reasons.

If you absolutely need me to, I can take a stiff drink (of Cherry Coke ;)) and try and spend another two hours poring through that 11K of text again point by point, trying to find things that make sense to move over…

I was not clear in what I was saying.
I can take care of the text that is removed from the requirements page, and re-organize it in the other page (as the title is CVS application review, what to expect, it makes perfectly sense to move parts of the requirements page there).
What I was saying was that I would like better that other contributions CVS maintainers would give some suggestions on the temporal terms to adopt about closing an application; the actually used terms (1 week, and 2 weeks) are the ones I proposed to AjK in an email I sent him, and he was fine with them (actually, I recall he was already using the 1 week term).

In the next 2 − 3 days I will move the part of the text that will not be included in the new revision of the requirements page into the other page.

a) disclaimer: i'm totally out of the loop on the cvs account approval process. i only get involved once folks have accounts and start breaking things. ;)

b) major hurray for webchick's initiative here on improving this page and the expectations we're setting for new potential contributors.

c) i'm mostly +100 on the new proposed text in #23, with one small (but important change). You have this:

Our code review will check for coding standards compliance, adherence to security best practices, and general knowledge of Drupal APIs.

While I think coding standards compliance is important enough to mention, it's the least important of those 3. ;) So, I'd rewrite that line as:

Our code review will check for adherence to security best practices, general knowledge of Drupal APIs, and coding standards compliance.

If I were a new contributor, that'd send the right message in terms of the relative importance of these aspects of my coding. I'd think to myself "the first thing they look for in code from new potential contributors is how secure it is -- that's great, and I better learn that stuff". This isn't just important for the contributor to know what's key to focus on, it also sets a message about what kind of community we are. Foremost, we care about security and code people can use, not pedantic nit picking... It's also some subtle PR about the security team and our overall culture as a project. We take security seriously, and we expect all our contributors to do the same. As I've said at various talks about contributing to d.o, everyone's welcome to write their own Drupal code. But, if you want to release it on d.o, you have a certain responsibility to your potential users, and first and foremost, that involves your responsibility surrounding the security of your code...

Given that, I'm going to call the text in #23 "RTBC". ;) Be sure to link to this issue in the revision log message on the edit, so that if future people want to start "improving" that page by re-adding more rules and cruft, there's a big "DRASTICALLY reduced the size of this page so people will actually READ IT. Please do NOT add more cruft here without reading http://drupal.org/node/703116 carefully." in the revision history...

Thanks!
-Derek

Late to the show, but here's what I'm missing from the old page:

- Hint about translations being handled differently. (How?)

- Hint about api.d.o documentation (only needed until ~D8).

- d.o CVS licensing issues/rules

- Although mentioned, it's not totally clear to me that I have to have complete, working code. Moving this detail to the start of the sentence might solve this point.

- When applying, you really mean it and are prepared to fight for your account.

- In general, I'd propose to split the list into 2 lists, where the second list has a leading heading of "Don't apply for a CVS account if... [list items]"

I've clarified and shortened the directions, also using more direct speech: http://drupal.org/cvs-application/requirements

After doing so, I realized that I'm missing a note about ongoing maintenance of the contributed project. While I certainly know that there are well-known contributors who are basically eligible to create new experiments in contrib and don't care for them at all, I don't think that this should be the standard and measure for new contributors applying for CVS access. Instead, we want to tell them that they are expected to maintain their work after providing it to the public masses.

Ideally, this should be a new bullet point (AFAICS, we'd be at a total of 7 then).

- When applying, you really mean it and are prepared to fight for your account.

Short note on what I actually tried to express with that: The entire application process is handled by volunteers. We get plenty of applications that look totally sloppy and awkward. It's absolutely no fun to review an application + walk through it with the applicant if there is only half-baked interest to provide a proper contribution and follow the instructions given by the reviewer in the first place.

I think part of the problem here is you're trying to refine documentation on a process that not everyone agrees on. Here's a couple of questions, which I don't expect to be resolved in this issue, but pointing out how they make wording difficult:

• Do contributions really need to be complete? People with existing accounts can put an alpha or even pre alpha module into CVS and start getting users and feedback while they complete it. New contributors are expected to have it all done before contributing.
• Do they need to support it? Existing account holders often toss up "as is" modules that are unsupported. This gets the code out to the community and maybe someone else will pick it up and run with it. New contributors are only allowed to submit code they plan to support.

There's probably more questions than those about new vs old and other issues with the whole process but I just got up and I'm drawing a blank on more.

Again, my point isn't to use this issue to resolve them but maybe they need to be resolved in other issues before everyone can agree on the wording here?

Michelle

The concepts express in the requirements page are not changed on the new revision of the page; what is changed is that part of the content has been moved to a different page.

@Michelle: Perhaps you are right. But then again, dww already put it this way earlier in this issue:

As I've said at various talks about contributing to d.o, everyone's welcome to write their own Drupal code. But, if you want to release it on d.o, you have a certain responsibility to your potential users, and first and foremost, that involves your responsibility surrounding the security of your code...

Obviously, it starts with security, naturally goes on to fixing bugs, and eventually also replying to support requests. As already mentioned, the situation is different for existing or well-known contributors, because we can usually expect a certain level of quality, and those people hand off their experimental projects quicker than you can say "hi". ;)

But if you are new, you should be prepared to take on responsibility for the project you want to create, and maintain. Note I'm saying "prepared" -- that entire page is about knowledge + understanding.

@sun re:

Obviously, it starts with security, naturally goes on to fixing bugs, and eventually also replying to support requests.

I completely disagree. That's not what I wrote, that's not what I think, and that's not what I believe our expectations should be. I do not for a second believe anyone has a responsibility to answer support requests about code they release on d.o. Ever. It's nice if they do, and we should make it easy for them to provide support if they wish to. But no one should feel obligated to do so, and no one should feel entitled to getting free support just because the code is hosted on d.o.

The only thing that I believe code authors have an obligation to care about when they put code on d.o is security bugs. "Your module doesn't work for my client's use case!" is not my critical problem. "Your module allows anonymous users to inject JavaScript into you my site" is. There's a giant, gaping difference.

re:

prepared to fight for your account

-1000 to this wording and conception of the process. webchick has it absolute right when she wrote this in #39:

People who are coming to this page are not our enemy. They are not some core patch, which must be mercilessly beat into submission until it's so clean you can eat off of it. They are one of an extremely rare group of people who instead of simply taking from the project, want to give something back. They want to take stuff that they've spent however many hours of paid or unpaid time on, and give it away to everyone else to use. For free. We should be treating these people like royalty, and we should be bending over backwards to help them in any way possible.

I completely relate to how frustrating it can be dealing with support requests in the issue queue from self-entitled complainers with half-baked "bug reports" dripping with anger and frustration at me, the person who wrote and maintain the code they got for free and just can't be bothered to read the README.txt to figure out how to use. Let us not mistake CVS applications from potential new contributors as the same thing. Yes, I'm sure we'll continue to get some half-baked applications that we'll have to (gently and temporarily) deny. Perhaps even some will be such flame-baiting trolls that we can lay down the hammer a little bit and send them off, but that should be extremely rare. Overwhelmingly, these are people we want to be welcoming and encouraging, even if they're not 100% "on board" with our culture and process. Of course they're not -- that's the whole point -- they're just getting started.

Keeping this page small, razor focused on the key points, and friendly in tone will hopefully do a lot to improve the quality of the applications we get, which in turn will make the job easier for the reviewers. If the fundamental things the applicants need to know all fit on one page, they're more likely to read them and therefore follow them. We'll spend less time saying "didn't you read section 4, paragraph 13 on the rules for submission?!" (pun about "submission" intended). If we set a tone of: "So, you want to give back?! KICK ASS!!! THANKS!!!!!!! Here's what you need to know to be a productive, responsible contributor: 1) ... 7)", and we fit those 6 or 7 points on a single screen, I predict we'll get more applications from people who've read them, and the tone of their requests will hopefully match the welcoming, encouraging tone we're setting.

This process shouldn't be a fight for anyone. We're volunteering to review the applications and be gatekeepers to (try to) keep the overall level of quality in our contributions repository one notch up from the bottom of the barrel. They're volunteering to contribute back and share their labor with the community. If there's friction, we should always keep this in mind, and try to deal with it from a place of compassion, not frustration.

I will add a note about use of patches.
Allowing the use of patches would mean to limit who would review code. Considering that reviews are made contemporary from more users, who reviews code should check all the comments to see if there are more patches to apply, then find the original archive, apply the patches, and review the code. If we want more people involved in reviewing the applications code, this not the way to get them. Who applies for a CVS account has just an archive to create, but who reviews should apply many patches.

If we don't want to have duplicate projects, then it should be clear that a minimum level of maintaining should be required; leaving out the big contributors (who would not be called so if their projects would not kept updated, and bug free), other contributors should show a minimum level of activity on their projects. This does mean they must correct the code for each request they get from users, but it also means a project cannot stay untouched for years when there are bug reports.

I have to agree with webchick. Nitpicky code reviews are not what we need and we also do not have the resources for.

@webchick #51: great points. Especially that if people have energy for such detailed reviews, let's throw that energy into one of the biggest resource bottlenecks for the entire project -- detailed reviews of core patches. Not only can existing core contributors handle (and expect) the resulting slap-downs, it's vastly more important that core code adheres to our highest standards (and yet, actually gets committed via frequent reviews and revisions) than the first offerings from potential new contributors, who, to be fair, only a tiny handful of whom will actually become the next webchick or merlinofchaos. We should treat everyone as if they might be the next shining star, but we should also be clear that not all of them will be, so we shouldn't pour valuable and scarce resources into everyone as if they will be. Not only is it discouraging for them, it's wasting our energy on a lot of people who might never turn into the rockstar contributors we hope they'll become.

However, I didn't write project.module circa revision 1.239.2.5 -- please don't hold that against me. ;) But yes, obviously being around the project for 4 years (and following all the changes in our style and best practices over that time) has certainly helped me write more Drupal-esque code...

Cheers,
-Derek

p.s. my first CVS application was refused, even back then. ;) I blame Gerhard. ;)

I'm not sure what we are discussing in the recent follow-ups. I totally agree that we don't want to do in-detail core-alike reviews for CVS applications.

In this context, it was previously mentioned already that we just decline to review code that is totally cannot be reviewed due to a horrible coding style. Happens. But not really often.

My last suggestion was to add something that raises awareness of applicants that they likely have to maintain the code they want to contribute. In all follow-ups, I didn't really see objections to that. It's basically logical, but possibly not for everyone. All of the previously mentioned projects + contributors wouldn't have been successful if they wouldn't have maintained their projects properly. The remaining question was, how to squeeze in that info for applicants.

Of course, we want to welcome new contributors and we all try our best to not scare them away. At the same time, however, we are also trying to decrease duplication of efforts and therefore module duplication hell on drupal.org, and ensure at least "some" quality for new projects. Times have changed since 200x and there are little things for which there is no module yet. Therefore, most of our current applications are either one-shot, single purpose solutions that duplicate the functionality of a more generic solution, or co-maintainer applications for existing projects. Only very rarely in between, we see applications that really sound like they could provide some value as a new stand-alone project.

Not sure why I wrote the last paragraph, but perhaps it summarizes the situation we are currently facing, as well as the future trend to expect.

Times have changed since 200x and there are little things for which there is no module yet. Therefore, most of our current applications are either one-shot, single purpose solutions that duplicate the functionality of a more generic solution, or co-maintainer applications for existing projects.

Reading that saddens me a little. Our 5000+ are *far* from covering all the things in the world, and we will only be able to stay on top of the game if we promote and ease innovation. We just cannot afford thinking that we already have covered all the ground, and that there are only "little things for which there is no module yet".

Sure. But we can't change reality, unless you're Neo. :)

Copying from IRC:

While we clarified the cvs applications/requirements page now, most of the applications are basically like: Do we really want to accept this? Not because the code is ugly, or insecure.
Just because there are generic modules that cover the use-case already, perhaps need a bit more configuration, but can do hella more.

I don't expect that to stop due to this change. People code that crap. Well, not crap, the code sometimes even looks good!

If I'd have to put all of the current applications in numbers, I'd estimate
50% one-shot, single-purpose crap, 40% co-maintainer applications, 10% (or less) "interesting" (or really new) stuff.

Most often, you are fighting with yourself whether the code you are about to approve really really deserves its own module (while you know that a patch to module X would achieve the same + naturally more).

But then again, you cannot really tell people to "patch module X instead", because they perhaps have a working solution.

Most often they are replying: "yeah, I looked into that, but found it too complex." So what?

Thinking ahead, it's literally the same we are facing with core development. Our APIs get more complex, and so are general-purpose contrib module APIs... add a new feature? "Sure! But please keep in mind that this function is also used by X and Y, and integrates with Z, and watch out for S, which interferes with T. But aside from that, cool feature request!" So what?

So it's always a "fight" (with yourself, as reviewer) whether this application is really worth approving, while you perhaps know that hacking that feature into module X would be "better", but then again, this person has a one-shot, working solution for the single-purpose use-case. BLARGH.

I'm not sure what we are discussing in the recent follow-ups.

I am not sure either.
The topic of the report is the requirements page, which has been already changed. The question is then: are there any other points that must be added in that page? As far as I can understand, that page already contains the points that should contain, and the page should contain as low points as possible (six points have been said to be the preferable number, and they seem to cover all that page needs to cover).

Other problems are not contained in the requirements page; in particular:

• Do we think the current process to get a CVS account, and be able to create a project is the one we really want? That has been already written, but no decision has been taken about that.
• Where do we point who wants to contribute new modules? Do we point them to the page with the link to apply for a CVS account, or do we direct them with a page with links to more information?
• How do we assure a plurality of point of views? If it's always the same person to review and approve CVS applications, then or the process will become faster than it should, or the process will become slower than it should. In the first case, there will probably be projects that are duplicate of existing ones, which have not been caught; in the second case, who reviews is checking too much details.
  Both the cases are not something we really want to happen; therefore, assuring the plurality of POVs is probably the first thing we really want, secondary only to avoiding to discourage people on contributing (although it should pointed out that creating a project on Drupal.org is not the only way to contribute on Drupal, as shown by many users who contribute on Drupal core code).

The page has been changed, but still there are users who don't understand when they should apply for a CVS account.
The page is much better than before; still, there are users not understanding what they should do (I agree there will always be users who don't understand what they need to do). Is there anything else that need to be changed?

You can't force people to read-- there will always bee some that just won't. However, I still find the page a bit wordy and hard on the eyes. How about this (below hr, the heading formatting is different on book pages, othewise it's a pretty faithful rendition of my suggestion):

Thanks for applying for a CVS account!

If you wish to contribute new modules, themes, or translations to Drupal, become a module co-maintainer, or take over an abandoned project, this is the place for you!

You do not need a CVS account to create patches for existing modules or to checkout core or contributed modules from CVS.

Please read and understand the following before applying:

• New CVS account applications go through an approval process. Our volunteers should be able to look at your application within a week. The approval of your application can be delayed or prevented if the guidelines below are not followed or refinements are required.
• Your work must be licensed under the same license as Drupal, which is GPL version 2 or later (read why). Also, we do not allow committing third-party libraries to CVS, even if they are GPL (read why).
• Before submitting an application, be sure you've read and understood this page as well as CVS applications review, what to expect (which also lists reasons an application may be declined).

For new projects:

• Your new project should not duplicate existing projects. Please consider collaborating with existing maintainers instead.
• You must submit a finished, working module or theme for review along with your application. Upload an archive containing the code to review in the issue automatically created for you by the application. Our review will check for adherence to security best practices, usage of Drupal APIs, and coding standards compliance.
• You must provide a motivation message, which should be a few paragraphs instead of only a few sentences. It should include details about your contribution, its features, how it compares to already existing solutions, links to screenshots or a demo, etc.

For co-maintaining existing projects:

• Create an issue in the module's issue queue requesting co-maintainership. You should only apply for a CVS account once the current maintainer has already accepted you as co-maintainer.
• Include a link to the issue requesting co-maintainership in the motivation message of your CVS application. Even if the current maintainer has asked you to become a co-maintainer, they still need to make a public record of this in the module's issue queue.

I changed the text as suggested by WorldFallz, but used just Failure to read and follow this procedure can result in your application being marked as "won't fix" as warning before the link to apply for an account.

Failure to read and follow this procedure can result in your application being marked as "won't fix".

is rather cryptic for someone not at all familiar with the cvs application queue. As from my understanding, "won't fix" equates to being denied, why not just say outright that failure to read and follow the procedures will result in your application being denied?

Should we ever "won't fix" applications? I understand from an issue queue perspective that it's nice to get them to a "closed" state but from a psychological perspective maybe "postponed" is better.

Perhaps the solution is to create new status that is considered "closed" in the project module's configuration on drupal.org and yet which is nicer to an applicant like "closed pending improvement" or something.

As someone who is going through and has gone through the review process I agree with many of the points made on this thread. I have been watching the CVS queue lately I think the three main things I have noticed are lagging behind are:

The easiest way to solve all of these problems is simply to take some of the burden off of the approvers. So lets say I submit a module that isn't quit up to coding standards or is apparent that I am missing some understanding of the Drupal API. Instead of just saying "Sorry you don't cut it, denied" it is kicked over to a "Drupal Programmer Improvement" queue that other people (including people w/o CVS requests) can comment on and help the applicant through the process. Once the module has been fine tuned and brought into compliance someone with a CVS account can approve (sponsor?) the module for another review by the CVS account approvers. To be honest you could even start the projects in this queue.

On another note, I would also recommend some type of point/rank system. This enables you to incentivize people contributing to all aspects of the community and not to mention most people love getting some sort of positive feedback for the work they do. Obviously there is still going to be some approval process that you will need to go through so people don't game the system. Some examples:

If we provide a place for people to learn and expand their skills as well as incentivize our existing community Drupal will continue to flourish. Let's do everything we can to facilitate that, not harm it.

Most of that is unnecessary. If you have people who can and want to review, point them to http://drupal.org/project/issues/cvsapplications -- we don't need more bureaucracy or weird, complex systems. We need more people who actually help out and do something.

Most of the CVS applications I'm tackling currently are trying to entirely duplicate existing projects. Bad. Very bad.

Hence, if anything, then our d.o search may totally suck. Perhaps people don't understand facets, perhaps they are just too dumb to search.

I have no idea what's the cause. But it's a clear sign that something is wrong.

Also note that most of the CVS applications I happen to review, which do not duplicate existing efforts, are more or less in a good shape.

Hence, if anything, then our d.o search may totally suck.

Seems alright, you just need to know exactly what you are looking for. If not it can be a pain to find something.

Perhaps people don't understand facets, perhaps they are just too dumb to search.

I highly doubt these people are too "dumb" (more on this later), I simply find it is not explained well enough. For instance:

Your new project must not duplicate the work done in existing projects....

That language needs cleaned up. While I am sure some CVS applications are literally duplicating functionality many I am sure read that as I did and thought "well it's not duplicating it, this module doesn't have that functionality". It also does not help that there are many examples of many modules in the system doing exactly that, either completely duplicating modules and approaching the solution in another fashion or providing additional functionality that another related module does not provide. It is extremely confusing and frustrating to someone trying to enter the system.

Even if this module duplicated functionality or was related to another module, how great would it be to turn that over to the contributer of the module and let them decide if they wanted the module integrated into their own or if it should be it's own module? Who knows better then the modules maintainer? Simple changes like will be the difference between someone continuing to try and contribute or just throwing their hands up in the air and giving up.

We need more people who actually help out and do something.

Give them a reason to. If you do not incentivize people most will not stick around and right now the entire system is all whip and no carrot. Even those people who will contribute their time freely will not stick around if they don't feel welcome. Something needs to change about the system or nothing will change, at least not for the better. To continue and do the same thing and expect different results is the very definition of insanity.

To follow up on people being too dumb, as someone who has spent countless hours on IRC helping people, spent money on Drupal books to attempt and understand the system better, and many unpaid hours of writing/cleaning up modules to contribute back to the community to have you imply that I am stupid is down right insulting. That type of attitude is exactly how you destroy a community.

Note to all: as part of the migration from CVS to Git, this whole process is going to change. Anyone who uploads an ssh public key to their profile will have a "Git account", as such. They'll be able to host sandbox repositories on git.d.o for proposed project ideas, whatever. The application/review/approval process will shift from when the account is first granted to official project creation. To have a specific sandbox repository turned into a real project, you'll need to go through a review before your project shows up in the module/theme/profile searches and download sections. See #781264: Decide on an appropriate git analogue to current CVS account workflow for more. Not that the current wording and process can't be further discussed and improved, but that effort would probably be better spent on the Git migration. ;)

Cheers,
-Derek

@webchick: Agreed. I didn't make it clear enough in comment #68, but I think the current hazing that potential new contributors must go through is insane. This whole process is crazy. The core-level, detailed reviews belong in the core issue queue, not in the "so, you want to contribute?" workflow. We need to lower the bar to contributing something at all, but raise the bar for what shows up when you search on d.o for code you might actually want to use... And yeah, calling potential contributors "too dumb" to figure out faceted search or whatever is a serious step in the wrong direction.

Cheers,
-Derek

dww & webchick - I think the next step of migrating over to Git will be a big help. However until you get the community more involved ultimately you will always be understaffed and slow on the uptake of new modules. As it stands right now one of the biggest holes in the process seems to be that if I make a module that uses the Facebook API I need to contact every contributer that comes up with a search for "Facebook". Heck, Facebook is an easy one. I can't even begin to fathom how many people I will need to contact for my Product Taxonomy Min/Max module. Not only is that an unmanageable expectation, these contributers simply do not get back to you. I have sent messages to several people asking them how best to proceed on several modules and have heard a response back from one person. Maybe they no longer check that email account or who knows, perhaps they simply don't want to talk to me, but this is soul crushingly bad. Once again I wonder if it is so important to stop module duplication and you need to talk to so many before you can get a module in place why are the contributers so disconnected from the process?

No matter what changes you all end up making the process needs clarified and be brought to reality. You need to provide people with a wizard (mentioned earlier on this thread if memory serves me) and walk them through step by step what they need to do before they submit a module. For example:

If that means they need to contact a dozen existing contributors on modules that are completely separate in functionality but happen to share keywords, fine, just make sure they know that. Provide some time frame they should wait for a response, preferably something some what reasonable like 48-72 hours.

If they need to go start a thread somewhere and ask how best to proceed, provide a link or at least direction as to where to go. Again, provide a time frame to wait for response.

Advise people that although they currently see modules that duplicate or extend functionality that they are held to different standards and must have a unique module to get a CVS account.

Provide people a link to the coder module and require they use it. Having only recently discovered it I haven't played around with it much but making it output a log file and requiring them to attach it to their application would be a good thing.

How many people will actually go through this process? Who knows, but at least they would know what to expect. I strongly implore you all start looking into ways to incentivize all aspects your community. Until that happens no matter what you do you will continue to have problems. I would also suggest you look at the "one module to rule them all" method you are holding new contributors to. Not only is it extremely cumbersome but it significantly slows down development and makes it all that much harder for people to get into the system or take over abandoned projects.

Sorry for not listing more specific examples, I couldn't come up with anything that wouldn't require a significant undertaking.

As an example of how people love ranking systems, here is a screenshot of what happens every time someone mentions karma on IRC.

subscribe

As a new person to reviewing CVS applications, and having made a public post about what I look for, I'll jot down my thoughts:

I think we can all agree that the CVS applications page needs to be as usable as possible (maybe some blink tags). I think it looks really good, but even now most applications I come across have not read it, or have just not got deep enough into the links. Not too sure of improvements. But I think at this point, we should be looking at automating Coder reviews and responses. A very easy note that, if read, could speed things up a bunch: suggest modules to review be a simple, but practical module. The larger the module the more there is to review, the more risk of complication.

Instead of taking less time to review, we should be ensuring that we come at it from a mentoring perspective. This is a big first step into the community. It actually benefits the community as a whole if we take a concentrated time to ensure that this new person is up to speed. I look at this as my ability to pass on the knowledge that has taken me years to gain and trying to package it up a little bit and jumpstart someone else. There is a lot to learn about the code and the community (I sure don't know it all) and this is a pivotal point that will probably decide a lot as to how the person will contribute further to the community. To me, its very much worth spending my time, making smaller, standards-level comments.

In my unicorn prancing mind, I see this sort of statement as being the first response to an application,

"I/we am here to ensure that you succeed and become a part of this community, but we're going to take some time in making sure you have a good base for contributing to this thing we call Drupal. It'll be fun but please be patient"

There should be no rush in granting CVS access. Yes, we want to be reasonable, and yes it could be annoying to put something up on github for a few weeks, but these are not reasons to potentially sacrifice quality contributions on drupal.org. I know there is a large case for ensuring that drupal.org is THE place for Drupal contributions, and I agree with that, but drupal.org is already THE place for Drupal contributions and slowing down the CVS application process will not change this.

I still have yet to once install any of the modules that I have reviewed. Yes, I am lazy, and I do focus a lot towards coding standards, but my point is that I don't actually care if the module works. Sure, I can pretty safely assume that a person applying ensures that the module works, but to me, the process is much more about this person becoming a part of the community and jumping into the cold, cold Drupal water with the flippers of coding standards, the snorkel of module maintenance, the swimmies of the Drupal API, the shark fin of security, and a wet suit of love. If we just throw them in the water and hope they swim, we'll have a lot of deadwood in the water (bad contributors). Ridiculous analogies, but I think my point is there.

Also, comparing new applicants to old applicants is unfair. There are quotes above that conjecture prominent people in the community would be turned off if they had to go through the same application process now. Maybe. But times are different: we have robust coding standards, lots of modules, more complex code, and a much bigger community. There was actually less to know back then and therefore the requirements should be less, so comparing the two is not fair in my mind.

And yes, I should be doing more core work, but reviewing someones first module and reviewing core patches are two completely different beasts, even coming from a code standards perspective. I am just pointing out that they shouldn't be compared as equal activities.

Overall, the process is tough. I know a number of people that have had rough times with this process. But I have gotten positive feedback from the applications that I have reviewed saying that they have learned a lot, and I think its so much more about taking this moment as small mentoring moment in order to create stronger contributors to the community.

zzolo,

i couldn't agree more with everything you've said. also, i want to say how totally awesome all your help and feedback has been, so thankyou.

i think that CVS applications, like docs work or any other entry point for community involvement, *definitely* needs to be dealt with in the mentorship spirit zzolo has described. people's first experiences with contributing can either turn them into an amazing contributor or can turn them away from it for life.

personally, the frustration i've had with my first experiences with this process has been high, but being heavily involved in the community, i have the tools, knowledge, and karma to get good help navigating this process and learning how it is supposed to work. that said, the people who i've been helping mentor myself, who are the ones applying for the accounts, would certainly have long given up if i was not pushing them to persevere and reminding them that it's not for nothing going through this. BUT it really shouldn't be so frustrating that people give up, i can only imagine how many who haven't had additional support have probably walked away.

largely *not* because of the guidelines themselves (most of which are pretty reasonable), but moreso the lack of clarity around more grey area cases and how to manage them, and even more influentially, some very abrupt responses, which were pretty discouraging to people who are still quite new to the community. nobody should ever be left with the sentiment of their contribution being flat out not being wanted, as that can be a valuable contributor lost for life.

that said, i do have faith that the cvs application reviewers do have the best intentions, and i could be wrong here, but i suspect that part of this might be a looming issue of burnout and a lack of reviewers... so i'm wondering if we might help this out somewhat by a bit of a drive for more reviewers.

anyway, just my two cents as it were!

As far as the CVS application exists, there will be users who have rough times with this process.

The CVS application has been implemented because there are reasons to avoid that users can create any projects they want (mainly to avoid the proliferation of modules with too similar purposes); differently, the process to assign a CVS account to users without one would have been reduced to a page with a single button that would add the necessary row in the database to allow a user to make commits in CVS, and create projects.
I think that we need to think of what we exactly want from the users, and what we want from the CVS application. Saying that the current process is too long, that it takes too man-power, and that we should remove it completely doesn't seem correct to me. We should remember that we have two different groups that are involved in this; if from a side there are the developers, from the other side there are the users who just use Drupal, and who could get confused from all the modules that are available for Drupal (especially when there are more modules with the same purpose).

As per a possible solution for the users who seem to not read the requirements page, and straightly go to the link to open a CVS application, I have already suggested a solution, which would also allow users to not get information that is not required in their case (i.e., it is not necessary they read about what to do when they need to become co-maintainers of an existing project, when they just need a CVS account to create their own modules).

I also think that users should be guided to the process to become Drupal developers. Just to make a silly example, it's unthinkable that a Linux developer creates Windows applications reading few things on how to develop a Windows application before to start; the fact the used language is the same it is not a reason to immediately start developing a Windows application hoping to get the best result.

Hello All,
I am going to add my 2 cents (in seeing that I have had an application rejected and recently resubmitted it)..
After the above had happened to me, I find myself looking in the CVS application queue to see what modules are being submitted. Just because certain module do not meet the criteria set out by drupal.org does not mean it is not a great idea.
I wonder how many great modules are not being shared because of these strict guidelines.
I totally understand not wanting duplication but what if the contributor cannot word his application properly or present his application the 'right' way. They are denied access to contribute to this open source community.
If a module is submitted and it does not use an existing module api, it get rejected or questioned?
In reference to building sub modules for other larger modules with API's... This one size fits all approach does not sound like a good idea. Google is now implementing site performance as part as their ranking process http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-w...
Is site performance a thought in the future of this project?
My personal site is on Mediatemple (gridservice). It runs slow. I had to turn off pretty much everything on this website. I had to create a custom module to pull in my twitter feed because the Twitter module was too slow for what I wanted.

Anyway these are my thoughts on this.

Sincerely,
Chris Bovard

Hi @cbovard. Your concerns are valid.

Its very subjective to say if a module is a "great idea", but I would be inclined to say that "great" modules don't just get thrown aside in the application process. We definitely make sure that everyone provides ample description of their project and features. There is definitely some limitations due to the fact that Drupal is officially English, but ultimately, it is the code that is getting the review. I am not sure how the CVS application guidelines would prevent someone form presenting their great idea.

As a reviewer, it is more important to me to see that someone has taken the time to describe their module as best they can, that it is obvious that they have looked for similar solutions, and in the case that another module does something similar, that they have attempted to contact the other module maintainer in hopes to combine effort. My assessment is on effort, not on mastery of the English language.

Performance is a whole separate issue than duplicating efforts and creating an unusable contrib space. It makes much more sense for the Drupal community to make the Twitter module better, than to create a new module that does the same thing minus some features. As a reviewer for this sort of application, I would look for an issue in the Twitter module that the applicant has started addressing the performance issues.

Overall, its not about how cool or how many features a module has, its about what is best for the community. And to me, that is ensuring that new contributors understand how to code and contrib to Drupal, as well as making sure the contributed pool of modules remains valuable.

Well said, zzolo. I'm not sure whether we are communicating the points you summarized good enough.

Kiss: Keep it simple and short

you want a CVS - account? Fine!

You only need it to maintain a project. If you comaintain a project, then …(as writen above).

If you have a brand new project - please doublecheck that this is realy a new project and try to cooperate with existing projects and other maintainers.

If you still think you have a brand new topic or an different approach for a task, then you commit yourself to the project-guidelines for (link) ‚project maintianance best practice‘, as a requirement for every CVS-account. Have your project code ready to add to the CVS-account form.

If (- and only if!) maintainers where more interested in accepting patches (what about a statistic how long an average patch stays in the issue queue?), then i would suggest: An other requirement is you can link to 3 accepted patches (or 50 lines of code or whatever is appropriate).

If people have accepted patches, then chances are high, that they know to use the api and that these people are willing to interact with other maintainers.

And whatever hurdle is - this only a hint to the behavoir of a maintainer in the future.

Well as iam gone through this pain once, iam really suprised that this issue is actually already discussed on. For me, i was that kind of "done with it", i was not even willing to open such a discussion.

For me the cvs application rules are pretty much the best way to get rid of any competent contributor by defintion. Iam very sure that you get rid of most people:
- reading the API
- caring about security
- caring about sharing the work and involve witht he community working on the modules
- being an experienced developer
- looking at other modules - helping there
- been in other communities - done the job there

Why?

Doing all those things above you wont find time to read the long docs about how to apply to CVS and the gazzilion rules. You are experienced and you just give a intuitive try to get an account and give something cool back to the community. And you will adopt all those rules one by one as you used to.

Thats how we developers work all day - thats what we are used to. We take something complex and big and work through it part by part - the practical way. We try&error, we evolve, think over it, discuss and fix it.

With the current module you exactly forbidden that kind of behavior. You set this things as correct implications

1. reading the cvs apply docs 100% and know ===== Interested, open minded and "drupal ready" developer.
2. dont read the docs like book from start till the end ==== Not interested, not experienced, not drupal ready.

And actually i expect the reality ( not theory ) to be the oppposite. People who are experienced, are used to open source and communities will choese 2.
People who are not will most probably choose way 1 (as they have absolelty now clue).

What happens now?

You discurage people you actually want to attract. You keep away exactly those people, who work full time on drupal development. Those are the experienced ones, those have cool contributions which do cool work. Those maintain the modules they have created - they give support. And those people wont deal with such treatment. They will simply invest their time in something more productive.

My personal standing?

Well after i applied for the CVS account the first time, i was writing a module to be similar to the drupal 7 file-api. My module had some minor flaws like some coding styles and i fixed them as i was pointed at them (well, remember the try&error thing).
After got through those critical parts the queue was about to be closed + accepted. During that time i recognised (after spoken to Aaron), that there is already such work undergo in the media module. I have talked to Aaron and he told me, he would be glad if i can help with the D6 port.

Got back to my CVS appliance issue, before it got accepted, i have writing down ( bymyself - not getting "caught") that i wont release that module but will put my time into the media module and help there.

You know what happened? My CVS account got denied. Why? "I got nothing to contribute" as iam not going to release file-api module. The module was _finished_ and uploaded to the queue before...!

Well this is the perfect way to really piss off people. Once and for all times.

Todays burden

i dont want to hijack this issue, just share my opinion and the way it took me. And i think the following part just reflects and how the current rules work out.

Today i see that most modules are not maintained at all. The quality of contributed modules is at the bottom ground with some dust over it. Maintainers are not present, not interested in contribution work, not interested in anything at all. Maintainers locking down modules just "for doing it". Queues are full if people with patches, contributions, ideas which never got recognised by the maintainers. And THOSE PEOPLE are OUR user _base_.

And the contrib modules are the first "interface" to the new community. You install drupal and some module and then you start to "tweak". This is the first step how to attract new contributors. This is our first line. This is front to the biggest part of the community.

Contrib modules and esp. their issue queus are our frontline to the community. And we do it like the irish people in Braveheart: We show our asses there! (hell yes, this is bold-underline-italic! :) )

So what we have now is, the rules are backfiring.

A lot of criticism - but what about something contructive?

1. Iam all for reducing the ruleset. Iam fine with the top 5 of webchick
2. Iam _very_ strong for reviewing contributions after people got their CVS account. Iam for a system allows to blame maintainers! Why? To actually get rid of those people who are not able to work in a community and harming the community. Get rid of people made "a nice show" for the CVS account and bringing hell after it.

So rather dont waste to much time before people have contributed, waste it afterwards. Look at there contributions while they not feel "watched".

- Iam all for bringing back FUN into working with other people. Iam for treating a contribution as a gift - not a threat

- This will encourage new contributors. This will give people which are eager to learn but not there yet the perspective to participate. And this will be one step to control the quality of Drupal-Contrib-Modules

Once and for all, contributions are worth it. They are the base open source and our project is build on. Every single contribution should be respected!

@EugenMayer, thanks for your thoughts and personal account. You obviously have some strong thoughts on the subject, and my personal apologies for your bad experience with the CVS application process. We are trying to make it beter.

But I don't fully agree with your attitude here. Yes, I think contributions are what make Drupal so strong, and I think we all try to do our best to foster meaningful contributions. But you yourself point out the following which actually justifies the application process, IMO:

Today i see that most modules are not maintained at all. The quality of contributed modules is at the bottom ground with some dust over it. Maintainers are not present, not interested in contribution work, not interested in anything at all. Maintainers locking down modules just "for doing it".

Drupal.org does not currently have the capacity to "police" every module (as this is done by contributions from the community), as we barely have the capacity to review CVS applications which are the first major steps into contributing code to Drupal, as well as all the other responsibilities of maintaining a module. So, the CVS application itself is the only current point we have to ensure that we foster responsible module maintainers and try to avoid the situations that you list.

Also note that, from what I understand, the idea with the move to Git as the main code repository, is to move to a workflow where anyone can have a sandbox, and then each module that gets officially contributed will be reviewed. Though I am concerned about our capacity to do this, as a community, it does address some of your grievances. But I imagine the approval process will still be similar as it is now as all the the same principles and guidances are needed with each module.

What can we expect form git „forks“?

1.) with not accepted patches, or patches rotting in the issue queue less and less coders are willing to post their issues and patches - they fork themself - like many do even right now - have a look at public repositories (github …).

2.) the issue queue on drupal.org losses importance, patches and issues are spread all over the internet: in the blogs of people, in public repos and worst in private issue queues and private repositories.

3.) We can expect more and more differences between contrib modules arising and we will get to a point where much more modules are incompatible to each other or even worse forks of drupal core come up and they get incompatible to the original.

4.) The effort of using a modul rises and the hurdle for a newcomer gets higher, means less newcomers, less coders, less quality, less reputation and so on.

What to do?
We need good reasons why someone wants to use the issue queue, how someone profits of contributing (a patch, …).
These are the topics to discuss and solve.

We have to many bad examples how it does not work - we need first - my opinion - a best practice guideline for good maintainership - and also procedures what shall happen if a maintainer does not follow the guidelines.

And to come back to the original topic:
We also of course expect new maintainers to commit to these guidelines and we offer a way for people to grow into the status of a good maintainer.

@83: You cant control a collective mass using some few empowered people. This is not working by defintion and it is never working if people work as voluntaries on the project.

Iam not sure how often this should be teached to projects until they finally recognise that the power of freedome like we have in open source is the base of its success. And thats what made wikipedia a huge success.

Instead of empowring a few people to approve ("control") the mass has been empowered. But everbody with micro powers. All together the main stream is to be expected to be positive. It is to be expected that a lot of eyes control what happens. And the so often propogated quality was not going down - it finally was going up! A community has teached and envolved with the process and it is not working on its own

So what i want to tell you is that the basic approach is wrong. Instead of empowring a few people to review / accept cvs appliance, make it the other way arround.

1. The cvs apply issue should be only a formality. Very few rules to follow or even none. Just a form to fill out - validating automatically - accpeting automatically
2. Let the mass ( community ) vote and judge on contributed modules AFTERWARDS (see vote system below). After the negative "judgement" reaches a critical value ( anything below is noice ) the webmasters are triggered. They use the written guidelines Thomas was talking about to judge within the community. They point the maintainner on some rules which he needs to adapt to and back off.
3. This should get repeated X (x defined by the rules) times and if the maintainer is caught to not willing to "learn" at all, CVS access is removed for a penalty time

And in the end, let the automated system work for you. e.g.:

1. When a module does not get updated half a year, the maintainer should get an email and get asked if he is still interested. If he does not answer to the reply adress, open the module - everybody with CVS access should be able to overtake the module by one-click
2. Should the module have more then 5 bug issues opened without any answer for more then 2 months, the maintainer should be thought as inactive. open the module
3. Use a voting system. Every vote counts one unit. Every vote of a member which is contributor of a module which has a positive vote-result right now should get a plus ( lets say 1/10 of the postive value ). So people which got judged to be "competent" get more vote-weight. And this is dymically.

With those rules you empower the userbase, you motiviate the contributors and you "teach" new developers. You also motivate maintainers to work actively on modules or actually cooporate with others. They will start looking for co-maintainers. Finding interested co-maintainers brings joy back to the maintainer, getting help and therefore credits for his contribution.

--

All in one we have a huge community you should finally start using its powers without treating the community like a small unable child. And yes, there will be people voting badly, there will be bad maintainers or people overtaken a project which are not doing it better. But it will cleanup in the next rotation then - or by votes.

Never create rules which are based to deal with the minor 'bad people'. Rather create rules for the good ones to deal with those, if you have SO MANY EMPLOYEES!

Agreed with zzolo.

1. Contributed Drupal projects are not Wikipedia pages. There are project dependencies, existing site content, updates and major upgrades, and a lot more. There are users, support requests, and handbook pages. Drupal contributions are not only called projects, they actually are projects.
2. The security team is even smaller than the CVS application review team, as everyone can review CVS applications. Only a small group of people is able to do security reviews. Security issues and announcements hurt Drupal's reputation very badly. Not limited to the originating, contributed project. Security effectively weighs more than the amount of contributed projects.
3. Duplication hurts, too. The essence and spirit of open source is to contribute and join forces to build better quality products. Initial reviews and discussions of new contributions are here to ensure, teach, and remind ourselves of our strong culture and principles. It's our culture and principles that makes up Drupal. And it's lists like this that make Drupal ugly and unusable. Freedom ends where it starts to harm others.

It is true that we may need to improve the maintenance situation of contributed projects. We may need to re-think and re-teach contributed project ownership and leadership. Discuss the anatomy and efficiency of contributions to contributions. But that has to be a much larger community debate, involving all roles from maintainers to developers to project consultants to users. Simply sticking five stars or yet another e-mail notification onto the current line certainly won't cut it. We have existing processes and procedures that work with the current system. Lastly, the version control system of your choice has nothing to do with these community processes. Instead, evolution is based on nature, quality, and trust.

I aggree:
Iam fine with that, that the ownership / leadership question of modules should be discussed in some other issue. But i think it is very much related to the question, what kind of CVS applications ( rules ) we need to apply before a contributor gets access.

Because if we "recheck" those "rules" after the access properly, like e.g. my idea above, you dont need too many rules in the inial cvs application.

I disagree:
I completly disagree that wikipedias "topics" are not related to our "modules" concept. They have dependencies, they have relations and they are based on rules (API -> facts of the topic). And its even more related, when you think about what does harm wikipedia most? Yes, WRONG information /content (this has been exactly the main issue in the past people where aware of). And wrong informations are related to our bugs / security issue / missused api problem.

So we have a lot in common with the wikipedia - and we have a lot to learn. Wikipedia is "open source knowledge" - and we have open source software . Both are written down in text, both have syntax and semantic which can be wrong. If it is wrong, people get mad, reputation sinks.

But we differ in mostly having a different policy: One person being allowed to edit the topic ( as specific one). A person who might have a very subjective undestanding our not being present at all anymore.
This would kill any quality on wikipedia. Any! And it really does the same on d.o.

Because of one main thing (already got mentioned). Wikipedia and Drupal reached a critical mass where it cant be handled by a small number of volunteers.

And yes, i talk about a shift of thinking about contributions. What i want to state is, contributions on drupal.org SHOLD be common sense and not pure maintainer ownership. Thats what drupal.org should stand for, a plattform for community projects to have them all in one place. And not a personal distribution plattform ONLY. Because personal distribution plattforms can be build easily.

So if drupal.org want to still establish itself as THE drupal plattform for the communit, it should use its power to merge the community. Otherwise it can be easily replaced by one gazzilion personal distribution pages with own issues queues. (which already does happen a lot..)

To get back to the topic here: I think before thinking about working on the CVS application we should talk about the concept of what gets contributed then, how it is related to the drupal community and things like this. Because that really makes a huge difference here.

After thinking about this, i though i summarize this up.

Goals:

1. Reduce size of CVS applications
2. At least dont make the contribution worse then they are right now
3. At least dont higher the effort the webmaster / cvs admins have right now

Problems:

• With the current "project culture" and power of maintainers, maintainers/ contributors need to be chosen wisely. To achieve that, the CVS appliance policy is a hard hurdle to filter properly ( sun / zzolo )
• This seems not really to work out to good for the contributions somehow (the quality seems to drop)
• We cant check modules again and again ( not enaugh manpower / too many modules ) to ensure proper maintaing

Observations:

• It seems like we probably cant achieve goals 2,3 while achieving 1 ( sun / zzola and others )
• So probably need a other approach

While I appreciate your passion, I tend to think it is as much a product of your particular experience with the process as it is the process itself. The process is in no way perfect, but the current page is significantly less bloated than it was, and probably the best we can do for now. I also think the plan to shift to more code contribution access with less project page access after the vcs migration will also lower the bar, and thus encourage, contribution.

Your repeated insistence that contributing modules to drupal.org is analogous to contributing text to wikipedia only serves to undermine any possible valid points you may have. Contributing modules to drupal.org is in no significant way similar to contributing text to wikipedia and no amount of insistence will make it so. Anyone who can read and write, a skill possessed by a majority of internet users, can contribute to wikipedia. Contrast that with the fact that in order to contribute module code to drupal.org you need to both know how to code AND know the drupal api-- skills only a minority of internet users possess. You also need to consider the ramifications of bad contributions. If someone contributes badly formed or inaccurate text to wikipedia what are the potential consequences? Now think about what happens if someone contributes a badly formed or insecure module to drupal.org? Sites can be hacked-- real property damage can occur.

No, the bar to contributing code to drupal.org needs to be higher than any internet schmo editing an article at wikipedia. I don't think familiarity with security best practices, the drupal api, and coding standards are too much to ask. Afterall, if one is unwilling to do even that, odds are they will also not bother to properly maintain their modules (one of your own complaints).

in any case, this should be postponed till after the vcs conversion. There's no sense in wasting time on a temporary process for a system that will soon go away.

Subscribing to follow how this pans out.

I know this issue has not been active in a while. I wonder if the switch from CVS to GIT will reactivate this topic. I also wonder if there could be a way so-called "apprentice level" module developers (or first-timers) could more easily share their modules.

Using GIT, is it possible to have different groups of contributors? I am wondering if there could be a "starter" GIT contribution account. Maybe something like Eugene suggested. This account would be (relatively) easy to get. Modules released from these developers would be tagged in a way to let end users know that it may be the developer's first release and perhaps these modules could be optionally filtered out from searches altogether.

This way, module newbies could share their work, while the community at large could benefit from it. Drupal webmasters could see how frequently the module is used and what sort issues emerge in the issue cue.

It seems to me it would take some of the load off the webmasters and transfer it to the community. It would also build on the already-existing module Darwinism in place and leverage the strength of the community, while also offering some protection from less-than-perfect modules.

Here is what I remember as the outcome of the conversation at the dev summit at Copenhagen:

1. Getting a git account will be easy. You fill out an online form on drupal.org that says that you understand community values and legal issues. You get an account. The details of the form are being hashed out in #720670: Figure out wording of the "Yes, I promise to upload GPLv2+ code" checkbox.
2. If you have a git account, you can create a project and project page on Drupal.org.
3. To create a release

you must go through a process basically equivalent to the current CVS application process.

So basically, we've thrown the gates open for people to join in and develop and create projects. The only limitation comes when they want to create a downloadable package for their project.

Hoping that is a correct representation of what we decided in Copenhagen.

That sounds pretty well accurate from what I can recall (and more detailed than what I could have scrounged together!) thanks Randy. :)

Will project pages be able to have downloadable code (modules) on them? Or is that reserved for "releases"?

2. If you have a git account, you can create a project and project page on Drupal.org.

Given the high amount of unwanted, bogus, or otherwise one-shot-off and test CVS applications created by people, I naturally and logically expect a vast increase of projects being registered on drupal.org that won't (ever) contain any code or releases.

The project short names and therefore namespaces of those projects will be unavailable for others, who might have working code already.

• Outsiders will probably rewrite their code to use a different, cryptic, but available namespace. Effectively adding burden on users and support channels; e.g., "Do you have the ftzgrp module installed?"
• Insiders will probably create a request to take over project ownership of the existing "fake" project. Effectively adding burden on d.o webmasters; unless a more automated project_conflict_resolution_process.module is developed.

If we'd want to prevent that from happening in the first place, then we'd slightly change the outlined process into:

1. Create a git account by filling out a form on drupal.org
2. If you have a git account, you can create unofficial projects without project page on drupal.org. I.e., like the current sandboxes, or similar. Code can be edited, improved, and also shared and worked on together with others.
3. To create an official project and project page with a release, you must go through a process basically equivalent to the current CVS application process.

The technical difference to now would be that the (CVS/git) application review process is based on revisioned code already, so iterative code reviews will be much faster; but most importantly, the result of that application review process will merely be to grant the "create project content" user permission.

Hi @sun. Your points are very valid. But, the idea with this particular plan is to allow people to easily put up code and have all the amenities of a project page without the official approval process. Think GitHub; there is no barrier to entry there and people have a whole infrastructure for their code/project.

So, instead of limiting this, I would suggest possibly the following:

• Namespace is the problem. We probably need more than one namespace for "approved" projects, and sandbox projects. This way, project names will not get used up, except with "official" projects.
• Some sort of very distinct visual difference between an "approved" project and sandbox project.
• Some sort of indication to user and creator that this project has not been committed to in X number of weeks.

Also, if we are going to further this discussion, I would suggest the following:

• A new issue.
• Determine goals of new system before process/rules.

Github's solution is to prefix every project with the username, which seems like it solves the problem of conflicts but creates a new one: it's really hard to find the right version of a module.

In this case I think a solution where we are very accepting during the code commit, project node creation etc. process is GREAT, but we may also need to add some conditions to the abandoned project process to cover new situations of project node takeover and make it more logisitically simple and socially acceptable to do it. For example the word "abandoned project takeover" sounds very hostile. Maybe "project transfer" would help. It's also very difficult right now to move project_issue nodes from one project to another, but if we are going to be doing more of this that will likely become necessary.

@mcfilms: the code would be accessible via git checkout, but not as a downloadable file until there was a community review process on the project/code.

I'm probably going to get reamed for that but it has to be said... Maybe it's time to reconsider the whole "golden projects" idea. One repository that is whatever anyone wants to submit with lots of warnings all over it and one that has gone through some sort of approval process. That would lessen the burden on the security team if they only had to worry about the approved one, would lessen the burden of being the gatekeeper because the code would be there and available in the other repository so it wouldn't be such a huge deal if it took a while to get a review.

If we could say to people like this, "Here's your space, put up your project, promote it, get people using it. When you have something solid, ask for a review to get into the main repository." I think that's a whole lot better than, "Sorry, we only have one person actively doing code reviews and 20 bazillion people applying so you're going to have to wait approximately half a gazillion years before you can share your work with the community."

Michelle

@Michelle, #98, I think that a "reviewed" or "officially maintained" status/flag for a module would be a great thing. Security team doesn't get involved with modules that aren't on the "reviewed" list. Applying for "reviewed" status is where the application process starts. Would work for me.

Moved to another ticket as we are actually coming up with a new process, specifically for Git, and this is a more abstract topic, and changes have already been made to existing system to help things as much as possible (ie text improvements):

#961144: Determine/finalize technical requirements for post-Git migration project approval process

(not sure the best way to mark ticket, but putting as fixed for now)

#98 sounds like a wonderful alternative to me. I wouldn't mind going through the process as bad if I had a way to promote my module. Of course I would prefer to have my modules reviewed, and in the officially maintained. At least with this method people who are using the module could still submit issues on module, and help get the module to an approved status. As it stands now I have had an application in the works for almost 2 months. It is really discouraging, and I have give serious consideration to not even using drupal any more. There are other CMS/Framework communities where its not quite so hard to get in the community.

I wouldn't mind doing code reviews myself; however, I don't think I should be doing them till I can get at least an approved status on one of my modules.

@kiamlaluno: why reopen this ticket? I see no reason to give this another 2 weeks and then have it bump everyone's tracker again when it's moved to closed another time. This is closed. #961144: Determine/finalize technical requirements for post-Git migration project approval process is what needs to happen next.

@dww: I didn't re-open the ticket (which was still marked as fixed); I made it visible to somebody who probably would need to see it.