Page MenuHomePhabricator

We need a Wikimedia process for filing tasks and patches upstream in the name of Wikimedia
Closed, ResolvedPublic


It is everybody's interest that Phabricator upstream maintainers put their attention and resources in the tasks and patches that matter most to Wikimedia. The better we prioritize our feedback and contributions upstream, and the better we play by their rules, the more effective our collaboration will be.


How? Proposal: process

  • Any task landing in must go through the Need Discussion phase and be moved to Ready To Go only when there is consensus.
  • It is fine to Decline tasks that we don't think that should be pushed as Wikimedia requests upstream.

Use of the #Wikimedia project upstream

  • Only tasks placed in Ready To Go or Reported Upstream in can be associated with the #Wikimedia project upstream.
  • The Wikimedia Phabricator team maintains the #Wikimedia workboard upstream. In case of doubt they can add or remove related tasks.
  • Only the Phabricator maintainers decide the priorities of these upstream tasks, not us.


Contributions at your own risk

  • Individuals can always push their own feedback and patches upstream, without using the #Wikimedia tag. In this case, they are on their own, out of the process.

Event Timeline

Qgil created this task.Nov 17 2014, 7:19 PM
Qgil claimed this task.
Qgil raised the priority of this task from to Medium.
Qgil updated the task description. (Show Details)
Qgil changed Security from none to None.
Qgil added subscribers: Qgil, Aklapper, chasemp, valhallasw.

I think there are three classes of bugs, seen from a s.phab.o perspective:

  1. Important. Should be under the #wikimedia umbrella upstream.
  2. Not important. Should be upstreamed, without umbrella
  3. Not reasonable. Should not be upstreamed.

Then there is a subcategory of 2): things we think are reasonable, but upstream disagrees (might also happen for 1) bugs).

Then there is a fourth class, 'untriaged'.

I'm not sure how to implement this separation, but (as I have mentioned before), the complete unclarity of the two different tags (what's Phabricator? what's why are the workboards the same??) definitely doesn't help for that.

I would suggest one project, where the distinction between 'wmf umbrella' and 'not wmf umbrella' is two workboards: 'upstream with umbrella' and 'upstream without umbrella'... although those are really more 'tags' than 'statuses'. Hm.

Qgil added a subscriber: Mattflaschen-WMF.EditedNov 18 2014, 11:14 AM

@valhallasw, "#phabricator" says

This is the default project for the Phabricator related tasks that don't fit in any of our subprojects.

while "" said... nothing :) and I just added a description in the lines of the proposal here.

I hope this clarifies the difference between both projects.

About the rest of your proposal, I think the solution is simple: tasks that matter to Wikimedia should be kept Open until Resolved, with their corresponding priority based on its importance and on whether there is someone assigned to them. The rest should be closed as Declined, leaving to the authors the option of go for their proposals directly upstream, at their own risk.

Qgil added a subscriber: Nemo_bis.Nov 20 2014, 8:52 PM
Qgil added a subscriber: Legoktm.Nov 24 2014, 9:05 AM
Qgil added a subscriber: greg.Nov 25 2014, 10:16 PM
Qgil added a subscriber: TTO.Nov 26 2014, 10:24 AM

I suspect this is rather useless. My understanding is that there are only two possibilities, when we have an idea/request:

  • upstream maintainers immediately fall in love with the idea -> very quickly implemented whatever the importance;
  • upstream hates it -> will never be developed no matter how important it is for us.

Either way, the only things worth investing time on are:

  • extremely careful filing upstream of super-curated and pitchy reports,
  • coding of local Wikimedia applications/modifications (or upstream changes *only if* upstream has preventively declared they like the idea).

I'm not going to do either, hence removing myself from this task.

Nemo_bis updated the task description. (Show Details)Nov 27 2014, 8:35 AM
Nemo_bis removed a subscriber: Nemo_bis.
Qgil moved this task from To Triage to Doing on the Phabricator board.Nov 27 2014, 11:54 AM
jayvdb added a subscriber: jayvdb.Dec 2 2014, 3:25 AM
Qgil lowered the priority of this task from Medium to Low.Dec 5 2014, 7:17 AM

Currently we are applying this process and it's working. I just don't have the time to wrap up and document this properly, there is still a lot going on that alos needs wrap up and documenting, with higher priority.

Qgil added a comment.Dec 5 2014, 1:29 PM

For what is worth, I have been sorting out our requests upstream:

Qgil added a subscriber: Gryllida.Dec 9 2014, 1:59 PM
Qgil added a comment.Dec 11 2014, 2:46 PM

I'm thinking of a better way to organize the workboard. The goals of this change:

  1. improve the focus on the most relevant tasks for Wikimedia
  2. help people proposing their improvements directly upstream, at their own risk

For this, we would use these priorities:

  • High and Normal identify the most relevant tasks for Wikimedia. The Wikimedia Phabricator team will focus its time pushing these, and we welcome all the help.
  • Low and Needs Volunteer identify tasks that should be pushed by their authors and whoever else is interested. We can help triaging and discussing them, but reporting them is not our priority.

And these columns:

Qgil added a comment.Dec 16 2014, 1:30 PM

I fine tuned the proposal above while I was implementing it. This process feels more natural:

  1. Backlog: default, no filtering)
  2. Need Discussion: not ready to be properly upstreamed
  3. Ready To Go: can be upstreamed by anyone
  4. Personal Requests: default for all tasks upstreamed
  5. Wikimedia Requests: labeled by the Wikimedia Phabricator maintainers

Anybody can get involved in any stage. I will focus on maintaining the Wikimedia Requests column, and I'm happy to keep helping interesting tasks moving forward.

Wow thanks man, my only thought would be to question keeping personal feature requests in this manner at all? There isn't a difference between a personal request from me, and one from some non WMF user in the upstream context which this is coordinating. No big thing, but if personal requests start to clutter we may want to detangle them from this install or at least this project. Good stuff.

Wow thanks man, my only thought would be to question keeping personal feature requests in this manner at all?

As I interpret it, the 'personal requests' board is for features that are deemed useful for the WMF phabricator (otherwise it would be WONTFIX), but not important enough to request upstream developer time under the WMF umbrella.

Qgil added a comment.Dec 16 2014, 2:00 PM

A task in the Personal Requests column implies that

  • it would be useful to have in (an aspect that can be discussed at any time, and if it isn't useful, we can decline it even after it has been filed upstream; they can still convince upstream).
  • it is open upstream (tasks rejected upstream should not be open in

Being compliant with these two requirements has some merit, and I think it is useful to keep track of these tasks.

thanks for the clarification guys

Qgil moved this task from Backlog to Doing on the ECT-December-2014 board.Dec 16 2014, 5:04 PM
Qgil raised the priority of this task from Low to Medium.Dec 19 2014, 8:22 AM
greg removed a subscriber: greg.Dec 19 2014, 4:48 PM
Qgil added a subscriber: Quiddity.Dec 19 2014, 9:41 PM
Qgil added a subscriber: Krinkle.Dec 21 2014, 12:08 AM
Nemo_bis added a subscriber: Nemo_bis.EditedDec 21 2014, 4:08 PM

Personal Requests: default for all tasks upstreamed

Then it should be just called "Upstreamed" (or "Other upstreamed" if you worry about non-overlapping titles).

Qgil added a comment.Dec 22 2014, 8:08 AM

Column renamed to "Upstreamed". I agree the title is clearer now, and I hope the sequence of columns makes also clear that "Wikimedia requests" are also upstreamed. Anyway, these tasks should have a link in the task description.

Qgil raised the priority of this task from Medium to High.Dec 22 2014, 11:29 PM
Qgil closed this task as Resolved.Dec 31 2014, 3:24 PM

This process seems to be running fairly well, and we can keep fine tuning it. I have documented it at

Thank you for your help and, above all, thank you for your participation reporting Phabricator bugs and feature requests here and upstream.

Tgr added a comment.Dec 31 2014, 7:01 PM

One thing that should be clarified is what it means when a task is in backlog/needs discussion, with a priority of needs volunteer. A volunteer is needed to conduct the discussion?

In T1298#951168, @Tgr wrote:

with a priority of needs volunteer.

See T78617 - you can translate it with "if you don't do it don't expect anybody else to work on it" IMHO.

Qgil added a comment.Jan 2 2015, 4:27 PM

Yes, exactly that, just like in any other Phabricator project.

I'm updating the board almost on a daily basis, and I'm reporting several tasks upstream every week. I do follow the priorities of the tasks, and in practice I only comment or act on the Needs Volunteer ones whenever I have a personal interest in them.

Tgr added a comment.Jan 2 2015, 11:07 PM

I know what "needs volunteer" means, I'm just not sure what a volunteer should do with a ticket in the "needs discussion" column. Does a prioritiy of "needs volunteer" mean that it does not actually need discussion, and anyone interested the task should just proceed to upstream it?

Qgil added a comment.Jan 3 2015, 10:15 AM

Tasks in Needs Discussion are considered to need discussion regardless of their priority. If someone thinks that the discussion is over / not needed anymore, then they can always submit the request upstream (again, regardless of their priority).

Krinkle removed a subscriber: Krinkle.Jan 8 2015, 8:26 PM
Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptMay 23 2016, 6:05 PM