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 <[email protected]> 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" <[email protected]> > 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 > > >
