[teampractices] Phabricator's "Epic" tag...why?

[Bryan Davis]

On Mon, Jun 1, 2015 at 1:35 PM, Kevin Smith <ksmith at wikimedia.org> wrote:
>
> On Mon, Jun 1, 2015 at 12:26 PM, Bryan Davis <bd808 at wikimedia.org> wrote:
>>
>> We used them for quarterly planning and other roadmapping activities.
>> This was a replacement for our prior process of maintaining a wiki
>> page to track the things that the team was interested in working on
>> (or that other teams were asking us to work on in the future).
>
>
> Ok. I'm still trying to understand this. Were *all* issues part of an Epic,
> or were there a mix of Epics (with subtasks) and standalone non-epics? For
> me, the line between epic and non-epic is very fuzzy, so viewing everything
> on one side of the fuzzy line doesn't seem very helpful. I'm genuinely
> curious here.

Not all tasks were traceable to an epic but all areas of work that we
felt were large enough to be considered for quarterly planning were
epics.

For me, the line between an epic and a non-epic is easy. Epics are all
tasks that are larger than the granularity used by the team for
iteration planning. Epics are useful to track and discuss features
that are too large to be built in a single sprint or as a single
sprint task. Discussion of this is veering towards a religious debate
however. :)

> Would the Goal project type be more appropriate for roadmapping?

Maybe in some cases. Creating a separate goal project for each epic
seems pretty drastic unless the epics are very very large. I guess for
the use case that MediaWiki-Core was using we could have had a
"future" goal type project that we stuck things in. For us the big
issue was that there were hundreds of various sized issues that had
been assigned to the team for some reason or other and most of these
were not issues that were relevant for roadmap grooming. The
intersection of #mw-core and #epic was much easier to groom. Due to
the way that Phabricator is designed to work these sort of
intersection searches work well where non-structured text searches
fail.

>> I have no personal desire to force a team or project into a particular
>> workflow. I'd rather not have my team's workflow changed so that you
>> don't get nagged by some undisclosed Phabricator user however.
>
>
> That makes total sense to me. If there is one right answer that fits
> everyone, great. But if not, then let's not force either team to work
> inefficiently.


Bryan
-- 
Bryan Davis              Wikimedia Foundation    <bd808 at wikimedia.org>
[[m:User:BDavis_(WMF)]]  Sr Software Engineer            Boise, ID USA
irc: bd808                                        v:415.839.6885 x6855