Page MenuHomePhabricator

Decide Phabricator improvements to be funded by WMF Technical Collaboration
Closed, ResolvedPublic

Description

The WMF Technical Collaboration team has some FY2015-16 budget available for Phabricator improvements. Let's agree on a sorted list of Phabricator improvements that could be proposed to Phacility Inc (Phabricator maintainers) for their prioritization, and then let's fund those that can be agreed with upstream and fit our budget.

Basic rules of this game:

  • Technical Collaboration funds, and therefore the features proposed need to have clear benefit for volunteers.
  • Proposals need to be presented in the form of existing or new tasks. Discussions specific to those improvements go to the tasks themselves. Here we discuss prioritization between tasks and other general topics.
  • We will not argue with upstream about the convenience of certain improvements. If a proposal fits their roadmap, good. If not, that will be the end of the discussion within the scope of this task.
  • This budget needs to be spent within this fiscal year (end of June), and counting back steps this means that we need to make quick decisions. In case of getting stuck in long debates, the TC team will make the last call, say by the end of May.

Improvements confirmed

Candidates

The list of candidates is closed now. We are drafting its prioritization in our discussion with the Phabricator maintainers. If you want to suggest changes in this list (additions / removals) or changes in priorities, please post them in a new comment.

  1. T136071: Get Phabricator i18n ready for translatewiki.net
  2. T76732: Exact matches should always win when suggesting/auto-completing
  3. T33: Phabricator should let you add dependencies both ways (depending and blocking)
  4. T75851: Email notification for "edited the task description" does not contain the actual content changes (diff) nor a link
  5. T234: Projects dropdown should offer project descriptions
  6. T96464: Upon edit, a task description which mentions a Phab user (re)adds that Phab user to CC/Subscribers field (missing report upstream)
  7. T1035: Consolidate the many tech events calendars in Phabricator's calendar
  8. T634: pholio/new/ requires drag and drop
  9. T78824: Phabricator task description diffs inaccurate due to 80-character line wrapping
  10. T78078: Videos cannot be viewed without downloading

Lack consensus

If you want to discuss proposals in this list, please do it in their own tasks. Providing common usecases welcome.

Unclear status upstream

Processing

You can help triaging these, moving under Candidates those which show a strong use case and consensus.

Ineligible

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Qgil updated the task description. (Show Details)
Qgil updated the task description. (Show Details)

I have triaged Nemo's proposals. My brain needs some no-Phabricator time ;) and then I will go through Danny's suggestions (thanks!)

Some of mine reports for the record and consideration:

I just commented in the task.

Both are relatively minor details of Calendar. If T1035 is selected for funding, then we can discuss with upstream whether these improvements can be included as well.

Just Closed Invalid upstream...

Some of mine reports for the record and consideration:

I just commented in the task.

So did I... ;-)

Both are relatively minor details of Calendar. If T1035 is selected for funding, then we can discuss with upstream whether these improvements can be included as well.

Sure. I've just added those, which were not mentioned, to triage.

Just Closed Invalid upstream...

Please check my response there - it is quite serious valid point. AFAIK we use such stats to improve the tasks life-cycle...

@Pginer-WMF I guess blocking tasks are ATM only those confirmed (see the task description which contains many tasks which are not added as blockers).

@Pginer-WMF I guess blocking tasks are ATM only those confirmed (see the task description which contains many tasks which are not added as blockers).

If that is the case, I was confused by this line in the ticket description:

Proposals need to be presented in the form of existing or new tasks blocking this one.

@Pginer-WMF I guess blocking tasks are ATM only those confirmed (see the task description which contains many tasks which are not added as blockers).

If that is the case, I was confused by this line in the ticket description:

Proposals need to be presented in the form of existing or new tasks blocking this one.

Hmm, I missed that one ;-) My assumption was according to the task history...

Well, @Qgil will sort it out somehow anyway... ;-)

Just Closed Invalid upstream...

Please check my response there - it is quite serious valid point. AFAIK we use such stats to improve the tasks life-cycle...

I'm not arguing that but see the description of this task

We will not argue with upstream about the convenience of certain improvements.

This is not only about not arguing. We don't have the time to argue in this exercise. :) Since there are so many candidates, if one is problematic then there are more to choose from.

Lists updated with the last round of feedback.

When I proposed to use blockers I wasn't expecting this amount of tasks proposed and this triaging. Propose as you think it makes more sense: I will go through all additions. :)

Just Closed Invalid upstream...

Please check my response there - it is quite serious valid point. AFAIK we use such stats to improve the tasks life-cycle...

I'm not arguing that but see the description of this task

We will not argue with upstream about the convenience of certain improvements.

This is not only about not arguing. We don't have the time to argue in this exercise. :) Since there are so many candidates, if one is problematic then there are more to choose from.

OK, np...
I thought we are going to have our own patches on our instance (ie. like we have specific WMF MediaWiki)...

Lists updated with the last round of feedback.

When I proposed to use blockers I wasn't expecting this amount of tasks proposed and this triaging. Propose as you think it makes more sense: I will go through all additions. :)

Blockers do not make a sense in this task - we would have to add everything which would basically duplicate the Phabricator (Upstream) tag...
We can create new goal which will track those, which will be decided to be fixed.
We can also create a specific column on Phabricator and/or Phabricator (Upstream) workboard.
Many better and more practical ways how to solve that...

I expect a bit more dancing with tasks until the end of this week. Then decisions on Monday, a discussion with the Phabricator maintainers, and hopefully a decision soon after. With this I mean that I don't think we need to touch this organic system that will only last a few days more.

I expect a bit more dancing with tasks until the end of this week. Then decisions on Monday, a discussion with the Phabricator maintainers, and hopefully a decision soon after. With this I mean that I don't think we need to touch this organic system that will only last a few days more.

Sure, I meant it exactly for "after it's decided"...

TTO updated the task description. (Show Details)

Skimming the sections "Users must be able to" in the requirements for our issue tracker (February 2014), I see multiple requirements which are not met yet. Should these be prioritised?

I don't think so; as "[s]ome requirements conflict with each other" so they could not all be fulfilled.

The list of candidates is closed now. We are drafting its prioritization in our discussion with the Phabricator maintainers. If you want to suggest changes in this list (additions / removals) or changes in priorities, please post them in a new comment.

I have proposed a sorted list of candidates based on an estimation of their impact on volunteers. This sorting is simply used to guide our discussion with Phabricator maintainers and the eventual allocation of funds. Tasks can still move up / down the ladder based on the Phabricator roadmap, complexity, dependencies...

Feedback is still welcome. Changes are still possible.

I moved this entry from Candidates to Unclear status upstream:

Happy to move it back to candidates if things are clear soon (was #7).

I've found two more to consider (or at least to add them to the list for possible next batch)

T1176: Get icon and color from API instead of screen scraping
T1177: Get anchors from API instead of screen scraping

At least mentioning them for the record...

Not mine tasks, I've just found them while browsing Phabricator, hence reported them to not be forgotten...

Cc: @valhallasw

I am considering the list of candidates closed. Thank you everybody for your participation!

The next steps for me are the contract approval and tracking the development of these tasks (probably in a new task, closing this one as resolved?)

@Qgil Will there be other round? When?

That's not determined yet and would depend on not-yet-finalized budgets for the next financial year

In such case I have to say, that no matter how much effort all involved people, especially Quim, put in it, it was regretably desperately short period to gather all relevant issues... :-/

As of today there is neither budget nor date for a new round, just like there was neither date nor budget for this round just a month ago. :)

This task is resolved. Let's continue at T136213: Complete the round of Phabricator improvements funded by Wikimedia.

@Ricordisamoa: This task is about upstream work, and T133825 is correctly not tagged as upstream.

@Qgil Will there be other round? When?

Now that we have the Developer Wishlist, let's use it to propose Phabricator improvements. As long as the Developer Wislist Survey exists, I don't see a reason to maintain a separate Phabricator wishlist.

By the way:

T78236: Phabricator silently overwrites changes (no mid-air collision/conflict detection) (upstream is not confident of implementing a satisfactory solution before resolving other dependencies first. They note that T765: Enable notification server (real-time pop-up notifications) in Phabricator reduces the need for such feature.)

No, it doesn't. Let's not mix unrelated things, especially when the "alternative" pseudo-solution is much more complex. (I certainly don't pay attention to notifications while I'm editing a task, and I'm often not subscribed at all.)