+1 for all three proposals
On Mon, Apr 21, 2014 at 11:51 AM, Benjamin Hindman < [email protected]> wrote: > The good news is, the project continues to grow! The bad news is, not all > of our procedures scale. I'd like to propose some changes to streamline > hotspots around the project. > > > *(1) Review Shepherds* > > Companies that rely on Mesos expect it to be the foundation of their > software infrastructure and it's imperative that we ship high-quality and > robust code. To help facilitate this we put our code through rigorous > reviews. Unfortunately, this can often act as a bottleneck, especially when > nobody wants (or has time) to review your code! > > I'd like us to be more accountable; I'd like to propose that all > significant code changes get shepherded by a PMC/committer as early in the > development phase as possible. We've played around with "review shepherds" > in the past and IMHO it's helped tremendously (and the earlier the > shepherding the better). > > Here's how I'm envisioning this would look: > > A contributor (or committer) would tell people they're interested in > working on a particular JIRA issue, feature, bug fix, TODO in the code, > etc. by either emailing [email protected] or posting a comment on JIRA. > Their note would specifically seek out a PMC/committer to act as a > shepherd. Note that the goal here is really to find a shepherd _before_ you > start architecting or coding! > > It's possible that nobody will volunteer as a shepherd either because (a) > nobody has time due to prioritizing other things in the project or (b) > they're a new PMC/committer and don't yet feel comfortable shepherding. > Seeking a shepherd early is exactly meant to deal with issues around (a) > which I'll discuss in more detail below. In the case of (b), I'd like to > propose people "pair" shepherd. That is, a newer PMC/committer actively > find an older (in project years) PMC/committer. > > To be clear, I don't think that all code changes should require a shepherd, > only "significant" ones. For now, I'd prefer we error on the side of > caution and seek out shepherds for most things, letting the shepherd decide > whether or not they believe the work requires them. In addition, I think we > should leave it up to the shepherd's best judgement to decide when design > documents or greater consensus around a certain change should be sought. > > *How can you help!? *In order for this to work we'll need to actively guide > people towards finding a shepherd. Moreover, we'll need to set good > examples ourselves. People often snoop on project mailing lists and mimic > the behavior of those they observe. > > > *(2) Active/Desired* > > One of the biggest reasons reviews go stagnant is because people just don't > have time to help review them. Often times this is an artifact of people > picking features to work on that are low in the priority list of the > project. To *help guide people* towards issues that are *desired* I'd like > to propose that we add a new JIRA labels called, drum roll please: desired. > In conjunction with the 'desired' label I'd like to propose we also add an > 'active' label. > > An active JIRA issue is something that a contributor/committer/organization > is actively working on (or has publicly allocated time to work on in the > next quarter). A desired JIRA issue is something that the > committers/organizations of the project would be working on if they had > more time! That is, things that the project community believes is of value > to the project and should get worked on. > > An advantage of labeling issues this way is that it makes creating a > "dashboard" for the project relatively easy. In fact, Chris Lambert has > already prepared one here: > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=33 (note: > that dashboard includes the 'newbie' label because these are also "desired" > issues just of smaller scope meant for new contributors). This dashboard > can help act as basis for a roadmap for the project as well. > > To help triage what issues should be made desired I'd like to suggest we > start (a) voting on tickets and recommending others vote on tickets and (b) > encourage people to make desired things known by emailing the dev@ and > user@mailing lists. In the short term I'd like to help facilitate the > triaging > via emails to the list where I can gather feedback and label tickets as > appropriate. In the long term I'd love to evolve this into > monthly/bi-weekly community meetings where people have a chance to curate > desired issues. > > > *(3) Becoming a PMC Member / Committer* > > Just like code, I'd like us to be accountable for growing the PMC/committer > base. Ultimately this will give us even more shepherds enabling the project > to handle even more concurrent changes. To do this effectively I'd like to > propose that we introduce shepherds for helping contributors become > committers (sorry for the overloaded user of the word shepherd!). Like code > changes, I think we need to be more proactive about assigning a shepherd to > someone that is interested in becoming a PMC/committer on the project. This > shepherd can help identify things that the contributor should demonstrate > in order to be a successful PMC/committer after potentially soliciting > feedback from the existing PMC. My hope is that this will make the actual > PMC/committer vote more of a formality than anything else. > > > In summary, I'd like to propose: > > Code/review shepherds. > The addition of 'active' and 'desired' JIRA labels. > PMC/committer shepherds. > > I'm clearly a +1 for these and I'm looking forward to hearing from others. > > Ben. >
