Core team membership - UrbanOS-Examples/TechnicalWorkingGroup GitHub Wiki

These were discussed in detail in the following issues:

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

Core team membership

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.