+1 It would be nice if there was way to specify things like "build system changes" which are different than just adding/removing a single file. But probably that level of enforcement isn't worth the effort it would take to add.
On Tue, Feb 10, 2015 at 8:56 AM, James DeFelice <james.defel...@gmail.com> wrote: > +1 Tom/Adam > > --sent from my phone > On Feb 10, 2015 10:52 AM, "Niklas Nielsen" <nik...@mesosphere.io> wrote: > > > +1 > > Thanks for the write up Ben! > > > > On Tuesday, February 10, 2015, Dominic Hamon <dha...@twitter.com.invalid > > > > wrote: > > > > > Well, we should probably do that anyway :) > > > On Feb 10, 2015 2:25 AM, "Adam Bordelon" <a...@mesosphere.io > > > <javascript:;>> wrote: > > > > > > > +1 on MAINTAINERS over OWNERS, and the rest of the proposal thus far. > > > > Also +1 on "Merit is not about quantity of work, it means doing > things > > > the > > > > community values in a way that the community values." > > > > I will, however, echo Tom's concern that we may need to break up > > > master.cpp > > > > and slave.cpp if we want fine-grained maintainers of subcomponents of > > > > either. > > > > > > > > On Mon, Feb 9, 2015 at 1:47 PM, Yan Xu <y...@jxu.me <javascript:;>> > > > wrote: > > > > > > > > > Good point for "MAINTAINERS" > > > > > > > > > > -- > > > > > Jiang Yan Xu <y...@jxu.me <javascript:;>> @xujyan < > > > http://twitter.com/xujyan> > > > > > > > > > > On Mon, Feb 9, 2015 at 12:05 PM, Vinod Kone <vinodk...@gmail.com > > > <javascript:;>> wrote: > > > > > > > > > > > I like MAINTAINERS because it sounds less authoritative than > > OWNERS. > > > > > > > > > > > > FWIW, maintainers is also a well understood and well used term > > (e.g: > > > > > > https://www.kernel.org/doc/linux/MAINTAINERS, > > > > > > > > > > > > > > > > > > > > > > > > > > > https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins#HostingPlugins-AddingMaintainerInformation > > > > > > ) > > > > > > > > > > > > On Sun, Feb 8, 2015 at 10:40 AM, Dominic Hamon < > > > > dha...@twopensource.com <javascript:;>> > > > > > > wrote: > > > > > > > > > > > > > Yes, great. > > > > > > > > > > > > > > Why not use OWNERS as it is already in use internally at > Twitter, > > > at > > > > > > > Google, in Chromium, and tooling already supports that as an > > > implicit > > > > > > > standard? > > > > > > > On Feb 8, 2015 2:52 AM, "Benjamin Mahler" < > > > benjamin.mah...@gmail.com <javascript:;> > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > I have been chatting with a few committers and we'd like to > > > > consider > > > > > > > adding > > > > > > > > the concept of MAINTAINERS files to coincide with our > > "shepherds" > > > > > > > concept, > > > > > > > > introduced here: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://mail-archives.apache.org/mod_mbox/mesos-dev/201404.mbox/%3ccafeoqnwjibkayurkf0mfxve2usd5d91xpoe8u+pktiyvszv...@mail.gmail.com%3E > > > > > > > > > > > > > > > > Please take a moment to read that thread and its responses > here > > > in > > > > > > which > > > > > > > > maintainers are alluded to: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://mail-archives.apache.org/mod_mbox/mesos-dev/201404.mbox/%3cca+a2mtvc61-3idxtm-ghgcxekqxwz063ouhpbrgbpvsa9zs...@mail.gmail.com%3E > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://mail-archives.apache.org/mod_mbox/mesos-dev/201404.mbox/%3CCAAkWvAxegdg8+QQ4-sqZ-SKi9J=2WJDCVg_Sc9aaHttS4=6...@mail.gmail.com%3E > > > > > > > > > > > > > > > > *Motivation:* > > > > > > > > > > > > > > > > To re-iterate from that thread, many companies rely on Mesos > as > > > the > > > > > > > > foundational layer of their software infrastructure stack. > Much > > > of > > > > > the > > > > > > > > success of Mesos can be attributed to our focus on quality > > (code > > > > that > > > > > > is > > > > > > > > simple / easy to read and understand, high attention to > detail, > > > > > > thorough > > > > > > > > reviewing, good testing practices, managing technical debt, > > > > learning > > > > > > from > > > > > > > > each other, etc). > > > > > > > > > > > > > > > > As the community of contributors has grown, it's become > > > > increasingly > > > > > > > > difficult to ensure that people are able to find reviewers > with > > > > > > > experience > > > > > > > > in specific areas of the project. Good contributions often > fall > > > > > through > > > > > > > the > > > > > > > > cracks as a result of the lack of clarity around this. > > > > > > > > > > > > > > > > We would like to ensure that reviewers with context and a > > > long-term > > > > > > > outlook > > > > > > > > on the particular area of the code are involved in providing > > > > > feedback. > > > > > > It > > > > > > > > can be difficult for a contributor to consider the > implications > > > of > > > > > > their > > > > > > > > change, when they are looking to get a bug fixed or a feature > > > > > > implemented > > > > > > > > before the next release or the end of a sprint. > > > > > > > > > > > > > > > > We'd like to be able to add more and more committers as the > > > > community > > > > > > > > grows, and incentivize them to become responsible maintainers > > of > > > > > > > components > > > > > > > > as they become more involved in the project. > > > > > > > > > > > > > > > > *MAINTAINERS file system:* > > > > > > > > > > > > > > > > In order to ensure we can maintain the quality of the code as > > we > > > > > grow, > > > > > > > we'd > > > > > > > > like to propose adding an MAINTAINERS file system to the > source > > > > tree. > > > > > > > > > > > > > > > > From the chromium mailing list (s/OWNERS/MAINTAINERS/): > > > > > > > > > > > > > > > > *"A MAINTAINERS file lives in a directory and describes (in > > > simple > > > > > list > > > > > > > > form) whose review is required to commit changes to it. > > > > > MAINTAINERShip > > > > > > > > inherits, in that someone listed at a higher level in the > tree > > is > > > > > > capable > > > > > > > > of reviewing changes to lower level files.* > > > > > > > > > > > > > > > > *MAINTAINERS files provide a means for people to find > engineers > > > > > > > experienced > > > > > > > > in developing specific areas for code reviews. They are > > designed > > > to > > > > > > help > > > > > > > > ensure changes don't fall through the cracks and get > > appropriate > > > > > > > scrutiny. > > > > > > > > MAINTAINERShip is a responsibility and people designated as > > > > > MAINTAINERS > > > > > > > in > > > > > > > > a given area are responsible for the long term improvement of > > > that > > > > > > area, > > > > > > > > and reviewing code in that area."* > > > > > > > > > > > > > > > > This would be enforced via our review tooling > (post-reviews.py > > / > > > > > > > reviewbot, > > > > > > > > apply-review.py), and a git commit hook if possible. > > > > > > > > > > > > > > > > There would be a process for becoming a maintainer, the > details > > > of > > > > > > which > > > > > > > we > > > > > > > > will clarify in a follow up. I’m thinking it will require an > > > > existing > > > > > > > > maintainer proposing a candidate to become a maintainer based > > on > > > > > merit. > > > > > > > > Merit is not about quantity of work, it means doing things > the > > > > > > community > > > > > > > > values in a way that the community values. > > > > > > > > > > > > > > > > As part of this, we would be documenting qualities we look > for > > in > > > > > > > > committers and maintainers. > > > > > > > > > > > > > > > > *Feedback:* > > > > > > > > > > > > > > > > The goal with this is to be even more inclusive than we are > > today > > > > > while > > > > > > > > maintaining the quality of our code and design decisions. > > > > > > > > > > > > > > > > I'm a +1 for this approach, and I would like to hear from > > others. > > > > > What > > > > > > do > > > > > > > > you like about this? What are potential concerns? Much of > this > > > was > > > > > > > thought > > > > > > > > about in terms of how to further the following of the Apache > > Way > > > > for > > > > > > > Mesos, > > > > > > > > any concerns there? Take your time to mull this over, your > > > feedback > > > > > > would > > > > > > > > be much appreciated. > > > > > > > > > > > > > > > > If this does sound good to everyone at a high level, I will > > > follow > > > > up > > > > > > > with > > > > > > > > further discussion to formalize this, and I’ll work to > document > > > and > > > > > > > > implement it. > > > > > > > > > > > > > > > > Ben > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
