+1 overall for everything that has been said already. This includes Andrew's comment. My experience on other projects has been that nearly every patch goes through at least one revision before getting committed.
I really like Sean's statements about a well-defined path towards committership with minimal drama. I think the success of Yetus will be closely correlated to how many Apache projects we can get signed up to use it. Contributors on individual Apache projects will have a vested interest in their own build processes, so I expect they'll naturally evolve towards wanting committership on Yetus. Many of these people will be established Apache contributors with a solid track record, so it makes sense to remove arbitrary obstacles like "must have X number of patches". I also think having representation from diverse projects on Yetus will improve the quality of Yetus over time. For PMC membership, I typically look for an established committer who has shown long-term commitment to the project, and participation beyond the code level into project management aspects. This includes release candidate testing, maintenance of accurate project metadata in JIRA, documentation, and user help. Looking purely at technical requirements, our codebase is focused on the Release Engineering and QA roles, and the implementation is mostly bash with some bits in Python too. We should be actively recruiting engineers in these roles. Perhaps they'll find it exciting too, because I believe it hasn't received such dedicated attention in Apache before. I'm excited, because we really have an opportunity to build a unique and talented community that improves the software engineering process across all of Apache (and beyond). --Chris Nauroth On 9/19/15, 4:46 PM, "Andrew Purtell" <[email protected]> wrote: >The only change I would make is to "you'll be practiced enough when >existing committers regularly don't have additional feedback on the >contribution". In my experience, most people don't think they've done a >review until they've given some feedback no matter what. (I've been >guilty of this too.) > > >> On Sep 19, 2015, at 4:14 PM, Jarek Jarcec Cecho <[email protected]> >>wrote: >> >> Seems reasonable to me. I¹m sure that the guidelines will evolve over >>time as the community evolves :) >> >> Jarcec >> >>> On Sep 19, 2015, at 7:56 AM, Sean Busbey <[email protected]> wrote: >>> >>> Hi folks! >>> >>> We need to decide on a couple of points wrt how our community will >>>make use >>> of the roles recognized by the ASF. >>> >>> * do we want committer and PMC status linked or distinct? >>> >>> * what do we expect from folks in those roles? >>> >>> Personally, I'd like to have a relatively low friction, well documented >>> path to committership while leaving PMC a distinct role. >>> >>> I'd like granting of committer status to mean that someone understands >>>our >>> norms well enough to handle contributions and guide a new contributor. >>> Ideally, I'd like a well documented path that a casual contributor can >>> complete in about a month. >>> >>> By well documented, I mean some clearly defined goalposts, e.g. >>>"review new >>> contributions and make sure they meet these guidelines; you'll be >>>practiced >>> enough when existing committers regularly don't have additional >>>feedback on >>> the contribution." Not a checklist of "do this X times" but something >>>more >>> definitive than "act like a committer." >>> >>> By casual contributor I mean either a hobbyist or someone whose job >>>doesn't >>> consist of primarily working on our project. Essentially, someone who >>>can >>> only spend an hour or two at a time on things, and at most a handful of >>> hours in any given week. >>> >>> What do others have in mind? >> >
