contributions and their lifecycle

["A. Soroka" <aj...@virginia.edu>]

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!

---
A. Soroka
Apache Jena




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

Re: contributions and their lifecycle

["A. Soroka" <aj...@virginia.edu>]

Bertrand--

Thanks, this is good stuff. I take your point about final responsibility always resting with the PMC. I think what I am looking for is exactly examples of the kind you point to in Commons. I'm going to delve into the Maturity Model a bit.

---
A. Soroka
Apache Jena

> On Jan 23, 2017, at 12:06 PM, Bertrand Delacretaz <bd...@apache.org> wrote:
> 
> Hi,
> 
> On Mon, Jan 23, 2017 at 3:34 PM, A. Soroka <aj...@virginia.edu> wrote:
>> ...the project is humming along nicely, growing and changing organically, when a Nice Person...presents
>> a contribution to the project. This contribution ...is _large_. It expands the remit of the project much more
>> than the ordinary commit..
> 
>> ....Is it okay for only one person to take responsibility for such a piece of the project going forward?...
> 
> What's important from the Foundation's point of view is that the
> project's PMC takes responsibility for releases of that module. If
> something goes wrong, like an urgent security hole that needs to be
> patched, it's not ok for a PMC to reject the responsibility for that
> on a specific sets of committers - it's the PMC's business.
> 
> So if a given module is clearly maintained by a single person that's a
> risk for the PMC and it should label that module accordingly.
> 
> Apache Commons for example classifies their projects in Proper,
> Sandbox and Dormant - that's a fair way to give honest info about
> their status, IMO, see http://commons.apache.org/
> 
> Items QU10 and QU60 of our Maturity Model [1] are relevant to this - a
> PMC should be honest about its code, and make sure users have a good
> visibility into each module's "community strength", quality, etc.
> 
> If a PMC feels uncomfortable accepting a contribution that's too big
> or not likely to be maintainable, it's fair to ask for that module to
> be developed elsewhere or incubated separately.
> 
> -Bertrand
> 
> [1] http://community.apache.org/apache-way/apache-project-maturity-model.html
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
> 



---
A. Soroka
The University of Virginia Library




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

Re: contributions and their lifecycle

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Mon, Jan 23, 2017 at 3:34 PM, A. Soroka <aj...@virginia.edu> wrote:
> ...the project is humming along nicely, growing and changing organically, when a Nice Person...presents
> a contribution to the project. This contribution ...is _large_. It expands the remit of the project much more
> than the ordinary commit..

> ....Is it okay for only one person to take responsibility for such a piece of the project going forward?...

What's important from the Foundation's point of view is that the
project's PMC takes responsibility for releases of that module. If
something goes wrong, like an urgent security hole that needs to be
patched, it's not ok for a PMC to reject the responsibility for that
on a specific sets of committers - it's the PMC's business.

So if a given module is clearly maintained by a single person that's a
risk for the PMC and it should label that module accordingly.

Apache Commons for example classifies their projects in Proper,
Sandbox and Dormant - that's a fair way to give honest info about
their status, IMO, see http://commons.apache.org/

Items QU10 and QU60 of our Maturity Model [1] are relevant to this - a
PMC should be honest about its code, and make sure users have a good
visibility into each module's "community strength", quality, etc.

If a PMC feels uncomfortable accepting a contribution that's too big
or not likely to be maintainable, it's fair to ask for that module to
be developed elsewhere or incubated separately.

-Bertrand

[1] http://community.apache.org/apache-way/apache-project-maturity-model.html

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

Re: contributions and their lifecycle

["A. Soroka" <aj...@virginia.edu>]

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 <ro...@shaposhnik.org> wrote:
> 
> On Sun, Jan 22, 2017 at 2:27 PM, A. Soroka <aj...@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
> 


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

Re: contributions and their lifecycle

[Roman Shaposhnik <ro...@shaposhnik.org>]

On Sun, Jan 22, 2017 at 2:27 PM, A. Soroka <aj...@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

Re: contributions and their lifecycle

[Shane Curcuru <as...@shanecurcuru.org>]

A. Soroka wrote on 1/22/17 5:27 PM:
> 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.

There aren't any Apache-wide policies or guidelines about that (i.e.
lifecycle of a module within a project); technical governance is left up
to each PMC to decide their own working style.

At the whole project level, the board reviews quarterly reports to see
that a PMC has at least three PMC members who are present in the project
- if not actively developing, at least regularly reviewing the mailing
lists.  Three PMC members are required to vote on a release needed for a
security fix, for example.

  https://www.apache.org/foundation/board/reporting

When a project seems inactive or dips to three of fewer PMC members
present, the board will typically ask the PMC to either figure out a
plan to add more active PMC members to provide oversight, or to ask the
community to consider moving to the Attic.

Mature projects with little code/release activity are fine, if that's
where their technology cycle is, as long as at least three PMC members
are present enough to provide oversight.

- Shane

> 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!
> 
> ---
> A. Soroka
> Apache Jena


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