Update how Plan frontend works with the `Open` column
This follows !28138 (merged) and a discussion that happened on Slack (https://gitlab.slack.com/archives/C72HPNV97/p1566908929453300):
full discussion on Slack
donald:speech_balloon: 1 day ago
Should we move issues that are scheduled in 12.3 but still on the validation track out of 12.3? @Gabe Weaver @Keanon O'Keefe
Gabe Weaver:gitlab: 23 hours ago
No we should surface how to move them through the validation track quickly :slightly_smiling_face:
:+1:
1
winnie 5 hours ago
@donald should we add extra columns for the validation labels in the frontend board as well? Otherwise somebody else (apart from me) may miss that they are not ready for implementation. :thinking_face:
(https://gitlab.com/groups/gitlab-org/-/boards/654688)
GitLabGitLab
Boards · GitLab.org
Open source software to collaborate on code
winnie 5 hours ago
or alternatively: can we have workflow::blocked on everything that still has validation::...?
donald:speech_balloon: 1 hour ago
Ideally we get to a point where only items marked workflow::ready for development are ready for implementation. Do we need more things in that column?
Gabe Weaver:gitlab: 1 hour ago
The goal is to not have any workflow:: label until it is workflow::ready for development. We need to have a single set of workflow:: scoped labels to indicate that an issue can only ever be in 1 state across our product development flow
winnie 1 hour ago
In the open column there are currently
issues that are ready for development (but don't have the label) for example Combine frontend and backend testing level documentation
issues that are not ready
issues that are in validation::... state. (edited)
winnie 1 hour ago
should we (as developers) always ignore the open column and rely on the workflow::ready for development to have stuff?
Gabe Weaver:gitlab: 1 hour ago
yes. If you see an issue that is "ready", add the to schedule label so I know that its ready and can prioritize it. We're slowly trying to work towards practicing Kanban. If you aren't familiar with it, the video / primer here is useful - https://www.digite.com/kanban/what-is-kanban/ .
DigiteDigite
What Is Kanban? :books: Comprehensive Overview Of The Kanban Method
Kanban is a visual system for managing work as it moves through a process. It visualizes both the process and the actual work passing through that process.
Aug 18th, 2018
(68 kB)
https://d30s2hykpf82zu.cloudfront.net/wp-content/uploads/2019/03/Daily-Tasks.png
winnie 45 minutes ago
If you see an issue that is "ready", add the to schedule label so I know that its ready and can prioritize it.
by prioritize you mean let it bubble up in the open column or add the workflow::ready for development label?
winnie 42 minutes ago
just to be clear: there is more than enough stuff in the workflow::ready for development column right now
so I may have brought up a non-problem :slightly_smiling_face:
Gabe Weaver:gitlab: 42 minutes ago
No this is awesome.
donald:speech_balloon: 39 minutes ago
should we (as developers) always ignore the open column and rely on the workflow::ready for development to have stuff?
not completely. There can be issues that are in the open column but are workflow::in dev (backend engineer has started working on it
donald:speech_balloon: 39 minutes ago
Tried to list out steps here: https://about.gitlab.com/handbook/engineering/development/dev/fe-plan/#picking-something-to-work-on (edited)
Gabe Weaver:gitlab: 38 minutes ago
The basic flow of an issue during its lifecycle starts with being open, then it should move through the steps outlined here - https://about.gitlab.com/handbook/product/categories/plan/ - with each step having a label. You use the "Plan Frontend" Issue Board, and I use the Plan Kanban board that mirrors the desired flow of an issue - https://gitlab.com/groups/gitlab-org/-/boards/1226305?&label_name[]=devops%3A%3Aplan
If something is Open and does not have workflow::ready for development, then it is not ready for development. However, if you think the issue is indeed ready for development, then add the planning breakdown or to schedule label so it can be prioritized. Prioritized issues get the workflow::ready for development label.
GitLab
Plan Stage
Code, test & deploy with GitLab. Everyone can contribute!(211 kB)
https://about.gitlab.com/images/blogimages/gitlab-blog-cover.png
GitLabGitLab
Boards · GitLab.org
Open source software to collaborate on code
:+1:
1
winnie 35 minutes ago
@donald thanks—I was aware of these steps but thought maybe we can more clearly separate "things to work on" from "things to ignore" in the issue board :slightly_smiling_face: (that is ideally have exactly one column to pick the next task from)
Also it seems like the steps don't 100% align with @Gabe Weaver's last message. I'm happy to create a merge request to adjust if you like.