Quoting Jakob Petsovits <jpetso@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/