YAM Governance Process Analysis and Questions

This is the first part of a larger discussion about governance within the YAM DAO. This is the first step in creating a framework to understand our current process and propose improvements. I encourage everyone to weigh in on what they think of the current process as well as if they have thoughts or suggestions about some of the questions and issues posed at the end of this post.

.
Introdution

In the process of running and improving the Yam DAO, there will be many different decisions that need to be made. These decisions will come in many shapes and sizes. So far, the process for developing and approving governance actions has been relatively ad hoc and is often led by a small group of contributors.

The general flow for decision making has been as follows:

  1. Early discussion usually starts in discord, where an idea is first presented and discussed.
  2. From there it moves to the discourse forum, and is usually presented as a proposal with objectives, some level of specification and a poll to vote on.
  3. If that poll is generally positive (there is no defined threshold) then it will proceed as a snapshot vote.
  4. If it passes the snapshot vote then it is considered ratified and handed over to developers to create the code modifications to build it, test it, audit it, and implement it.
  5. Finally, there is an on chain vote to commit the code to the blockchain. This last vote should be mostly symbolic as all the work has already been done and the goal with the rest of the process is to iron out previous consensus issues beforehand.

Most governance actions were non-contentious, but there have been a few contentious ones that have passed. These were the compensation proposals, the proposal to change the rebase sell percentage, and the proposal to remove rebasing. In all of these actions, initial pushback on the proposals led to adjustments and resubmission to assuage concerns.

Other actions, like the ragequit proposals, have been split into multiple pieces to come to consensus in smaller steps. This process has also been somewhat ad hoc, but speaks to a more flexible model where larger issues can be approached in smaller chunks with different governance criteria.

The most difficult part in this process is determining whether consensus has been reached on contentious proposals. This is especially important in YAM, since governance by fork is severely hampered by an un-forkable treasury. As the YAM treasury is central to the value proposition of the YAM DAO and the YAM token, there are few options for YAM holders who disagree with the direction of governance decisions.

With proposals that are split close to 50/50, this is a losing proposition for all sides if it means half the token holders will be disgruntled or exit. This should drive all YAM holders toward better understanding each other’s positions and some kind of compromise.

At some point it may not be possible to fully compromise and some YAM holders may exit when a proposal they disagree with is passed. These situations should be discouraged, and situations like this are a large reason for having strong social consensus around the goals, mission, and values of the YAM DAO. Without a unified understanding by token holders as to what YAM is and is striving to become, conflict will inevitably arise.

These issues are in some ways beyond the scope of the governance flow. But a well defined governance flow will allow all participants to focus their efforts on the specific actions they are proposing. It will also help participants in the process gain information about whether what they are proposing will be contentious or not, and what elements of their proposals may need to be tweaked to improve them.

.

.
Goals of a Good Governance Process:

  • Make good decisions
  • Governance process should be transparent and clear.
  • Encourage contribution and involvement.
  • Make sure opposing views can be heard and considered.
  • Make sure a proposal is technically feasible
  • Keep the governance process moving and free of gridlock.

.

.
Analysis of the Governance Process as it currently exists

In this post by Trent, he describes the current governance process as it applies to Forum discussions. In it, he lists the proposal flow as:

Forum Discussion + Poll > Off-chain Signalling(Snapshot) > Code Production > On-chain Vote

Below, I will break down each step.

.
Forum and Discord Discussion

Proposals start as a post on the YAM forums or in the Discord server. Trent’s post linked above describes the current process. Proposals should generally follow the template provided on the forum and include a poll. Discussion should last at least 3 days before submitting for a snapshot vote.

There is no requirement for a post or poll to have a specific result to submit a snapshot vote. This part of the process currently relies on community members choosing to follow these rules.

.
Off-chain Signalling/Snapshot (Binding, but only through social consensus)

Pre-requisites:
It is expected that the proposal has been discussed on Discord and the forums for 3 days and “the community signals its interest.” Enforcement of this rule falls to social consensus.

Submission Requirements
Proposal = 100 BoU YAM
Quorum = 200,000 BoU YAM voting “For” the proposal.

There is nothing hard-coded to set a maximum or minimum voting period, but the current documentation specifies that snapshot voting be 3 days. It is unclear whether these 3 days can overlap with the 3 days of discussion on the forum or if they are additional. Either way, enforcement of this rule falls to social consensus. Certain core team members have the ability to hide/remove snapshot votes from the voting interface, but the norms around removing snapshot votes is unclear.

50% of votes required to pass if a Yes/No Vote. It is unclear what the procedure is if the vote is weighted between multiple options. But previous proposals were considered to pass if they met quorum and the average was accepted as the outcome of the vote.

If this proposal requires modifications to deployed contracts, or for new contracts to be deployed, then that development work happens after this step and before the final on chain vote. There is no requirement to resubmit for a snapshot vote if the implementation of the proposal is changed between snapshot and on-chain voting.

If the proposal does not require modification to contract code or the creation of new contracts on Ethereum then the proposal is final if passed.

.
Code Production

Pre-requisites:
A passed snapshot vote is a signal that there is consensus on this topic and development work can be done with minimal risk.

Development work is done primarily by the core devs of the project and the development work for governance actions is prioritized by the core team depending on its perceived importance and time sensitivity. Some governance actions require significantly more developer time to implement and may require audits. Developer time is currently a bottleneck for the implementation of complex governance proposals.

.
On Chain Voting requirements (Binding through Ethereum consensus)

Pre-requisites:
Snapshot vote has passed. (social consensus)

Code must be ready as this step creates new contracts or implements the changes to the existing contracts running on Ethereum.

Standard Governance Vote
Submission requirements = 50,000 BoU YAM
Quorum = 200,000 BoU YAM voting “For” the proposal
2 day voting period (12345 blocks)
12 hour time lock after vote closes
Guardian can stop the proposal at any time during these 60 hours if deemed malicious.
50% of votes required to pass.

Contributor Payment Vote
Submission requirements = 25,000 BoU YAM
Quorum = 100,000 BoU YAM voting “For” the proposal
3 day voting period (18514 blocks)
12 hour time lock after vote closes
Guardian can stop the proposal at any time during these 84 hours if deemed malicious.
50% of votes required to pass.

There is nothing that will prevent someone with access to the above submission requirements from proposing an on-chain vote. This proposal then is dependent upon reaching quorum and passing with a majority of “For” votes. That it may not have gone through any of the previous steps does not matter unless the Guardian deems that it is malicious and blocks it. The norms around what is malicious or not are not defined anywhere.

.

.
Issues and questions with the Current Governance Process

  • The only truly binding governance decisions occur once an on-chain proposal passes. Everything else is built upon varying layers of social consensus.

  • All steps before an on-chain vote can be skipped if a proposer has enough YAMs to propose a vote. While this is not a powerful attack vector since the proposal can be voted down or the Guardian can veto, it does risk undermining the social consensus around how the governance process works.

  • Code implementation of proposals is a centralization vector if the number of people who can implement proposals is limited. Opening up the coding work to outside developers adds security risks. A middle ground where core developers offer to write and or review code for specific proposals may help mitigate this issue.

  • Code implementation costs and audit costs are often not considered in proposals and these numbers are often hard to find.

  • There is no governance procedure in the event that a proposal requires significant changes in the code development phase between snapshot voting and on-chain voting. This risks a proposal changing significantly between votes.

  • In the snapshot process, Yes/No votes have clear quorum and passing rules, but other voting types, which have been used, do not. These should be clarified and confirmed.

  • Because all that is required to create a snapshot vote is holding or having 100 BoU YAM delegated to you, it is possible to spam snapshot votes or create confusing alternate versions of votes to derail the process. This would require administrative actions from the core team and the norms for these actions have not been defined.

  • In the forum proposal and snapshot process, it is unclear whether the time requirements to discuss and have snapshot votes open are additive or overlapping (i.e. 3 days of discussion and then 3 days of voting, or 3 days of discussion and voting).

  • What power should core team members, or other community members have in policing the social consensus rules within the proposal and snapshot voting phase?

  • How can we determine if a discussion has progressed to a point where it should be voted on? What happens if a vote occurs on a proposal that is underspecified or impossible and it passes?

2 Likes

Precise discourse and analysis.
Dao is a new economic model, there’s no SOP to give any guidance. We should modify it better and better through what we have experienced and discussed. It needs to cover the balance between investor’s right and efficiency. If the investor didn’t take a look of what is happening in the community in a week, or they just keep watching but not to express their opinion. I think 3~7 days will be quite enough for gathering poll and discuss, no matter in forum or snapshot.
It would be much better for this topic if providing polls for different options.

YAM治理流程分析及问题

最近关于简化和明确YAM DAO治理流程的问题引发了广泛的讨论,为了使我们我们可以明确当前的流程并提出改进建议,以下对相关讨论内容进行了梳理。这是第一部分,也是创建治理结构的第一步,希望大家可以权衡考虑自己对当前治理流程的看法,以及本文末尾提出的一些问题和建议。

介绍

在运行和改进Yam DAO的过程中,需要对不同形式和规模的提案决议作出选择。 到目前为止,治理决策的制定和通过流程,具有相对的特定性,通常表现为只由一小部分贡献者负责参与和实施。

当前治理决策的通用流程如下:

  1. 早期讨论通常源自Discord频道,一般开始于一个想法,在提出后会加以探讨。
  2. 之后这些想法会转至Yam论坛以进一步加深讨论,在这一环节,一般会以提案的形式发布,其中包含具体目标、一定程度上的论述以及投票测试。
  3. 如果该提案的投票结果得到普遍的认可并且没有明确的阈值设定,那么之后该提案便会进入到链下快照投票(Snapshot)环节。
  4. 如果在链下快照投票环节该提案也获得了通过,那么它便会被移交至开发人员手中,进行代码的构建和修改、测试、审计等工作,直至部署部和实施。
  5. 最后一步是进行链上投票(on-Chain)以将代码在区块链上进行提交。由于此时大部分工作都已经完成,因此链上投票也具有一定的象征意义。所有上述这些环节,都是以解决问题和取得共识为导向而进行的。

目前看来,绝大多数的治理决策都没有产生争议。但也有少数被通过的提案存在一定的争议性,例如「贡献成员薪酬分配提案」,「正向Rebase用于购买金库资产的分配比例」提案,以及「取消Rebase机制」提案。在这些提案的治理过程中,初期的阻力导致了后续的调整和重新提交,以缓解和消除对于这些提案内容的担忧和顾虑。

还有一部分决策如「RageQuit退出保护机制」,后来被拆分成多个不同的部分并逐步达成了共识。从某种意义上来说,这种处理方式也带有一定的特殊性,或者说是一种更为灵活的方式。通过采用分开提交逐步治理的方式,可以使规模较大和较为复杂的问题一步步得到解决。

在整个治理过程中,最困难的部分就是如何确定各方是否就有争议的提案决策达成共识。这一点对YAM而言尤为重要,由于Yam金库是是Yam DAO和YAM代币最为核心的价值主张,因此提案可以出现分歧,但Yam金库却无法产生“分歧”。基于此,那些与治理决策方向有分歧的YAM持有人就会变得较为被动。

就一个提案来说,如果该提案的投票比例接近50:50,这意味着可能有接近一半的YAM持有者对该提案表示不满或退出。对任何一方来说此提案可能都是一个失败的案例,但这反而会促使YAM持有者朝着相互谅解的方向去努力,并最终实现某种程度的妥协与折衷。

在某些无法达成妥协的提案中,一部分YAM持有者可能会因为不满提案被通过而最终选择退出。这种情况的出现令人沮丧,但这也正是为什么我们需要围绕着Yam的核心目标取得强大共识的主要原因。如果YAM持有者无法就Yam的价值和努力方向达成一致,那就无法避免上述冲突。

某种程度上,这些问题已经超出了治理程序的范畴,但制定一个清晰合理的治理程序,可以使治理参与者避免无谓的干扰,将精力集中于他们所提出的具体举措上,也可以帮助他们判断出自己的提案内容是否产生了争议,以及需要改进那些要素来完善这些提案。

设定合适的治理程序

  • 做出明确合理的决策;
  • 治理过程应保持干净透明;
  • 鼓励各方积极参与并出谋划策;
  • 确保可以听到不同的声音并对其予以尊重和纳入考量;
  • 确保提案内容在技术实施上是可行的;
  • 保证治理过程畅通并避免陷入僵局;

当前治理程序的分析与说明

在Trent的这篇文章中,他对适用于论坛讨论形式的当前治理流程进行了描述说明,并将提案流程列出如下:

论坛讨论 + 民意测验 > 链下快照/签名投票 > 完成代码开发工作 > 链上投票 > 链上部署执行

下面我将就每一个步骤进行单独说明。

论坛和Discord讨论环节

提案首先应该在Yam论坛或Discord频道上公开发表。Trent的文章对这一环节进行了说明,原则上发表提案应该遵循论坛提供的模版格式并包含投票测验,在提交到链下快照投票(Snapshot)环节之前,针对该提案的讨论应至少持续3天。

将提案提交到链下快照投票并不需要针对该提案的讨论或投票具有特定或明确的答案,讨论环节目前依赖于参与的社区成员能够遵守上述规则。

链下快照/签名投票环节

此环节仅通过社会共识产生效力。

先决条件

一般预计该提案已经在Yam论坛或Discord上进行了为期3天的讨论后,并且“社区对该提案显示出兴趣”,这一规则的落实是社会共识所认可的。

提交条件

提交提案门槛:不少于100枚初始发行数量(BoU)YAM;

票数定额门槛:不少于20万枚初始发行数量(BoU)的YAM投出赞成(For)票;

链下快照投票(Snapshot)环节本身没有限制最短或最长的投票期限,但当前Yam文档规定的投票期限为3天。目前该规定并没有明确这3天期限是否可以和讨论周期相重叠,或是必须在讨论期限之外延展3天,但无论采用哪一种方式,这个3天期限的规定也都是得到社会共识所认可的。部分Yam核心团队成员具有隐藏/移除快照提案投票的权限,但当前有关移除快照提案投票的规范标准尚未得到明确。

在二选一式(Yes/No)的提案投票中,通过一方须不少于50%的得票数。但对于具有多个选项的提案投票,关于如何衡量得票数量权重这一点尚未得以明确。在此前的投票中,如果其中一个选项达到票数定额即被认为是该选项获得通过,并且以均值作为投票结果。

如果该提案需要对现有合约进行修改,或是部署执行新合约,则会在链下快照投票(Snapshot)与最终的链上投票(on-chain)两个环节之间进行相关的代码开发工作。如果该提案的实施在此期间发生了变化,则无需重新提交链下快照投票。

如果该提案不涉及代码相关工作,则该提案一旦获批即为最终执行方案。

代码开发环节

先决条件

链下快照投票(Snapshot)获得通过,就表明该提案内容已经取得社会共识,同时可以以最小的风险完成相关开发部署工作。

目前开发工作主要由项目的核心开发人员负责,同时核心开发人员也会根据治理提案的重要性和时间敏感性来确定开发优先级。一些治理举措需要投入大量的时间进行开发部署,并会根据需要执行审计程序,开发人员时间严重不足正是当前开发部署复杂治理提案的主要瓶颈。

链上投票环节

此环节通过以太坊链上取得共识生效。

先决条件

链下快照投票(Snapshot)已获得通过(达成社会共识)。

所有代码相关开发工作均已完成并准备好实施部署。

标准治理投票

提交提案门槛:不少于5万枚初始发行数量(BoU)YAM;

票数定额门槛:不少于20万枚初始发行数量(BoU)的YAM投出赞成(For)票;

投票期限2天(约12345个区块高度);

投票结束后有12小时的锁定期限;

如监护人(Guardian)认为该提案属于恶意提交行为,则监护人可以在此60小时(投票期限+锁定期限)内的任何时间终止该提案;

通过须不少于50%得票数。

贡献成员报酬投票

提交提案门槛:不少于2.5万枚初始发行数量(BoU)YAM;

票数定额门槛:不少于10万枚初始发行数量(BoU)的YAM投出赞成(For)票;

投票期限3天(约18514个区块高度);

投票结束后有12小时的锁定期限;

如监护人(Guardian)认为该提案属于恶意提交行为,则监护人可以在此84小时(投票期限+锁定期限)内的任何时间终止该提案;

通过须不少于50%得票数。

任何满足上述要求的人都可以提交链上投票(on-Chain),链上投票甚至可以无需经过之前的任何环节即可提交。提交后该提案是否通过则完全取决于是否达到票数定额并获得多数赞成票,除非监护人(Guardian)认为该提案属于恶意提交行为并对其予以阻止。目前有关如何界定恶意提交行为的规范尚未得到明确。

当前治理程序存在的问题和疑虑

  • 如果发起方拥有足够数量的YAM,就可以跳过链上投票之前的所有环节直接发起链上投票。由于提案存在被否决的可能性,并且监护人(Guardian)拥有最终否决权,所以这其实算不上是一种有效的攻击手段,但它确实有可能会破坏治理程序运作的所依赖的社会共识机制。
  • 如果可以实施部署的人员数量受限,那么代码实施部署就会成为一个过于中心化的载体。另一方面,向外部开发人员开放与代码有关的工作又会增加潜在的安全风险。一个折衷的考虑方案是,特定提案的代码开发和审核工作由核心开发人员负责,以降低上述风险
  • 提案中有关代码部署实施的花费和审计费用通常未被考虑和列明,难以查询到相关数据。
  • 如果一个提案在代码开发期间(即链下快照投票和链上投票两个环节之间)需要做出重大更改,此时又无需重新提交链下快照投票(Snapshot),针对这一情况所带来的风险,目前暂时没有相应的治理处理程序。
  • 在链下快照投票(Snapshot)环节,二选一式(Yes/No)的提案投票具有明确的票数定额及通过规则,但目前针对其它类型提案投票的通过标准没有明确的规定,这部分的相关规则应予以阐明并获得批准。
  • 由于创建链下快照投票(Snapshot)只需要持有100枚初始发行数量(BoU)YAM代币,或是取得同等数量的授权委托,这可能会造成链下快照提案被滥用,或是同时创建某一提案的多个不同版本并造成混淆,从而破坏投票过程。这就需要核心团队采取行动,如隐藏/移除快照来避免这种情况的发生,而目前有关此类措施的规范尚未被明确。
  • 在论坛讨论环节和链下快照投票(Snapshot)环节,有关讨论时限和投票时限是累加还是叠加的规定尚不明确(具体是3天讨论 + 3天投票,还是讨论 + 投票共3天)。
  • 在提案以及链下快照投票(Snapshot)阶段,核心团队成员或其他社区成员应具备哪些权力来对社会共识原则进行监督管理?
  • 我们该如何判定一个提案在进入投票环节前,已经经过了充分的讨论?如果一个描述不足或是其内容不可能完成的提案被提交并表决通过,我们该如何处理?

We don’t seem to be getting much discussion about governance here. Maybe Ross if you can boil down your questions into polls? Basically a list of polls to get people’s opinions?

  • Would you like a list of poll questions to help decide on governance structure?
  • No Thanks Let’s just Discuss It.
  • I’d like the team to decide on all options then present it to community for vote.

0 voters

There hasn’t been a lot of discussion here so I will post some of my thoughts on answers to the issues I posed. These are my thoughts and not an official view of the team.

This issue speaks to our need to solidify our social consensus around off chain the governance process. All the process before an on chain vote is the way in which we assure that we are making good decisions for YAM and limit controversial actions.

See previous comment. The fact that the social consensus can be skipped is something we can use for emergency votes though. But this itself must live within our social consensus layer as an understanding of when it is acceptable to skip steps and how we go about determining that. Anything that does not fall within these guidelines can then be vetoed by the guardian without controversy.

In order for a proposal to be deemed a final proposal that can get a binding snapshot vote, it must contain specification information that includes what kind of development work is required and whether treasury funds will be needed to pay for audits or other expenses. I recommend that all proposals that get to the final step of the governance process either be approved by a member of the core team to verify that the proposal can be completed and explain what they think the development load will be, or propose that this work be completed by an outside team and provide funding estimates in the proposal.

If a proposal changes materially between what is in a proposal and is voted upon in a snapshot vote, these changes should be made clear as soon as they are known to be necessary. Either a new snapshot vote should be done to approve these changes or the on chain vote to approve this proposal should not be included with any other proposals.

Final snapshot votes should be performed as Yes/No votes. Any votes to determine weighting or distribution should occur prior to this final vote and the information obtained is what will be voted upon as a Yes/No vote.

I have a bold proposal for this. I would like to make the ability to create a final governance proposal limited to a specific group of YAM holders, while at the same time increasing the number of people who have an expanded role in YAM governance. We want the YAM community to feel empowered to help govern the DAO, and rewarding those who are active and contributing is a key element of this. I propose that we create a new internal group of contributors who have more access to the core team, additional mod powers in the discord and access to additional channels, and the ability to submit Proposals. This group should be flexible and it should be possible to become a member by hanging around and adding value. We do not want this group to serve as gatekeepers, but as ambassadors and helpers who will guide the governance process. Since anyone in this group can submit a proposal, non-group members can still submit ideas to “proposal brainstorming” and other locations on the forum, and if it can gain the support of one of these members or a member of the core team, they can help shepherd the idea into becoming a proposal.

In my mind, the speed of governance should not be the driving factor in our decisions. As a DAO, we are limited by our structure. Changing this structure fundamentally changes who we are, so we should try to understand where we can offload decisions that need to be made fast to those we feel comfortable empowering to make those decisions. This is what we are doing with YDS. The DAO does not move at a speed to make fast investment decisions so we are entrusting that power to our YDS investment manager and setting guidelines and guardrails for them to follow.

The base governance layer of the DAO should be making decisions for things that will be happening in the next quarter or the next year and not in the next week. Giving ample time for community members to come to understand the system and trade-off of decisions is important and as a DAO we cannot expect that everyone has time every day to commit to YAM.

assuming the rules are clear and have been ratified by the governance process then the core team and other community members tasked with making sure governance is running smoothly should feel empowered to enforce those rules. At the same time, there should be a process in which those who feel like they have been treated unfairly can have their voices heard.

Requiring specifications for the work to be done and either core team support or a commitment to get outside devs to do the heavy lifting is a start in this regard. In the end, voting on a proposal is what will determine outcomes, but we want to make sure that all constituents have an opportunity to make their voices heard.

I hope some of you governance nerds out there can chime in about what you think of these issues and others that I may not have thought of.

Yes, I agree or before it even get to this process, have a discussion with a team member to see what the current dev resources are, what and how the idea can be accomplished.

This might be a bit limiting but you had an idea that I really liked which was having “seconds” on proposals where anyone making a proposal would need someone to second their proposal. Seconds on proposals could be a group of community members that are familiar with the governance process and overall workings of Yam.

I think our ideas are very similar. This group of YAM community members are the “seconds.” Basically, in order for a proposal to move from “proposal brainstorming” to “proposals” category it needs a “second” who will make sure that it is crafted properly and meets the requirements. Making “seconds” the group that has access to create posts in the proposal category fulfills this requirement while relying on less moderation overhead (i.e. you and me having to close a bunch of posts that don’t have “seconds”).

from a purely practical note, the term “second” may not be the best as it has a second (haha) meaning and could get confusing in translation. Maybe something like “ambassador” or “facilitator” would be a better term.

1 Like

Somehow missed this very important discussion.

Some thoughts from my side:

  • DAOs might be new relative kind of economic organization, but has a large dependency to software development and therefore a strong overlap with open-source project governance and proven OSS best practices .

    • As reference for an OSS setup in the blockchain space I like the Baseline protocol as a good example: Open Source Community - Baseline Protocol (heavy enterprise IT stuff :nerd_face:)
    • In this case it might be an interesting exercise to translate the Baseline specification- and technical-steering committee to the YAM DAO setup.
    • The Zenhub Dashboard looks quite neat as well, would assume something like this is the prerequisite to manage exponential growth:
      Specifications Steering Committee - Baseline Protocol
  • Within the overall governance- and software-development process, I think there is in general room for improvements between the snapshots votes (or general DAO governance project) and changes to the GitHub repository.
    For example:

    • There could be some kind of technical integration between Snapshot votes and GitHub. I’m thinking of three aspects:
      • Manual mapping of GitHub commits and pull-requests to Snapshots votes. This could help to match the DAO governance process to the software development aspect, e.g. which artifacts were changed or created in GitHub for a certain Snapshot vote.
      • This is more like a brainstorming mode, but ideally there would be some technical integration between snapshot votes and github. For example some kind of approval process aligned with the snapshot vote and changes to the repository.
      • Or some kind of snapshot for a technical governance board to approve changes to the repository.
1 Like

Thanks for the thoughtful response! I will dive in to Baseline a bit.

Upon a quick browse the one thought I have is that it may be more “institutional” than we currently need. Baseline’s goal is to create a protocol that can be used by numerous large institutions and they will therefore want say in how it is governed. While that is similar to YAM, it is at a much larger and more corporate scale than our current needs.

To your second point, tie ins with Github are probably a good idea, but I will need to defer to the more technical members of the team who are using github day in and day out to determine how this is best achieved. As many non-technical members are probably not super versed with Github, we should make sure that it doesn’t become a requirement to use until it is needed. And that there is support to guide people through that process when it arrives at that point.

FYI, there is a governance meeting tomorrow (12/31) at 6:00 UTC if you would like to join. More details will be posted to the discord when they are worked out.