Thanks for outlining the process Ben. I have a few comments/suggestions. We need to more formally define what "active" and "desired" mean. As Dominic alluded to every JIRA ticket that is *open* is desired. So it would be nice to have a notion of time frame or a release that is tied with the *desired* label. Probably *desired* is the wrong label to use here. This helps me (and other shepherds) prioritize the reviews. Also, regarding *active*, are these tickets that are assigned to someone and they have started work (thinking, design, code) on it? If yes, I agree with Dominic, why not just use "In Progress"?
On a related note, how do these labels tie with "Fix Version"? Can we just use "Fix version" for things that are *desired* in our next release (assuming we tie *desired* to releases without explicitly tying them to a time frame)? Another thing that is not clear is is the relationship between shepherds and reviewers. Can a ticket/review have multiple shepherds? Multiple reviewers? I'm assuming single shepherd and multiple reviewers to avoid giving conflicting directions to contributors? Does a review need to have a "ShipIt" before it can get committed? @Dominic: Regarding specialized committers, I'm assuming you are alluding to something like having *OWNERS* files for sub components? While I think it is a great idea, I don't think the project is there yet in terms of the knowledge split. I would suggest following Ben's suggestion on people just pinging the dev list (or IRC) to pick shepherds. If it doesn't scale or creates too much noise we could rethink the approach. As an aside, whatever we do we should prioritize fixing tests! We already add a component "test" for flaky tests but we hardly prioritize them. I would love for contributors and committers to pitch in fixing the tests as top priority because they are annoying and give a bad user experience. On Mon, Apr 21, 2014 at 12:27 PM, Jie Yu <[email protected]> wrote: > +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. > > >
