Wallet Selector Maintenance & Positions
Request For Proposals
Overview
The OnboardDAO is seeking three individuals to hold paid positions with the OnboardDAO to lead and maintain the Wallet Selector Product.
Github Repo → https://github.com/near/wallet-selector
NPM Package → https://www.npmjs.com/package/@near-wallet-selector/core
Approved Proposal → Proposal For Ownership
Proposals can be submitted as individuals applying for one position or as a team applying for all 3 positions. If the council determines that the best proposals are from individuals, they will ask those submitters to form a team for the purpose of these requirements.
Positions
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.
Budget & Compensation
Budget
A preliminary budget has been approved. Listed below is the average hours expected and max hours allowed with listed hourly rates.
| Resource | Hourly | Avg. Hrs | Avg. Cost | Max Hrs | Max Cost |
| Cycle Administrator | $35.00 | 2 | $70.00 | 4 | $140.00 |
| Principal Engineer | $50.00 | 3 | $150.00 | 6 | $300.00 |
| Sr. Engineer | $40.00 | 3 | $120.00 | 6 | $240.00 |
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 OnboardDAO should pay all rewards by Wednesday of the following week they are earned.
Plan
A preliminary repo management and working process was drafted as part of the proposal.
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.
Requirements
- The maintainers agree to the base repo management and process outlined above.
- The maintainers agree that the project will remain open-source.
- The maintainers agree that major changes and new features will be coordinated with the Wallet Builders community on Telegram.
- The maintainers agree to list themselves as maintainers on the repo readme.
- The maintainers will behave and perform their duties with professionalism and empathy.
- The maintainers will create a focused Telegram channel for Wallet Selector based communications and announcements.
- The maintainers will inform the committee and community of major incidents, outages, or controversies.
- The maintainers will provide a weekly update in the Telegram channel of current tasks, issues, projects, initiatives, and overall progress.
How To Submit
Please make responses in this forum, as a response to this post. Please use the following template to ensure consistency → OnboardDAO Wallet Selector Template - Google Docs
Submissions will be open for 2 weeks starting from April 1st, 2024 and ending April 15th, 2024.