Problem
Pagoda no longer has the mission directive or resources to maintain the Wallet Selector product. This is currently a critical tool in the ecosystem utilized by 90%+ of dApps. It allows the user to designate which wallet they prefer to use and remembers that selection. It is vital to maintain NEAR foundation’s mission of supporting a wallet-neutral platform.
Ongoing responsibilities will include;
- Onboarding new wallets.
- Regular marketing comms around new wallets.
- Oversight and maintenance of the public Github repo.
- Oversight of pull requests for standards, compatibility, and quality.
- Outreach within the community for devs to participate in new features and ongoing maintenance.
Proposal
The Onboard DAO (OD) has expressed interest in owning and organizing the maintenance of Wallet Selector. We propose giving the OD full ownership and responsibility for the Wallet Selector. They are the group currently organizing wallets and securing funding for various onboarding initiatives.
The OD will need to vote on this proposal to officially take ownership of Wallet Selector.
Once the vote is complete and ownership passes to the OD, any and all admins from Pagoda will be removed from the repository. Pagoda will no longer be responsible for the maintenance or improvements of the Wallet Selector. Additionally, the OD will take ownership of the package on NPM.
Council members should be given full admin permissions to the open Github repository and the NPM repository. The OD will be responsible for oversight and organizing community teams to maintain and upgrade the Wallet Selector.
A budget should be approved and funds granted to the OD for the costs associated with maintenance and for the incentive for community members to maintain or upgrade the Wallet Selector.
The OD will put in place the resources and processes outlined below to ensure the ongoing availability of the Wallet Selector. Any replacement or sunset of the Wallet Selector project will include informing the NDC and seeking approval from the NDC to ensure the support of a wallet-neutral ecosystem.
The granting of ownership to the OD includes the agreement to these limitations, resources, and processes.
Resources
The following personnel should be considered for consistent oversight and management of the product.
Project Oversight
The council of the OD will oversee the product and any projects related to the product – including maintenance. It is suggested for major breaking changes that the repo be configured to require a certain number of council members to approve a pull request.
Cycle Administrator
The CA will oversee the regular cadence of triaging defects, pruning the repo, and helping the engineers and council prioritize changes or fixes. They should help organize reviews and default to async communication using ticket comments or documents. The CA is a facilitator and organizer and should defer all authority to the OD council.
The Cycle Administrator will keep a spreadsheet to track hours worked and at what rewards are earned. The weekly average price of NEAR tokens should be included in this spreadsheet for each week of rewards. The sheet should be available to all participants to edit and viewable by the community.
Principal Engineer
The Principal Engineer should endeavor to become the subject matter expert on the Wallet Selector.
The Principal Engineer is responsible for the review of pull requests ensuring they adhere to best practices, standards, and quality. They will triage incoming defects for validity, priority, and severity. They will keep the repository pruned and call regular reviews of the repository by participating members. All merges should require a minimum of one review by either the Principal or Sr. Engineer.
Sr. Engineer
The Sr. Engineer will act as a backup resource to the Principal Engineer. They will strive to gain expertise on the Wallet Selector. They can help with the pull request workload, repo pruning, and triage of defects. All merges should require a minimum of one review by either the Principal or Sr. Engineer.
Plan For Maintenance
Terms
Selected = work on these in the current cycle.
Backlog = keep in the queue to work on in a future cycle.
In Progress = always choose this status when something is being worked on. This can be the initial work or rework based on reviews.
In Review = when an item is ready to be reviewed. This issue should have a corresponding pull request(pr) ready to review.
Blocked = there remains outstanding coding issues, decisions, or upstream problems blocking the completion of the ticket.
Complete or Closed = pr merged and deployed
Task = issue type. For tracking tasks within a project.
Defect = issue type. For issues or problems within the product or project.
Feature Request = issue type. For requesting an enhancement for the product.
Project = issue type. As a “top level” issue to house task lists tracking the completion of a project.
Repository Configuration
- The Repository should be linked to a Github Project with a Kanban board so the public can quickly assess progress. The columns should consist of Selected, In Progress, In Review, and Blocked.
- One tab of the project will be the Backlog. Tickets in this status are waiting for a new cycle selection.
- One tab of the project will be Completed. This will house all closed and completed tickets for easy reference.
- One tab will contain Decisions, a special type of Issue that documents for discussion any major decisions under consideration for the project. Github discussions can be used like a forum for the community to discuss. Once a Decision is complete, one or more Issues (Tasks) can be created for required changes / fixes.
- Any new Defects submitted should be given a status of Triage. A tab will be created to show these defects in Triage. Once defects have been triaged, they can be either moved to Selected or Backlog.
Processes
Decisions
- When disagreements arise about changes or information is lacking to make a pertinent decision, a special type of issue should be created to document the decision to be made.
- This Decision should then house all major ideas, challenges, and potential solutions.
- Discussion of a Decision can be housed in the discussion forum for the repo / project.
- Once a Decision has been made, the issue can be closed.
- These Decisions should remain in the repo in closed status for future reference.
Issues, Features, & Defects
- New defects should be immediately reviewed by one of the engineers for validity and severity. Comments should be made on the ticket for reference.
- A weekly cadence will be established where participants will review the current submitted defects in Triage status. The triage process should determine priority for newly submitted defects. Once the reviewers determine priority, they can then be changed to Selected (work on right away) or Backlog (work on in the future).
- New feature requests can be reviewed in the same process as defects. Engineers should first review in Triage for validity and complexity. Comments should be made on the ticket for reference.
- A regular cadence will be established for engineer resources to review all outstanding PRs. In some cases this might require more frequent reviews for times of increased submissions. The minimum suggested cadence is once a week.
- In the event of major changes, the Principal Engineer should call for a review of the change in questions. A minimum quorum of council members must include comments as to their approval or opposition to the change. If approved, the Principal Engineer can schedule and plan a merge.
- Major breaking changes should first be communicated to the community so changes can be made to accommodate the major breaking change.
- Major changes should be limited to 2 in one cycle. Care should be taken to avoid change fatigue in the ecosystem. Care should be taken to avoid breaking other dependent apps or wallets.
Releases & Cycles
- A regular cadence of cycles should be determined to coordinate changes, fixes, and releases. The repo should be configured to utilize these cycle durations for easy reference by the community.
- All releases should follow a defined process whereby environments are used to “stage” changes for testing. The release should first be made to TESTNET and stay there for a specified amount of time. Once everyone is happy with the functionality and quality, the release is pushed to MAINNET.
- This time could be a couple days for a less impactful change to a full week for a major breaking change.
- Care should be taken that all releases have a rollback plan to quickly reverse a release in the event it has any unintended impact on the ecosystem.
Compensation
- Rewards will be calculated and dispersed weekly.
- A spreadsheet will be created that is viewable to the public and editable by participants.
- Hours worked will be tracked on the spreadsheet.
- Columns will be available to track approvals by the council. A minimum of two approvals will be required to validate rewards per participant per week.
- The weekly average price of the NEAR token should be tracked on the spreadsheet for easy reference.
- Amounts paid will be in NEAR tokens = to the dollar amount (US) earned that week.
- The council should pay all rewards by Wednesday of the following week they are earned.
Budget Guidelines
Rewards will be paid in NEAR tokens equivalent to dollar amounts per hour; averaging the NEAR price across the week of hours worked.
To begin, the monthly maintenance cost should be approved and distributed monthly. This will have a cost between $590.00 to $1,380.00 per week in NEAR. The cost is dependent on activity for the Wallet Selector.
As projects for maintenance or new features are proposed, the council will need to approve and request additional funding. New features or upgrades will be submitted on a per-project basis for individual funding. Some estimates for these projects is included in the budget sheet below.
See Spreadsheet for budget breakdown.