This document contains categories of contributions and behaviors relevant to becoming an Apache Mesos committer. As a committer candidate you can use a copy of this list to collect and aggregate data on what you have achieved so far. Neither is this an exhaustive list nor do all categories need to be addressed, since there can be reasonably diverse committer profiles. But some categories are always crucial to have covered, e.g., writing high quality source code and performing meaningful code reviews. Eventually, your nominator can hand in your filled-out variant of this list to the PMC to facilitate their reviewing your case.
Candidate name:
JIRA user name:
Github user name:
Reviewboard user name:
Nominator:
Understanding of the Apache philosophy (The Apache Way). Demonstrated by:
Understanding of the Mesos project’s goals. Demonstrated by:
Commitment to the Mesos project. Demonstrated by:
Knowledge and activity breadth and depth in the Mesos project as well as areas where the candidate could be a maintainer:
Can the candidate be trusted to act the right way outside of known areas where they have already demonstrated committer-level expertise and behavior:
High quality source code. A committer vouches that the candidate writes high-quality, “readable” code, adhering to Mesos style and best practices standards, both formal and informal. Name of the committer:
General comments on community engagement:
Helping new contributors:
Presentations at meetups, conferences, etc.:
Reviews catching functionality issues. List reviews and a committer for each as witness:
Reviews catching style issues. List reviews and a committer for each as witness:
Major source code contribution. Description of the contribution:
JIRA tickets created. List initiated JIRA tickets (or an equivalent JIRA query and count/summary):
JIRA tickets completed. List resolved JIRA tickets and committed review requests (or an equivalent JIRA query and count/summary):
Evidence of testing as a priority: A simple metric could be <#tests written> / <#testable tickets>. Or you could detail a particularly complex set of unit tests you had to write. Or explain how you have improved the project’s testing infrastructure or best practices. NOTE: These are just suggestions for documenting testing efforts. The ultimate goal here is convincingly corroborating that all contributed source code is adequately covered by tests.
Initiated design documents:
Reviewed design documents:
Contributions to Documentation:
Dependability. Issues quickly / immediately solved that arose out of own contributions: