Note, this is still under construction. At this point code commit, core team and release pipeline are covered pretty well and likely only will receive grammatical corrections.

• December 13 requirements
• Process for code commit
• Core team membership, commit access and release pipeline
  • Core team membership
  • Release pipeline
• Community Engagement Recommendations

---

December 13 requirements

Milestone 2:

1. Identify a process for code commit, core team membership, release pipeline
2. Recommendation on how to engage and manage the community

---

Process for code commit

We have discussed the what we feel is the process for code commit within the following issues:

1. #7 - Pull Request Model
2. #4 - Develop contribution guide

The content in Pull Request Model mostly covers the objective.

The only addition is that we recommend following up in the future with a template contributions.md , code of conduct and issue and pull request templates for use on all projects. This is more efficient and consistent across each of the projects versus making each project have its own ( obviously, allowing for customization ).

Core team membership, commit access and release pipeline

There are two distinct aspects being lumped together here. The first being core team membership and the second being a release pipeline.

These were discussed in detail in the following issues:

1. #14 - From contributor to core team transition
2. #2 - Model Organizations

Core team membership

Note, the content below has been copied over to Core team membership in the wiki.

As suggested in the Model organizations wiki we should look to function by a meritocracy.

This core team membership first needs a bootstrap. The previous recommendation to start with members of the core development team and technical working group members is a logical first step. This can be done organization wide and/or within each git project - eg delegation of duties.

We should define the role of a core team member as an individual with certain capabilities and responsibilities:

1. Having merge access to and/all branches of a project
2. Responsible for ensuring the stability, health and direction of the project
3. Responsible for ensuring quality of
   • code
   • documentation
   • security
   • unit and functional tests
4. upholds the suggested code of conduct

We should develop a ( likely very short ) list of conditions for contributors to meet which would be used to consider invitation to become a member of the core team. Simply meeting one or more of these alone is not enough it must be a combination of the below as well as a recognition of a need for additional capacity / work distribution. The following is a list of some examples:

1. Regular contribution of issues as well as pull requests
   • Code contributions
   • Documentation
   • Collaboration with other issues offering assistance
   • Promotion of project(s) within the community
2. Willingness to make modifications to contributions before being accepted
3. Politeness in dialog within the community ( issues, wiki, documentation etc )
4. Expressed interest in a more active role within the project

Ideally, being a member of the core team isn't seen as a big deal. One can participate and contribute to both the community and the project(s) regularly and meaningfully without being a member of the core team. If the number of PRs to merge somehow becomes burdensome, adding another person to the core team might help keep things moving. In my experience, that's generally not been a real bottleneck.

What other things might core team membership afford? Greater decision making? Greater weight to their votes on issues? Something else? It's hard to predict in advance how the community will evolve, or what process challenges might arise such that the core team needs to take specific actions that only they are permitted to do.

The existing core team members should feel completely comfortable suggesting when to invite new people to join, based on their collective interpretations of people's involvement with the community and their contributions. Broad representation of the different interests from the community within the core team is advisable, so the core team can extend an invitation to fill a gap as needed, or in response to discussion from the community.

One thing we should also look to address is core team membership succession plans. People move on, have desires to reduce their load, take time off etc. We should look to have guidance and wording in the future around this to ease transitions in/out of core membership.

Release pipeline

The easiest way to summarize the release pipele - Release early, release often. Smaller incremental releases are generally easier to consume than big huge releases. A CI tool can ensure the code works as desired by passing tests, and then produce a releasable artifact.

We should look to implement the structure described within Community Engagement and the recommendations from Model Organizations recommendations.

Release cadence

Outside of the generic "release early, release often" we do not have specific recommendations. Thought should be put into setting sensible milestones and determining what features / bug fixes will be included and picking a date accordingly. Special care should also be placed upon submitted issues against each project. If the severity warrants a more rapid release or to address security related issues this can and should be done.

unit and functional tests

When appropriate ( eg, source code, operations code etc ) repositories must contain unit and/or functional tests. Prior to a project being given a release these tests must be 100% passing. There should also be some measure of coverage / completeness of the testing.

---

Rough content for the slides. Note these may be tweaked and cleaned up in the final ;)

Core team member qualifications

1. Has commit / merge access to the repository
2. Responsible for stability, health and direction of the project
3. Responsible for ensuring quality of
   • Code
   • Documentation
   • Security
   • Unit and functional testing
4. Upholds the code of conduct
5. Community reach-out
   • Meetups, mentoring etc
   • Seeks out / recruits new core members as needed
6. We should likely start with existing developers and TWG technical members as a seed
   • We should look to have 1+ core member not be exclusively scos developers
7. We need to think about a succession plan to allow core member rotations

Release cadence

1. Release early and often
   • Value smaller incremental deliveries / releases over larger
2. We should avoid waterfall delivery
   • Especially of multiple projects / code repositories at the same time
3. Set sensible milestones for releases
   • Features
   • Bug-fixes
   • Reported issues
4. Allow for shortened release cycle when appropriate
   • Especially for security related exposures
5. All unit / functional tests must be passing
6. Advertise and track test coverage

Growing the core for a project

We are looking for qualifications. Examples:

1. Regular contribution of issues, pull requests, documentation, promotion with the communities etc
2. Collaboration on issues, pull requests with other contributors
3. Willingness to make modifications to contributions prior to being accepted
4. Politeness in dialog within the community ( issues, wiki documentation etc )
5. Expressed interest in a more active role within the project