community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A. Soroka" <>
Subject Re: contributions and their lifecycle
Date Mon, 23 Jan 2017 14:34:58 GMT
Thanks, Shane and Roman--

These answers aren't exactly to my question, and I see now that I did a very poor job of asking
it. My apologies, and let me see if I can improve that.

Jena does (I think!) very nice work keeping a strong committer population and we have a perfectly
fine practice with regard to quotidian changes. (We use an ad hoc mix of review styles, and
people definitely commit their own code. I also work on projects for which one doesn't commit
one's own code. Both ways have merits.)

This question is specifically about a situation in which the ordinary processes are not useful.

Let me give a scenario: the project is humming along nicely, growing and changing organically,
when a Nice Person (could be a committer or not, doesn't matter) presents a contribution to
the project. This contribution (and this is what I was hinting at with my use of the word
"module": I should have been _much_ more explicit, sorry) is _large_. It expands the remit
of the project much more than the ordinary commit, perhaps with a lot of new functionality,
perhaps with functionality of a new kind, perhaps to a new audience, perhaps all of these
things. It is much larger as a delta to the code than an ordinary commit (whatever that means
for this particular project). It is so large that it's not possible logistically for it to
go through the normal process (not enough committer time, too much to review). It is clearly
a good addition, and the committers agree that they would like to offer it, but the question
then arises (and this is one concrete part of my larger question) under what terms? Is it
okay for only one person to take responsibility for such a piece of the project going forward?
Is okay if two people share that responsibility? N? And what happens over time (this question
applies to pieces of the project that have grown organically as well as those that have been
contributed wholemeal)? At what point are so few people able to take responsibility for a
piece of the project that it should be deprecated, decommissioned, split off into an archive,
etc.? I understand that Apache doesn't require any such lifecycle: my experience is that such
lifecycle management can be necessary depending on the technologies involved and their use.
(Some software may be fine left alone for a long time, other software requires a lot of "care
and feeding" to continue to be useful.)

To be very clear, I understand perfectly well that there are no general rules for these questions,
either from Apache or elsewhere. I am _not_ asking for general rules or policy guidance from
beyond the scope of a single project. I _am_ hoping that folks who have a system that works
well for them, be it enshrined in formal policy or simply "the way we do things at Project
P", might be willing to share some experience. I'm asking for responses of the type: "Our
project is really old, and while we started out doing X, we eventually ended up doing Y, which
works better for us, because..." or "We take everything on an ad hoc basis; we tried having
a rule of thumb about this, but it didn't work because..." or "We have a very clear rule about
this; three committers must vote to take any contribution directly from a non-committer, whether
small or large, and we do that because..."

I hope this clarifies things a bit. In the end, I'm really less asking a question than asking
to compare notes on what has worked over time and what hasn't. Jena is a fairly old project,
but for only part of its life an Apache project, so we are always introspecting about how
to be one.

A. Soroka
Apache Jena
> On Jan 22, 2017, at 9:45 PM, Roman Shaposhnik <> wrote:
> On Sun, Jan 22, 2017 at 2:27 PM, A. Soroka <> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message