Wikimedia monthly activities meetings/Quarterly reviews/Engineering Community/January 2015

The following are notes from the Quarterly Review meeting with the Wikimedia Foundation's Engineering Community Team, January 15, 2015, 2PM - 3:30PM PST.

Present (in the office): Erik Moeller, Rachel Farrand, S Page, Tilman Bayer (taking minutes), Philippe Beaudette (until 2:45), Rob Lanphier, Damon Sicore, Asaf Bartov; participating remotely: Greg Grossmeier, Andre Klapper, Chase Pettet, Quim Gil, Mukunda Modell (from 2:15)

Please keep in mind that these minutes are mostly a rough transcript of what was said at the meeting, rather than a source of authoritative information. Consider referring to the presentation slides, blog posts, press releases and other official material

Welcome and team intro

Quim: welcome
Most of this will be dedicated to Phabriactor, which was our top priority

slide 2

[slide 2]

reminder about what we do

slide 3

[slide 3]

4 people (in the last quarterly review we were 5, but during the past quarter we have been just 3)
Welcome S, who just joined
S: transferred from collab team, will provide tech documentation for developers
Rachel: I'm events coordinator, right now working on dev summit, then Lyon hackathon, then Wikimania hackathon
Andre: Bugwrangler, looking at incoming bugs etc...
now more and more in charge of Phabricator
Quim: leads team, also programs like GSOC, OPW

What we said

slide 5

[slide 5]

focusing on Phabricator
got advice to emphasize smooth rollout over timeliness, so we postponed a bit
at end of Sep, still had plan to move code review to Phabricator too

slide 8

[slide 8]

BZ migration: late, but well done
no other Phab instance with so many tasks (at least no public one)
migration was stressful, Chase helped a lot
RobLa: it was fantastic
(Quim:)
RT migration: less tickets, but not easier - e.g. permissions for sensitive tickets
completed by mid-December except two queues (access requests - by now done too - and procurement)
Phabricator as general PM tool:
~63% of teams migrated at end of year - https://phabricator.wikimedia.org/T825 and https://phabricator.wikimedia.org/T434
Mingle users: MM, lang engineering and FR tech use Phabricator now (mostly)
Trello users: not yet (no migration script so far - https://phabricator.wikimedia.org/T821 )
Erik: This matters because if information is dispersed across platforms, it is very hard for Product teams to follow
Not dismissing concerns about specific needed features, but we need to make this a wider discussion
(Quim:) Goal to publish PM guidelines - worked with Team Practices Group: https://www.mediawiki.org/wiki/Phabricator/Project_management
done, delivered well before end of quarter
For the first time, can assign one task to several teams, not possible when each used their own platform
Regarding code review, we got plenty of pushback
So we focused on the other things instead

slide 11

[slide 11]

What we learned

Got no pushback on delays, and we were always fully transparent
RobLa: Often deadlines are missed because a team doesn't have sense of urgency, but not in this case - team wanted to get things right, we should avoid death marches
Erik: I think you made the right call
Quim: also, we kindly got Chase and Mukunda from their respective teams beyond the period initially expected
We have learned a lot about how Phabricator upstram works as a project - it's a bit of a different style
they are not afraid to say no
This has influenced how we manage this project ourselves
They move fast - we should avoid maintaining local patches, they will likely break soon. Instead push own development upstream.
Bugzilla was updated maybe once a year, with Phabricator we aim to upgrade at least once a month.
Chase: Mukunda and I got into this trouble in our previous job, with customizations that ended up being unmaintainable, and we had to restart.
Most of the time upstream WONTFIXes something because they plan a bigger change
Robla: not sure they are planning a rewrite there. Anyway, Chase was a master diplomat in talking about that issue:
https://secure.phabricator.com/T6905
S: what about burndown (Sprint) extension, would the same kind of concern apply?
same for Trello features - stickers / labels?
Chase: they say Phabricator is not stable yet, but I also got the sense it's meant to be an extensible framework, long-lived API
Phabricator extensions are a bit like MW extensions, meant to live side by side, but the API is not stable and things do break.
[local] patches though are tricky
They are very aware though of other use cases [besides their own]
Erik: let's take this opportunity to discuss the degree to which we want to customize
Quim: Besides lack of Trello migration script
these teams are also more isolated, missing links (e.g. Mobile apps)
yes, there are things that save you time in Trello, but need to work within entire org
this needs further analysis
Code review: 3-4 months ago it wasn't clear the CI would be blocker
differing opinions on how difficult this would be

slide 14

[slide 14]

number of active users in Phab is higher than it was in BZ
more activity - now not just bugs, but epics etc.
no obstacle for non-technical teams to use it
WLM Netherlands uses it

slide 15

[slide 15]

burn rate - now flat
now moving to business as usual
Andre will talk about that

slide 16

[slide 16]

[this slide was added after the review]

slide 18

[slide 18]

Andre:
work on PM best practices - e.g. shared understanding of priorities

slide 19

[slide 19]

What is considered crucial?
taxonomy: currently every team organizes for themselves, works OK so far, but need to investigate need for changes
success measures
some metrics that were available on BZ I currently don't have on Phab
not sure how to quantify cross-team coordination
Trello blockers
defined roles for dealing with upstream
Need to sort out how much time we can spend (Chase, Mukunda) on local Phabricator development / customization

Discussion

Erik: Damon, you said you are concerned about local work on patches?
Damon: for these first few months, I don't want to bind us to commitment about pushing upstream
want linear regression analysis to determine when we can ship
there are some fantastic tools we could integrate
looking at longterm burndown plan, but want to avoid one-off effort in next
e.g. for VE, would like lightweight feature that facilitates prediction there
Quim: for the Sprint extension, the Interface etc is already there; this is different from developing a whole new feature
RobLa: (explains) Phabricator as shipped does not have burndown charts at all
Upstream for this is WMDE (Christopher Johnson is developer there)
upside: receptive, downside: might not have capacity
Erik: (demos FR Sprint burndown https://phabricator.wikimedia.org/sprint/view/994/ )
has support for points estimation, also for burndown charts, but look broken to me
again, WMF has not put effort in this (yet)
Nice things about Chris' thing: it's well integrated
Linear regression prediction would be something
Damon: want to prioritize complex long bugs first, this will help
Erik: so you are OK with putting effort in this?
Damon: yes, if this is what we already have in production, I'm in favor with moving ahead based on this
Erik: caveat: upstream is not us
Andre: he is happy about feedback
Damon: will do that, also involve Arthur's group
Erik: also, talk to the people who are currently using it
besides this, I don't see things that would need WMF development effort
In general, avoid "just a tool "mindset - this is used by 1000s, also volunteers, so a bit more than just an internal bug tracker
RobLa: So we postpone Gerrit migration?
Quim: talk about that in later slide

Asks

slide 24

[slide 24]

Andre: still need support from Ops and RelEng:
for feature requests, more than one team should consider something as crucial
Quim: and be conscious we don't have much capacity for them
Andre: need CI strategy etc.
Damon: what is the scope of these local patches?
Chase: these are about extensions, locally

security/privacy settings
SUL / auth provider, still maintained locally, upstream has not yet merged
Sprint extension (just discussed) - based on templates

Damon: do they have a coherent set of tests, so that we could at least push these upstreams?
Chase: no. background - they want launch a company offering Phabricator hosting....
Damon: thanks, that was super helpful

slide 25

[slide 25]

Quim: code review migration
Mukunda thinks this should actually not be that hard, Antoine thinks it is
Mukunda: this is contingent on *not* migrating Gerrit history
Quim: per RfC discussions, we agreed not to migrate Gerrit history but preserve historical Gerrit comments etc. in a separate archive
Mukunda: code review process itself is not that big a challenge
Quim: ask for time from Antoine and Timo to discuss
Greg: my team's priorities - beta cluster will likely consume all efforts in next quarter
this unfortunately ties Antoine's hands pretty strongly
Erik: what aspects of beta cluster focusing on?
Greg: wrap up conversations between Ops and RelEng, ...
Erik: hearing differing opinions on importance of beta cluster
RobLa: would put odds of postponing at 50% (re starting in April)
migration to Phab will put likely pressure on upstream, not sure they are in a good position for that right now
Quim: some say Gerrit is fine, some say start migration asap
Damon: I don't think Gerrit is fine, I think it's user hostile
Quim: at least try to get a shared understanding
Erik: does compete a bit with migrating away from Jenkins etc. - I find Jenkins user hostile too ;)
i.e. many other parts of our dev tooling need work too

What's next

slide 18

[slide 18]

Quim: We only have a few minutes to discuss the other main goals for the current quarter.

slide 21

[slide 21]

Rachel: need plan a year ahead for event in SF because venues get booked. So need to plan now for 2016
invite more mindfully to hackathons, reaching out to developers out of Wikimedia.
get more tech talks from outside Wikimedia
survey all WMF teams to identify potential technical partners

slide 20

[slide 20]

S: Developer hub documentation portal
prioritize documentations
two ways to improve doc;
1. edit wiki pages
2. comments in code that generate doc
figure out how to get these together
Erik: would love to clean up http://doc.wikimedia.org
Damon, Erik: thanks again
Erik: kudos again on a seamless and hairy migration
Asaf: thanks for letting me observe, and (as amateur dev) thanks for putting resources in documentation