Update GraphQL-TSC.md to detail voting process #1515
Conversation
Formalize vote phases, adding more detail to the call and conclude phases, explicitly calling out contact methods and reporting back results
|
|
||
| **2. Open voting** | ||
|
|
||
| Once the Github issue requiring a vote is posted and all voting TSC members have been contacted, the vote is open. Individual votes may be publicly or privately cast. Once the threshold of a quorum has been met and a vote is valid, one of these two critera must be satisfied to conclude a vote: |
There was a problem hiding this comment.
“Privately cast” should be clarified, for example it cannot be via an anonymous poll otherwise we cannot tell which votes are from “active” members for quorum purposes, and it should not be directly and solely to the vote caller for transparency and auditing reasons. I’m assuming privately means to the [tsc-voting] mailing list, but this should be made explicit or otherwise clarified.
There was a problem hiding this comment.
I'd argue there probably should not be privately cast votes. I'd be tempted to say all public votes we should be OK with publicly recording our votes for. For the same reasons you probably don't want your parliamentarian casting private votes.
There was a problem hiding this comment.
Whilst I agree with you in general, there are times when votes being public may unfairly sway the vote - for example if the vote relates to a person, project or organization then personal relationships may influence a public vote whereas a private vote, hopefully, can be cast without fear of reprisal. That said, deciding up front whether something is a public or private vote (for all participants) and allowing TSC members to recuse themselves seems reasonable.
There was a problem hiding this comment.
Isnt it more about the result ... we share the outcome rather how every single one of us voted?
|
|
||
| - Only a member of the TSC may call for a vote (though any member of the community may join a GraphQL Working Group meeting to propose one) | ||
| - A Github issue should be opened in the appropriate repository detailing the vote along with any relevant context and guidance to voting TSC members. Most votes are public and are held in the [graphql-wg](https://github.com/graphql/graphql-wg) repository. In less frequent cases a private vote may be held in a specific private repository (for example, to address security concerns). | ||
| - A reasonable effort must be made to contact all voting TSC members by the individual calling for a vote. Best practice is to **a)** mention `@graphql/tsc` on the Github issue, and **b)** email all voting TSC members, and then optionally **c)** direct message individuals on preferred messaging platforms. |
There was a problem hiding this comment.
I think we are missing the major part of the algorithm, which is time to present your case or even form your position on the topic.
For example, I have concerns about some topics but need to formulate them (which takes time), but I go to the issue and see that it is supported by the majority of the votes.
This situation is very discouraging because, at this point, you are going against an already approved decision without knowing if your arguments could influence votes if the people read them before voting.
In all voting systems, I saw, there is a mandatory discussion period before voting.
Recently, I was in a situation where I disagreed with an already-voted decision and raised my concern because I feel strongly against it in its current form.
Imagine the same happens with our current procedure: I go to an issue and see it already has the majority of votes in favor. If I just write my concerns, I am not sure that members who already voted will see them at all (depending on their GitHub settings and willingness to regularly check them), so I was forced to write separate emails to everyone.
This creates an effect where a decision can "rubber stump" very fast, and TSC members that have concerns need to decide if voicing them is worth the effort or not.
The same goes for public votes; if we add something to the agenda on the day of the WG call, only people who joined the WG call for some other reasons would have an option to voice their concerns.
Taking into that currently we vote a few times per year, I don't see any harm in making a rule that stuff can be voted on only if it were added to the agenda (or after it is posted in this repo and TSC members are notified) at least one week before the vote.
| **1. Call for vote** | ||
|
|
||
| - Only a member of the TSC may call for a vote (though any member of the community may join a GraphQL Working Group meeting to propose one) | ||
| - A Github issue should be opened in the appropriate repository detailing the vote along with any relevant context and guidance to voting TSC members. Most votes are public and are held in the [graphql-wg](https://github.com/graphql/graphql-wg) repository. In less frequent cases a private vote may be held in a specific private repository (for example, to address security concerns). |
There was a problem hiding this comment.
We need stronger criteria here, something that prevents situations similar to what happened.
I should be something like:
Vote can be held in private only if there are a significant risk to GraphQL foundation or broader GraphQL ecosystem. It is MANDATORY that decision record include explanation of potential risk of making this vote public.
For example, in case of security issue it can be as short as:
This security issue is not disclosed to the public so we can't disclose information about it.
So we need to embrace the "public by default" policy that was advertised, and for that, TSC members suggesting "private vote" should provide explicit arguments for making it.
| Because we work in a distributed environment, the voting process must account for a range of time zones and schedules. Once the threshold of a quorum has been met and a vote is valid, one of these two critera must be satisfied to conclude a vote: | ||
| The GraphQL TSC is a distributed group and our voting process must account for a range of time zones and schedules. TSC votes are held asynchronously and follow three distinct phases: | ||
|
|
||
| 1. Call for vote |
There was a problem hiding this comment.
Capturing a note from @benjie - need to capture what constitute a vote, and what appears similar but is different (for example, an opinion poll or asking for feedback)
Formalize vote phases, adding more detail to the call and conclude phases, explicitly calling out contact methods and reporting back results.
@graphql/tsc