I'm not saying this to be a downer or anything but we have some substantial questions to answer in terms of maintenance of this kind of work, and I'm going to oppose any local changes carte blanche that are not coupled with resource allocation for carrying them forward. Not that I necessarily have the final world on anything, but writing the code is by far the easiest part. Maintaining local changes in Phabricator land is often very time consuming and requires a lot of constant negotiation between short term and long term maintenance.

For reference: https://phabricator.wikimedia.org/T78464#981482

Improving on burndown chart-related functionality (this could be a great time to knowledge-share with @Christopher and start taking the burndown functionality to where we need it to be for WMF teams)

This is safe, right?

@Aklapper @chasemp thanks for your comments - I don't see what either of you brought up necessarily as blockers to what I am proposing.

Like @Qgil is pointing out, I think there are things we can do to help improve existing functionality (upstream, in existing extensions, etc).

Also, one of the big selling points for migrating to Phabricator was that it's open source and we can have an active hand in shaping it to be valuable and useful for WMF engineering teams and the broader community. We know there are things missing/incomplete/etc in Phabricator that are preventing some WMF teams from using Phabricator - and some of those things we know that upstream is unable/unwilling to address. Let's figure out how to get at least some of these issues resolved given the necessary constraints.

@Awjrichards :)

I don't think any one of the Phabricator folks think that what you are saying is crazy. We all would agree I think in general with your points, but we have also felt keenly the growing pains here and want to temper expectations based on what we know.

• We have two people working on Phab in a technical sense, both are on a slim margin. I could easily spend the entire time I have allocated to Phab 3 times over on just keeping up with upstream now based on our existing local changes, and @mmodell has a similar workload. Simply put there is no one to maintain any work done to Phab locally. Writing the code is seriously the easy part by a factor of a 10 or even 100. A local change done in 5 minutes could easily consume days of maintenance time over the next year on its own. There are no resources for part of what you are suggesting. That's not being bullish honestly, it's just reality. This was discussed in the quarterly review and agreed upon.

• The sprint app is done in a way that has already been negotiated among the team. The "extension" framework in Phab is a bit wild at the moment but makes for a lowest possible barrier mechanism to continue forward with those local efforts. This is not without cost itself. Every time we upgrade sprint we have to vett it against our security concerns and other local changes. This is on top of lagging behind upstream as much as necessary to do so. Having some hackathon time dedicated to helping @Christopher do more great things sound awesome.

• It is true that upstream has things they are unable/unwilling to address but I would go so far as to say most of these are because based on their own roadmap it is a bad time to do so, or they are going in a direction that would make it very difficult to do well now, or that will need to be completely rewritten. Everything so far has been a balancing act between resources available and what we absolutely needed to move forward.

So I guess what I'm saying is, yes this is open source, but the cost of maintenance is very real and very expensive and not at all, as far as I know, accounted for by the organization. A serious amount of time, effort, and negotiation has gone into the local changes we are maintaining now. I'm sorry if this seems like jumping on you or this quest for good here. Honestly, I just want to keep the expectations realistic. If we desire as an organization to stray from the upstream path we need to do so in very deliberate ways. When I saw this task and some of the suggestions it made me worry that https://www.mediawiki.org/wiki/Phabricator/Code#Local_changes wasn't on the radar here.

I did talk with upstream a bit on whether we could do this in a way that was supported by them. It was a resounding "maybe!". They are currently swamped with launching phacility.

My synopsis of the maybe is:

• May-ish is more possible than now
• If we prevetted a list of things we all like and roadmapped them together
• We organized things well on our end
• We keep it to a reasonable number (my note is especially to kind of get our feet under us for this)

Background story is they actually participated in "Open Academy" a few years ago and understand that this sort of thing is a big time commitment.

I think it would be really neat if we could:

• Sort out some sprint app things as a whole and provide @Christopher with some muscle
• Work out some things we really care about as an organization that upstream wouldn't otherwise prioritize and be good stewards about communication and shared effort

Note that I have been proposing this Phabricator activity for Lyon:

In T18#1029056, @Qgil wrote:

The Wikimedia Hackathon is more about getting things done and less about presentations. We could have two lines of work:

• T560: Proof of concept of code review in Phabricator (hands-on)
• T31: [keyresult] Connect Differential code review with continuous integration (discussion / experimentation)

The goal being to crack enough nuts in 3 days as to have the basis for an agreed plan.

So what about focusing on Code Review and Sprint?

In T89776#1048508, @Qgil wrote:

So what about focusing on Code Review and Sprint?

@chasemp, @mmodell, @Aklapper, and myself had a meeting about Phabricator misc topics yesterday. We agreed that if we want to work on T560: Proof of concept of code review in Phabricator in a hackathon. Wikimania is more suitable than Lyon because of dates and travel preferences.

So what about focusing on Sprint? @Christopher, are you planning to attend the Wikimedia Hackathon in Lyon?