Trac to Phabricator (Maniphest) migration prototype

[Matthew Pickering]

To first reply to the one specific reoccurring point about custom fields.

The problem with 'os' and 'architecture' is a philosophical one, in
what way are they any different to any other metadata for a ticket? I
am of the opinion that we should only include information when it is
relevant, a lot of the time these two fields are not.
Including the fields as a special case is in fact worse as users feel
obliged to complete them even when they are irrelevant. Users who are
interested in these platforms are interested in problems which are
specific.

These fields have been structured for over 10 years now, some options
have been barely used but still clutter all interfaces. Nearly 2000
tickets are tagged as relevant to `x86` which massively dwarfs the
other fields -- there is an assumption that unless otherwise stated
the problem is manifested on x86 as that is the default use case.
What's more, just by browsing tickets categorised with this meta data,
it is often evident from the title that the problem is on a
non-default operating system. The assumption in this case is some
debian derivation, users reporting issues on other operating systems
include the operating system prominently as they know it is not
standard. (For example -
https://ghc.haskell.org/trac/ghc/query?os=MacOS+X&order=priority)

Stats for architecture - https://phabricator.haskell.org/P133

Stats for operating system - https://phabricator.haskell.org/P134

I modified my local install of phab to add custom fields,

http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/M1/7/

The results were better than I remembered but I am unsatisfied that
they behave differently to projects and clutter up the description of
each ticket when they are "unset".


On the other hand, I think custom fields are suitable for things like
test case, wikipage etc. It is easy to add a field to carry over the
test case but I always found it a bit redundant as by looking at the
commit information you could work out which test is relevant to which
commit.

So to summarise I think..

Component -> Projects
OS -> (Sub)Projects
Arch -> (Sub)Projects
Keywords -> Projects
Version -> Remove (It is a proxy for date reported)
Milestone -> Project (Milestone)

Matt

On Sun, Jan 8, 2017 at 2:32 PM, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
>
>> On Jan 8, 2017, at 12:40 AM, Ben Gamari <ben at smart-cactus.org> wrote:
>>
>> * Metadata: Custom fields are supported.
>
> In agreement with your comments above, I'm glad to see this. Trac's metadata currently is suboptimal, but I don't think this means we should throw out the ability to have structured metadata in its entirety.
>
>>
>> * Flexible user interface: Custom fields can be hidden from the new
>>   ticket form to prevent user confusion.
>
> Yay.
>
>>
>> * Familiarity: Many users may feel more at home in Phabricator's interface;
>>   reMarkup's similarity to Markdown also helps.
>
> Nitpick: Do we have any control over this? (I doubt it.) I find switching between GitHub Markdown, RST, and reMarkup to be a low-grade but constant annoyance.
>>
>> * Legibility:
>
> I seem to recall that Phab originally used gray-on-white in Diffs, but we were able to fix with some CSS. (Or did it require upstream intervention?) Perhaps we can do something similar here. I find the modern trend to use lower-contrast interfaces utterly maddening.
>
>>
>> What does Trac do well?
>> -----------------------
>>
>> * Convenient cross-referencing: while the syntax is a bit odd, once you
>>   acclimate it is quite liberating to be able to precisely
>>   cross-reference tickets, wiki documents, and comments without copying
>>   links around.
>
> Yesyesyes.
>
>>
>> * Automation of ticket lifecycle: Trac tickets progress through their
>>   lifecycle (e.g. from "new" to "patch" to "merge" to "closed"
>>   statuses) through predefined actions. This means that moving a ticket
>>   through its lifecycle typically only requires one click and the right
>>   thing happens with no additional effort. I think this is a great model,
>>   although in practice it's not clear how much we benefit from it
>>   compared to a typical Maniphest workflow.
>
> I'm less convinced about this benefit of Trac. For instance, if I close a ticket in error, I lose ownership. Then I have to reopen but cannot set an owner at the same time. Maybe it's just a configuration issue, but I imagine we have experienced devs doing ticket-state management and don't need strict controls here.
>>
>>
>> What does Trac do poorly?
>> -------------------------
>>
>> * Active development: Trac is largely a stagnant project.
>
> I was unaware of this. This is a significant downside in my opinion.
>
>> * Safety: I have personally lost probably a half-dozen hours of my life
>>   to Trac eating comments.
>
> That's odd. I have not had this experience.
>
>>
>> * Relations between tickets: Trac has essentially no first-class notion
>>   of ticket relatedness. Even duplicate tickets need to be manually
>>   annotated in both directions.
>
> Yes. Frustrating.
>
>>
>> * Keywords are hard to discover and apply
>
> Yes. With discoverable keywords, we might be able to get more reporter buy-in.
>
>
> One more issue that we should consider: email notification. Perhaps I'm stodgy, but I'm a big fan of email. Trac emails notifications are not quite ideal (I wish the new content came above the metadata), but they're very functional. How does Phab compare? Can we see a sample notification it might create?
>
> Thanks!
> Richard
>
>