We all agree that we want some sort of github-like fork/clone to participate in a project with git.
This means, that somehow, we want to be able that, for a given project and a given issue all users which have submitted a ssh key can contribute.
What we haven't decided on is how to do that, there are several ways.
One repository per project, per user
Each user gets a clone of the main repo hosted on d.o where she can do whatever she wants to.
When posting to an issue in the project, she can decide whether she wants to just comment, attach a patch (as usual), or get a patch from her personal repo. For the latter, she would select the branch which contains the commits which should turn into a patch. The posted comment then allows downloading the patch, viewing the selected branch and it needs to contain the commit id.
To merge the changes of the patch, the project maintainers could click on a link called 'merge' which would in turn merge all the commits from the personal branch into the corresponding branch of the project. We would need to take care here that at the time of the post, branch refers to one commit, but at the time of the merge, branch could refer to more commits we don't really want because they're potentially unreviewed. We also need a display to see if we have a clean merge between the project's branch and the personal branch.
A simpler alternative is simply to have the user submit a range from one tag to another as part of the post in the issue queue. The range of tags should then promptly be turned into a patch file, which would be the definitive representation of the patch and which would be tested by the buildbot, commented on or downloaded by other coders (particularly the ones who are not Git users) and eventually applied and committed by the project maintainer upon final acceptance.
Lines of responsibility are 100% clear. You own your repo. Other people own their repos. Official repos are owned by maintainers. You can do whatever you want in your repo without fear of stepping on someone else's toes.
Likewise, permissions are clear. You have permission to push to your repo; nobody else does. Collaboration is via pulls or posted patches, not pushes or commits.
Ease of implementation: Because a public Git repo can live behind any URL on the net, and because there is no need to give multiple people write access to shared repos, this system can be set up with a minimum of work. We needn't even give users official Drupal-hosted repos -- users can submit URLs and branch/tag names for any public repo they have, hosted wherever they like. The first version of this can go live tomorrow -- just invite users to submit URLs and branch names together with the typical patches that they post to the issue queue. Then, at a later stage, the testbot can be augmented with the ability to fetch commits from a remote repo and generate patches from them.
When there are a lot of users collaborating, they don't see the work done by others, and they don't have one central place to work in, so work could be easily done twice. (Though this is going to be a problem anyway, unless we assume a 100% Git adoption rate among Drupal developers.)
It may be unclear from whom the project maintainers should merge. (This can presumably be resolved, as usual, in the issue queue thread. --mikebooth)
(A solution would be to allow other users to commit to an issue-specific branch in a personal repo, but that doesn't feel nice to me -- CorniI).
(I agree: giving users personal branches and then letting other users commit to those branches is overcomplicated, and will create security and ownership issues. --mikebooth)
One repository per project, per issue
Each issue gets a repository in which all collaborating users can commit. They either can work in personal branches (personal-[user]) or in a main branch. When they comment, they can, as above, choose a branch for which a patch should be attached.
Everyone can work together and it's clear where to look for patches. (NOTE: This is also true for branch-per-issue, described below.)
When there are two users fighting about an approach, they easily can use a personal branch in that repo to develop 'their' version of a patch instead of collaborating with the others, if they choose so. (NOTE: This is also true for "one repo per project per user", described above.)
Disk space? As far as I (CorniI) remember disk space is not an issue, as a HD can be bought if necessary (This refers to an IRC discussion held maybe a half year ago). (mikebooth: Redundancy of disk space can perhaps be finessed, though not without some careful work. See how Github saves space.)
Unclear lines of responsibility. Should you make a commit on the end of the branch where someone else is working? Or would that be rude? Maybe it is always better to work on your own branch. But that creates additional complexity.
Complexity. If you thought reading a very long issue in the queue was a lot of work, just wait until that long linear issue becomes a tree.
(Of course, in practice, nobody will ever look through every branch of the issue repository. Instead, attention will be focused via the issue queue. Only a handful of patches will actually be debated in the queue, and eventually only one patch will be committed. But, given that this is true, do we really need such a complex infrastructure to support many parallel branches?)
Security vs Access: Who gets permission to commit to the repo? If we give it to everyone, spammers and griefers can trash our work. If we don't give it to everyone, we create a caste system: Those who have Git knowledge and commit privileges will have more influence than those who haven't applied for permission or who choose to use a different VCS. No matter what option we choose, adjudicating the resulting system will take up a lot of someone's time.
Consistency. Each per-issue repo will presumably be a clone of the parent project's official repo. That clone will be made at some point in time. After that, every time official commits are made to the official repos, all the child repositories need to be updated with
git pull. So there will need to be a lot of cron jobs and complexity... or perhaps repos will be manually updated from time to time by users by hand, as needed.
One repository per project, one branch per issue
Each issue gets a branch in the main project repo, to which all collaborating users have access.
One centralized place for collaborating for a given issue.
Takes up less space than the above solutions.
If there are two approaches to solve a problem, or commit fights, this isn't a nice solution, because we limit 2 users in one branch.
This will get the online-repo-viewer a long list of branches, imagine a branch for every drupal-related issue ;)
Both branch/repo-per-issue have the problem that a malicious user can chime in and bitch around and hindering collaboration. We need either a process which determines if a given user is allowed to commit to such issue-specific branches/repos or a fast way to ban such users.
(Many of the other cons of the repo-per-issue approach also apply to this one.)
Please feel free to add your own arguments, make this prettier, fix my mistakes, etc!