near-wallet issues triage (discussion)

[stefanopepe]

Want to discuss a framework to triage inbound issues, and more efficiently queue them into our daily activities.

Currently, NEAR Wallet work is split between two macro-areas: build new features and improve existing features.

1. Building new features is organized via near-wallet-roadmap repo and comes from discussions that involve strategy, market dynamics and, overall, NEAR's vision. New items in the roadmap come "top-down" from stakeholders and conversations with experts. In the most recent iteration, anyone can submit a new feature request, but this is still experimental and preliminary. This is out of scope from this specific thread
2. Improving existing features is organized via issues in this repo, and includes a large number of cases - from mere bugfixes to enabling functionalities that weren't included in the first iterations of certain features. Here, new items come "bottom-up", and are mostly issues opened here. This is what is being discussed here

If we do only 1, we can stick our product to NEAR vision and we are constantly on top of the community trends, but no one can build the perfect feature on the first try, so we can't only build new features and then leave them to their destiny. Given that NEAR Wallet is a very young product, some features are still at their "version one", and still need some "2" to better fit users' needs.
On the other hand, if we do only 2, we iterate a product that does very well what is built for, but we would end up offering something that is not really covering the community's needs and express NEAR's potential. Here, we did great with the functionalities displaying the available balance, while we are still working on improving the onboarding flows.

The problem I want to solve, starting from this thread, is how to properly prioritize the "2", in a way we can predict any impact on "1".

Solutions proposed below:

1. Objectively measure the priority of inbound issues
2. Estimate issue complexity and associate it with epics, initiatives, and themes
3. Queue them in the two-week-sprints and measure the original estimation

Disclaimer: nothing is decided yet. This is async grooming where anyone is free to drop their opinion and concerns. We need lean useful processes loved by everyone using them, not useless bureaucracy. UX reigns here too!

1. New issues: Measure and Estimate

We currently have 4 labels to define priority:

• Priority 0 - URGENT: Drop everything to address this issue
• Priority 1 - Top Priority
• Priority 2 - Important
• Priority 3 - Not urgent

The idea is to associate objective parameters that can escalate the priority, such that every inbound issue is default Priority 3 and increases based on certain criteria, such as:

1. number of users potentially impacted (can be absolute, or relative to the total of NEAR Wallet users)
2. number of support tickets that might have been avoided or resolved
3. the experiences touched by this issue, from @corwinharrell's Wallet Critical Paths
4. if the issue is blocking/disrupting one or more of these paths (yes/no)
5. if the issue can be added to any planned/existing effort
6. how old is the issue

NOTE: scope down any analysis/concern to the criteria above and not the list below. Having a good set of parameters can make the list below more accurate and easy to understand.

We might "render" the criteria above it into some general rules (below some examples):

• if the issue impacts >80% of the user-base, the priority 3 is -1 and becomes priority 2
• if the issue impacts account creation, third-party app login, and reduces users' available liquidity (including account recovery) it's -1 and can stack to others - so >80% and app login experience becomes priority 1
• if the issue is not blocking/disrupting any of the three experiences above can be only >0
• if the issue is blocking any of the three above AND impacts >80% of the user-base becomes instantly 0
• if the issue has the label security and impacts >80% of the user-base it's -1
• if the issue is present on more than 20% of the last 15 days of tickets it's -1
• if the issue can be included in a currently run epic or initiative, it's -1

Rules can be potentially infinite, that's why it is important to discuss good criteria to back them.

---

The part below is only to introduce the final result and raise concerns on the overall process, rather than discuss the single elements

---

2. Estimate issue complexity and associate with existing activities

I will keep this lightweight since it will be discussed later on: once we have the priority of an issue, we need to measure its impact on our time.
We currently have some labels that help with that:

• blocked -
  Cannot proceed until dependency is met
• bug -
  Something is not working as it should
• duplicate - This issue or pull request already exists
• good first issue - Good for newcomers
• help wanted -
  Extra attention is needed
• needs design - Requires discovery and/or deliverables from Product Design
• new feature - A new feature that comprises a new user flow or new & robust functionality.
• translation - Changes to application messaging that require translation
• user story -
  User story to be implemented

Let's leave this part of the discussion for later (after we found good triaging rules), but overall these tags will help the team to decide who is the best owner to this specific issue.

Along with these categories, I will propose to adopt the Epics, Stories, Themes and Initiatives framework, with:

• epics that will use the standard GitHub logic, and will list the associated issues
• stories defined within the list of acceptance criteria in the issue
• initiatives as milestones (see here)
• themes as additional labels, e.g. today we have security, but I expect to have more in the future, e.g. "from zendesk"

Ideally, knowing the owner, the epic/initiatives, and the number of stories/acceptance criteria should be enough to estimate the impact in terms of time and resources of a given issue.

3. Queue the issue with existing initiatives and milestones

This is also preliminary, but the idea is to batch inbound issues into the right initiatives, and keep them there until we launch one or more "sprints" to complete these initiatives.
This will close the loop:

• an initiative may contain multiple issues with key improvements to one single experience (e.g., "recover existing account")
• an initiative may be the collection of low priority bugs
• an initiative may be the expression of a feature that we have here

Still, worth some discussion, by now I put it here to help you understand where I want to go with this job.

---

This discussion is open for comments. Ideally:

1. comment the overall process of measuring priority -> estimate the impact -> queue to initiatives
2. review the priority criteria that I've put together, and provide ideas
3. help me simplify: we are a small team and less is more

Thank you 🙏