[development] Trust (was: Hit and run contrib)

[Jakob Petsovits]

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*