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
