Re: [teampractices] Phabricator terminology change (blocking->subtasks)
Just so everyone doesn't think this is "done" per se (parts of it are), work is still on-going upstream in https://secure.phabricator.com/T4788 See, for instance, the work on creating the task dependency tree. It's already gone through a few iterations today and will probably change more. Greg > This week, phabricator changed the terminology it uses for managing > dependencies between tasks. What has been called "Blocking"/"Blocked by" is > now called "Parent"/"Subtask". Ignoring phab terminology for a minute, here > are the two basic cases these terms are covering: > > 1. *Sequential dependencies.* For example, if "Implement feature X" needed > to be complete before "Document feature X", then the implementation task > would Block the document task, and the document task would be blocked by > the implement task. > > 2. *Composition relationships/task breakdown.* For example, if "deploy > feature X" consisted of "implement feature X" and "document feature X", > then the deploy task might be a parent, while the implement and document > tasks would be subtasks. > > Until recently, phab has used the blocking/blocked by term to cover both > cases. A parent task would be blocked by its subtasks. There was a command > to create a subtask, which would create the appropriate blocking > relationships. > > Now, phab uses the parent/subtask terminology to cover both cases. In the > sequential tasks case, the endpoint would be considered the parent, so in > the example above, "document" would be the parent, and "implement" would be > its subtask. Note that a task may have multiple "parents". > > A nice feature they added is the ability to manage the parent/subtask > relationship from either end. While editing a task, you can change its > subtasks or its parents. Previously, you could only edit one direction. > > I created T139181 as a task to update our wiki phab documentation. > > Kevin Smith > Agile Coach, Wikimedia Foundation > ___ > teampractices mailing list > teampractices@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/teampractices -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Phabricator terminology change (blocking->subtasks)
(Mostly) Max: Jira only allowed 3 levels of tasks, which was frustrating. If phab adds "types" of subtasks, I hope it doesn't fall into that same trap. (Mostly) Joel: Yes, I would definitely favor distinguishing between blocking tasks and subtasks. Trying to cover both cases with one set of terms is very awkward, as one of my examples demonstrated: "implement X" certainly doesn't feel like a subtask of "document X", but that's how it will appear in phab right now. Kevin Smith Agile Coach, Wikimedia Foundation On Fri, Jul 1, 2016 at 11:27 AM, Max Binder wrote: > Technically, yes. > > This distinguishes tasks that are subtasks of already-estimated (story > pointed) tasks, so to avoid double estimation. JIRA, for example, has > blocking tasks and subtasks, presumably for this purpose. > > On Fri, Jul 1, 2016 at 10:40 AM, Joel Aufrecht > wrote: > >> aren't those both parent/child relationships? What's the difference? >> >> >> >> *-- Joel Aufrecht* >> Team Practices Group >> Wikimedia Foundation >> >> On Fri, Jul 1, 2016 at 10:39 AM, Max Binder >> wrote: >> >>> I know my teams would love to distinguish between subtasks (of tasks >>> with story points) and children (of epics). I don't think that is possible >>> right now, so they often use the title prefix "[Subtask]". >>> >>> On Fri, Jul 1, 2016 at 10:25 AM, Joel Aufrecht >>> wrote: >>> Should we make (or find and join) a request that they provide a way to differentiate between the two cases? Possible uses: different display in the UI use in data analysis, e.g., summing up tasks by summing up their subtasks (and not dependencies) *-- Joel Aufrecht* Team Practices Group Wikimedia Foundation On Fri, Jul 1, 2016 at 9:56 AM, Kevin Smith wrote: > This week, phabricator changed the terminology it uses for managing > dependencies between tasks. What has been called "Blocking"/"Blocked by" > is > now called "Parent"/"Subtask". Ignoring phab terminology for a minute, > here > are the two basic cases these terms are covering: > > 1. *Sequential dependencies.* For example, if "Implement feature X" > needed to be complete before "Document feature X", then the implementation > task would Block the document task, and the document task would be blocked > by the implement task. > > 2. *Composition relationships/task breakdown.* For example, if > "deploy feature X" consisted of "implement feature X" and "document > feature > X", then the deploy task might be a parent, while the implement and > document tasks would be subtasks. > > Until recently, phab has used the blocking/blocked by term to cover > both cases. A parent task would be blocked by its subtasks. There was a > command to create a subtask, which would create the appropriate blocking > relationships. > > Now, phab uses the parent/subtask terminology to cover both cases. In > the sequential tasks case, the endpoint would be considered the parent, so > in the example above, "document" would be the parent, and "implement" > would > be its subtask. Note that a task may have multiple "parents". > > A nice feature they added is the ability to manage the parent/subtask > relationship from either end. While editing a task, you can change its > subtasks or its parents. Previously, you could only edit one direction. > > I created T139181 as a task to update our wiki phab documentation. > > Kevin Smith > Agile Coach, Wikimedia Foundation > > > ___ > teampractices mailing list > teampractices@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/teampractices > > ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices >>> >>> ___ >>> teampractices mailing list >>> teampractices@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/teampractices >>> >>> >> >> ___ >> teampractices mailing list >> teampractices@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/teampractices >> >> > > ___ > teampractices mailing list > teampractices@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/teampractices > > ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Phabricator terminology change (blocking->subtasks)
aren't those both parent/child relationships? What's the difference? *-- Joel Aufrecht* Team Practices Group Wikimedia Foundation On Fri, Jul 1, 2016 at 10:39 AM, Max Binder wrote: > I know my teams would love to distinguish between subtasks (of tasks with > story points) and children (of epics). I don't think that is possible right > now, so they often use the title prefix "[Subtask]". > > On Fri, Jul 1, 2016 at 10:25 AM, Joel Aufrecht > wrote: > >> Should we make (or find and join) a request that they provide a way to >> differentiate between the two cases? Possible uses: >> >> different display in the UI >> use in data analysis, e.g., summing up tasks by summing up their subtasks >> (and not dependencies) >> >> >> >> *-- Joel Aufrecht* >> Team Practices Group >> Wikimedia Foundation >> >> On Fri, Jul 1, 2016 at 9:56 AM, Kevin Smith wrote: >> >>> This week, phabricator changed the terminology it uses for managing >>> dependencies between tasks. What has been called "Blocking"/"Blocked by" is >>> now called "Parent"/"Subtask". Ignoring phab terminology for a minute, here >>> are the two basic cases these terms are covering: >>> >>> 1. *Sequential dependencies.* For example, if "Implement feature X" >>> needed to be complete before "Document feature X", then the implementation >>> task would Block the document task, and the document task would be blocked >>> by the implement task. >>> >>> 2. *Composition relationships/task breakdown.* For example, if "deploy >>> feature X" consisted of "implement feature X" and "document feature X", >>> then the deploy task might be a parent, while the implement and document >>> tasks would be subtasks. >>> >>> Until recently, phab has used the blocking/blocked by term to cover both >>> cases. A parent task would be blocked by its subtasks. There was a command >>> to create a subtask, which would create the appropriate blocking >>> relationships. >>> >>> Now, phab uses the parent/subtask terminology to cover both cases. In >>> the sequential tasks case, the endpoint would be considered the parent, so >>> in the example above, "document" would be the parent, and "implement" would >>> be its subtask. Note that a task may have multiple "parents". >>> >>> A nice feature they added is the ability to manage the parent/subtask >>> relationship from either end. While editing a task, you can change its >>> subtasks or its parents. Previously, you could only edit one direction. >>> >>> I created T139181 as a task to update our wiki phab documentation. >>> >>> Kevin Smith >>> Agile Coach, Wikimedia Foundation >>> >>> >>> ___ >>> teampractices mailing list >>> teampractices@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/teampractices >>> >>> >> >> ___ >> teampractices mailing list >> teampractices@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/teampractices >> >> > > ___ > teampractices mailing list > teampractices@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/teampractices > > ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Phabricator terminology change (blocking->subtasks)
I know my teams would love to distinguish between subtasks (of tasks with story points) and children (of epics). I don't think that is possible right now, so they often use the title prefix "[Subtask]". On Fri, Jul 1, 2016 at 10:25 AM, Joel Aufrecht wrote: > Should we make (or find and join) a request that they provide a way to > differentiate between the two cases? Possible uses: > > different display in the UI > use in data analysis, e.g., summing up tasks by summing up their subtasks > (and not dependencies) > > > > *-- Joel Aufrecht* > Team Practices Group > Wikimedia Foundation > > On Fri, Jul 1, 2016 at 9:56 AM, Kevin Smith wrote: > >> This week, phabricator changed the terminology it uses for managing >> dependencies between tasks. What has been called "Blocking"/"Blocked by" is >> now called "Parent"/"Subtask". Ignoring phab terminology for a minute, here >> are the two basic cases these terms are covering: >> >> 1. *Sequential dependencies.* For example, if "Implement feature X" >> needed to be complete before "Document feature X", then the implementation >> task would Block the document task, and the document task would be blocked >> by the implement task. >> >> 2. *Composition relationships/task breakdown.* For example, if "deploy >> feature X" consisted of "implement feature X" and "document feature X", >> then the deploy task might be a parent, while the implement and document >> tasks would be subtasks. >> >> Until recently, phab has used the blocking/blocked by term to cover both >> cases. A parent task would be blocked by its subtasks. There was a command >> to create a subtask, which would create the appropriate blocking >> relationships. >> >> Now, phab uses the parent/subtask terminology to cover both cases. In the >> sequential tasks case, the endpoint would be considered the parent, so in >> the example above, "document" would be the parent, and "implement" would be >> its subtask. Note that a task may have multiple "parents". >> >> A nice feature they added is the ability to manage the parent/subtask >> relationship from either end. While editing a task, you can change its >> subtasks or its parents. Previously, you could only edit one direction. >> >> I created T139181 as a task to update our wiki phab documentation. >> >> Kevin Smith >> Agile Coach, Wikimedia Foundation >> >> >> ___ >> teampractices mailing list >> teampractices@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/teampractices >> >> > > ___ > teampractices mailing list > teampractices@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/teampractices > > ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Phabricator terminology change (blocking->subtasks)
Should we make (or find and join) a request that they provide a way to differentiate between the two cases? Possible uses: different display in the UI use in data analysis, e.g., summing up tasks by summing up their subtasks (and not dependencies) *-- Joel Aufrecht* Team Practices Group Wikimedia Foundation On Fri, Jul 1, 2016 at 9:56 AM, Kevin Smith wrote: > This week, phabricator changed the terminology it uses for managing > dependencies between tasks. What has been called "Blocking"/"Blocked by" is > now called "Parent"/"Subtask". Ignoring phab terminology for a minute, here > are the two basic cases these terms are covering: > > 1. *Sequential dependencies.* For example, if "Implement feature X" > needed to be complete before "Document feature X", then the implementation > task would Block the document task, and the document task would be blocked > by the implement task. > > 2. *Composition relationships/task breakdown.* For example, if "deploy > feature X" consisted of "implement feature X" and "document feature X", > then the deploy task might be a parent, while the implement and document > tasks would be subtasks. > > Until recently, phab has used the blocking/blocked by term to cover both > cases. A parent task would be blocked by its subtasks. There was a command > to create a subtask, which would create the appropriate blocking > relationships. > > Now, phab uses the parent/subtask terminology to cover both cases. In the > sequential tasks case, the endpoint would be considered the parent, so in > the example above, "document" would be the parent, and "implement" would be > its subtask. Note that a task may have multiple "parents". > > A nice feature they added is the ability to manage the parent/subtask > relationship from either end. While editing a task, you can change its > subtasks or its parents. Previously, you could only edit one direction. > > I created T139181 as a task to update our wiki phab documentation. > > Kevin Smith > Agile Coach, Wikimedia Foundation > > > ___ > teampractices mailing list > teampractices@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/teampractices > > ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
[teampractices] Phabricator terminology change (blocking->subtasks)
This week, phabricator changed the terminology it uses for managing dependencies between tasks. What has been called "Blocking"/"Blocked by" is now called "Parent"/"Subtask". Ignoring phab terminology for a minute, here are the two basic cases these terms are covering: 1. *Sequential dependencies.* For example, if "Implement feature X" needed to be complete before "Document feature X", then the implementation task would Block the document task, and the document task would be blocked by the implement task. 2. *Composition relationships/task breakdown.* For example, if "deploy feature X" consisted of "implement feature X" and "document feature X", then the deploy task might be a parent, while the implement and document tasks would be subtasks. Until recently, phab has used the blocking/blocked by term to cover both cases. A parent task would be blocked by its subtasks. There was a command to create a subtask, which would create the appropriate blocking relationships. Now, phab uses the parent/subtask terminology to cover both cases. In the sequential tasks case, the endpoint would be considered the parent, so in the example above, "document" would be the parent, and "implement" would be its subtask. Note that a task may have multiple "parents". A nice feature they added is the ability to manage the parent/subtask relationship from either end. While editing a task, you can change its subtasks or its parents. Previously, you could only edit one direction. I created T139181 as a task to update our wiki phab documentation. Kevin Smith Agile Coach, Wikimedia Foundation ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
