Tidy up labels in this repo

[iteles]

A lot of the labels in this repo were created in 2015, before our official list was created, but some of these are super useful (I very much like having a docs label for example).

Aim: Bring some consistency to our labels and determine if any should be removed.

Tasks

• Compare labels with https://github.com/dwyl/labels
• Make suggestions in this issue
• Update labels

[iteles]

• Labels unique to this repo I propose we delete:

  • - We have an MVP label already, we're only using that terminology for now
  • - We will eventually have a version of this label but I don't think this is useful in it's current form (or colour - which is the same as our time estimates colours). I propose we delete it for now and re-create something more fit for purpose as needed.
  • -Everything that is not in the MVP label will be post-MVP and GH now has more advanced organisation features (projects and milestone prioritisation) that invalidate the need for this label

• Labels unique to this repo I think should stay:

  • API: we will undoubtedly need this in the near future given the architecture of the app
  • docs: useful so that we know when there is something that just needs to be added to documentation (if deemed relevant) vs being a feature request, such as EU Employees Must Track Time by Law #229, Do time management apps really make people more productive? #225 or Six easy ways to manage your time better (Nature) #226
  • investigate: this is particularly useful when there are articles like in Do time management apps really make people more productive? #225 where the PO might want to look into things a bit more or if there's s technical question that requires further thought like Is it a necessity to have an append only database? #227
  • MVP: I'm in two minds about this one because it will quickly become deprecated as we come out of 'MVP' and then we'll have a label we don't use stuck in our system forever. However I propose we keep it in because:
    • Using a label for this is better than a milestone because the 'MVP' tag is lost the second you move the issue into a sprint milestone and therefore you lose clarity
    • We will in future have 'MVP's of different features whenever there is a new one so I think we will keep using this label
  • nice-to-have: will absolutely be needed to allow us to keep using this repo for ideas and not just core features
  • UI: In the same way we will need API, UI is an obvious keeper for me - it quickly allows us to determine whether an issue is deeper than UI-level and which skills will be needed

• I've already updated the colours for the following labels which existed here and were part of our standard dwyl labels but had a different colour (for consistency): chore, discuss, priority-4, priority-5, technical

• Delete duplicate external-dependency label:
  

• Change colours/format of the following labels:

  • - change colour as it's the same as the NiceToHave label
  • - change to kebab case to match other labels

Note: I've had a thought about and propose we keep this in for now. There may be some investigative or testing tasks that would make sense to pass to a Virtual Assistant.

@nelsonic @SimonLab Any thoughts on the above proposed changes? Anything you don't think should be done?

[nelsonic]

@iteles while I'm a fan of simplifying/streamlining and agree that there are labels that can be removed, Post-MVP can be safely be removed but it's worth capturing why we had it in the first place, it was to help us focus on the features that we considered necessary for MVP.
I agree that we can achieve the same aim by simply ordering the issues on the Project board. #238
If an issue is toward the bottom or not on the board it's not a priority.
[ alpha ] can safely be deleted. ✂️
Front End could be replaced with UI/UX but I think we need to have a clear labelling system to indicate when an issue is related to the interface that people using the app see/feel.
MVP can be removed if we get our Project Workflow nailed #238 it will be obvious what is "MVP".
NiceToHave or nice-to-have can be denoted by applying a priority label e.g: priority-4
meaning we will get to it eventually ... the original reasoning for the label was to denote a feature/idea that was not essential but would be nice-to-have in the future. Perhaps we could simply apply the discuss label to ideas that we aren't sure need to be included in the product so that we don't hurt anyone's feelings by applying a super-low priority (essentially "killing" the idea).
If we completely remove the NiceToHave label, then it won't matter what color investigate is. I think yellow #fbca04 is a good color for it, perhaps a green #1bffc5 could work too as it's an "action" color, feel free to propose an alternative. 👍

@iteles you have final say on this so just make the changes you deem necessary
and document your reasoning in case anyone is curious/confused in the future.

[SimonLab]

I think the UI/UX label is often used with the API or another "backend" label as a change in UI often requires first a change on the backend. Applying both of these labels was a bit weird but I can see it can be useful in some cases.

Otherwise the list looks good 👍
Would be great to check after a few sprints (or we could already check on the other dwyl repositories) which are the most/less used labels this could help us to iterate on some label names maybe

[iteles]

Done!

[iteles]

Reopening this as there is definitely some clarification needed with regards to prioritisation labels at least, as exemplified in #243:

[nelsonic]

@iteles in my mind priority-5 is where ideas go to die;
it's the label equivalent of saying "Yeah, that's nice but it's never gonna happen..."
In the case of #243 "Gamifying" interaction to promote good habits, is an excellent UX that we should figure out how to include soon in order to help people form/maintain good habits and replace bad "infinite scroll" (anti/social) apps.

[iteles]

@nelsonic This is exactly why I re-opened this issue, because it was very clear that we have different utilisations/ideas of labels.

The issue that the team was having was that opening a bunch of issues that are not fully formed, in spite of a low priority was causing all kinds of interruptions due to the un-differentiated importance given to Github notifications.

We have just discussed this verbally and concluded that priority labels will only be applied to:

• Issues that are complete and ready for development (i.e. have a good description, UX and acceptance criteria)
• Issues that are imminent (within the next 1 or 2 sprints)

I'm happy to trial this and formalise it.

Furthermore, we have determined we need two new labels which will help the team understand whether issues are half-baked ideas (very low priority) or need attention a little sooner:

• needs-criteria: This label denotes that the issue still needs acceptance criteria to be added to it and is not ready yet for review/work to be started
• needs-ui: This label denotes that the issue still needs wireframing to be added to it and is not ready yet for review/work to be started

---

NOTE: The below has been superseded and is no longer relevant, but is written here for information purposes.

For the record, my view of priority labels (and usage up until this point) was as follows:

• priority-1: there should only ever be one of these at a time and they are 'drop everything and work on this' type emergencies
• priority-2 and priority-3: MVP features, required before user testing can begin
• priority-4: Features that will definitely be implemented but not until after the first iteration of the MVP
  • These are reviewed weekly by the Product Owner before sprint planning of the next sprint to determine whether any need to be moved up in priority
• priority-5: Features that are good ideas but they need more discussion and are not definite implementation features
  • These are reviewed monthly by the Product Owner to determine whether any need to be moved up in priority

[iteles]

Leaving this issue open until this has been documented.