Page MenuHomePhabricator
Create Task
Maniphest T85564

Ability to associate workboards with parent tasks
Closed, DeclinedPublic
Actions

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.

Related Objects

Event Timeline

• RobLa-WMF created this task.Dec 30 2014, 10:01 PM
• RobLa-WMF raised the priority of this task from to Needs Triage.
• RobLa-WMF updated the task description. (Show Details)
• RobLa-WMF added a project: Phabricator (Upstream).
• RobLa-WMF subscribed.
Qgil subscribed.Dec 31 2014, 8:52 AM

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.
• RobLa-WMF added a project: Epic.Dec 31 2014, 8:21 PM
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.

• RobLa-WMF removed a project: Epic.Dec 31 2014, 8:23 PM
• RobLa-WMF set Security to None.
Qgil added a project: Project-Admins.Jan 8 2015, 10:02 PM
In T85564#951213, @RobLa-WMF wrote:
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.

Qgil added a comment.Feb 23 2015, 9:54 AM

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 closed this task as Declined.Apr 20 2015, 7:38 AM
Qgil claimed this task.
Danny_B added a project: Upstream.May 23 2016, 6:03 PM
Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptMay 23 2016, 6:03 PM
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL