Page MenuHomePhabricator

Add support for task types
Closed, ResolvedPublicFeature

Tokens
"Like" token, awarded by Zoranzoki21."Love" token, awarded by Jdforrester-WMF."Love" token, awarded by Tobi_WMDE_SW."Like" token, awarded by Jonas."Baby Tequila" token, awarded by mmodell."Baby Tequila" token, awarded by KLans_WMF.
Assigned To
Authored By
Fjalapeno, Mar 22 2015

Description

Members of the org are using Phab for track many types of tasks - some that I have seen are: Features, Bugs, Stories, Goals, and Epics.
Moreover we will track multiple types of tasks within the same project (Feature/Bug/Epic comes to mind).

It would be good if we had a field to support these different task types.

Having task types would allow us to:

  • Represent types differently on project boards (think different colors, different sizes, styling)
  • Filter for a specific type of task in search (I am just looking for bugs)
  • Support different fields for different task types (Bugs have a field for "Steps to Reproduce", but features do not. Features have "story points", goals do not)

A good concrete example of this request is JIRA issues:

https://confluence.atlassian.com/display/JIRA/What+is+an+Issue

This may be a prerequisite for T92708 which aims to support specific fields for bug reporting.


Status quo as of 2016-05-27

tagtask / creatornote
Epichistory unclear
Storycreated by @Lydia_Pintscher
CategoryT119459: Create Milestone tagused to be #milestone change discussed in T129684: Rename "project" and "Milestone" in Phlogiston to something else; milestones available now as parts of projects
SpikeT138380: Reading teams would like a tag to identify spikes
TechCom-RFCcreated by @Lydia_Pintscher
Tracking-Neverendingimported from Bugzilla
GoalT127007: Create a generic #Goal tag
#bughistory unclearalias to archived Bug-Report which existed only 20 days back in 2014
#feature-requestnothing relevant exists (per T109492#2026281 and T109492#2029518 WorkType-NewFunctionality is not the same)
Roadmaphistory uncleararchived
ReleaseT99143: Create a generic "Release" tag in Phabricator
Regressionhistory unclear
TestMeimported from Bugzilla

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

@mmodell In regards to @MBinder_WMF's question and the spirit of the I opened the task:

One of the primary motivators of having task types is to the able to treat tasks differently. See the other task I opened: T92708: Add fields to support bug specific information In this case, the power of having a task type (rather than a tag) is so we can display different fields. Maybe we can display other tasks differently (it would be nice to be able to quickly differentiate between an Epic and a bug on a Phab board) or as Max is suggesting having an easy drop down filter button.

But to Max's point, if we can't filter on all "bugs" because some were tagged and can never be converted to the new task type that effectively makes this feature not useful since we can't be sure if it will show all bugs.

@Fjalapeno suppose we could convert them, how would you identify which ones to convert?

@mmodell for iOS there is a tag: iOS-app-Bugs
Android has a tag: Android-app-Bugs
I see there is also a generic Bug-Report tag.
Would these work?

mmodell added a comment.EditedOct 11 2017, 8:30 PM

@Fjalapeno Yes but there obviously will be some tasks which aren't covered by the tags. The generic Bug-Report tag is archived and no longer used afaik.

that effectively makes this feature not useful since we can't be sure if it will show all bugs.

My point was that you'll never be sure it will show all bugs because there is no reliable way to identify all bugs.

mmodell removed mmodell as the assignee of this task.Jan 31 2018, 8:13 PM
atgo added a subscriber: atgo.Apr 9 2018, 11:05 PM

Hi @mmodell ! I'd like to use "deadline" tasks, and I see that they're tagged as such in the workboard view. What would be more helpful is if the deadline (date) appeared there rather than the task type. For tasks without a deadline there could be nothing there. This is how other similar tools I've used have represented deadlines and it's been really helpful to seeing at a glance where we are against deadlines.

Is this possible? Something I should ask upstream about?

Hi @mmodell ! I'd like to use "deadline" tasks, and I see that they're tagged as such in the workboard view. What would be more helpful is if the deadline (date) appeared there rather than the task type. For tasks without a deadline there could be nothing there. This is how other similar tools I've used have represented deadlines and it's been really helpful to seeing at a glance where we are against deadlines.


Is this possible? Something I should ask upstream about?

I'll see what I can do.

atgo added a comment.Apr 9 2018, 11:12 PM

Thanks @mmodell! Much appreciated.

mmodell added a comment.EditedApr 10 2018, 2:31 AM

@atgo:

I should be able to get this deployed on wednesday.

atgo added a comment.Apr 10 2018, 8:33 PM

@mmodell this is great! One thought... it might make more sense to have tasks that have a longer deadline be something neutral/not eye catching, and then escalate to orange and then red as they get closer. The idea behind that is that you can scan the board and see what deadlines are at risk.

Also, is it possible to set up notifications to the folks who are assigned to those tasks as a deadline approaches? We could set the rules to do a reminder 3 days before or something.

Thanks so much!

@mmodell this is great! One thought... it might make more sense to have tasks that have a longer deadline be something neutral/not eye catching, and then escalate to orange and then red as they get closer. The idea behind that is that you can scan the board and see what deadlines are at risk.

The current scheme is as follows:

DeadlineColor
In the pastGrey (with faded text)
Within 1 dayFire (red-orange)
Within 2 daysOrange
Within 5 daysViolet
Beyond 5 daysGreen

I can adjust those colors only slightly, phabricator has built-in styles for those colors plus "indigo", "yellow", "black" and "white" which I didn't use because they didn't look very nice. Yellow lacked contrast, white lacks a border, black looks fine but it's a bit bold compared to the others.

Also, is it possible to set up notifications to the folks who are assigned to those tasks as a deadline approaches? We could set the rules to do a reminder 3 days before or something.

Currently there isn't a straightforward way to do notifications.

atgo added a comment.Apr 10 2018, 9:58 PM

Thanks @mmodell. Bummer about the notifications, thanks for letting me know.

If I might make a suggestion, this might be more intuitive, since I'd think a missed deadline would be something folks would want to be alerted to.

DeadlineColor
In the pastFire (red-orange)
Within 2 daysOrange
Within 7 daysGreen
Beyond 7 daysGrey
atgo added a comment.Apr 10 2018, 9:59 PM

Also, what is the behavior if no deadline is set? IMO it should display nothing there.

Thanks @mmodell. Bummer about the notifications, thanks for letting me know.
If I might make a suggestion, this might be more intuitive, since I'd think a missed deadline would be something folks would want to be alerted to.

DeadlineColor
In the pastFire (red-orange)
Within 2 daysOrange
Within 7 daysGreen
Beyond 7 daysGrey

+1 this makes sense to me. If a task is due and then the deadline passes, it's useful to know that it had a deadline and was not resolved, and that doesn't necessarily mean that the task can't still be done (and grey implies that missing the deadline means the task is no longer urgent).

I know that that "Bug" form stamps a task with [BUG], and that if a task has that and then the user changes their mind, it can't be removed. Would there be any such issues with Deadlines and this visual implementation?

atgo added a comment.Apr 11 2018, 12:16 AM

@mmodell that looks great and makes a lot of sense to me. Thank you!

I know that that "Bug" form stamps a task with [BUG], and that if a task has that and then the user changes their mind, it can't be removed. Would there be any such issues with Deadlines and this visual implementation?

The same applies except that I sort of cheated my way around it in the code - if the deadline is removed from a task then the code still executes but it produces an invisible box instead of the word "DEADLINE." So it's effectively removed, at least for all practical purposes other than a tiny bit of overhead on the server.

@atgo: It's deployed. You'll have to edit the due date on any previously created tasks before it'll show up, due to a configuration problem. All new deadlines should show up on workboards and at the top of task detail pages.

atgo added a comment.Apr 12 2018, 1:11 AM

AMAZING THANK YOU @mmodell!

@mmodell, this is great functionality! I was curious if it's possible to customize the browser tab / window title? When a user clicks our "bug report" link, the task form page shows with "Create Deadline" in the window title which may be confusing for a user only wanting to enter a simple bug. Thanks!!

@Niedzielski Can you think of a better label? It should be unique to distinguish it from the regular task type. Maybe "Create urgent task" would be a little better? "Create Task with a due date" seems a bit too verbose.

greg added a comment.May 9 2018, 8:12 PM

"urgent" might confuse people with "priority" (eg UBN!). :/

mmodell added a comment.EditedMay 9 2018, 8:13 PM

@greg: Good point. I'm really unsure maybe it should just be Create Task ... I really don't know if it should be a separate task type at all (other than the major reason which is that most tasks don't have due dates)

Love the discussion here. :)

A few teams have adopted this task as their new default, because it offers everything a standard task does plus the Deadline option. Because of that, I like the idea of simply labeling it "Create Task", as @mmodell suggested. That would relieve the issue @Niedzielski brought up, and I don't think it's so wrong to cause big issues (the biggest I can think of is that there would be 2 forms that are similarly described).

ok I changed it to just say "Create Task" in the form title. I'm also looking into the possibility of hooking into the calendar system to implement deadline notifications (via email / phabricator built-in web notifications)

That would be super cool, I've definitely heard at least one use case for
that. :)

Upstream just added the ability to change task types after the fact: https://secure.phabricator.com/rPc5b13a6be3b7262c49635ceade437345a02de2cc

mmodell claimed this task.Jun 30 2018, 12:05 PM

D1074 will add the ability to set task types from herald rules.

atgo added a comment.Jul 10 2018, 5:48 PM

Hi @mmodell. Would it be possible for Due Dates and their changes to be logged in the revision history of the task? This came up recently with some due date vandalism, and would also be useful for visibility into the history of a project.

@atgo: I'm actually not sure why the aren't logged. I'll see what I can do.

I filed (non-public) T198671 about due date handling.

It would be great to be able to split Story slightly into 2 subtags, such as "tech-story" and "feature-story" for example.
The WMDE teams would currently really appreciate being able to do this.

@Addshore Some teams will make Milestones in tags like Technical-Debt , such as https://phabricator.wikimedia.org/project/edit/2296/ (Phab wouldn't autocomplete #RW-Tech-Debt for some reason). I don't know if it would solve all your issues, or if it would be acceptable, but theoretically you could make a pair of milestones within Story and call them "WMDE-Tech-Story" and "WMDE-Feature-Story". I think we could also have those as generic (i.e. just "Tech-Story" and "Feature-Story" Milestones), but that might also introduce confusion that would be mitigated by making them team-specific. :)

Is there any way to change task subtype manually? I think we should document this new future properly on MediaWiki.org really soon. I guess most people don't even know that these feature exists and if/how they can use it.

In the mid-term, I think we should proactively assign these subtypes to tasks already created. There might be some bulk editing that can be done with Tasks prefixed with [BUG] or that are positioned in some appropriate workboard columns to handle major parts of this.

Furthermore, I think we shouldn't add too many of them, to avoid collisions when we would like to assign multiple subtypes at once. As far as I can see, this is already partly the case with Deadline tasks, which can be feature requests, bugs, administrative requests and so on.

mmodell moved this task from Backlog to Working on it on the User-MModell board.Sep 10 2018, 4:58 PM
mmodell added a comment.EditedSep 20 2018, 10:56 PM

@MGChecker: The only way to manually change types is using the batch editor. There is also the possibility to build herald rules which either react to the type or set the type based on other criteria.

Regarding multiple subtypes at once: That isn't possible. If a task belongs to more than one type then it should really be split up into multiple tasks. I can probably add the deadline functionality to all task subtypes to avoid that being a problem.

@MGChecker: The only way to manually change types is using the batch editor. There is also the possibility to build herald rules which either react to the type or set the type based on other criteria.

Are there any plans upstream to allow changing this with the normal task edit form in the future? Really seems like a missing feature to me…

@MGChecker: no I don't think so. Changing task types shouldn't be the norm and some changes would break things so it really shouldn't be on the normal task edit form.

But if we want to actually replace the mentioned projects with task types, I think such a functionality would really be needed, as after all these task types are especially useful if they are applied consequently to our tasks (especially looking at Bug and Feature request here).

What could break by changing task types given our current set of task types?

@MGChecker: any custom fields which belong to one type would be lost when converting to another type. Converting a release task to any other type would completely break the release schedule and "task series" navigation (the prev / next links on each train release)... It would just be broken in multiple ways.

MGChecker added a comment.EditedSep 21 2018, 9:59 AM

@MGChecker: any custom fields which belong to one type would be lost when converting to another type. Converting a release task to any other type would completely break the release schedule and "task series" navigation (the prev / next links on each train release)... It would just be broken in multiple ways.

Couldn't this problem be circumvented by just allowing to add a subtype (e.g. changing it from the default?) This should satisfy the main use case without causing too much trouble.

Couldn't this problem be circumvented by just allowing to add a subtype (e.g. changing it from the default?) This should satisfy the main use case without causing too much trouble.

That would address many of the problems. Can you provide an example of when you would want to do such a thing? That might help me understand the need better.

Well, currently most tasks don't have any defined subtype, even tough suitable subtypes exist for many of them. This greatly reduces the usefulness of this future, as you can't really use it to filter tasks by type (Bug, Feature requests, etc.) Currently, some projects use Workboards to satisfy these needs, but these aren't universal, which reduces their functionality greatly when considering Phab as a whole. Furthermore, this adds a new global dimension of sorting tasks (additional to status, priority, etc.), so these Workboards can be used to map different categories of tasks in the future.

Some configuration I think would be suitable:

  • Trusted-Contributors should be able to assign subtypes to existing tasks. As this isn't easy to undo, there should probably be a restriction in place.
  • When creating a task using the simple creation form, users should be required chose a subtype, defaulting to task.

When creating a task using the simple creation form, users should be required chose a subtype, defaulting to task.

I'd not want this option shown for all and any users. Adds just more clutter to the UI and for some users everything is a bug while it's a feature for PMs and devs.

debt added a subscriber: debt.Dec 13 2018, 7:22 PM
Alroilim removed mmodell as the assignee of this task.Feb 2 2019, 7:12 PM
Alroilim updated the task description. (Show Details)
Alroilim removed subscribers: debt, SBisson, kostajh and 29 others.
Scott updated the task description. (Show Details)Feb 2 2019, 8:47 PM

Yay, upstream https://secure.phabricator.com/T12314 is resolved and according to https://phabricator.wikimedia.org/phame/post/view/145/phab_phebruary/ we now have task types here. :)
The Change Subtype dropdown currently offers for me:

  • Task
  • Bug Report
  • Deadline
  • Feature Request
  • Release
  • Goal
  • Administrative Request
  • Security Issue

Not sure what that means for our workaround so far of using tags like Goal, Release, etc.

Can / should this task be closed? Are more things wanted?

jmatazzoni added a subscriber: jmatazzoni.EditedFeb 28 2019, 6:27 PM

In T93499#4991791, @Aklapper wrote:

Can / should this task be closed? Are more things wanted?

CommTech would like to see the following subtypes:

  • Spike
  • Design

Is that possible?

Just wanted to say that I love that we can also filter/search for tasks on subtype! :-D

@jmatazzoni ok, what special features do these task types need? Are you just wanting them for categorization? In that case it might make more sense to use 'tag' type projects to group them. Task types enable custom forms but it takes some setup to configure them and I'd rather not create a bunch of types that are all identical.

@Aklapper: do you think we should use types instead of tags? The advantage of tags is that a task can have more than one tag and they are light-weight / low maintenance.

@jmatazzoni: To be clear, I don't want to discourage teams from having what is needed in order to have the most optimized workflow, I just want to be sure we think it through before I go and add more types. This is mainly due to two reasons:

  1. Ongoing maintenance cost - it takes time to manage all of the types and corresponding configurations, edit all the forms to be sure they have the right layout, etc.
  2. If we add types that turn out to be not that useful then it will take a lot more time to remove them later and clean up the mess.

So I guess I'm just asking for a description of the types and a bit of a use-case narrative so that I can be sure to configure things in a way that'll be most useful.

I'm already a bit unsure about "feature request" as I don't know if that type will really be useful.

mmodell added a comment.EditedFeb 28 2019, 9:08 PM

One more thing to consider: we now have project types as well. We already differentiated between project types by using different icon and color combinations. Now this is just a bit more formalized and I can create custom forms that correspond to e.g. team projects (Release-Engineering-Team-TODO (201907)), tags (Regression), personal work-boards (User-MModell), etc.

@jmatazzoni ok, what special features do these task types need? Are you just wanting them for categorization? In that case it might make more sense to use 'tag' type projects to group them. Task types enable custom forms but it takes some setup to configure them and I'd rather not create a bunch of types that are all identical.

Mainly we use such labels for visual differentiation, so that when we look at the board we can tell what type of ticket is for what purpose. Currently our workaround is to write things like this into the ticket title. E.g.,

  • T208564 [Spike 4 hour] [BUG] MediaViewer ignores thumbnail options when using API provider for thumbnails
  • T215690 [BUG] Labels appear in different font size than the image on Commons
  • T200487 [Design] Make it clearer that the participants section is collapsible

So since the subtype label is so visually prominent, and since we generally prefer to keep titles shorter, these subtypes would be a superior way to provide the type of differentiation we currently achieve via workaround.

@jmatazzoni: interesting, I hadn't thought about that. That does sound like a fairly compelling use-case. I'll add the types with default forms so that they behave otherwise the same as regular tasks.

mmodell closed this task as Resolved.May 14 2019, 2:53 PM
mmodell changed the subtype of this task from "Task" to "Feature Request".

It seems that the task types experiment has been a success. With many types implemented and no major issues so far I think this can be marked as resolved.

mmodell changed the subtype of this task from "Feature Request" to "Design".May 14 2019, 3:06 PM
mmodell changed the subtype of this task from "Design" to "Feature Request".May 14 2019, 3:15 PM