Report, understand and prioritize unmet needs

How do we process unmet needs (problems) reported by users that are not yet satisfied by the platform?

1- Needs collection and understanding

When a need that is currently not satisfied by the software is reported by a user, the user can submit a new item in our wishlist repository. When clicking on "New Issue" a template is provided to guide on how to report the need.

Most of the time, the reporter of the need will not have all info when they start the discussion about their request. When discussions move on, the curators of the discussion will update the main post to always keep the specification of the need up-to-date. Some solution candidates might come up and one option might be quickly chosen in the discussion.

WARNINGS: Users often tend to express their needs as solutions or features ("I would like a new button here that will let me do this thing...") and won't explain clearly the need behind it ("I'm having trouble finding this thing and it's one of the most frequent things I do"). It is the responsibility of the local instance product owner to understand the underlying need, and express that need in a structured way, before starting to brainstorm on potential solutions.

2- Needs priorization

Many OFN users in different countries have different needs. So how to decide which need we address first?

Each instance will have their way to discuss with their users and decide together with them what are the top priorities for their instance. We have experimented voting on features but this process did not really lead to spot the features that we really needed to do first. We are currently reviewing this system.

The current prioritized pipe can then be seen in Github but also in our community forum. Once a week the delivery circle will issue notes in the community forum that keep everyone updated of where things are.

3- About "emergency needs"

Some users sometimes express their need as an "emergency need". We invite instance managers to question why it is an emergency. In OFN we consider as emergencies only bug severity 1 and 2 that really prevent users to use the platform. If you consider an unsatisfied need (i.e. a feature request) an emergency, you can create a topic on our community forum to discuss it.

4. - Papercuts

A Papercut is a tiny issue - usually UI or UX - that is never a high priority but causes lots of pain to users. It might be a small bug or a missing bit of UI. It might be issues we tend to always hear about from users but do not have direct implications on the actual functionality and thus never make it into the priority list. It might be things that we look at and think “Ergh is this still not fixed?” or “%^&* that is SO ANNOYING”. We might have been looking at it for years.

We want to fix some of these so that we start bringing real joy to our users. Fixing Papercuts is designed to bring sparkles in a world that often has few.

A successful Papercut (that can be considered for development) is an issue where:

• The dev work required will take less than 1/2 day to complete

• The solution is obvious and widely supported - if there is uncertainty, outstanding differing opinions, or takes more than 5 mins discussion to agree on what is being done, it will be rejected as a papercut

• The issue is clearly specified

The papercut team meets every first Wednesday of the month, in order to review the candidates column of the wishlist repo and assess what can be considered as a papercut. Confirmed papercuts are labeled as such in the wishlist repository and are available to core instances for selection at a regular pace (as soon as all papercuts are delivered, someone from the papercut team launches a new round of papercut selection).