Typically the process(es) & policies that work best, can be drawn on a simple 'old school' flow diagram.
Why? Because it becomes obvious when a process is obtuse, or ambiguous. Cheers, Tim ----- Original Message ----- > From: "Vinod Kone" <vinodk...@gmail.com> > To: "dev" <dev@mesos.apache.org> > Sent: Monday, April 21, 2014 3:00:41 PM > Subject: Re: scaling proposals > > 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 <yujie....@gmail.com> wrote: > > > +1 for all three proposals > > > > > > On Mon, Apr 21, 2014 at 11:51 AM, Benjamin Hindman < > > benjamin.hind...@gmail.com> 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 dev@mesos.apache.org 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. > > > > > > -- Cheers, Tim Freedom, Features, Friends, First -> Fedora https://fedoraproject.org/wiki/SIGs/bigdata
