# Pulp Team and Kanban

Thoughts In My Brain on how we can implement kanban using GH functionality.

Mission Statement: this proposal (like any good software process proposal) aims to meet the following requirements:
* It should be easy to know what the team should work on next
* It should be easy to know what the team is working on now
* It should be easy to know where there's a logjam
* It should be a smooth ride from "stakeholder requests a feature/reports a bug" to "end-user receives working code"

If we miss any of these points, then we need to hit the process with a hammer until we fix it.

## Kanban Review
* Kanban is a pipeline
* "Backlog" is the issue-source, and can be arbitrarily large
* things "being worked on" go through the fix-pipeline in stages
* typical stages might include:
* "work on next"
* "being worked on"
* "being evaluated"
* all stages have a "maximum allowed entries" limit
* nothing can move into a maxed-out stage, unless something else leaves it
* if/when a kanban team experiences a bottleneck (e.g., "nothing can move to evaluated because there's too much there already"), the team "swarms" onto the bottleneck
* this means "everyone drops what they're working on and moves to clearing the bottleneck"
## PROPOSAL for Pulp
What follows is a first-thought of the "stages" that make sense for us as a team, given how we are currently operating. I've tried to post queries for "seeing" what's in each stage; the limitations of the GH search syntax has been surprising, alas.

Draft PRs make things complicated. My current thought is "the process IGNORES DRAFT PRs", if such a thing exists it's between whoever opened it and whoever they might have asked to look it over. It's probably worth having a 'stage' that is "all draft PRs", with its own limit, to push us to "make it official, or close it, don't leave it around forever".
### Stages
* **backlog**
* DEFINITION: unassigned, not tagged prio-list, issues
* ENTRY-TRIGGER open an issue
* EXIT-TRIGGER add prio-list label
* QUERY: https://github.com/issues?q=is%3Aopen+is%3Aissue+org%3Apulp+-label%3Aprio-list+no%3Aassignee+
* **prio-list**
* DEFINITION: unassigned, tagged prio-list, issues
* ENTRY-TRIGGER: add prio-list label
* EXIT-TRIGGER: get assignee
* QUERY: https://github.com/issues?q=is%3Aopen+is%3Aissue+org%3Apulp+label%3Aprio-list+no%3Aassignee
* **in-progress**
* DEFINITION: assigned issues
* ENTRY-TRIGGER: set assignee to issue
* EXIT-TRIGGER: linked, not-DRAFT, PR
* QUERY:
* from github search page: 'You cannot search for issues and pull requests that have any assignee'
* **BLOCKER**: you can't search on an "OR" list of assignees
* **waiting-evaluation**
* DEFINITION: PR that has no reviewers
* ENTRY-TRIGGER: open a not-DRAFT PR
* EXIT-TRIGGER: not DRAFT, has reviewers
* QUERY: https://github.com/pulp/pulpcore/pulls?q=is%3Apr+linked%3Aissue+is%3Aopen+no%3Areviewer
* **under-evaluation**
* DEFINITION: not-DRAFT PR, with assigned reviewers
* includes "ready to merge but hasn't been yet"
* ENTRY-TRIGGER: add reviewer to a PR
* EXIT-TRIGGER: merge or close the PR
* QUERY:
* from github search page: 'You cannot search for issues and pull requests that have any assignee'
* **BLOCKER**: you can't search on an "OR" list of assignees
* **waiting-release**
* DEFINITION: merged-PR, not yet included in a release
* ENTRY-TRIGGER: merge a PR
* EXIT-TRIGGER: release the branch
* QUERY:
* **BLOCKER**: can't figure out how to github-search for "PRs in a release"
* NOTES
* would be good to have this per-repository-per-release-branch?

The limits to GitHub's search syntax are definitely in the way of driving this "by query". If we can use the "triggers" noted, then once we have an initial project-board, we can perhpas manage this automatically using the project-board-API. I haven't dug into what's available there too much.

We could have a label for each stage, and have the trigger apply the correct label? Feels like it's just asking for the label and the actual reality to get out of sync - e.g., "this PR has no reviewers but is marked as 'under-avaluation'"

### Limits
The way the larger Pulp team is organized makes "limits" more complicated than with a more typical, single-focus, team.

In the abstract case, stage-limits can be directly tied to team-size - you shouldn't have more things being-worked-on, than you have people to do-the-work. Pulp has a lot of repositories, a lot of "mini-teams", and a LOT of overlap where a given person can (and does) work on multiple teams at the same time.

This can be (and has been) further complicated by change-requests coming in unevenly - sometimes a large number of issues come in against a single problem-domain that has a limited number of SMEs that can address them. The people on the Pulp team are not interchangeable, everyone has their own areas of expertise, and while we strive to learn All The Things, every problem opened is going to have a subset of the team that is best suited to work on it. This can result in a limit to how effective "swarming" is.

We're also in the unenviable (and yet entirely inevitable) position of receiving out-of band emergency assignments from stakeholders that are expected to get done regardless of what our process says.

All of which means "the suggestions below are at best a first-guess". We shouldn't spend too much time on the initial proposal - I expect we're going to adjust limits A LOT as we learn how best to make this process work for us.

#### Assumptions
* There are 13 developers on the "Pulp Team"
* rchan and ttereshc do NOT count, they have full-time jobs that don't include code :)
* It is a fact of life that all of us work on more than one thing at a time.
* I am going to set an arbitrary limit of "nobody can be doing more than **tw** things at once".
* Working on code takes more time than reviewing it (generally - there are defintiely exceptions)

#### Proposal
* backlog
* arbitrarily large, "stale" process is the ultimate limiter
* prio-list
* 13 (team size)
* in-progress
* 20 (team size plus, people work on more than one thing at a time)
* waiting-evaluation
* 10 (pushes us to get reviewers assigned)
* under-evaluation
* 13 (pushes us to complete reviews and merge)
* waiting-release
* prob some number tied to number of repos? per repo? unclear to me