WIP: Simply TSC membership and RFC responsibilities #48
Conversation
This attempts to simply the TSC and RFC process. It does 2 things: - Sets a maximum of 5 seats for the TSC. This is to prevent awarding the position to everyone and keep the group efficient. - Removes the need for "RFC meetings" which rarely happened in reality. Instead RFC voting can happen via GH issues and PRs.
matthewp
changed the title
There was a problem hiding this comment.
The process changes make sense to me 👍
I might question if we need a hard rule about the TSC size? We’ve never had more than 3 people on TSC to my knowledge, and I’ve never seen pressure for more or for everyone to be included. Given that, I’m not clear on the motivation for setting that in stone and generally we lean towards only legislating for realities we’re actually facing, but happy to hear others’ thoughts.
| @@ -234,6 +234,8 @@ A TSC member guides the direction of the project and ensures a healthy future fo | |||
|
|
|||
| A TSC member has significant sway in software design decisions. For this reason, coding experience is critical for this role. TSC membership is one of the only roles that requires a significant contribution history of code to the Astro project on GitHub. | |||
|
|
|||
| TSC seats are not time-limited. The size of the TSC can not be larger than 5 members. This is to ensure that the TSC is able to make decisions efficiently. | |||
There was a problem hiding this comment.
TSC seats are not time-limited.
This feels like we should therefore also describe situations in which a member does leave. Can they ever be asked to leave? required to leave? Are there any criteria to establish ongoing eligibility, since the only criteria mentioned thus far is past contribution history.
Not that we're gonna grow super large any time soon, but if we're going to have a limited number of "not time limited" positions, at some point (e.g. 80 core members) it can't just be "the five people who got there first." So we should probably write now to describe what should happen to keep this group "the 5 people we most need steering the ship."
There was a problem hiding this comment.
I'd also add that I don't know what "time-limited" means. It might be worth giving it its own line where you state this and also define it clearly.
There was a problem hiding this comment.
TSC seats are not time-limited.
Can you explain more about the benefit of adding this paragraph at all? What is your goal here?
The reason I ask: Currently, this is left undefined, and all undefined behavior falls back to the Steward. So in this case, semi-intentionally, this means that the TSC currently "Serves at the pleasure of" the steward, meaning that its membership and state can be modified at any time by the steward in whatever configuration the steward feels is best for the project.
So if you'd like to add restrictions on that power and structure/expectations of the role outside of just "whatever the steward thinks is best at the time", I think that's well within the scope of our governance doc. But as a voting member of the team I'd love to understand what problems you aim to solve so that I can best vote for/against.
If your goal is more about documenting the ideal TSC as a north star, without strictly defining/requiring it, then I think you could rephrase this specifically towards that goal, like:
The ideal TSC should be:
- [...list its characteristics]
Then that would still put some pressure on the project steward to match the ideal TSC as defined, or have a good reason for the team as to why they are avoiding that.
There was a problem hiding this comment.
I got this idea and number from ESLint's governance: https://eslint.org/docs/latest/contribute/governance#technical-steering-committee-tsc
The reason I wanted to add it was to signal that TSC is intended to be a smaller group and remove any expectations that it's something that you "graduate" to for continuing contributions. You graduate only if there is an open seat and core decides there is a need for another person.
@sarah11918 On leaving, my assumption would be that this follows the same rules for core in general. Someone can leave TSC voluntarily, they can be asked to leave when they become inactive and become alumni, they can be asked to leave for violating CoC, etc. Do you think there needs to be any extra rules as far as TSC is concerned? What would those be?
| 5. **If consensus is reached:** the RFC is approved. | ||
| 6. **If consensus is not reached:** The RFC author and TSC members must make all reasonable attempts to resolve issues and reach consensus in GitHub or a follow-up RFC meeting. The process of reaching consensus can take time, and should not be rushed as long as all participants are making a reasonable effort to respond. | ||
| 7. **If consensus still cannot be reached:** The project Steward may invoke [rough consensus](https://en.wikipedia.org/wiki/Rough_consensus) to resolve an RFC that has not achieved absolute consensus, as described below (borrowed from the [IETF](https://datatracker.ietf.org/doc/html/rfc2418)): | ||
| 2. Changes can be discussed and approved entirely within the RFC GitHub issue. TSC members can vote on the RFC via a review of either **Approve (For)** or **Change Requested (Against)**, in the case of Pull Requests. For issues, TSC members can vote via a comment. |
There was a problem hiding this comment.
TSC members can vote on the RFC via...
Do you mean "must" vote? If I choose to vote elsewhere (ex: in a Discord channel) would we count that vote?
There was a problem hiding this comment.
Yes, I meant must vote via PR / issues, will update.
This attempts to simply the TSC and RFC process. It does 2 things: