Decide on an appropriate git analogue to current CVS account workflow

Mentioned this thread at #703116-68: Our CVS account application requirements are obtuse and discourage contributions

This should be relatively easy to implement, either via taxonomy or a CCK field or something. We'll have flag.module on d.o in the near future, too, so we could also use that. Basically, new project nodes don't show up in searches or the project download and browsing pages. Instead of applying for a CVS account, the project owner would create an issue pointing to their project requesting "promotion" to an official project. Reviewers in a higher role would be able to review the application issue, see the code, the revision history of the code as it was being developed, issues the owner created, documentation on the project node, etc. If the project is worth listing at all, they add the appropriate flag/term/field to indicate the project should be seen (basically, added to the d.o solr index). This isn't golden contrib. Just a base-line review: no obvious security problems, no direct duplication of existing projects for no reason, basic adherence to our code style, etc.

BTW, another mechanism that could work nicely here would be that new project nodes start life with releases disabled. We'd just split out the permission to control if releases are enabled or disabled on a project node into a separate set of permissions so that all project maintainers don't necessarily have power to decide that. Then, there's an application/approval process to request the ability to create releases, and a team of users with the right role have perms to go in and enable releases for the approved projects. Nothing shows up in the project browsing pages if there are no releases, so we'd get that behavior for free this way.

Maybe not all releases disabled, but tagged releases disabled. So you can still have a 6.x branch that people can download but no stable.

That has the added side benefit of re-enforcing the "responsible maintainership" concept. If you're just throwing code up there that you're not going to actually maintain but figure could be useful to someone, you leave it as a "lower level" project. By making a request to promote it to a "full" project, you are (explicitly or implicitly) making an affirmative statement that yes, you are willing to maintain this module responsibly.

There should then probably also be a (voluntary?) demotion process of some kind, and taking over a lower-level project should be easier than taking over a "maintained" project (assuming that you're going to for-reals maintain it).

Maybe not all releases disabled, but tagged releases disabled. So you can still have a 6.x branch that people can download but no stable.

i actually don't think this is enough of a 'penalty' for not being officially approved, because:

1. many people (against our recommendations) already treat -dev snapshots as production-level code
2. anybody searching for code via google could find a project that is "pre-approved" fairly easily, with an available tarball to download in a few clicks

not allowing any official releases creates a much steeper barrier for pre-approved projects in terms of becoming widely available for deployment -- sure people can still git it, but folks at that level usually know what they're getting into.

I agree with hunmonk.
Permitting them to access the Git repository is a step forward, which allows them to make practice with the d.o repository; it would allow them to have an issue queue they can use for the bug reports. The code would be available for who wants to test it, and the author would get some feedback; compared with the actual workflow for the CVS application (write the code, create an archive, upload it in attachment to a comment, change the code, create an archive, upload it in attachment to a comment, change the code, …) is a big step forward.

Once they get approved, they can create any releases for which d.o creates an archive.

Disabling project releases would not stop users from being co-maintainers of an existing project.

Again, this would be a big step forward from the actual situation, where users who apply for a CVS account to be co-maintainer (for which there isn't any code review) are able to create all the projects they want.
It happened already that users applied for a CVS account proposing a module that has not been accepted for the CVS application, then they applied to be co-maintainers of an existing project (which was the project they were trying to duplicate), but ended up creating the original project for which they would not have obtained a CVS account.

Lowering the barrier for upload access but raising the barrier for release node access (what we're discussing here) has a lot going for it, but there is another caveat: namespace issues. If we make it really really easy for any ol' joe to throw a module up on the site, we're going to drastically increase the number of modules sitting around taking up namespace.

Perhaps we should follow the model of places like GitHub and give each user their own module namespace, and then "certified" modules (those that are reviewed and get releases) move to a shared namespace. Essentially making the current CVS "sandbox" area actually useful for a change. Would that be possible?

I am also required to note that if "you uploaded an ssh key" means "you've got git!", then the "I formally certify that I will only upload GPL code that I'm legally allowed to upload" check must be a prerequisite for uploading an ssh key.

@Crell: we have grand designs for Git sandboxes, but that's Git phase 3, since it'd potentially delay Git at all for months if we blocked on that. See http://drupal.org/community-initiatives/git for the full plan.

Meanwhile, I'm not sure there's much we can do about this project namespace problem. Either we're trying to lower the barriers or we're not. ;) If we're going to make it easier for people, then it'll be easier. If that makes namespace squatting or wasting more common, so be it. We can of course always come in with a big stick and either reclaim squatted namespace for someone who's actually going to do something responsible and productive with it, purge the squatted projects entirely, whatever. I think we should just let this rip for now. We have mechanisms to deal with problems as they arise, and we have plans for N months down the road to have a better solution. But, if we block progress on the perfect solution for now, we'll never get off CVS.

And thanks for the legal reminder that the GPL step needs to be tied as close to the Git account creation as possible. If all that's needed is to upload an ssh key (yay), then yes, we need the GPL checkbox to live next to the ssh key field. But that seems like it really needs to be handled over at #720670: Figure out wording of the "Yes, I promise to upload GPLv2+ code" checkbox (and hurray, you're already involved in that issue, so I think we're set).

Cheers,
-Derek

I'm fine with "we'll deal with that later". As long as that potential pitfall is on people's radar.

adding redesign tags

I assume one important point that needs to be touched on would be: Is this for any release, or just a non-dev release?