# Single priority list (DECOMISSIONED IN FAVOUR OF https://hackmd.io/@ggainey/kanban_thoughts)

## Motivation
To avoid picking a task which is potentially not the most important item to work on, to avoid asking a specific person about the next thing to work on.
Various folks will benefit from having a single, up-to-date priority list across Pulp project.
Unless you lead a specific area and work only on tasks in this area, a single priority list will be helpful for you.

## Challenges
* keep the list up to date
* low maintenance

## Proposals

### Proposal 1 - create at sprint planning
* ~~before sprint planning **mini-teams prepare tasks** which should go to the upcoming sprint~~
* ~~it depends on priority and some areas of pulp might be under more pressure/load than the others, but on average it should not be a lot, e.g. **a couple of average size tasks or 3-4 small ones**~~.
* ~~in the ideal world, a task which go on the sprint will have its **priority set**. Priority is for the sprint only and in relation to other tasks within a plugin.~~
* ~~at sprint planning when we discuss what is being worked on and share some priorities, we also mention those tasks, in case there are some concerns or competing priorities. No discussion in detail, that should happen at mini-team meeting prior to the sprint planning if neeed.~~
* ~~**tasks are marked with Sprint label** (Sprint label is removed from open tasks for the old sprint)~~
* ~~anyone who picks up a new task has to take it from this list~~
* ~~at triage time, mini-team evaluates if the incoming bug has higher priority than the ones on the sprint and depending on that puts it on the sprint or not~~

### Proposal 2 - lighter version of Proposal 1

* unify a label across whole pulp org - for example - `sprint`
* each mini team in prep for the sprint planning meeting would be identifying issues that should go onto the upcoming sprint and mark them as such
* each mini-team would take the responsibility to keep issues that have this label up to date ( ready to be worked on and priority wise)
* Propose this is a single miniteam lead or their delegate/backup if they are out?
* during sprint planning meeting look at the query across whole pulp org containing `sprint` label and ensure there is a list of issues with a reasonable number. Define a limit for that list, for example 10. If the list exceeds that number we cut on it. The KEY DIFF is we do not discuss any of those items at sprint planning at al, just agree that it is too long and offline take off items.
* anyone who picks up an item from the list has to assign themselves
* for the issues incoming in between 2 sprint planning meetings mini-teams evaluate if the incoming issue has higher priority than the ones on the sprint and depending on that puts it on the sprint or not

### <Your proposal here>

### bmbouter comments
* Proposal 2 is very much what I imagined with a few additions
* Have use do the review actually in GH issues. If we want some way to export the data to take a snapshot that's ok, but let's make the GH list the actual list.
* Have the number of unnasigned items per mini-team be no more than 3 (or maybe 5?). The idea is to really focus on the right things. If that number goes down because items are being assigned, mini-teams (or their leads) can put more items on.
* Don't have triage be the time to put on the sprint or not, it creates recency bias. Instead have the reduction of the unassigned issues on the sprint be the triggering event.

Reached agreement on:
- have a org wide label "prio-list"
- limit number of in-progress tasks, undecided how many
- limit number of ready-to-work tasks, undecided how many
- each mini-team marks their tasks prior to the sprint planning

AI:
- add to docs
- find a short video as intro to Kanban
- look again into GH projects