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

[Earnie Boyd]

Quoting Jakob Petsovits <jpetso at gmx.at>:

> 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.
>

And IMO every module, as well as Drupal core, should have it's own 
ChangeLog file.  This is standard in every other project I've ever 
worked with.

>> 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'm thinking of wiki from these statements.  Everyone is trusted with 
being able to update the document or create new documents.  Everyone is 
trusted to fix the mistakes of others with no fuss.

> 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).
>

I agree and disagree; see below.

> 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.
>

It helps with the collaborative effort, yes.

> 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.
>

This "personal property" is one of the reason we have such a large 
number of duplicated modules.  However with the "take over" process 
already identified, I shouldn't need to duplicate for this reason any 
longer.

> 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,

If I have a module that I've put a lot of work into then "personal 
property" is how I would feel about it.  I wouldn't want Joe Schmuck 
coming along and undoing some long hard work and thus creating work for 
me to retract his changes.  Commit access without collaboration isn't a 
good thing.  Commit access with collaboration is a good thing but I 
would want to have the control over when a person can commit.  It would 
even be nicer to be able to control that commit access to a particular 
branch tag.

However, for the abandoned modules this would be a good start to 
develop the infrastructure.  The modules could become open and everyone 
has the right to create a release.  There are some modules that are 
just simple and need a touch here and there when a new core release are 
made; this idea fits perfect from them.  Perhaps on the CVS access page 
for the project an "Open for all" could be established for a project 
and the maintainer would then be "Community".  So if a maintainer is 
turning over a project he can just grant access to everyone and move on.

>  Jakob
>
>
> P.S.: A showcase.
>

It can work but there has to be a lot of rules in place and that 
infrastructure isn't ready here.

Earnie -- http://for-my-kids.com/
-- http://give-me-an-offer.com/