Proposing a subsystem-specific-maintainer model.
Subsystem Specific Maintainers ---- Problem statement As Mesos project grows in terms of subsystems, features and contributors, it becomes harder to scale development and maintenance without a model. To list a few problems: - Getting attention for a contribution (patch or any proposal) becomes hard. - As more subsystems are developed, it becomes hard to maintain standard and context without domain knowledge experts. - Some subsystems could have more velocity than others and having a uniform distribution of maintainers will have scaling problems. Abstract Open source projects have proven scalable model that works on the idea of having subsystem specific maintainers. Linux kernel is a good example of this model [1]. This proposal explores the possibility of such a model for Mesos project. Subsystems Possible subsystems in the Mesos project are: - Allocator - Master - Slave - Security - Http endpoints - Containers - Storage - Networking - Messaging - API/ABI and versioning These subsystems can be further subdivided into granular subsystems. Cross subsystem concerns There could be issues and projects that span across subsystems. Some of them could be: - Coding guidelines - System performance - System testing - Code analysis (coverity) Model 1. View the project as a system of subsystems 2. Have mailing list project page specific to the subsystem to provide guidelines and context 3. Have a core set of maintainers for the subsystems and have a rotation of non-core maintainers. This would address two requirements: - Core maintainers will have the domain expertise - Rotation/on-demand maintainers will allow scale 4. Have core maintainers of a subsystem also be rotated for other subsystems. - This will allow knowledge base distribution. 5. Define a set of criteria for becoming core maintainer of a subsystem. Maintainers will have to make a effort to keep their status[2]. 6. As the system grows, some subsystems would be in “support” only mode and some of them could be in “obsolete”/“deprecated” mode. 7. Not all mails and queries would be addressed to subsystems. These should be addressed by the “General” maintainers. This set of maintainers could be picked from the available pool of maintainers. Engaging Maintainers Each upcoming project should engage subsystem maintainers. This will enable planning for those projects. This also has other side effects - - Each project/epic should be guided by proper design documents that has section that lists the stakeholders. Subsystems are stakeholders. - Design docs should ideally define expected behavior from subsystems (SLA). References 1. https://www.kernel.org/doc/linux/MAINTAINERS <https://www.kernel.org/doc/linux/MAINTAINERS> 2. https://lwn.net/Articles/500443/ <https://lwn.net/Articles/500443/> ---- thanks Jojy > On Sep 18, 2015, at 11:24 AM, Vinod Kone <vinodk...@gmail.com> wrote: > > +1 > > On Fri, Sep 18, 2015 at 10:55 AM, Niklas Nielsen <nik...@mesosphere.io> > wrote: > >> Hi folks, >> >> Per our last community meeting, I created a list on our Confluence Wiki to >> keep track of and increase visibility into the running working groups. >> We have previously created these groups implicitly, and as the community >> grow, we unfortunately ended up with duplicate meetings with different >> stake holders in the case of Networking and folks have been missing out on >> other meetings too. >> >> So, here it is: >> >> https://cwiki.apache.org/confluence/display/MESOS/Apache+Mesos+Working+Groups >> >> I imagined that we could create IRC channels, hangouts etc and note the >> channels there. >> >> Of course, the main activity should be on the dev@ list but we have >> traditionally met up (online or IRL) for design sessions, higher frequency >> feedback during reviews, etc. >> >> Thoughts / ideas? >> >> Cheers, >> Niklas >>