community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <ro...@shaposhnik.org>
Subject Re: contributions and their lifecycle
Date Mon, 23 Jan 2017 02:45:20 GMT
On Sun, Jan 22, 2017 at 2:27 PM, A. Soroka <ajs6f@virginia.edu> wrote:
> Just a quick question for anyone who wants to answer or has any advice:
>
> Other than the obvious Apache-wide conditions (proper measures for intellectual property,
etc.), does anyone have examples of policies for accepting and maintaining (code) contributions
to a project? I am thinking here about the kinds of conditions that must obtain for a piece
of code to remain viable.
>
> For example, in a (non-Apache) project with which I am involved, any contribution must
have at least two committers ready to take responsibility for it. If at any time after contribution
of a module, that stops being the case, that module starts moving on a road to being deprecated
out of the mainline codebase into ancillary curation (a process that can stop and reverse
at any time if more committers are willing to join in).
>
> So I'm looking for examples of similar conditions to meet for contributions to be accepted,
simple rules to measure commitment and community, and on the other end of the lifecycle, examples
of conditions that decide when a piece of a project has lost vitality and should be excised
from the responsibilities that all committers share.
>
> Thanks for any examples, pointers, experiences, thoughts to ponder!

As Shane pointed out you need to separate foundation-level governance policies
(which are really more about how the community governs itself and its IP) from
the project governance polices (which are left to the PMC).

Shane gave a great answer on the foundation side. On the project's side the two
acronyms that get talked about all the time are RTC and CTR. RTC stands for
Review Then Commit and CTR stands for Commit Then Review. As you can
guess former requires a certain # of positive votes from reviewers
while the later
leaves feedback gathering exersize unspecified and relies on committers seeking
such feedback when they see it is required and simply committing when they
are confident in their changes. Both of these greatly benefit from a robust CI
pipeline, but CTR is pretty much predicated on good CI.

These are the two most popular choices. Then there's also sorts of CI mechanics
that can be thrown in (Gerrit, etc.).

Finally, even though I haven't seen it at ASF myself, I've worked in a
project where
you couldn't commit your own code (well you could technically -- but that would
be a faux pas). Somebody else had to do it for you -- thus taking the
responsibility
for it. This was a more interesting example of creating a social
dynamic around the
project that made a shared responsibility for the code base much more
visceral than
I've seen otherwise. It also, effectively, made a notion of a
"committer" pretty moot.
As a side note, I'll add that this practice also lends itself pretty
nicely to a sort of a
remote pair programming model -- where the other guy committing the
code will also
have to think about testing.

As you can see, you can get a to a pretty sophisticated (convoluted?)
set of policies pretty
quickly. So IMHO it is always a good idea to start with something
super simple (like
CTR or RTC) and then evolve from there.

Thanks,
Roman.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org


Mime
View raw message