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). > I agree that shepherding makes a huge difference, but one other part of this that Mesos hasn't yet had to deal with is splitting the knowledge base. Ie, it's assumed right now that every committer is familiar with every aspect of the code-base. It may be worth considering splitting that up so that committers are responsible for subsystems. This allows the wider developer community to know which committer to go to for best response, and allows committers to specialise more. > > 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! > Is it enough to mark the JIRA ticket as 'in progress'? We should be able to track these transitions and make sure a shepherd is attached as soon as possible. > > 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. > Is there a danger here that smaller changes (specifically cleanups) will be neglected as they don't have a shepherd attached? > > *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. > The best way for new developers to get involved is to pick up low priority tickets. I'd hate to see the project stagnate because those newer contributors' patches don't get attention. I think we need to be very conscious about encouraging new contributors by actively prioritising their patches for review above others. This will get them up to speed quickly and will sow the seeds for more committers and potential shepherds down the road. > > 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. > How about an 'active' ticket is one that is marked 'in progress' and a 'desired' ticket is everything else. If we have JIRA tickets for things we don't think are of value to the project, we should close them out. There's no point in holding on to tickets that we don't believe should be worked on at all. > > 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. > Thanks for putting all this down. I completely support the push for a better review process, however I have seen efforts like this fail in the past due to adding too much process to the, well, process. There needs to be a clear path to becoming a committer and eventual shepherd (number of successful patches is often a good guideline) and as little up-front learning curve as possible for new contributors. Finding a committer/shepherd for a change should be a simple task and knowing when a shepherd is required should also be something a new contributor can readily understand. One thing that is critical is documenting the contribution/committer/shepherd process and roles as soon as they're clear and pointing new contributors to that document. > > Ben. >
