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