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

[Quim Gil]

On Sat, Oct 25, 2014 at 4:21 AM, S Page <spage at wikimedia.org> wrote:

> On Wed, Oct 22, 2014 at 9:51 PM, Quim Gil <qgil at wikimedia.org> wrote:
>
> What is stopping you from starting the move?
>>
>
> No real motivation to do it before WMF tracks bugs in Phabricator.
>

Fair point. The Bugzilla migration is taking longer than expected, but we
are needing the extra time to polish the details of such a complex move.
Now we have closed the gate for new blockers and we are working to announce
the migration date.


Flow has a large backlog in Trello we'd like to migrate, but only those
> cards that don't have associated bugs. If anyone has done any automation of
> Trello/Mingle migration, speak up here and on
> https://phabricator.wikimedia.org/T36
>

Two days ago we learned about another project that had migrated "40.000
Trac/Trello tickets to Phabricator" https://phabricator.wikimedia.org/T821

I wonder, can we help you help us moving faster in this front? In
principle, our current work on the Bugzilla and RT migrations shouldn't
block any progress done by others in the Trello and Mingle fronts.

Also, one question. Some teams have hundreds of Trello / Mingle cards, but
then again only a few are selected for a next sprint. I wonder how feasible
it is to start the migration sooner with a bit of manual work, taking into
account that the teams need to learn and get used to the tool anyways. The
MediaWiki Core team is already working this way, and whenever a task
currently developed corresponds to a yet-to-be-migrated Bugzilla, report,
they just copy the title, link to the report in the description, and off
you go.

https://phabricator.wikimedia.org/tag/mediawiki-core-team/board/

Yesterday I had a very interesting meeting with the Language team, and they
(heavy Mingle users) have decided to do a test by replicating in
Phabricator the cards of the next sprint (or the following, tbd), and have
the team working in Phabricator only during the sprint, leaving the basic
syncing with Mingle to the product/project owners.


I assume Phabricator will have a "Flow extension" project for all the
> migrated Flow bugs.
>

Here is a sample of what you will get:
https://bugzillapreview.wmflabs.org/tag/mediawiki_extensions-flow/


> When the Flow team switches to Phabricator we'll add a subset of them to a
> "Flow-sprint-K" project for the current sprint and work with that project's
> workboard. Maybe we'll have a "Flow-backlog" project as well.
>

With the help of Arthur (no less!) we are drafting the new guidelines /
conventions at https://phabricator.wikimedia.org/T558

In your case, you could have a "Flow" team project that would act as
backlog, and then you could have "Sprint-Flow-K" projects, yes. (Starting a
project with "Sprint" will give you extra sprint features as soon as the
Burndown extension is available).

Questions:
> * Can you limit who can edit a workboard (drag cards, reorganize, add
> /delete columns)?
>

Mmm... requires more investigation. Columns seem to have their own
policies, but I'm not sure who can change them, and whether it is per
columns or per board. See
https://phabricator.wikimedia.org/project/board/35/column/65/  Can you
create a task? I can see how this will be needed in some circumstances.


> * What kind of information can we show in a workboard view? (more below)
>

Something that Trello/Mingle users could do is to agree on a prioritized
list of features required for workboard cards. Phabricator's free workboard
is relatively young and cannot compete with the commercial and well
established Trello/Mingle counterparts. Still, this is a solvable problem.
And the best way to solve it is to identify the most important features and
go after them.

https://phabricator.wikimedia.org/T154 has been sitting without much
definition for a long time. Could be a good place to work on this
prioritized list of missing features.

Thank you for your extensive reply, and forgive me for following you at
comparable length.  :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20141031/2fe213dd/attachment.html>