MediaWiki

Developer Wishlist/2017/Tools (Phabricator, Gerrit, etc.)

< Developer Wishlist
Developer Wishlist 2017
Tools (Phabricator, Gerrit, etc.)

17 proposals, 67 editors, 144 votes

The voting phase has concluded. Thanks for participating!

You can view the results or discuss how to follow up.


Allow to search tasks about MediaWiki core and core only (create MediaWiki umbrella project?)

Tracked in Phabricator
Task T76942

As a user looking for a report about a MediaWiki core bug, I want to quickly look for it without bothering about non-core reports or specific components/projects, so that I find what I'm looking for before I give up out of desperation.

Currently, I must type N MediaWiki core projects manually in the "Projects" field. (Cf. https://secure.phabricator.com/T3670#65849, first bullet.)

Endorsements (T76942)

  1. I really hate the lack of what we called "products" in bugzilla. It's really hideous to not be able to look for certain errors I may want to fix in MediaWiki, for instance: I'm forced to do searches with dozens of projects. Most of the time I just give up. This also causes conflict between the different usages of the issue tracker, because for instance any Wikimedia-specific of non-coding task ends up adding noise to the searches of anyone who is interested in MediaWiki development only. This is therefore an important impairment to our ability to involve more people in MediaWiki development, and an extremely sad indicator of out total lack of interest in providing non-Wikimedia people with real ways to be involved. Nemo 09:53, 14 February 2017 (UTC)[reply]

Support (T76942)

  1. Greg (WMF) (talk) 17:54, 6 February 2017 (UTC)[reply]
  2. Krinkle (talk) 19:58, 6 February 2017 (UTC)[reply]
  3. Nikerabbit (talk) 08:11, 7 February 2017 (UTC)[reply]
  4. Matěj Suchánek (talk) 13:58, 7 February 2017 (UTC)[reply]
  5. Mglaser (talk) 10:23, 13 February 2017 (UTC)[reply]
  6. James Martindale (talk) 17:05, 13 February 2017 (UTC)[reply]
  7. Martin Urbanec (talk) 18:15, 13 February 2017 (UTC)[reply]
  8. Nemo 09:50, 14 February 2017 (UTC)[reply]
  9. Quiddity (WMF) (talk) 20:00, 14 February 2017 (UTC)[reply]
  10. Volker E. (WMF) (talk) 23:01, 14 February 2017 (UTC)[reply]

Automatically add "patch-for-review" tag when `arc diff`

Tracked in Phabricator
Task T150510

Problem

In contrast to Gerrit patches with "Bug: TXXXXXX" in the commit message, there is no "patch-for-review" tag added for Differential patches on arc diff.

Who would benefit

The tag is helpful to maintain better overview on the state of tasks for developers and product managers in workboards, like for example #ui-standardization-kanban Currently you have to manually add the tag, see T147612: Variable naming in WikimediaUI Base as comparison.

Proposed solution

Add #patch-for-review tag when triggered trough valid commit message at arc diff.

Endorsements (T150510)

Support (T150510)

Re-evaluate how we implement phabricator's search engine

Tracked in Phabricator
Task T146843

IMPORTANT: Experimental elasticsearch support has been enabled, to try it out please do the following. Enter something in the searchbar then you will get a url like https://phabricator.wikimedia.org/search/query/.trvn2LNszXn/#R please replace #R with ?elastic=1 which will give you elasticsearch results, example elasticsearch url https://phabricator.wikimedia.org/search/query/.trvn2LNszXn/?elastic=1


When we originally deployed Phabricator, we started out using the #ElasticSearch back-end for searching phabricator Tasks / Objects. Unfortunately, after launching with #elasticsearch there were quite a few user complaints about unexpected search behavior and we eventually made the (IMO, somewhat hasty) decision to switch to using the MySQL Full-text search backend.

Now that we reached the scalability limit of MyISAM fulltext search, we've been sort of forced to switch to Innodb Fulltext search (see T146673: Contention on search phabricator database creating full phabricator outages)... The fulltext search feature in innodb is not as mature as MyISAM fulltext. The ranking algorithm is very simplistic and I expect results to be lower quality than before.

ElasticSearch should be far superior to mysql for implementing phabricator search. Lets try again to solve the problems with phabricator's elasticsearch integration rather than settling for a much worse search experience in Innodb.

A bit of history

There is quite a bit of history behind Phabricator's search implementation. Some of the more relevant tasks I was able to dig up are linked below:

Original ElasticSearch task

T95: Use ElasticSearch backend for Maniphest to get stemming feature

Stuff about switching to MySQL

T75854: Fix provided search results in Wikimedia Phabricator T86805: Lots of unrelated results when searching for specific string

Problems after switching to Mysql

T89274: Mysql search issues flagged by Phabricator setup T146789: Phab Advanced Search no longer showing typical results


Endorsements (T146843)

Support (T146843)

  1. EEvans (WMF) (talk) 13:35, 6 February 2017 (UTC)[reply]
  2. Amir E. Aharoni (talk) 14:04, 6 February 2017 (UTC)[reply]
  3. Greg (WMF) (talk) 17:53, 6 February 2017 (UTC)[reply]
  4. Santhosh.thottingal (talk) 03:39, 7 February 2017 (UTC)[reply]
  5. BSitzmann (WMF) (talk) 22:59, 11 February 2017 (UTC)[reply]
  6. Nemo 09:56, 14 February 2017 (UTC)[reply]

Small enhancements to current system of dumps

Tracked in Phabricator
Task T155697

I know dumps are being re-written but it's taking several years so in the mean time, it would be great to have small enhancements (low hanging fruits) to the current system:

  • Make it faster and nimble:
    • Remove Yahoo! summaries: For example it's 38 GBs for Wikidata and it slows down the whole process of generating dumps for all wikis. The Yahoo! itself is about to die and I don't know why we keep doing this.
    • Keep one compression method and abandon the other. Why we build two dumps one for 7z and one for bz2?
  • Notifications: I would love to receive an email once the monthly dump of Wikidata is done so I can run some checks and fix it on-wiki. (It's already possible and now documented)
  • UI. It's so 1990s. Please have something a little bit prettier.


Endorsements (T155697)

  1. This topic is extremely important but I have no idea how it fits in this page. Nemo 10:02, 14 February 2017 (UTC)[reply]

Support (T155697)

  1. Krinkle (talk) 19:52, 6 February 2017 (UTC)[reply]
  2. Santhosh.thottingal (talk) 03:40, 7 February 2017 (UTC)[reply]
  3. Headbomb (talk) 20:59, 8 February 2017 (UTC)[reply]
  4. Smalyshev (WMF) (talk) 02:30, 10 February 2017 (UTC)[reply]
  5. These particular fixes are not crucial but I'd like to see signs of progress in the dumpfile-related-area  :-) 47.222.203.135 18:18, 13 February 2017 (UTC)[reply]
  6. Framawiki (talk) 18:00, 14 February 2017 (UTC)[reply]

Consolidate the many tech events calendars in Phabricator's calendar

Tracked in Phabricator
Task T1035

We have three problems related to calendars that need to be resolved, which are related but perhaps may be fixed separately, even at different points in time:

  • Introducing calendar data. Now we are doing this in 1001 places. Ideally it would be just one place. The assumption of this task is that the one place would be Phabricator's calendar (today a prototype), but other candidates should be considered.
  • Pulling calendar data in other supports, mainly wiki pages. While we could start linking from wiki pages to Phabricator calendar queries, the desired scenario would be a way for editors to embed calendars based on queries in wiki pages. This probably implies a Calendar API to query data (which is missing) and a MediaWiki extension allowing to embed those queried calendars in wiki pages (which we don't have). Maybe this is just too much, and at least the tech-inclined Wikimedians would be fine clicking a Phabricator link.
  • Integrating calendar data with other systems (mainly Google Calendar). "Future work" upstream, no plans today.

As we can see, deciding on Phabricator Calendar as the one place to introduce data would not provide a quick path to use that data out of Phabricator. However, what would be the alternatives? Other than defaulting to Google Calendar (which I think would be wrong as a matter of Wikimedia principles), I don't see a shortcut but others may have better ideas.

Phabricator Calendar in a nutshell

After playing a bit with https://phabricator.wikimedia.org/calendar/, I think the most practical option is to focus on having that calendar up to date, and then link to it from the right places in mediawiki.org.

  • Entering events is simpler. The usual you can expect in a calendar application. There is no need to archive past events, since this is done automatically.
  • Users can RSVP, getting notifications about the event and letting others know that they are attending.
  • The calendars shown are the result of queries allowing for multiple parameters, including month view vs list, show only upcoming events, etc. These queries have static URLs.
  • Events can be assigned to projects, which means that
    • We could have projects for i.e. Tech Talks, Technical Office Hours, etc, people could subscribe to these projects and receive notifications when a new event is filed.
    • By adding an event to existing related projects (i.e. #Web-APIs-hub, #Google-Summer-of-Code-2015), users following that project would receive notifications as well.
    • Queries can be fine tuned to show a specific set of events.

If we agree on this, the implementation would be relatively simple, since (at least in Wikimedia tech) a few people create most of the events. Redirecting from the current calendar pages to their equivalent Phabricator calendar queries should be enough to tell current users about these calendars about the new way to create new events.

Basic review of existing MediaWiki extensions

I went through https://www.mediawiki.org/wiki/Extension:Calendar (a linkhub for the ~12 different extensions or methods of integrating calendars with MediaWiki). There was no extension surviving a basic check against our needs. In fact, most of them are more than abandoned, and in general they focus on presentation, not on easy input, even less on semantic data (except the SemanticMediaWiki one, perhaps). SimpleCalendar looks like the only candidate if we would ever want to start from this point.

The reason for a lack of a proper MediaWiki Calendar extension may well be that MediaWiki was not designed to input calendar data, subscribe to events, etc.

After this short investigation, I still think that it is better to start from something other than MediaWiki, and the main candidate keeps being Phabricator. Then work separately in a way to import Phabricator Calendar data and present it in MediaWiki pages.

Background / previous description

https://www.mediawiki.org/wiki/Project:Calendar has a lot of room for improvement. Creating tasks is not trivial, and although the calendar can be watched and the entries appear in the mediawiki.org homepage, it doesn't have any of the features expected nowadays in an online calendar, i.e. integration with the calendar apps people use to organize their lives.

Also, for some low hanging fruit, a reporter explains in an email:

the whole project:calendar page hierarchy is confusing - I would avoid subpages at more than one level deep

It's not clear to me why this page is in the Project: namespace to begin with https://www.mediawiki.org/wiki/Project:Namespaces seems to suggest the Project: namespace is for "organization of mediawiki.org", which does not describe this page see https://meta.wikimedia.org/wiki/Tech for a better way to provide consistent navigation/page structure across a set of dispersed pages without use of subpages you asked :)

Endorsements (T1035)

  1. Usually task authors on Phabricator wants to know, when a patch was deployed to WMF wikis. But it is usually hard to find out this information. Some type of collective calendar would really help Dvorapa (talk) 09:28, 6 February 2017 (UTC)[reply]

Support (T1035)

  1. Dvorapa (talk) 09:23, 6 February 2017 (UTC)[reply]
  2. Smalyshev (WMF) (talk) 02:30, 10 February 2017 (UTC)[reply]
  3. SamanthaNguyen (talk) 03:42, 10 February 2017 (UTC)[reply]
  4. B20180 (talk) 13:47, 14 February 2017 (UTC)[reply]

Enable Gerrit reviewers-by-blame plugin

Tracked in Phabricator
Task T101131

Per discussion in T91190: When uploading a new patch, reviewers should be added automatically, it would be nice to enable reviewers-by-blame which helps inexperienced developers find the right person for code review. (I'm not sure what the roadmap is for Gerrit -> Phabricator migration - please decline if it's too close for Gerrit improvements to be worth the effort. Closest Phabricator equivalent I have found is phabricator:T1743, still under development.)

Endorsements (T101131)

Support (T101131)

  1. Tim Landscheidt 11:31, 6 February 2017 (UTC)[reply]
  2. Tgr (WMF) (talk) 09:03, 8 February 2017 (UTC)[reply]
  3. FFS Talk 10:54, 8 February 2017 (UTC)[reply]
  4. Cindy.cicalese (talk) 14:15, 8 February 2017 (UTC)[reply]
  5. Smalyshev (WMF) (talk) 02:31, 10 February 2017 (UTC)[reply]
  6. JustBerry (talk) 04:34, 11 February 2017 (UTC)[reply]
  7. Mglaser (talk) 10:24, 13 February 2017 (UTC)[reply]
  8. James Martindale (talk) 17:06, 13 February 2017 (UTC)[reply]
  9. Matěj Suchánek (talk) 21:10, 13 February 2017 (UTC)[reply]

All projects should have an "Open Tasks" view in their sidebar

Tracked in Phabricator
Task T127903

I used to be able to click a tag, click "open tasks" on the sidebar and see a list of open reports for that project. (T89865: Phabricator project page should not default to workboard made that slower but still feasible, at least for people with good enough CPUs and networking.) Nowadays, I have no idea how to reach the same result in less than 10 clicks or so: can someone point out a way? Thanks.

Upstream task (with potential Phabricator extension code): T10308: Please undo some changes

Endorsements (T127903)

  1. I'm not sure I share the current proposal, but the problem is very real. Nemo 10:02, 14 February 2017 (UTC)[reply]

Support (T127903)

  1. Amir E. Aharoni (talk) 14:04, 6 February 2017 (UTC)[reply]
  2. Krinkle (talk) 19:53, 6 February 2017 (UTC)[reply]
  3. [[kgh]] (talk) 23:28, 6 February 2017 (UTC)[reply]
  4. Santhosh.thottingal (talk) 03:41, 7 February 2017 (UTC)[reply]
  5. Info-Screen (talk) 05:48, 7 February 2017 (UTC)[reply]
  6. Ladsgroup (talk) 07:17, 7 February 2017 (UTC)[reply]
  7. Matěj Suchánek (talk) 13:56, 7 February 2017 (UTC)[reply]
  8. Tgr (WMF) (talk) 09:06, 8 February 2017 (UTC)[reply]
  9. Cindy.cicalese (talk) 14:16, 8 February 2017 (UTC)[reply]
  10. Ciencia Al Poder (talk) 12:00, 12 February 2017 (UTC)[reply]

[MediaWiki-commits] Reverts are not notified by gerrit

Tracked in Phabricator
Task T49252

New changesets which are reverts, and the respective comment on the reverted change, are not announced on mailing list; the merge of the revert is. Example: http://blog.gmane.org/gmane.org.wikimedia.mediawiki.cvs/day=20130415/page=7 (59135).

Endorsements (T49252)

Support (T49252)

  1. Liuxinyu970226 (talk) 08:03, 6 February 2017 (UTC)[reply]
  2. Dvorapa (talk) 09:31, 6 February 2017 (UTC)[reply]

Phabricator silently overwrites changes (no mid-air collision/conflict detection)

Tracked in Phabricator
Task T78236

Upstream task for Phriction and Maniphest: https://secure.phabricator.com/T4768

It looks like Phabricator may be unintentionally removing CCs when a comment is submitted shortly after a person subscribes? This is pretty worrying.

Examples: T77611: Investigate Erik's ideas about why enwiki is not equivalent to other wikis, T78116: 503 Varnish error when adding template to a page on Commons., T78607: Update from 1.19 to 1.23 fails: Error: 1054 Unknown column 'page_content_model' in 'field list'., T85196: Checkuser results should update usernames after a user is renamed

Issues with subscribers additions: T96464: Upon edit, a task description which mentions a Phab user (re)adds that Phab user to CC/Subscribers field, T913: Adding subscribers to a Phabricator task should be more lightweight.

Endorsements (T78236)

  1. Quite a relevant defect. In my early days with Phabricator this kind of thing was quite shocking, I guess it can be for any newbie we get in the present and future too. Nemo 10:01, 14 February 2017 (UTC)[reply]

Support (T78236)

  1. Tim Landscheidt 11:32, 6 February 2017 (UTC)[reply]
  2. Bmansurov (WMF) (talk) 14:31, 6 February 2017 (UTC)[reply]
  3. Jdforrester (WMF) (talk) 16:24, 6 February 2017 (UTC)[reply]
  4. — MusikAnimal talk 22:47, 6 February 2017 (UTC)[reply]
  5. Tgr (WMF) (talk) 09:06, 8 February 2017 (UTC)[reply]
  6. Framawiki (talk) 18:01, 14 February 2017 (UTC)[reply]
  7. Quiddity (WMF) (talk) 20:02, 14 February 2017 (UTC)[reply]

Announce all creations, deletions and renaming of gerrit repos (for e.g. translatewiki.net workflow)

Tracked in Phabricator
Task T48982

Creation, deletion and renaming of Gerrit repositories regularly has a very negative impact on the translatewiki.net workflow.

Recently the repo DonationEmailUnsubscribe appears to have been deleted. The repo FundraisingEmailUnsubscribe appears to have been moved from wikimedia to mediawiki, without updating the permissions on the repo, and without updating .gitreview.

Deleting repos causes errors in mass update scripts. They will exit with inexplicable errors, which then means that you have to start chasing ghosts in https://gerrit.wikimedia.org/r/#/admin/projects/

Endorsements (T48982)

Support (T48982)

  1. David1010 (talk) 06:45, 6 February 2017 (UTC)[reply]
  2. Jdforrester (WMF) (talk) 16:24, 6 February 2017 (UTC)[reply]
  3. Nikerabbit (talk) 08:10, 7 February 2017 (UTC)[reply]
  4. Osnard (talk) 11:40, 13 February 2017 (UTC)[reply]
  5. TerraCodes (talk) 21:09, 13 February 2017 (UTC)[reply]
  6. Nemo 09:49, 14 February 2017 (UTC)[reply]
  7. Quiddity (WMF) (talk) 20:03, 14 February 2017 (UTC)[reply]

Phabricator is unfriendly to assistive technology

Tracked in Phabricator
Task T109

Filed upstream: https://secure.phabricator.com/T4843

Nothing ever shows on cursor hover, and none of the popular images (avatars, Phabricator logo, edit menu buttons) include the "alt" attribute.

Actually, the pictures all seem to be added through CSS (as part of background for div, span, and similar tags), which is very bad for screen readers and similar software (IIRC).

Endorsements (T109)

Support (T109)

  1. Dvorapa (talk) 09:32, 6 February 2017 (UTC)[reply]
  2. Charlie Kritschmar (WMDE) (talk) 12:19, 6 February 2017 (UTC)[reply]
  3. Jan Dittrich (WMDE) (talk) 12:46, 6 February 2017 (UTC)[reply]
  4. Prtksxna (talk) 07:52, 7 February 2017 (UTC)[reply]
  5. MHolloway (WMF) (talk) 22:27, 7 February 2017 (UTC)[reply]
  6. Smalyshev (WMF) (talk) 02:32, 10 February 2017 (UTC)[reply]
  7. SamanthaNguyen (talk) 03:43, 10 February 2017 (UTC)[reply]
  8. PaleAqua (talk) 02:03, 14 February 2017 (UTC)[reply]
  9. Volker E. (WMF) (talk) 06:29, 14 February 2017 (UTC)[reply]
  10. Nemo 09:53, 14 February 2017 (UTC)[reply]
  11. Framawiki (talk) 18:02, 14 February 2017 (UTC)[reply]
  12. Quiddity (WMF) (talk) 20:03, 14 February 2017 (UTC)[reply]

Free-form tagging in gerrit

Tracked in Phabricator
Task T37534

As with CodeReview, to organize work. See https://www.mediawiki.org/wiki/Gerrit/Tagging

See Also: http://code.google.com/p/gerrit/issues/detail?id=287

Endorsements (T37534)

Support (T37534)

  1. Nikerabbit (talk) 08:10, 7 February 2017 (UTC)[reply]
  2. Nemo 09:50, 14 February 2017 (UTC)[reply]

Phabricator should suggest possible duplicates when creating a new task

Tracked in Phabricator
Task T45

When you create a new bug report in Bugzilla, you get a list of possible duplicates. I find it useful. It might be even more useful for new users filing what is going to be probably an obvious duplicate.

Upstream ticket: https://secure.phabricator.com/T4828

Endorsements (T45)

  1. An obvious deficiency of Phabricator compared to modern issue trackers. Not necessarily the worst thing in this page though. Nemo 09:58, 14 February 2017 (UTC)[reply]

Support (T45)

  1. Info-farmer (talk) 05:25, 6 February 2017 (UTC)[reply]
  2. Shizhao (talk) 07:02, 6 February 2017 (UTC)[reply]
  3. —Mainframe98 talk 09:28, 6 February 2017 (UTC)[reply]
  4. Dvorapa (talk) 09:32, 6 February 2017 (UTC)[reply]
  5. Ladsgroup (talk) 10:01, 6 February 2017 (UTC)[reply]
  6. Frettie (talk) 10:07, 6 February 2017 (UTC)[reply]
  7. Tim Landscheidt 11:33, 6 February 2017 (UTC)[reply]
  8. ·addshore· talk to me! 12:21, 6 February 2017 (UTC)[reply]
  9. Xaosflux (talk) 12:25, 6 February 2017 (UTC)[reply]
  10. Jan Dittrich (WMDE) (talk) 12:46, 6 February 2017 (UTC)[reply]
  11. Matěj Suchánek (talk) 14:25, 6 February 2017 (UTC)[reply]
  12. Bmansurov (WMF) (talk) 14:33, 6 February 2017 (UTC)[reply]
  13. Jdforrester (WMF) (talk) 16:24, 6 February 2017 (UTC)[reply]
  14. EBernhardson (WMF) (talk) 17:57, 6 February 2017 (UTC)[reply]
  15. Niedzielski (talk) 19:10, 6 February 2017 (UTC)[reply]
  16. Krinkle (talk) 19:56, 6 February 2017 (UTC)[reply]
  17. Miriya52 (talk) 21:22, 6 February 2017 (UTC)[reply]
  18. SamanthaNguyen (talk) 22:14, 6 February 2017 (UTC)[reply]
  19. Daniel Mietchen (talk) 22:39, 6 February 2017 (UTC)[reply]
  20. — MusikAnimal talk 22:47, 6 February 2017 (UTC)[reply]
  21. [[kgh]] (talk) 23:29, 6 February 2017 (UTC)[reply]
  22. Santhosh.thottingal (talk) 03:41, 7 February 2017 (UTC)[reply]
  23. Prtksxna (talk) 07:53, 7 February 2017 (UTC)[reply]
  24. RHo (WMF) (talk) 10:40, 7 February 2017 (UTC)[reply]
  25. Chico Venancio (talk) 13:26, 7 February 2017 (UTC)[reply]
  26. MHolloway (WMF) (talk) 22:27, 7 February 2017 (UTC)[reply]
  27. Tgr (WMF) (talk) 09:07, 8 February 2017 (UTC)[reply]
  28. Trizek (WMF) (talk) 13:10, 8 February 2017 (UTC)[reply]
  29. Cindy.cicalese (talk) 14:17, 8 February 2017 (UTC)[reply]
  30. André Costa (WMSE) (talk) 15:34, 8 February 2017 (UTC)[reply]
  31. Whatamidoing (WMF) (talk) 19:07, 8 February 2017 (UTC)[reply]
  32. Enterprisey (talk) 20:36, 8 February 2017 (UTC)[reply]
  33. Headbomb (talk) 21:01, 8 February 2017 (UTC)[reply]
  34. Edward Chernenko (talk) 22:29, 9 February 2017 (UTC)[reply]
  35. Smalyshev (WMF) (talk) 02:32, 10 February 2017 (UTC)[reply]
  36. JustBerry (talk) 04:35, 11 February 2017 (UTC)[reply]
  37. — Mr. Stradivarius ♪ talk ♪ 08:51, 11 February 2017 (UTC)[reply]
  38. BSitzmann (WMF) (talk) 22:55, 11 February 2017 (UTC)[reply]
  39. Helder 17:48, 12 February 2017 (UTC)[reply]
  40. Mglaser (talk) 10:22, 13 February 2017 (UTC)[reply]
  41. Sebastian Berlin (WMSE) (talk) 10:31, 13 February 2017 (UTC)[reply]
  42. Martin Urbanec (talk) 18:15, 13 February 2017 (UTC)[reply]
  43. TerraCodes (talk) 21:09, 13 February 2017 (UTC)[reply]
  44. Volker E. (WMF) (talk) 06:29, 14 February 2017 (UTC)[reply]
  45. Phuedx (WMF) (talk) 15:54, 14 February 2017 (UTC)[reply]
  46. Sage (Wiki Ed) (talk) 17:47, 14 February 2017 (UTC)[reply]
  47. Framawiki (talk) 18:02, 14 February 2017 (UTC)[reply]
  48. Quiddity (WMF) (talk) 20:04, 14 February 2017 (UTC)[reply]
  49. Dave Braunschweig (talk) 21:54, 14 February 2017 (UTC)[reply]

Cannot disable "Notify" for token award in phabricator

Tracked in Phabricator
Task T91289

Upstream report: https://secure.phabricator.com/T7468

I am missing a way to disable the "Notify" when a task was getting a token.

In the Email Preferences under https://phabricator.wikimedia.org/settings/panel/emailpreferences/ I have not found a way to disable this. I did not need tokens and therefore no notify if a subscribed task get a token.

Endorsements (T91289)

Support (T91289)

  1. Nemo 09:57, 14 February 2017 (UTC)[reply]

Phabricator email notifications should bundle events as the web interface does

Tracked in Phabricator
Task T85305

As a user with limited email digesting capabilities*, I want phabricator to make some basic digesting on my stead, so that I'm not overwhelmed; and to have a consistent behaviour across web interface and emails, so that I'm not confused.

I. Observed: the web interface bundles/digests/collates tightly connected events by a single user under a single header/timestamp, e.g. https://phabricator.wikimedia.org/T85304#943638 . The emails instead show separately the actions which were made separately. Not only the additional emails are annoying, but whether some actions were made together or in multiple steps is totally irrelevant for me as a subscriber, to the point they're often impossible to verify in the web interface (because not displayed). II. Expected: a single email should be sent for all the events which the web interface bundles together. A delay in sending the email notifications may be added, if needed for this purpose.

(*) Note: I don't fall in this category so I don't have a COI in filing this task.

Endorsements (T85305)

Support (T85305)

  1. James Martindale (talk) 17:03, 13 February 2017 (UTC)[reply]
  2. Nemo 09:57, 14 February 2017 (UTC)[reply]

Duplicate tasks are not listed in or near the description of the target task

Tracked in Phabricator
Task T883

As a user, I want to have a list of tasks currently marked as merged to the one I'm reading, so that I know what are the tasks currently marked as merged to the one I'm reading.

The description of T857: Imported bugs from bugzilla should be assigned the same number as their bugzilla ID (i.e. Bug 1 -> Task 1; Bug 2007 -> Task 2007) has no mention of the fact T625: Bug 1 be bug 1 was merged into it. The fact should be noted:

  • in or around the description, with a list of all merged tasks (as with blocking tasks);
  • in the history of actions/comments [this is currently satisfied, but hard to find].

Endorsements (T883)

Support (T883)

  1. Liuxinyu970226 (talk) 08:03, 6 February 2017 (UTC)[reply]
  2. James Martindale (talk) 17:05, 13 February 2017 (UTC)[reply]
  3. Nemo 09:54, 14 February 2017 (UTC)[reply]
  4. Framawiki (talk) 18:02, 14 February 2017 (UTC)[reply]
  5. Quiddity (WMF) (talk) 20:05, 14 February 2017 (UTC)[reply]
Tracked in Phabricator
Task T687

In comments, [Bb]ug #?<N> should be parsed as T<N+2000>: that is, "bug 323" would be rendered as T2323; or converted to "bug 323 ([1])". Ideally, the full bugzilla syntax would be parsed/converted, see https://bzr.mozilla.org/bugzilla/4.4/view/head:/Bugzilla/Template.pm#L234

Potentially incomplete proposal:

string in comment to become
[Bb]ug 9123000 bug 9123000 (T9125000)
[Bb]ug #9123000 bug 9123000 (T9125000)
[Bb]ug #?9123000,? [Cc]omment #?123 bug 9123000 - comment 123 (T9125000)
[Bb]ug 9123000#c123 bug 9123000 - comment 123 (T9125000)
http://bugzilla.wikimedia.org/show_bug.cgi?id=9123000 http://bugzilla.wikimedia.org/show_bug.cgi?id=9123000 (T9125000)
https://bugzilla.wikimedia.org/show_bug.cgi?id=9123000 https://bugzilla.wikimedia.org/show_bug.cgi?id=9123000 (T9125000)
http://bugzilla.wikimedia.org/9123000 http://bugzilla.wikimedia.org/9123000 (T9125000)
https://bugzilla.wikimedia.org/9123000 https://bugzilla.wikimedia.org/9123000 (T9125000)
http://bugs.wikimedia.org/show_bug.cgi?id=9123000 http://bugs.wikimedia.org/show_bug.cgi?id=9123000 (T9125000)
https://bugs.wikimedia.org/show_bug.cgi?id=9123000 https://bugs.wikimedia.org/show_bug.cgi?id=9123000 (T9125000)
http://bugs.wikimedia.org/9123000 http://bugs.wikimedia.org/9123000 (T9125000)
https://bugs.wikimedia.org/9123000 https://bugs.wikimedia.org/9123000 (T9125000)

Use case:

@Chasemp: For sentences imported from Bugzilla tickets in comments like

* Bug 12345 has been marked as a duplicate of this bug. *

(yes, those are three stars at the start of the line turned into a bullet point, meh, another cosmetic thingy)

I know that some folks like to look at duplicates because they might provide more information about a bug and clicking instead of manual copy and paste fiddling sounds easier...

@chasemp: If a volunteer (or me) wanted to work on this, what would be needed? Write code with regexes and set up a bot for it?

Could a volunteer work on this task (or if not fully, how much of this task)?

I'm not sure how the bot fits in, but I am also thinking of this as a historical one-time fixup. I never had any plans for an ongoing translator. This is a straight mysql job in the first case which means simpler and more dangerous :)

This really doesn't require me / privs to write the job, only to validate / run it. It could easily be worked on on phab-01 or whatever.

The off-the-cuff break down to achieve this for

comments:

1. Find all issues that were historically BZ using the custom reference field 2. use the task PHID to find all comment type transactions 3. use the comment transaction to find the actual comment itself 4. retrieve the comment content from the db (assuming we only want to mangle comments from before migration) 5. Run some kind of transform on the content (regex based changing Bug: Foo to Bug: Bar or whatever), and write the output back as the content. 6. Repeat for every comment on every BZ imported task 7. Wipe remarkup cache

descriptions

1. Find all issues that were historically BZ using custom reference field 2. retrieve the task desription (is this stored as a transaction now or not, I'm not sure anymore?) 3. Perform same regexy type logic as above and update description 4. Repeat for every task from BZ 5. Wipe remarkup cache


The good news is a basic framework for this would handle all cases, and it's not too hard to write this, just very time consuming to make sure it's not doing something awkward and untoward.


Endorsements (T687)

  1. I think it's probably too late to fix things, and we must be happy that at least the numbering was corrected by a committed person in the latest phases of the migration phase. But this is indeed one of the most evident ways that the hasty ditching of bugzilla caused us a long-term harm. Nemo 09:56, 14 February 2017 (UTC)[reply]

Support (T687)

  1. Shizhao (talk) 07:03, 6 February 2017 (UTC)[reply]
  2. This, that and the other (talk) 08:21, 6 February 2017 (UTC)[reply]
  3. —Mainframe98 talk 09:28, 6 February 2017 (UTC)[reply]
  4. Amir E. Aharoni (talk) 14:05, 6 February 2017 (UTC)[reply]
  5. Tgr (WMF) (talk) 09:07, 8 February 2017 (UTC)[reply]
  6. Ciencia Al Poder (talk) 11:57, 12 February 2017 (UTC)[reply]
  7. Helder 17:48, 12 February 2017 (UTC)[reply]
  8. Martin Urbanec (talk) 18:08, 13 February 2017 (UTC)[reply]
  9. Matěj Suchánek (talk) 21:09, 13 February 2017 (UTC)[reply]
  10. Framawiki (talk) 17:59, 14 February 2017 (UTC)[reply]
  11. Quiddity (WMF) (talk) 19:59, 14 February 2017 (UTC)[reply]
Retrieved from "https://www.mediawiki.org/w/index.php?title=Developer_Wishlist/2017/Tools_(Phabricator,_Gerrit,_etc.)&oldid=4171341"