Re: scaling proposals

[Brenden Matthews <br...@airbedandbreakfast.com>]

+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 <ts...@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" <vi...@gmail.com>
> > To: "dev" <de...@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 <yu...@gmail.com> wrote:
> >
> > > +1 for all three proposals
> > >
> > >
> > > On Mon, Apr 21, 2014 at 11:51 AM, Benjamin Hindman <
> > > benjamin.hindman@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
>