Page MenuHomePhabricator

Evaluate adding "In progress" status to Phabricator.
Open, In Progress, MediumPublic

Description

Currently, there is no reasonable status to assign to tasks that are actively being worked on - it seems like many statuses that we currently have are tracking things that are somehow rejected (some of them imho could be merged in example: “Stalled” could be a tag based on prolonged inactivity, “Declined” and “Invalid” could be just merged to “Won’t do”)  but nothing that would track something that’s in action. I can understand hesitance to overcomplicate, but I see nothing that could correspond to the “I’m on it” step of SDLC. I do see statuses as a high-level and shared, in contrast to the many different per-team workflows that engineering teams have and going through other workboards, almost every single one has some columns that are representing “In Progress” status just under different names. Having such a shared status available would also allow me to easily filter out things being actively worked on from both my and different boards, which is not possible currently.

Event Timeline

Thanks for filing this. I'd love to see more input on this proposal, for example from other teams if they see a similar need, and from the Release-Engineering-Team.

Sharing some background for everyone:

In an ideal world, I'd expect people to set themselves as assignee when they work on a task, and I'd expect a task not to have an assignee when someone is neither actively working nor planning to work on the task soon™. (I guess this can also be applied to setting such a new status.)

Indeed there is currently no way to differentiate between "I am working on this right now" and "I plan to work on this".

I assume the proposal also implies that a task with "In Progress" status should always have an assignee set?
When a task has several (team) project tags associated, could there be ambiguity when such new statuses "collide" between teams?

Ideally, I see statuses as rather high-level and shared, in contrast to the many different per-team workflows that engineering teams have. This diversity of workflows, plus having seen Bugzilla's complexity as a result of trying to serve many individual team workflows, is a reason why I'd like to first better understand the underlying problems to solve with using workboard columns to track progress, if these problems are common, and explore if there might be better solutions.

I'm open to adding additional statuses if several teams see it as the best solution for a common or shared problem (plus also discuss how to potentially migrate from workboard columns to new statuses, as WMF is notoriously bad in workflow change management).

Thanks for filing this. I'd love to see more input on this proposal, for example from other teams if they see a similar need, and from the Release-Engineering-Team.

I'll pass to @mmodell for more informed comment, but the intent here seems similar to T148805: Phab feature request: Cycle time for a task entering a column to resolution, with support for wildcards.

In an ideal world, I'd expect people to set themselves as assignee when they work on a task, and I'd expect a task not to have an assignee when someone is neither actively working nor planning to work on the task soon™. (I guess this can also be applied to setting such a new status.)

Indeed there is currently no way to differentiate between "I am working on this right now" and "I plan to work on this".

+1

I assume the proposal also implies that a task with "In Progress" status should always have an assignee set?
When a task has several (team) project tags associated, could there be ambiguity when such new statuses "collide" between teams?

Right, "in-progress" gets tricky when something is on multiple workboards: this is why so many teams have an "in-progress" and a "watching" column since a particular task can be both depending on perspective.

I would love to see an in-progress status so that I can know when something is being actively worked on.

I agree that assignment to a task doesn't indicates that someone is working on something. I find the assignment useful to see whether someone is planning to work on something (soon), so that I know whether or not I need to take action on it.

If a task is big enough to be worked on by multiple teams, I think it would benefit from being broken into subtasks. That would also alleviate the problem people might see with in-progress only applying to a certain team's work on a large task.

If a task is big enough to be worked on by multiple teams, I think it would benefit from being broken into subtasks. That would also alleviate the problem people might see with in-progress only applying to a certain team's work on a large task.

Fully agreed. Out of scope for this task (or is it?) but I would be a big fan of limiting task assignments to a single workboard at the time.

I'd like to see more input on this from engineering teams (as I prefer to implement things that are broadly wanted), and I admit that I don't know where this should be best brought up (maybe engineering mailing list and some walled Slack channel?).

I'd like to see more input on this from engineering teams (as I prefer to implement things that are broadly wanted), and I admit that I don't know where this should be best brought up (maybe engineering mailing list and some walled Slack channel?).

Foundation teams? probably the engineering-all list and the same-named walled slack channel. Also probably worth a check-in with WMDE.

Could someone who wants to see this please actively gather more input from other engineering teams on this task? Thanks a lot.

There are some benefits to having this as a status, from my perspective.

One benefit is that workboard columns can trigger status changes, but status is a more visible and easily searchable field. As stated in the description, it's not possible to search for in-progress across multiple workboards and there isn't a consistent way to express "start of work" which has enormously complicated my work for generating phabricator metrics and reports.

I'll try to gather more feedback on this as I believe it could be valuable for many teams workflows.

Platform Engineering is +1 on this, we use an In Progress column on our boards but we can incorporate the use of an "In Progress" status - this would be extremely helpful.

Research is a +1. We will need to do some updates to our current tasks, but collectively we can distribute and absorb the cost, and then enjoy the benefits.

greg added a subscriber: greg.

👍 from me.

I think this is an excellent addition. As teams attempt to reduce Work in Progress (WIP) it would be great to have a status that allows them to see what is currently being worked on.

Change 720811 had a related patch set uploaded (by Jforrester; author: Jforrester):

[operations/puppet@production] phabricator: Add 'In Progress' task status

https://gerrit.wikimedia.org/r/720811

I imagine we'd want @gerritbot to also state-change tasks into "In Progress" when a Patch-To-Review tag gets added?

I imagine we'd want @gerritbot to also state-change tasks into "In Progress" when a Patch-To-Review tag gets added?

Good idea! But we could avoid modifying any bots: the same could be done (most easily?) with a herald action.

What icon should we use?

These are the ones that jumped out at me:

  • tachometer
  • thumb-tack
  • play-circle
  • caret-square-o-right
  • fast-forward
  • step-forward
  • cogs
  • compass

You can see the full list here.

Opinions?

Oh I hadn't noticed https://gerrit.wikimedia.org/r/720811... That is unfortunately out of date / obsolete. Phabricator gets that setting from the database:

{
  "open": {
    "claim": false,
    "name": "Open",
    "special": "default"
  },
  "resolved": {
    "claim": true,
    "closed": true,
    "name": "Resolved",
    "name.full": "Closed, Resolved",
    "prefixes": [
      "fixes",
      "closes"
    ],
    "special": "closed",
    "suffixes": [
      "as resolved",
      "as fixed"
    ],
    "transaction.icon": "fa-check-square-o",
    "transaction.color": "green"
  },
  "stalled": {
    "claim": false,
    "closed": false,
    "name": "Stalled",
    "name.full": "Open, Stalled",
    "suffixes": [
      "as stalled"
    ],
    "transaction.icon": "fa-spinner",
    "transaction.color": "yellow"
  },
  "declined": {
    "claim": false,
    "closed": true,
    "name": "Declined",
    "name.action": "Declined",
    "name.full": "Closed, Declined",
    "suffixes": [
      "as declined"
    ],
    "transaction.icon": "fa-thumbs-o-down"
  },
  "duplicate": {
    "claim": false,
    "closed": true,
    "name": "Duplicate",
    "name.full": "Closed, Duplicate",
    "special": "duplicate",
    "transaction.icon": "fa-clone"
  },
  "invalid": {
    "claim": false,
    "closed": true,
    "name": "Invalid",
    "name.full": "Closed, Invalid",
    "suffixes": [
      "as invalid"
    ],
    "transaction.icon": "fa-trash-o"
  }
}

FWIW this would help with reporting on my end to better track work in progress. Apologies for commenting late to the party

Oh I hadn't noticed https://gerrit.wikimedia.org/r/720811... That is unfortunately out of date / obsolete. Phabricator gets that setting from the database

Should we delete it from Puppet then?

Should we delete it from Puppet then?

Some of the values in that file are still used but many are overridden in phabricator. I've been wanting to migrate away from keeping those settings in puppet for a long time but it's not quite straightforward to tell which are in use and which are not. It's made a bit more annoying by the fact that puppet uses yaml and phab uses json. If we were to keep the config in puppet I'd like to replace the yaml with json that matches phab's schema and then we could just copy the live config over the puppet config.

There are a couple of advantages to not using puppet, however:

  1. keeping private config private (random seed used by some hashing, parameters used by the antivandalism extension)
  2. Phabricator validates the config syntax and schema when you save. It prevents an invalid config from bringing down the service and presents you with the opportunity to fix the problem and retry the save.
    1. This is not the case when puppet applies an invalid config and I'm not sure how to implement the same level of validation via CI without some effort.
    2. It probably wouldn't be too difficult to figure out, however, it hasn't ever been a priority.

Apparently there are no strong opinions about the icon, I'm going to go with step-forward , we can change it if there are objections.

mmodell changed the task status from Open to In Progress.Sep 15 2021, 4:38 PM

Ok ^ you can see what it looks like above.

mmodell changed the task status from In Progress to Open.Sep 15 2021, 4:42 PM
mmodell changed the task status from Open to In Progress.
Restricted Application triaged this task as Medium priority. · View Herald TranscriptSep 15 2021, 4:43 PM

I don't think it makes sense that in-progress tasks would "need triage." therefore I added the above herald rule: If setting a task to in progress without setting the priority, it'll get set to medium priority automatically. Should that be high priority or is that a bad idea to have the herald rule prioritize it?

Maybe we should notify wikitech-l about this? I would tag as user-notice but this isn't for tech news

@DannyS712: sure, I'll write a quick notice to the list.

I don't think it makes sense that in-progress tasks would "need triage." therefore I added the above herald rule: If setting a task to in progress without setting the priority, it'll get set to medium priority automatically. Should that be high priority or is that a bad idea to have the herald rule prioritize it?

I don't think this is a good idea. It implies that people/teams using the new "in progress" status also actively use the priority field ("why is this task only medium????"), which is not always the case.

hmmm, well needs triage is the highest possible priority besides unbreak now. Medium is the same as "no prioritization" in my mind, but maybe others think of it differently.

hmmm, well needs triage is the highest possible priority besides unbreak now. Medium is the same as "no prioritization" in my mind, but maybe others think of it differently.

In my view it's not "second highest possible priority", it indicates that there is no priority set and for technical reasons it appears on the list as the second (but it could very well be the first or in the middle or whatever). I don't use the priority field on my CentralAuth work and I don't want Herald going around and implying to others that I do if I (or Gerritbot or another Herald rule) starts using the new status value. Perhaps the priority should be named something like "No priority set".

I've disabled the herald rule.

Maybe we should notify wikitech-l about this? I would tag as user-notice but this isn't for tech news

Email sent.

Change 720811 abandoned by Jforrester:

[operations/puppet@production] phabricator: Add 'In Progress' task status

Reason:

https://gerrit.wikimedia.org/r/720811

Change 721384 had a related patch set uploaded (by Legoktm; author: Legoktm):

[labs/tools/wikibugs2@master] Add new \"In progress\" status

https://gerrit.wikimedia.org/r/721384

Change 721384 merged by jenkins-bot:

[labs/tools/wikibugs2@master] Add new \"In progress\" status

https://gerrit.wikimedia.org/r/721384

Btw tasks set to "in progress" are not visible on the main page at 'new tasks', like tasks set to 'stalled'.

Btw tasks set to "in progress" are not visible on the main page ate 'new tasks', like tasks set to 'stalled'.

That's been fixed.