Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update GraphQL-TSC.md to detail voting process #1515

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Update GraphQL-TSC.md to detail voting process #1515

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
20 changes: 19 additions & 1 deletion GraphQL-TSC.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -200,16 +200,34 @@ Note: A member may be recused (i.e. for a member election) in which case they do

### Voting process

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
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

2. Open voting
3. Conclusion of 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).
Copy link
Member

@IvanGoncharov IvanGoncharov Apr 22, 2024 •
edited by benjie

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


**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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

“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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


- A notice is sent via email that the vote will conclude in three business days, reminding those who haven't voted that they should do so. The vote will conclude at the end of this time.
- The election results would not change if all remaining members were to vote.

**3. Conclusion of vote**

Once a valid vote is concluded, the result is determined by the number of votes received at that time (as opposed to the total number of TSC members):

- For a binary choice, the votes in favor must exceed half for a majority (or 2/3 for a supermajority) of the total number of votes.
- For ranked choices, all votes received at the time the vote is concluded are considered.

The result of the vote must be published back to the original Github issue which called for the vote.

### Non-votes

TSC members are not required to vote. There are three ways an _attending_ member may reply to choose not to vote, each with a different intent and impact on the voting process:
Expand Down