On Friday, 30. May 2008, Daniel F. Kudwien wrote:
We are parsing the "#12345" bit, but why don't we also parse the "by sun" bit to assign 'contributor credits' to users for the corresponding project?
Imho that's a quick-and-dirty workaround, whereas the proper solution would involve letting the contributor commit the patch by herself. That might either be reached by switching to a distributed VCS (where "committer" and "uploader" are decoupled from each other - probably the right solution for core) or by the even more open-sourcey way of granting access to all of contrib by default.
OTOH, if there was a prepared candidate - would you really grant CVS access? Would you grant access to me?
The question is "would I trust you not to mess up my modules"? Personally, I'm confident that you are careful with other people's modules (given your previous track record), I would grant you commit access to all my projects in a second because I know that you won't abuse that power. But that is the core of the issue at hand here - we've got lots of CVS accounts, but we don't trust them a single bit. Instead of relying on trust and goodwill, we rely on technical measures to lock out potential helpers before they even get the chance to do something wrong. Now there are plenty of arguments against this, but I think trust is a crucial element in open source projects, and stimulating involvement is important *especially* for modules that have wide exposure and a large user base. I think granting CVS access should be the default, as well as expecting the account holders to follow a commit policy that we set up. Instead of denying commit access to single directories, we'd trash the CVS account of people who don't respect the commit policy (which would involve not pissing off the respective module maintainer). That also has the consequence that people who deliver more and better code for a given module can't be blocked by inactive maintainers anymore, instead the maintainers have to actively work on their status as project leader. Which in turn stimulates progress both of "external" contributions and of maintainer involvement. As of now, modules are considered to be the personal property of a given person or company, even if their importance has a much higher impact than those. I think we should get away from this notion, and consider modules on drupal.org the joint property of the community, not only in license but also in governance. If collaboration doesn't work out (which I believe will be the exception much rather than the rule), one can still fork anything and come up with something else on his own. That's how open source normally works, and I fail to see why drupal.org needs to be the big exception. If we grant CVS access to people, we should trust them to fix more stuff than they break. If they break more stuff than they fix, retract commit access on the whole. Think about how we can make a transition to trusting people. Wishes, Jakob P.S.: A showcase. KDE has a repository where each committer has access to the whole SVN repository, and an accompanying commit policy [1] (next to other policies). Potential committers need to formally apply for an account, but when they get one then they're trusted to do stuff right. And you know what? It works. Bugs are fixed by people who would otherwise just be watching the progress, and code gets ported by people who modify the base framework. Just recently I fixed a few trivial bugs in Kate, which made me motivated enough to join the Kate development list and post a few more, less trivial patches there for review - if they're approved, I can commit them on my own. On the other hand, just recently I noticed a missing break; statement somewhere in Views. Checked out with CVS. But it didn't directly concern me or pose any problems to what I was doing, and opening up a new issue would have taken more time and effort than I was willing to put in. Like, "someone will probably fix it anyways". With commit access, I would have committed the fix right away, and in the unlikely case that it's actually wrong (and a "// fall through" comment would be required instead) then Earl would have noticed and fixed it the right way. It's probably still unfixed, I guess. Now you can critizise me for being lazy, but I think this is symptomatic and happens all the time. If we want to scale contrib, we need to lower the contribution barrier for people who are able to fix stuff, while raising the barrier for people who break stuff. Let incompetent CVS users release their modules on their own server (they're probably no good for drupal.org either) and educate them to get into version control and patches before they're granted a CVS account. In turn, give trust to the people who actually have proven to be worthy of a CVS account. [1] KDE commit policy: http://techbase.kde.org/Policies/SVN_Commit_Policy *goes off to get his flame-resistant jacket*