First, some context:
This mail is a followup to a formerly private thread among the
Subversion full committers. Below, I quote a bit of context from that
thread, but I think the original poster won't mind, as there's nothing
really private about it.
C. Michael Pilato wrote:
> Karl, I posted this to s-f-c because we always post discussions
> about commit access to s-f-c. Maybe this is different because we
> aren't evaluating someone's skillset, though -- I dunno.
Exactly what I was getting at, yes. Let me make the point explicit:
The reason most commit access discussions happen on s-f-c is not
because they are about commit access per se. Rather, it's because
they often (but not always) involve speaking frankly with each other
about someone's skills, and that obviously can't be public.
But note the "not always" above! When the discussion doesn't involve
any sensitive stuff, then it can and should be on dev@.
The "Elego tree conflicts work" conversation was really about "What
should our branch policy be?" not "How skilled are Elego developers?"
Not only could that discussion have been on dev@, it would have been
better on dev@, because we *want* our branch policy discussions to be
as transparent as anything else in this project.
True, when we give new developers experimental branches, they might
not know all our commit conventions. But we should view this as an
opportunity! It's a chance to grow a new committer in a safe space,
while getting some useful work done in Subversion. We'll just point
them to http://subversion.tigris.org/hacking.html, and as we review
the branch commits, we'll say when something not meet the guidelines.
I don't really care if someone commits some junk the first few times,
or messes up some log messages, or whatever. I don't even care if the
majority of experimental branches end up going nowhere. Our revision
history is not some pristine jewel needing protection.
IMHO we should be *extremely* liberal in handing out commit access for
experimental branches; I don't think we need private discussions about
such commit access on s-f-c. Certainly, any discussions around this
policy question should not themselves be private -- which is why I'm
posting this mail to dev@, not s-f-c.
The only sense in which an experimental branch is a resource drain is
in its demands on our attention. Therefore, I think that any time a
full committer offers someone an experimental branch, it is by
definition appropriate and should be granted, because at least one
committer has expressed a willingness to pay attention to that branch.
This is specifically what I mean by a "liberal" policy.
We're pretty good about making the project inviting for new
developers, but we could be better, and this is one way to do so.
Any objections to making such a policy official?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 20 19:50:00 2007