search

NCATSTranslator / SRIGovernance

Coordinating governance for the Translator community
2 stars 0 forks source link

Update voting process #18

Closed diatomsRcool closed 2 years ago

diatomsRcool commented 2 years ago

The voting [on PRs] process did not work last year. How can we update this process so that all necessary participants are informed and have a voice while at the same time making it more efficent?

sierra-moxon commented 2 years ago

Thanks @diatomsRcool!

Some thoughts: Voting process works well for some groups like TRAPI where the items are directly actionable. The closer and more specific the issue we're voting on to the work we have to do, the easier it is to vote from a technical POV (once something has gotten into the weeds, it may take less time it takes to really understand the issue and dedicate time to the voting process. The meeting time has been used to get into the weeds for everyone).

For more upstream decisions, like the modeling, it may be that voting is less effective? Some reasons might be: 1) the issue isn't clear enough (on the team asking for a vote to clarify) 2) the issue is too big to vote on (on the team to clarify and phase out the change) 3) the issue is far enough away from implementation that its hard to prioritize putting the time in to making an educated vote and/or 4) not all who are voting are affected the same way by the question being voted on. 5) other reasons :)

Some ideas that others have brought up that might help: 1) allow the issue to go through unless it has x number of downvotes. silence is acceptance. 2) distinguish between "breaking" changes (require a vote) and non-breaking changes (just proceed with PR process as usual). 3) Elect beta implementors that work on a small set of breaking changes and act as early implementors to help refine the ask to make voting easier.

diatomsRcool commented 2 years ago

It sounds like 1 and 2 are not problems with the voting method, just a description of what is being voted on. For 3, if the issue is too far in the future to make an educated vote, maybe the vote should be postponed. Number 4 is the one we have to keep an eye on. We don't want to bulldoze anyone, but we can't be left in a standstill. Here is what I would suggest.

  1. Be abundantly clear in the notes and in the documentation what is being changed and include this in the weekly newsletter.
  2. If it is a non-breaking change, proceed with the usual PR process.
  3. If it is a breaking change, elect beta implementers who can refine the ask, give early feedback, and focus voting. The beta implementers can be skipped, if the group feels it will not help.
  4. Allow issues to go through unless there are down-votes. Silence is acceptance.
nlharris commented 2 years ago

The voting process did not work last year.

Which voting process? What was being voted on? How did it not work? (The answers to these questions may exist elsewhere!)

diatomsRcool commented 2 years ago

Voting on PRs.

diatomsRcool commented 2 years ago

See final voting process here.