Skip to content

WalletConnect for Hedera: Repository Governance

Jump to bottom
itsbrandond edited this page Mar 18, 2024 · 3 revisions

Abstract

This specification outlines a straightforward governance framework for the community to oversee the maintenance of the WalletConnect reference library and related elements specific to Hedera. The framework is designed to encourage open discussions, facilitate group consensus, and lead to decisions that are transparent and clear to all involved. It also outlines how the group should be governed.

Motivation

As the Hedera ecosystem develops and the needs of wallets and decentralized applications (dApps) expand, WalletConnect for Hedera will require updates and improvements. It's important to establish an easy and transparent method for updating this helper library through voting. Additionally, we should ensure there are straightforward channels for community involvement in this process.

It's essential for dApps and community members to play a role in shaping WalletConnect for Hedera.

Rationale

The WalletConnect Working Group for Hedera, which includes key wallet providers, developed this library (along with WalletConnect RPC specifications and HIP-820) during its initial phase. This group established effective workflows and mechanisms to facilitate discussion, reach consensus, and make decisions. The specifications we have now are the result of these efforts. They reflect the community governance frameworks that were successfully established and tested by the original working group. It also allows existing wallet providers to seamlessly move forward with the community behind them.

This streamlined governance framework not only facilitates dApps and community members in offering practical feedback, but also enables them to actively propose and implement updates, fixes, and improvements.

Specification

The official Hedera Hashgraph Contributing Guidelines act as a parent to the specifications outlined below. These specifications act as a suggested framework for further development of this repository.

Roles

Maintainers

  • Wallet providers, Swirlds Labs and Hgraph
  • Providing support and service to the repository.
  • Approve pull requests (Hgraph will publish to NPM)

Contributors

  • Community members and projects who contribute to the WalletConnect for Hedera repository.
  • Fork and submit pull requests.

Contribution guidelines

Contributions to this repository follow the official Hedera Hashgraph Contributing Guidelines. We have highlighted a few key areas relevant to submitting updates to the WalletConnect for Hedera repo.

  • Issue types:
    • Bug, documentation or enhancement
    • If the update is sufficiently large, complex or requires coordination among multiple Hedera projects (a breaking change), it should first go through the HIP process (HIP-820)
  • Issue lifecycle:
    • Submit a ticket to start the discussion
    • Consider if it is a “breaking” or “non-breaking” change
  • Pull requests
  • PR lifecycle:
    • How to submit your update
  • Releases:
    • Hedera uses semantic versioning for releases

Community Engagement

Discussions:

  • Use GitHub Discussions or similar platforms for community engagement and feedback.
  • Leverage established group discussions in Slack and Discord.
  • Break out discussions into social media.

Regular Updates:

  • Keep the community informed about development progress and decisions.

Documentation

Maintain clear and comprehensive documentation for both internal stakeholders and the broader community.

Pull Request Approvals

Non-Breaking Changes

A non-breaking change is an update to the WalletConnect for Hedera repository that doesn’t affect integrations of wallets and dApps, doesn’t require coordination and is easy to revert.

PR Approval (3):

  • A wallet provider
  • Hgraph
  • Swirlds Labs

Breaking Changes

A breaking change is an update to the WalletConnect for Hedera repository that is sufficiently large, complex or requires coordination among multiple wallets and dApps or is hard to revert.

Additional steps for facilitating breaking changes:

  • First, determine if the HIP process should be used (a major new feature for example) and review the existing HIP-820 for an area of discussion.
  • If the HIP process isn’t appropriate for the breaking change, follow steps outlined in the issue lifecycle to submit a ticket in the repository.
  • Make stakeholders aware of the suggested breaking change. Formalize decisions on GitHub.
  • Utilize external meetings and communications for in-depth discussions and consensus-building.
  • Leverage social media and other public platforms to gather community input.

PR Approval:

  • Breaking changes should be handled differently.
  • A wallet provider should not engage in the approval of a breaking change without good documented consensus from other providers and the community.
  • It is advised to leverage the HIP process for these changes.

Voting System: Adding Approvers (Recommendations)

  1. Nomination Process:
  • Initiation: Any current approver can nominate a new participant.
  • Nomination Criteria: Clearly define the criteria for eligibility, such as being an active wallet provider in the Hedera ecosystem.

  1. Vetting Process:

    • Review of Nominee: Conduct a thorough review of the nominee’s contributions to the ecosystem, adherence to community guidelines, and overall reputation.
    • Discussion Period: Allow a fixed period for current voting members to discuss the nominee's qualifications and potential impact on the group.

  2. Voting on New Participants:

    • Voting Mechanism: Use a simple majority vote (over 50%) for the decision.
    • Voting Period: Set a reasonable time frame for voting to ensure timely participation.
    • Voting Method: Use GitHub polls.

  3. Onboarding:

    • Orientation: Ensure the new approver has all the information they need.

  4. Transparency and Documentation:

    • Document the nomination, discussion, and voting process for transparency.

Voting System: Removing Approvers (Recommendations)

  1. Criteria for Removal:

    • Established Grounds: Define clear grounds for removal, such as inactivity, non-compliance with community standards, or cessation of business operations.
    • Regular Review: Periodically review the participation and contribution of members to identify any potential candidates for removal.

  2. Initiating Removal Process:

    • Proposal: A removal proposal can be initiated by any voting member.
    • Justification: The proposal must include a clear justification based on the established criteria.

  3. Discussion Period:

    • Debate and Deliberation: Allow a fixed period for an open and transparent discussion among voting members about the proposed removal.

  4. Voting on Removal:

    • Voting Mechanism: Require a significant majority (e.g., 80%) to vote in favor of removal.
    • Voting Period: Set a reasonable timeframe for all members to cast their vote.
    • Voting Method: Use GitHub polls.

  5. Process Post-Removal:

    • Formal Notification: Notify the removed member formally and explain the reasons for their removal.

  6. Transparency and Record Keeping:

*   Documentation: Keep detailed records of the removal process for accountability.
Clone this wiki locally