[teampractices] Trellos & Minglers, what is blocking your migration to Phabricator?

Matthew Flaschen mflaschen at wikimedia.org
Thu Nov 13 19:24:28 UTC 2014


On 11/13/2014 12:31 PM, Quim Gil wrote:
>
>
> On Thu, Nov 13, 2014 at 4:22 PM, Arthur Richards
> <arichards at wikimedia.org <mailto:arichards at wikimedia.org>> wrote:
>
>     The lack of this feature in Phabricator may seem like just a minor
>     inconvenience to some. But I believe it's been an integral part of
>     teams feeling like they can move fast with minimal friction in the
>     planning process.
>
> I'm fully aware of its importance...
> (https://phabricator.wikimedia.org/T129 &
> https://secure.phabricator.com/T4900 <--- consider lobbying upstream as
> well :) )

Yeah, there are a few related but distinct things, in likely 
implementation/installation order (first to last):

1. Pop-up notifications when the page (e.g. a task/bug) you're on has 
changed.  This addresses the problem of wondering whether you need to 
refresh.  It doesn't auto-update without a refresh, but it explicitly 
tells you that you need to refresh (and you can also refresh by clicking 
the pop-up).

This feature already exists in Phabricator, but it has to be 
installed/configured: https://phabricator.wikimedia.org/T765 .

2. Workboards updating in real time (e.g. you see a task move between 
columns instantly): https://secure.phabricator.com/T4900 .  The upstream 
maintainers are supportive of doing this ("I think for Workboards and 
Conpherence this is a pretty solid use case, basically any interface 
that tends to stay active for longer periods of time that streaming 
updates are noticeable and expected.").  But we could still accelerate 
it by helping with implementation.

3. Live updates everywhere else (e.g. you're on a task page and you see 
the description change instantly).  Discussed at 
https://secure.phabricator.com/T4901#60993 but the maintainers have been 
clear they don't want to invest the effort in this feature ("We're 
generally satisfied with this relatively low-tech approach for now: we 
tell users things have changed, but don't automatically update to 
reflect changes. As users, this has felt sufficient. As implementors, 
this is dramatically simpler.").  If we want #3, we'll probably have to 
do it ourselves.

Matt Flaschen



More information about the teampractices mailing list