Page MenuHome

Task status review
Open, NormalPublic

Description

The current task progress is hard to follow on a
more fine-grained level.

Once a task is assigned it doesn't necessarily mean
it is actually being worked on.

To get an overview what assigned tasks are worked on
we have two options for handling that:

Task status, introducing two new statuses

  • in progress
  • done

Archived and closed are two statuses that would
be at the very end, done is more to signal the
task can be taking forward.

Workboards

In addition to backlog (the default workboard
if created for a project) there could be several
workboards that can be used to signal task flow
status:

  • next up
  • in progress
  • needs testing
  • needs doc
  • done

Next up: user moves task to this column when it'll
be addressed by that user 'soon' (within a day or two).

In progress: user moves task to this column when
work on it is started.

Needs testing: code is in, fixes have been made. Have
user feedback on the fix to verify it is actually fixed.

Needs doc: fixes have been made, testing has been
successfully completed. Now documentation needs to be
updated.

Done: all of the necessary steps to complete the tasks
for a release have been handled.

Details

Type
Design

Related Objects

Event Timeline

Nathan Letwory (jesterking) triaged this task as Normal priority.

Hi, I have some feedback based on our current process, my previous experience with code quest, and personal opinion. Take with a grain of salt, I don't want to sound negative, just to present some counterpoints:

FIrst, is this intended for any tasks or only bug reports?

I'm a bit concerned about over engineering the developers process. In the past (code quest) we had mixed results where overtime developers would just work in a task and after the fact acknowledge that. I'm open to your proposal, just a bit skeptical.

needs testing

How often does a bug have to be reopened because the bug is still there? Wondering if we are not complicating the process and let users be the bottleneck on already confirmed bugs that we managed to reproduce and fix.

Also confused with the term "user" here. So far you were using it to refer to developers, and now you are using it for "Blender Users", right?

needs doc

Nothing should be fixed/committed without docs. Worst case scenario something is committed and a new task is created "Add documentation for XXX". But even that should me avoided

...

So what I miss the most is columns for confirmed or planned bugs/tasks. There is an abysmal difference between reports that fall into backlog (of which we have no control, since new bugs may just fall there, even if unconfirmed), and issues/tasks that developers confirmed that are valid and to be tackled in the next release or in the future.

From that poll of valid bugs we can stick to priority to sort them in their workboard columns, no problem. We could even have a column for "Next Release" if you think we need to make more clear, but I think it may be too much.

Besides (for tasks, not bugs necessarily) we could use a way to indicate that the task is already curated in the main page, or if it should not get highlighted on there. Maybe instead of using the workboard for that we could simply have them as children of the module page (the curated ones).

FIrst, is this intended for any tasks or only bug reports?

I would say all tasks, but:

I'm a bit concerned about over engineering the developers process. In the past (code quest) we had mixed results where overtime developers would just work in a task and after the fact acknowledge that. I'm open to your proposal, just a bit skeptical.

I understand the reaction. To clarify my position on these: I don't think using the workboards strictly should be enforced in any way. These should be regarded as guidelines and tools for all to schedule own time. Some will use it, some won't. Having them available as a tool will be much more useful than not having it at all.

I see this leading eventually to be used as a way to figure out what a dev thinks is possible to do in the short term in the time allotted. How many columns/lanes there in the end will be is open for discussion.

Also confused with the term "user" here. So far you were using it to refer to developers, and now you are using it for "Blender Users", right?

Both, really. But yes, having users confirm the fix actually works is IMO something that we could incorporate into our QA process. It is great to have devs do testing, but it is even better to have one, or better yet, several, users say the problem has actually been fixed.

Nothing should be fixed/committed without docs

True, except that the user manual is what I was getting at. Potential text changes, updated screenshots, etc. This to get a sense of work to do closer to a release.

So what I miss the most is columns for confirmed or planned bugs/tasks.

Right, it is still a bit open how we'll end up doing this, but for planning against the release cycles I think we should use the milestone as a tag. Milestones have also workboards, so whatever gets tagged for milestone X could be moved to the todo-pile (backlog) for that, and devs should be able to quickly find work to do through that.

With columns consistent throughout the parent project, subprojects and milestones we should be able to accomplish that.

For tasks/bugs that didn't make it into the final release we can have them moved automatically to the next milestone and its workboard

regarding the workboard workflow:

In addition to backlog (the default workboard if created for a project) there could be several workboards that can be used to signal task flow status)

I assume you are talking about columns here, right?

needs testing, needs doc

I also see this rarely used (might be useful in certain cases), should not cause harm [should not lead to confusion/lockup/bottleneck -- maybe column header can explain this is "optional"?], or just leave out alltogether...

So what I miss the most is columns for confirmed or planned bugs/tasks

+1
Atm. I would see myself preparing the workboard usage as the bugtracker guy: I tag with the right project/module (so it shows up in the correct workboard) and I set priority/confirm, it would be good if the confirmed stuff stands out from the backlog. I wonder if this could somehow be automated / hacked into phabricator? As the minimum workaround you can at least sort (the backlog) by priority and scroll to the confirmed entries...

introducing two new statuses

still thinking if we need an actual status for this, or if the workboard columns are enough...

  • pro: you can see in progress / done from anywhere (not just the workboard)
  • con: people forget to set this (thats more harm then use -- stuff being worked on that is not tagged in progress, stuff committed that is not tagged done)
  • could this (setting the status) be automated when dragging a task from one column to the other? automated when committing?

could this (setting the status) be automated when dragging a task from one column to the other? automated when committing?

That is actually a nice idea. I'll try to get something like that set up on my test box.

My two cents on the columns:

  • Needs testing is something we currently don't have and I don't see actual value out of it. For example when doing GPU fixes the testing needs to be done during the coding. Testing if an issue is fixed is part of the in process, otherwise the bug was not clearly described or understood.
  • I do think that a In Review is a better one. As reviewing can take longer than in development. Looking at other boards like Jira; they have categorized board states to several statuses that users can understand. As long as a task is in the review column. the task status is still In Progress.
  • Looking at Kanban (as this is more suited to our work style) there are 3 overall Task states (Todo, Work In Progress and Done) And every task state can be in a specific column. Implementation wise these could be seen as substates or meta states, but that is defined by the technology fit :-) Perhaps for documentation we should make a separate state as it is very important and developers tend to forget about it.
  • Whatever we do, we should make sure that every viewpoint (actor) can gets its data by using filters and perhaps provide standard filters and tagging rules.