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.

In T282740#7091212, @AntiCompositeNumber wrote:

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

In T282740#7091212, @AntiCompositeNumber wrote:

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.

In T282740#7094125, @JoKalliauer wrote:

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

@JoKalliauer: I am not sure how to proceed here...
The question is basically "who works on this" when it comes to issues not in librsvg, and those folks or teams may not necessarily use the Priority field - basically, I don't think it necessarily solves a problem as priorities reflect reality and do not cause it.
If an issue is in librsvg, that's Upstream by definition and I'm afraid that means low priority by default (apart maybe from tasks to upgrade the Debian version on Wikimedia servers, which would bring us more recent librsvg versions and thus fix some tasks). We don't influence upstream priorities here in WM Phabricator. :)

I guess you could create additional workboard columns if someone plans to continuously long-term triage and move tickets into these columns, if you think that these categorizations solve a problem.