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 Bugzilla (superseded by Phabricator in 2014) we had many statuses: https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla#Statuses
• There was a long discussion which statuses [not] to have when moving to Phabricator: T212: Decide which task statuses we want to have in Maniphest
• The simplified task workflow is currently covered in https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle

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).

In T288956#7286922, @Aklapper wrote:

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.

In T288956#7289337, @jeena wrote:

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?).

In T288956#7304332, @Aklapper wrote:

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.

👍 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.

Thanks everyone for the feedback, appreciated! I guess next would be someone cooking up a patch to update maniphest.statuses in https://gerrit.wikimedia.org/g/operations/puppet/+/refs/heads/production/modules/phabricator/data/fixed_settings.yaml#153 , and afterwards updating docs at https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle and https://www.mediawiki.org/wiki/Phabricator/Project_management#Assigning_tasks ?

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

In T288956#7349849, @Aklapper wrote:

Thanks everyone for the feedback, appreciated! I guess next would be someone cooking up a patch to update maniphest.statuses in https://gerrit.wikimedia.org/g/operations/puppet/+/refs/heads/production/modules/phabricator/data/fixed_settings.yaml#153 , and afterwards updating docs at https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle and https://www.mediawiki.org/wiki/Phabricator/Project_management#Assigning_tasks ?

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

In T288956#7349858, @Jdforrester-WMF wrote:

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

In T288956#7350247, @mmodell wrote:

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?

In T288956#7350410, @Jdforrester-WMF wrote:

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.

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.

In T288956#7355962, @mmodell wrote:

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.

In T288956#7355978, @mmodell wrote:

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.

In T288956#7355968, @DannyS712 wrote:

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'.

In T288956#7370524, @Zabe wrote:

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.

Thanks for adding this, @mmodell (and/or whoever else may have been involved). I have one minor issue; if you sort a workboard by status, the tasks that are set to "In progress" are shown after tasks that are Open and Resolved (see screenshot).
I think it would make more sense to show it at the very top, to highlight that this is what's actively being worked on at the moment. (I can file a separate task for this if you think that's better, of course.)