feat(voting): add async voting process

[kantorcodes]

Summary

This PR establishes standardized asynchronous voting procedures for the Hiero TSC to address quorum challenges and improve decision-making efficiency.

Related Issue

Closes #159

Changes

• Creates comprehensive voting procedures document in proposals/tsc-voting-procedures.md
• Defines PR-based voting process using GitHub's built-in review features
• Establishes clear timelines (14 days)
• Specifies voting eligibility tracking via tsc-voting-eligibility.md
• Provides templates for proposals and voting records

Key Features

🗳️ Voting Methods

• In-meeting votes: Continue as normal when quorum is present
• Asynchronous votes: GitHub PR-based for when quorum cannot be achieved

⏱️ Process Flow

1. Optional discussion phase via GitHub Issues
2. Immutable proposal submitted as PR
3. 14-day voting window with early resolution when outcome is determined
4. Clear pass/fail thresholds (>50% for standard, charter-specified for special cases)

📊 Transparency

• All votes recorded in PR reviews
• Public voting record maintained
• Member eligibility tracked in dedicated file

Charter Considerations

The proposal includes recommended charter modifications to:

• Reduce reinstatement requirement from 2 meetings to 1
• Explicitly state >50% threshold for standard decisions

Next Steps

If approved, this proposal will:

1. Create the proposals/ directory structure
2. Enable asynchronous voting for future TSC decisions
3. Improve TSC participation and decision velocity

[MilanWR]

Looks good, thank you Michael!

[hendrikebbers]

Is this a concrete suggestion to change the charter?

[kantorcodes]

Yes, this was a suggestion from @popowycz: #159 (comment)

If we feel it doesn't belong in this document, we can remove it

[hendrikebbers]

We should sync with LF / LFDT and check if there are best practice documents for async voting. If yes we maybe can depend on those definitons. I will check that (maybe with @jwagantall )

[rbair23]

I think it would be good for in-meeting votes to also have a proposal that is merged into the repo. Whether it is in-person, or asynchronous, there would be a proposal. Often we've had a vote but in retrospect we have a different recollection of what we voted for. Having it written down plain, that we can go back to and reference, would be an improvement over our current way of working. It also means we have a very clear and publicly accessible record of what we voted for.

[rbair23]

I think we can have a 2/3 in-person vote as well (and maybe would prefer that over async for important votes, if possible).

[popowycz]

agree - we should be consistent so that one voting method is potentially not gamed

[rbair23]

I'm not sure the date is going to be useful here. What if we had a proposal number, similar to HIP numbers, where the number is the PR number. Then we get some kind of sequence?

[popowycz]

That makes sense - let's leverage what can be implemented natively to reduce confusion with potentially arbitrary numbers, etc.

[kantorcodes]

I'm not sure the date is going to be useful here. What if we had a proposal number, similar to HIP numbers, where the number is the PR number. Then we get some kind of sequence?

My thinking on the date is that it would provide providence on when the proposal was issued in relation to the cadence of meetings without needing to look at the commit date. If we'd like to remove it, I'm indifferent. The only issue I would flag for using PR numbers is it is often a two-step process if you calculate the name of the proposal incorrectly through the PR.

Feel free to edit the PR with any combination of approaches here, as I'll be out of office next week and don't want to be a blocker here.

[rbair23]

If we simply clear all approvals if the file is changed, would this also work?

[kantorcodes]

If we simply clear all approvals if the file is changed, would this also work?

I was looking at it from a strictly immutable lens, but of course the Github configuration settings could get in the way here. If discussion is required, it could happen outside of the PR per step 1. If changes are required that were not accurately reflected in the discussion it should require closing the PR and reopening a new one with a clear history / new proposal, similar to how decentralized governance works today commonly. Once you attribute your tokens to a YES or NO answer, you cannot change that vote.

Again, open to amendment / commits here, the initial flow is just a recommendation

[rbair23]

Do we vote "no" by leaving a comment on the PR?

[kantorcodes]

Do we vote "no" by leaving a comment on the PR?

I like that approach, and good nudge to have that documented.

[rbair23]

This will not be needed if we modify the charter to eliminate this requirement

[rbair23]

What if we simply removed the "attend the meeting" requirement for voting eligibility. Then we wouldn't have to track attendance for voting purposes.

[kantorcodes]

I think @popowycz mentioned that it was added to help create incentives on participation, I'm personally indifferent either way

[rbair23]

He's right, that was the original intent. The concern expressed at the time was that people would not participate in the meetings, but then still vote, and having participation is healthy for an open source project.

On the downside, it is a lot of overhead to maintain the list of who can vote when, and can cause us to take incorrect votes if we get it wrong.

There is a different control though -- if a TSC member becomes inactive, we can vote them out. We don't want MIA members, but maybe penalizing through voting is too cumbersome a mechanism. Maybe if we're having a problem with participation, we ask them to either participate or step aside so new people who are eager to participate can join, and if they refuse and still don't step up, then we can vote them out for failure to fulfill their responsibilities.

Or maybe there is a different incentive mechanism that doesn't make the voting process so cumbersome. I'm not sure.

[jwagantall]

I’d like to add a few comments. While I support the addition of asynchronous voting, since it significantly speeds up processes that require TSC approval, I do have concerns about the proposed charter changes. I haven’t yet had a chance to connect with Hart or Daniela, but I’d like to get their perspectives as well, especially since some of these changes could have legal implications. It’s important we’re on solid ground here. If we loosen our governance requirements and something goes wrong, it could reflect poorly on LFDT.

Another point I’d like to raise is regarding TSC member inactivity. Diane and I are currently working on a way to better track attendance and ensure accountability. I understand this might come across as a bit strict, but I believe it’s necessary. Encouraging participation is important, but we also need to be able to show that members are actively engaged. While our TSC is still small, establishing this accountability now will be valuable as the project grows and brings in more members.

Finally, I want to +1 @rbair23 suggestion about recording voted items as commits in the repo. This would make it much easier to locate decisions without having to sift through meeting recordings.

Thanks again for putting this together!

[jwagantall]

I’d like to add a few comments. While I support the addition of asynchronous voting, since it significantly speeds up processes that require TSC approval, I do have concerns about the proposed charter changes. I haven’t yet had a chance to connect with Hart or Daniela, but I’d like to get their perspectives as well, especially since some of these changes could have legal implications. It’s important we’re on solid ground here. If we loosen our governance requirements and something goes wrong, it could reflect poorly on LFDT.

Another point I’d like to raise is regarding TSC member inactivity. Diane and I are currently working on a way to better track attendance and ensure accountability. I understand this might come across as a bit strict, but I believe it’s necessary. Encouraging participation is important, but we also need to be able to show that members are actively engaged. While our TSC is still small, establishing this accountability now will be valuable as the project grows and brings in more members.

Finally, I want to +1 @rbair23 suggestion about recording voted items as commits in the repo. This would make it much easier to locate decisions without having to sift through meeting recordings.

Thanks again for putting this together!

FYI on the charter changes.
I was discussing this one with Hart. Charter changes would definitely require legal approval. However, we should make careful considerations about what's being changed here and think of scenarios where this will not affect us in future. (Considering too the fact that the TSC group can grow as the project develops).

[jwagantall]

In today's TSC there was a discussion regarding tracking attendance. The idea is to help making attendance tracking and eligibility simpler and easier.
@popowycz suggested we could consider the previous week's TSC attendance as eligibility for voting to make it simpler.
@hendrikebbers has created a tracker available here https://github.com/hiero-ledger/tsc/blob/main/minutes/2025-07-08.md#active-tsc-member-state
Another idea is to use tools like gitvote to track attendance in the PRs of each meetings minutes and possibly also automating in GHA the attendance based on the minutes.

We are going to continue discussing this further in the community call. I will comment back on anything that comes out from that conversation.