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