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?

In T93499#4118919, @atgo wrote:

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.

Thanks @mmodell! Much appreciated.

@atgo:

I should be able to get this deployed on wednesday.

@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!

In T93499#4121553, @atgo wrote:

@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:

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.

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.

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

@atgo:

In T93499#4121780, @atgo wrote:

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.

Deadline	Color
In the past	Fire (red-orange)
Within 2 days	Orange
Within 7 days	Green
Beyond 7 days	Grey

+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?

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

In T93499#4122098, @MBinder_WMF wrote:

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.

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.

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

@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

Awesome!

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.

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

In T93499#4604434, @mmodell wrote:

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

In T93499#4604839, @mmodell wrote:

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

In T93499#4605241, @MGChecker wrote:

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.

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?

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.

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), tags (Regression), personal work-boards (User-MModell), etc.

In T93499#4992449, @mmodell wrote:

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