ApacheCon NA 2017 Travel Assistance Applications Now Open!!
Hello Fellow Apache Enthusiasts!! The Travel Assistance Committee (TAC) are pleased to announce that travel assistance applications for ApacheCon NA 2017 are now open! We will be supporting ApacheCon NA, Miami, Florida, USA, May 16th - 18th, 2017. TAC exists to help those that would like to attend ApacheCon events, but are unable to do so for financial reasons. For more info on this years applications and qualifying criteria, please visit the TAC website at < http://www.apache.org/travel/ >. Applications are already open, so don't delay! ApacheCon NA is split into two separate themed events - Apache Big Data and ApacheCon. There will be a hackathon and BarCamp on either end of the main conference; therefore, the Apache Travel Assistance Committee will only be accepting applications from those people that are able to attend all week. Important: Applications close on Wednesday, March 8, 2017. Applicants have until the closing date above to submit their applications (which should contain as much supporting material as required to efficiently and accurately process their request), this will enable TAC to announce successful awards shortly afterwards. As usual, TAC expects to deal with a range of applications from a diverse range of backgrounds; therefore, we encourage (as always) anyone thinking about sending in an application to do so ASAP. We look forward to greeting many of you in Miami, Florida in March, 2017! Kind Regards, ~Melissa (On behalf of the Travel Assistance Committee)
GSoC 2017?
Time flies and I still haven't gotten around to conducting the survey on GSoC. The application period for 2017 has already started and we need to apply before Feb 9. I will conduct a quick gathering of opinions on mentors@ but would like to also have opinions from the wider community. Should we apply this year or do people have reservations (e.g. not worthwhile our volunteer energy for the benefits gained)? Cheers, Uli - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: contributions and their lifecycle
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 > wrote: > > Hi, > > On Mon, Jan 23, 2017 at 3:34 PM, A. Soroka 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-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > --- A. Soroka The University of Virginia Library - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: contributions and their lifecycle
Hi, On Mon, Jan 23, 2017 at 3:34 PM, A. Soroka 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-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: contributions and their lifecycle
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 exa
Help with task: Create Twitter list of all projects
I would like to help out with the task listed at https://helpwanted.apache.org/task.html?5c18cd0e
