Page MenuHomePhabricator

evaluate priorities of Wikimedia-svg-rendering-tasks
Open, Needs TriagePublic

Description

I made a table contain containing all 94 tasks and tried to order them by priority from 1 (hightest) to 94 (lowest) at https://www.mediawiki.org/wiki/User:JoKalliauer/phab/wikimedia-svg-rendering#table which is sortable by the individual columns.

37 of 94 Task did not contain a Priority, I tried to triage them.

The current priorities are imho sometimes a bit inconsistent: T36947 is currently set to high but it can be solved by e.g. tasks that are set to low: T265549 or T40010. Try to make it a bit more consistent, but generally tried to keep the old priority if set.

Currently "Wikimedia-svg-rendering" has two boards: "Backlog" and "Fonts to install", however I would like to split them more well-arranged in 8 boards, otherwise it is dificult to have a clear view:

  • Backlog (3tasks)
  • Fonts (11tasks)
  • MediaWiki (21tasks)
  • Client-side-rendering (7tasks)
  • update librsvg (28tasks)
  • Unresolved librsvg-bug (20tasks)
  • Math formula (4tasks)

I would set everything that is "Fixed Upstream" or "Upstream" to "Stalled", and setting them the "Fixed Upstream" a subtask of update librsvg (T193352 till 2.42; after 2.42: T265549 ). WMF won't repair svg-rendering, so it is something WMF can't realistically fix (without update/changeing renderer).

The duplicates I will suggest/discuss at the individual task, before taking an action. The suggested declined/invalid ones, I might mention them to think about it, but I would keep them open for now.

I made the columns "related to 40010" and "related to Math formula", 1==true means it is related. 54 Tasks are related to T40010, which has the highest number of subscribers, thats the reason why it is the only one where I would use "high" priority.

I made the coloums "Update to librsvg 2.51", "resvg", "Inkscape", 1==true mans that is fixed, 0==false means it is not fixed, empty means that it is not related.
*Updating librsvg fixes 28 tasks (not counting the two update libsvg-tasks)
*resvg fixes ~45 tasks
*inkscape fixes ~41 tasks

I highlighted in yellow the suggested changed priorities and the suggested changed status, see https://www.mediawiki.org/wiki/User:JoKalliauer/phab/wikimedia-svg-rendering#table (The table is too complicated for phab, and on phab it would not be sortable. )

Event Timeline

Whou, impressive. Thanks a lot for your work!

Quick comments: The columns above seem to mostly use the concept of categories but there is also one column ("discuss") which uses the concept of progress. In my understanding, columns should only be used for one or the other concept, because tasks can only be in one column at the same time.

I'd also love to avoid duplicating already existing information ("Upstream", "Fixed upstream" expressed by the Upstream tag) to get out of sync in several places but I have no good idea how to avoid that here either (Herald rules do not support column moves, and workboard column triggers do not look feasible either). Sigh. :-/

"Fixed upstream" sounds like a subset of "Upstream", latter could be maybe renamed to "Unresolved upstream" or so?

Organizing by category is better in this situation, because Wikimedia-SVG-rendering has been used as a bit of a catchall for SVG-related tasks. Some of what you have categorized as "MediaWiki" would actually fall under Thumbor, while others fall under MediaWiki-File-management or other MediaWiki components. I don't know how useful separating these two would be on this board however, and they're already identified by tags.

Priorities are really related to how likely we are to write code or make changes to Wikimedia infrastructure (including backports) to fix this particular bug. Most tasks fixed by upgrading librsvg are Low, because there's no reasonable way to fix them outside of librsvg, but we will fix them eventually by upgrading librsvg. Bugs that librsvg haven't fixed yet are often going to be Low or Lowest for similar reasons - if there's no reasonable workaround, and nothing we could even backport, there's not much for us to do yet.

Organizing by category is better in this situation, because Wikimedia-SVG-rendering has been used as a bit of a catchall for SVG-related tasks. Some of what you have categorized as "MediaWiki" would actually fall under Thumbor, while others fall under MediaWiki-File-management or other MediaWiki components. I don't know how useful separating these two would be on this board however, and they're already identified by tags.

Thank that are valuable comments, I might have to rethink the suggested categories. The category which was missing for me is "Upstream (librsvg)" in Thumbor , which I did not found, I searched it in Wikimedia-SVG-rendering . The categorizing is for me a bit opaque. (Not knowing how it should be done better.)

I find the "Backlog" category in Wikimedia-SVG-rendering overcrowded by mixed, hardly related, topics.

I would like a #librsvg project-tag, which should be a subproject of Thumbor and Wikimedia-SVG-rendering . (I think sub-projects are not possible on phab?)

Priorities are really related to how likely we are to write code or make changes to Wikimedia infrastructure (including backports) to fix this particular bug. Most tasks fixed by upgrading librsvg are Low, because there's no reasonable way to fix them outside of librsvg, but we will fix them eventually by upgrading librsvg. Bugs that librsvg haven't fixed yet are often going to be Low or Lowest for similar reasons - if there's no reasonable workaround, and nothing we could even backport, there's not much for us to do yet.

Are you saying this issue T282740 about evaluating priorities or T280718 update font list might be high priority because it is imho likely to be implemented, but T36947 font-kerning which is currently marked high should be lowest, because it is for MediaWiki a wont-fix-bug? Sounds strange to me, maybe I misinterpreted/missunderstood your comment.

I don't have much knowledge about phabicator (e.g. not as much as you), but I would prioritize them generally according the importance for the community/reader . However e.g. Client-side-rendering would solve allmost all reported bugs (e.g. all high prioritized bugs), however it is imho so far away, that I prioritized them only low, however publish an update a font-list is something reades don't care, however it got the same priority, because It's easy to implement. So the priortiy is imho about the benefit-cost ratio.

Let's assume a security-bug, were someone can hack all wikimedia-servers and get's full ownership, it would be imho a "unbreak now" isssue even knowing nobody could fix it. (A bit philosophical, because a can't-fix-bugreport does not help anyone.)

Or let's assume the opposite, a bug nobody cares, which is not even worth spend reading it, does not get high priority, just because all bugs in that category will get fixed within a week by someone volunteering.

I would like a #librsvg project-tag, which should be a subproject of Thumbor and Wikimedia-SVG-rendering . (I think sub-projects are not possible on phab?)

Phabricator supports subprojects but it depends on which problem you think would be solved by that (and also if Thumbor maintainers think it would help). :)

I think this also welcomes input from @Gilles as Thumbor maintainer with regard to workflow preferences, as Thumbor is the closest software part to dealing with SVG files here apart from librsvg itself (in my understanding).