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 #phabricator.org? 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.

@valhallasw, "#phabricator" says

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

while "#phabricator.org" 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.

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.

For what is worth, I have been sorting out our requests upstream: https://secure.phabricator.com/project/board/404/

I'm thinking of a better way to organize the Phabricator.org 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:

• Backlog
• Need Discussion
• Wikimedia Reports - should map to https://secure.phabricator.com/project/board/404/
• Personal Reports - users can move their tasks here after reporting them

I fine tuned the proposal above while I was implementing it. This process feels more natural: https://phabricator.wikimedia.org/project/board/6/

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.

In T1298#850429, @chasemp wrote:

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.

A task in the Personal Requests column implies that

• it would be useful to have in wikimedia.phabricator.org (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 #phabricator.org

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

Personal Requests: default for all tasks upstreamed

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

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.

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.

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

I'm updating the Phabricator.org 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.

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?

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).