Repository navigation
From contributor to core team transition #14
Description
Activity
If we want to encourage participation in the community then "core team membership" ought not have "some number of good PRs" as a firm requirement. There are so many ways to meaningfully contribute to an open source community: writing good documentation; copy editing other people's documentation; triaging and managing issues; being a good spokesperson at conferences and events; etc etc.
Re-reading the deliverable, though, I see three distinct things:
- process for code commit
- process for core team membership
- release pipeline
The first is relatively easy: all code should be committed via a pull request. Ideally, an issue should be created in advance of each PR, and the subsequent PR should reference that issue. This can get a little annoying for smaller things, but in general it's a well established pattern that's pretty easy to follow. The PR must receive some number of positive votes from the community before being merged. If any negative votes are applied, a discussion should probably be continued on the associated issue to identify the discrepancy between opinions and work toward a consensus. Unanimity is not the goal: consensus is.
The second item is the thorniest of the bunch, and the hardest to prescribe up front because it involves people more than process. In general, core team membership should be decided by the existing core team. One of the things being a "core team member" provides is the ability to push the merge button on GitHub. In this regard, the person being invited to join the project should have a demonstrated history of contributions, and a demonstrated understanding of -- and support for -- the vision of the project, as well as a history of positive community involvement. Of course, having the ability to merge code does't mean they must: core team members don't have to feel compelled to merge!
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.
As such, I feel completely comfortable suggesting that the core team decides 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.
Item three above, the release pipeline, seems pretty easy to solve, too. 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.
As a general request, can we please lump in some of the meritocracy bits from model organizations I think would flow well here
From the presentation 12/13 we had some questions come back which we need to think about and make further recommendations on:
- size of the core team
- time commitment required of core team
- definition of a project
My assumption is that it is not required that every member of a dedicated SCOS development team be a core team member. The dedicated team size is up to the organization and the framework used, e.g., Scrum.org says optimal team size range is 3-9 members. I would think a team needs a minimum of 2 core members, although that may not be as feasible for a team of 3 due to skills and interest. Additional core team members would help spread out the workload. I don't know that we need a cap on core team members if the team uses consensus methods effectively and/or has a designated tie breaker.
Time commitment depends on the size of the overall open source community and its adoption. As the number of users and contributors increases there are more channels of communication to manage and time commitment will be higher when a team is forming, changing processes and technologies, etc. For example a core team member may need to pull stacktrace duty to support users of the software which could be a considerable time commitment in itself.
It was mentioned in the segment 2 meeting discussion that open source projects usually map to github repositories and the organization will have its own project definition which could span repositories. Github introduced projects for organizations in 2016. I have not used this but it seems like a way to manage projects that span repositories.
@PhilNorman2 started to address the core team size (3-9 members) and time commitment (unknown). Any other thoughts on these?
Also, succession planning. Anyone have thoughts on how long someone should serve as a core team member? Indefinitely, or plan to rotate new people in?
I'm a big fan of the phrase "The best way to have good ideas is to have lots of ideas." That suggests that some regular influx of new perspectives is valuable.
I don't know that there needs to be a cap on core team size, as long as decision making can be scaled appropriately. It's hard to get unanimity with more people; but simple majority rule also has perils.
I'd recommend that core team membership should be perpetual, until the person elects to leave the team. If they simply stop participating, their lack of involvement will also mean lack of strong stances for or against proposed options.
On core team size...
-
The size of the core team probably does not have a set number.
-
note this is for each individual git repository not the entire monolithic core.
- In the beginning we fully expect a lot of overlap of individuals across multiple projects. Over time this should ( hopefully naturally ) balance out. As other cities / entities cycle in/out, as members elect to move on etc
- The idea behind this is to both scale and prevent monoculture
-
I have mixed feelings on this one:
I'm a big fan of the phrase "The best way to have good ideas is to have lots of ideas." That suggests that some regular influx of new perspectives is valuable.
I don't know how to balance keeping the group active vs becoming stagnant or taking dogmatic approaches ( eg, we did it this way once, we keep doing it this way even if its no longer the best or known to be wrong )
-
I agree with @skpy on the assertion about not having a defined time limit. I think so long as individuals are interested in being a part of a given project this should be acceptable. We should encourage the members to think about their plans longer term - eg succession planning. I'm not sure what to recommend toward this end - may need further discussion or maybe just recommending is sufficient. ( I feel like the latter is enough personally )
-
As long as there's no drag on the project by having non-participatory members hanging around (presumably not engaging in issues, discussions, or the like) then there's no real incentive to suggest, let alone encourage, people to step aside after a tour of duty.
You accurately identified the root notion behind the quote, @bilsch. A consistent and cohesive group can become apathetic, if not hostile, to new ideas. Monoculture is definitely something to avoid; just like a complete free-for-all of ideas to pursue is to be avoided. The role of the core team is, among other things, to take a long-term view toward project activities, but this needs to be balanced with a sensitivity for new, potentially wild or unorthodox, ideas that might provide real value.
Another way of thinking about this would be "strong opinions, loosely held." The core team can and should have a firm understanding of where the project and its components are going, but not be so enamored of their own ideas that they reject things that will promote vitality and relevancy.
Yes, it's a balancing act. There's no way to encode up front how to do this successfully. It's a series of judgement calls, experiments, evaluations, and retrospective analysis (as well a good bit of personal self-reflection from the individuals involved). I'd say that at a minimum the core team needs to be cognizant of these challenges, sensitive to the public perceptions of their decision making, and actively working to welcome and groom new participants.
I’m looking at deliverable 4
And I’m honestly at a bit of a loss when it comes to recommending a process for transitioning a contributor into the core team.
On my project, this was a simple thing. After a contributor had some number of good PRs, reviews on other people’s PRs, and general helpfulness to the community, they would gain the trust of my co-maintainer and myself.
At some point, I trust this contributor, have a quick conversation with the co-maintainer and we would simply make a decision to add that contributor to the core team.
I have no idea how to codify & adapt that (very informal) process for the purposes of the Smart Columbus project. If anyone has ideas around this (or simply wants to take ownership of this particular item), I’m all ears.