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-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
