+1 I also second what Tim said.
It would be good to record these things into a wiki somewhere, for ease of editing & amendment. On Wed, Apr 23, 2014 at 6:22 PM, Tim St Clair <tstcl...@redhat.com> wrote: > 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 >