Page MenuHomePhabricator

Ability to associate workboards with parent tasks
Closed, DeclinedPublic

Description

It would be all kinds of awesome if we could associate a workboard with a task (and its blocking bugs) rather than requiring the creation of a project. Since tasks are meant to be more easily created and ephemeral than projects, a task with a batch of blocking bugs could be a better match for the concept of "sprints" than a project is.

In terms of state management, it would be acceptable (and maybe even desirable) to make sure that the workboard state is locked to a project to prevent an explosion of workboard state to manage. This feature in combination with the concept of sub-workboards (see T78225) would be really nice.

Event Timeline

RobLa-WMF raised the priority of this task from to Needs Triage.
RobLa-WMF updated the task description. (Show Details)
RobLa-WMF added a subscriber: RobLa-WMF.

I don't see what is the problem of creating short-lived projects for very specific purposes. It is easy to create and archive projects. Teams are creating bi-weekly project sprints right now.

Do you have specific tracking tasks in mind?

Qgil triaged this task as Low priority.Dec 31 2014, 8:52 AM
Qgil moved this task from Backlog to Need Discussion on the Phabricator (Upstream) board.
In T85564#950398, @Qgil wrote:

I don't see what is the problem of creating short-lived projects for very specific purposes. It is easy to create and archive projects. Teams are creating bi-weekly project sprints right now.

Then why limit the permissions and have a process for creating projects then? You'll have to admit that tasks are easier to create than projects, no?

The other motivation is that tasks still provide a number of things that projects don't. There's state (open, stalled, resolved/completed, declined). Tasks can themselves represented on workboards. There's a discussion area specific to the task. Ownership can be assigned. One task can be marked as a blocker for another task. It's possible to create a hierarchy of tasks.

Do you have specific tracking tasks in mind?

Pretty much everything that's marked with Epic, which is a list I anticipate growing.

In T85564#950398, @Qgil wrote:

I don't see what is the problem of creating short-lived projects for very specific purposes. It is easy to create and archive projects. Teams are creating bi-weekly project sprints right now.

Then why limit the permissions and have a process for creating projects then? You'll have to admit that tasks are easier to create than projects, no?

This might be as simple as to agree that Project-Admins can create projects around tasks marked as Epic, and add this criteria to the guidelines.

The main point of the guidelines and the restriction of permissions to create projects is to avoid duplication, non-sense, and empty / quickly abandoned projects. If an Epic task is valid, the project derived from it has all the chances to be just as valid.

The other motivation is that tasks still provide a number of things that projects don't. There's state (open, stalled, resolved/completed, declined). Tasks can themselves represented on workboards. There's a discussion area specific to the task. Ownership can be assigned. One task can be marked as a blocker for another task. It's possible to create a hierarchy of tasks.

Fine, but then you only need to keep the Epic task that will mark the completion of the project. Just like we had i.e. T15: Migrate Bugzilla to Phabricator as the task defining the completion of Bugzilla-Migration.

I still that the use case of this task can be satisfied with the current Phabricator behavior and our processes: create a project (ephemeral or not), create an epic task defining the goals of the project, and play with workboard and subtasks.

I propose to decline this task.

Aklapper lowered the priority of this task from Low to Lowest.Feb 23 2015, 5:29 PM

@RobLa-WMF: Is there at least one concrete example of an existing task already where this functionality is wanted?

This might be as simple as to agree that Project-Creators can create projects around tasks marked as Epic, and add this criteria to the guidelines.

Quim's proposal also sounds feasible to me.
I don't see upstream supporting some technical binding of workboards to one task, as 1 workboard = 1 project.
Create a project that (not technically) "blocks" that epic task by mentioning it in the project description, and once the project has no open tasks left and is finished, close the epic task too.

Proposing declined for this request too, but only after documenting the workflow above.

Qgil claimed this task.