When Labels to act as custom date fields
Problem to solve
Feature parity with other DevOps plan phase tools which have custom date fields. Instead of adding a custom field to the database, we make a fancy “when” label which can either be a normal label or a scoped tag. If it’s normal, then it’ll add new dates to the same label for each. If it’s scoped, it’ll have 1 date that changes when the label is updated.
The tough part will be sorting, filtering with date math, and building useful reports.
We may also be able to use date fields to expose when a related MR was created, accepted, or the first successful pipeline.
Parker may use it for deciding which features are stale or interesting. If an issue tracks how often a certain failure stage happens and an API keeps adding these failure tags, it could be very helpful.
Delaney may use it for getting better cycle analytics than the built-in reports. If teams who have certain lag metrics outperform others, being able to capture those for the user’s organization would be very helpful.
Sam May use it for vulnerability reporting. Often just knowing about a vulnerability is insufficient to identify and measure the risk.
In Jira, you can say “make a new field that stores the day a vulnerability was identified” this may or may not be the day the issue was created. Then when they’ve closed the issue, they can find the lag time between when it was found and when it was fixed. While fixing it, the developer may note the code that caused the vulnerability and look at the commit that resulted in that vulnerability. They could add the
date committed and add additional data for risk management.
Putting values in
Rather than the unsupportable idea of adding database fields or the hacky method of creating an XML schema that attaches to each issue and carries around the extra data, we can leverage the built-in labels and by adding an optional date value, provide the ability to track dates.
Without having looked at the implementation, I’d guess that the following user inputs would create reasonably useful labels.
when~failedwould create a “failed” label with the current date. If there already was one, it’ll add another with the current date.
when~failed@2019-04-01would set it to April first. Maybe pop up a calendar helper when they get to the
when~~first seenwould create the scoped date and set it to now or update the previous “first seen” value to now.
I know tilde is already used for labels so replace that with whatever character or combination makes sense. I think confluence uses
// to start typing a date field so
when~threshold passed//2019/5/14 might be more familiar for some folks.
Whichever pattern is used, it needs to be available in:
- issue list label adder
- issue page label adder
- quick actions
- label API
- merge requests
- Maybe epics
Getting value out
So now we have all these date tags all over the place...
Issue list should be sortable by each
when labelin ascending or descending order.
The search issues should be able to do date math on the
Search and sort epics and MRs by
The issue boards should be able to have date ranges applied to the columns for individual or multiple label.
Epics and merge requests should have the date labels shown in a calendar view. Epics could have for all the children issues as selectable. MRs could show the progression of related issues along with its own dates.
Permissions and Security
Any user who can modify labels could modify these. If we start creating a label permissions model to only allow supervisors or security teams to modify labels, i would hope these are included.
Depending on the pattern selected, it could impact existing projects. Might make sense to escape any presently in the database or have an option to disable the
when labels which can be set to disable for these projects and default to enabled for the rest of gitlab.
What does success look like, and how can we measure that?
If we see gitlab.com users starting to add when labels, that would mean its successful. Certain clients have requested custom fields and when pressed typically come up with dates as the counterexample to labels.
Also, cycle analytics may be able to make use of them to store measurements like when a commit or merge leads to a failed deployment or poor performance (or a revert).