Trac to Phabricator (Maniphest) migration prototype
Richard Eisenberg
rae at cs.brynmawr.edu
Sun Jan 8 14:32:56 UTC 2017
> 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
More information about the ghc-devs
mailing list