(This needs a sister issue once it's finished called "Document the actual process for obtaining a 'privileged' Git account" :P)
Over in #961144: Determine/finalize technical requirements for post-Git migration project approval process, we came to consensus about a few different things:
1. There will no longer be an application process stopping people from committing code to drupal.org. Instead, anyone who agrees in their d.o profile to post GPL code will be able to create projects and commit stuff.
2. Because these projects might contain experimental code, might never amount to anything, etc. we don't want to pollute the very limited project URL namespace with them (http://drupal.org/project/views et al). So initially, they won't be given a shortname, but will instead be referred to by http://drupal.org/node/129893).
3. "Real" projects get release nodes, and they get human-readable short names, and they show up in search results/listing pages, where "experimental" projects don't.
There needs to be some process for moving from an "experimental" project to a "real" project, which is the point of this issue to discuss.
Possible suggestions that came about from the other issue:
- Mostly, our current process: New developers post to an issue queue (probably something like http://drupal.org/project/issues/projectapplications) and ask for their code to be reviewed, and provide a link to the repo. Someone from the reviewer team checks out the project's code and posts to the project's issue queue any feedback they have, which centers around code reviews, Drupal best practices, ensuring duplication isn't occurring, etc. Maintainer resolves problems. Repeat. Once reviewer is happy, they're given the ability to create project release nodes, and can assign a "human-readable" name on their project. They can now create as many unofficial or official projects as they see fit.
- Peter's proposal (I think; feel free to correct me if I interpret this wrong): All new projects initially end up at a URL like http://drupal.org/node/12345. You must always submit an issue to the projectapplications queue if you want your project to go from http://drupal.org/node/123456 to http://drupal.org/project/bananas, and the request must be verified by another human. They'd check for things like module duplication, general sanity check, but not as extensive as the mentorship process in the first proposal. For long-time contributors, a role could be granted to exempt them from the pre-approval process.
- Michelle's proposal (I think; feel free to correct me if I interpret this wrong): All new projects initially end up at a URL like http://drupal.org/node/12345. If you want a human-readable short name, you must apply to get your project included into "Golden" contrib, which goes through an extremely strict approval process including coding standards compliance checks, security checks, API checks, etc. Only "golden contrib" modules would be covered by the security team, and no others.
So... let's talk. :)
Comments
Comment #1
webchickSmall wording fix in title.
Comment #2
mark trappIf the goal is to solve the namespace problem, every project needs to be peer-reviewed, and getting exempt from that process should be exceedingly rare to virtually impossible.
Contributors who have been grandfathered-in or have gone through the approval process once are no less likely to nab a project name and create a half-baked project than a completely new contributor: one only needs to follow the new modules feed for a few days to see people who have been contributing for years still creating projects that don't have any released code, don't explain their value, and never go anywhere. It's just human nature: even the best of us make mistakes and act on impulse without thinking about the long-term implications of securing a project URL.
But there is the very real problem of it taking weeks to months to get approved for applications now. That process should definitely be streamlined, but removing it doesn't solve the namespace pollution problem either.
In my opinion, creating a new project should be a fairly significant event, even for long-time contributors: a little peer-review checkup before being granted a namespace, with all the implications thereof (the potentially long wait), should give even long-time contributors pause to stop and think before creating new projects for that half-baked idea they had:
I think more bureaucracy is bad, and a new approval queue doesn't mean the current months-long wait to get a published release is going to magically go away. But there shouldn't be a separate line for people who have contributed once (or even many times) because none of us are infallible and the reason for keeping the approval queue (the namespace issue) applies to new people and old people alike.
Let everyone be subject to namespace peer review: perhaps it'll get more people interested in reviewing other projects just to speed things along for their own. To this end, I think Peter's proposal is a reasonable compromise: subjecting anyone to a full security/VIP/"golden" review before contributing is soul-crushing and a big part of the problem with the CVS app process now.
Comment #3
webchickDo remember though that project nodes with shortnames are still just nodes. There's absolutely nothing stopping us from deleting them, unpublishing them, assigning different maintainers to them, etc. Earl lays out one possible "decay-based" scenario for dealing with crappy projects at #855508: Policy Proposal: Reduce bad maintainer reliance on -dev modules.
So while namespace pollution is definitely an issue, and a serious one, it's also worth considering the "pain in the ass" factor trade-off for contributors.
(This doesn't negate any of the points in your post; just making it clear to others that there's a "bottom-up" way to deal with the namespace problem as well as a "top down" one.)
Comment #4
mark trapp@webchick: Definitely: I don't think the namespace issue should be the only factor in determining the process. Personally, I think it's more efficient to ask for forgiveness (delete bad projects/assign new maintainers) than to beg for permission (have an approval process to create projects), even if one considers the namespace issue to be the most important.
But if there needs be initial barriers to graduating from an experimental project to a "real" project because of real technical concerns (like a need to check namespaces or duplicate functionality), those barriers need to apply to everybody, and they need to be as straightforward as possible: check for the bare minimum to ensure the concerns are addressed on every new "full project" request, regardless of who made it, and no more.
The other nice-to-haves (like a security audit, mentoring, active maintainers, and/or conformance to best practices) affect projects even after initial review, and problems with them can be addressed by all the tools you mentioned.
Comment #5
sdboyer commentedImportant for sprint 6, if we're working on sandboxes. Untag if you disagree.
Comment #6
dwwWe still need a process for deciding when this should happen and who has permission to do it, but the technical act of promoting a sandbox project to "real" project will be a user with sufficient permissions toggling a "Sandbox" checkbox when editing the project node. See #986718: Add support for sandbox projects.
Comment #7
dwwSlightly OT from this policy decision, but interested readers should also see:
#984734: Meta: Visually distinguish sandbox projects from regular projects when viewing them
#991466: Expose the sandbox bit as a facet in Solr index
#991486: Add a setting to hide sandbox projects from global issue queues
#991504: Ensure Git repository names match project shortnames across transition from "sandbox" to "real" projects
Comment #8
marvil07 commentedComment #9
eliza411 commentedTagging for Git Sprint 7.
Comment #10
mikey_p commentedComment #11
webchickOh boy. :) What did I get myself into? ;)
Comment #12
webchickSince we have not seen the kind of wider community feedback that we really need about this in this issue, I'm officially postponing this decision on the outcome of http://groups.drupal.org/node/114264.
Please spread the word.
Comment #13
webchickOk, seems there's been enough consensus built up at http://groups.drupal.org/node/114264 to un-postpone this now.
Consensus seems to be that we're okay sticking with the process we have now (for all of its flaws) to get us past initial launch, but then later there's a pretty big call to revisit this decision and tweak it.
Given that, I'm disinclined to put much effort code-wise behind this procedure, since there's a chance that whatever we do here will get blown away or otherwise changed in < 6 months.
So, the proposal:
1. We create a http://drupal.org/project/projectapplications project, analogous to http://drupal.org/project/cvsapplications. We add instructions that point to the guidelines, and tell people to include a link to their sandbox project (or we just pre-populate it with the link).
2. When users who attempt to create releases and are not in the "Project maintainers" role (or whatever) they get a
dsm('You cannot create releases of this project. Please <a href="/node/add/project-issue/gitapplications">apply for access</a>which will be about 4 lines of code in some drupalorg_something module.3. We create a sign-up list at http://groups.drupal.org/drupal-org-git-migration-team for people who want to participate in the reviewing of applications.
Done. That's the minimum viable spec to get us to launch, and we can always expand on if needed (for example, if we end up ditching approvals altogether, we rm the project, and tell reviewers to go join http://groups.drupal.org/peer-review instead. If we decide we need more stringent policies, we can always add more gateway code in front of the basic queue.)
Objections?
Comment #14
Josh The Geek commented@webchick: I like this. This should be good for a while if we get enough reviewers.
Comment #15
webchickActually, Michelle doesn't review apps anymore. It's mostly Kiam La Luno, zzolo, Dave Reid, and sun these days, most of whom are all frightfully busy already with other stuff.
So yes, we definitely need a crop of people to help. I intend to spam http://groups.drupal.org/node/114264 with a place to sign-up when the time comes. :D
Also, one amendment to the above proposal: Let's call it "/project/projectapplications" because a) it's really about granting full project access not Git access, and b) you never know, we might migrate to Visual Source Safe someday. :D
Comment #16
Josh The Geek commented@webchick: It's been a while since I looked at that.
Comment #17
eliza411 commentedSee #1011700: Document the actual process for obtaining a 'privileged' Git account
Comment #18
eliza411 commentedTagging for Git Sprint 8
Comment #19
webchickOk, no objections raised, and the recommendation follows the general consensus of the commnunity in that g.d.o thread.
Therefore, I feel comfortable marking this fixed. Thanks all for the participation!
Comment #20
eliza411 commentedRemoving the sprint 8 tag since this was closed before we started :) Yay!