(v1.3 Revised 15 Oct 2020)
What is a Papercut?
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 bug 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 must be clearly specified using the appropriate Github templates
So you want to get a Papercut into the pipe? here’s how …
1) Get agreement on your suggested change
To maximise likely success in getting to the pipe, you should reduce as much uncertainty as possible before creating the papercut. This means making sure that others are on board with your proposed change and that there is clear agreement on implementation.
You may wish to create a Wishlist item in Discourse first and lead a discussion to refine the Papercut sized piece of work (incl. requesting a dev to t-shirt size it).
When the proposed change is clear and a dev has indicated that it is likely papercut sized . .
2) Create an issue on the Papercuts list
by adding an issue to the ‘Potential Papercuts’ column of the Papercuts project.
The issue must be clearly specified using the appropriate Github templates
3) Assess validity as Papercut
When we have room for more papercuts in the pipe, a ‘Papercut Curation’ meeting will be held with one person from Dev, one from Product and one from Design to do a quick run through of all the Proposed Papercuts to select those that make the cut for ‘Next Up Papercuts’ (participation in these meetings will be rotated)
There are three possible outcomes for each Potential Papercut
a) It meets the criteria above and can be selected for voting - move it to ‘Next Up Papercuts’
b) Needs design input and this design input could be done in 2hrs or less - move to ‘Papercut Design’. To be a valid papercut with required design input we would need to be confident that after the design input the dev task will still be a papercut. If we can’t be confident of that then it is likely not a papercut and will be rejected.
c) If a Potential Papercut is rejected we will move to ‘Rejected Papercuts’. Rejected papercuts will generally have a comment that explains why. If you make the necessary changes (or ask someone to help you) then afterwards feel free to move back to Potential Papercuts column.
4) Instance Selection of Papercuts
Every active* instance will be given the option to choose one Papercut from the list of Next Up Papercuts OR Papercuts Design.
Choose a papercut by adding your instance label to the papercut issue (as we did for s3 bugs).
Once selected these will be moved onto the Papercuts Backlog in Zenhub OR the Design / Inception pipe for those that require design.
NB. Design will not happen until a Papercut has been selected by an instance to progress. When design is completed on a papercut it will be moved into the zenhub Papercuts backlog.
Currently we have defined active* instances as: Australia, UK, France, Belgium, Katuma, Canada, US.
We have based this on who is contributing and who is trading.
If anyone thinks that their instance should also be on this list please say so. We can expand this list on the next iteration of this process.
5) Papercuts are delivered
Each release one Papercut will be completed. The order in which this happens is semi-random - with some discussion at Delivery Train meetings. If you believe there is a strong case for yours to be prioritised above others, please post your rationale in Slack #delivery-train
This is an ongoing experiment. Please add your thoughts on what you like and don’t like below so that we can keep improving the process
If you create an issue you’ll have to choose one of them.
! I’m sooo looking forward to this
