| TTO | |
| Nov 25 2014, 8:42 AM |
| F4171601: pasted_file | |
| Jun 16 2016, 12:40 PM |
Glaisher edited the task description. Glaisher set Security to none. TASK DETAIL https://phabricator.wikimedia.org/T18976 REPLY HANDLER ACTIONS etc bla bla bla bla
Doesn't give me a diff, or a link to a diff.
Filed upstream as https://secure.phabricator.com/T7643
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T141457 blog.wikimedia.org post on Phabricator improvements | |||
| Resolved | • mmodell | T137727 Write blog post highlighting recent Phabricator improvements | |||
| Resolved | Aklapper | T136213 Complete the round of Phabricator improvements funded by Wikimedia | |||
| Resolved | None | T75851 Email notification for "edited the task description" does not contain the actual content changes (diff) nor a link |
For what is worth, this is what MediaWiki does as well.
Providing a diff in an email might sound like a good idea, until you get into details. No problem if it's just about adding a couple of lines, and you could even think of replicating the diff UI found on web using HTML. Now, let's look at more complex edits, and let's not forget that Phabricator defaults to plaintext emails. Do we really want to send emails with ++ -- lines to users that might or might not be used to this syntax?
To me this is a dubious case, and if our users can survive with it on MediaWiki, I don't see the need in upstreaming this request for Phabricator in the name of Wikimedia. Proposing to decline this task.
I don't see why it would be too difficult to provide a basic unified diff in the e-mail. From our perspective, most MediaWiki users are familiar with diffs (admittedly, side-by-side diffs, but it's not too hard for them to transfer that knowledge to unified diffs). And Phabricator's infamous "audience statement" does say that Phabricator is destined for technically-savvy users, so diffs ought not to be out of the question upstream.
I should also note that Bugzilla's e-mails provided a diff (in a table) of changes to the bug title, dependencies, etc. Here in Phabricator, the task description is now another one of those metadata fields (unlike in Bugzilla where it was an immutable comment), so I feel that we should get a diff of that as well.
The main reason I filed this task is that the current e-mail for this is rather sad. "Yeah, XYZ edited the task description; sorry, don't know any more." It could at least try a little bit harder and say "30 bytes added" or something like that, but providing a diff would be the most useful thing to do.
As said in my previous comment, MediaWiki doesn't do this either, and therefore Wikimedia users are used to it. Phabricator is not introducing any novelty by doing the same.
For these reasons, I don't feel this is a good request to be made upstream in the name of Wikimedia. You can report it at your own risk, if you want (see T1298 just in case it's useful).
Declining this task.
Is this "decline, closed" as in "you can have useful content in these e-mail messages over my dead body", or "declined, closed" as in "it's not enough of a problem for me to justify expending the resources necessary to fix this"? If the latter, then I suggest that "declined, closed" ought to be removed, and "needs a volunteer" left.
Right now, what I'm getting is an e-mail message that amounts to "Unknown changes were made to a task number you don't recognize with a task title that may be unintelligible to anyone except the original poster and/or have nothing to do with the new contents. Good luck figuring out whether you care about this." This isn't working for me.
I grant that MediaWiki doesn't send diffs in e-mail. However, MediaWiki's mail gives me a direct link to the relevant diffs, which Phabricator doesn't do. MediaWiki also gives me a watchlist with links to the diffs, which Phabricator also doesn't do. If "MediaWiki doesn't do that" is the justification, then let's talk about what MediaWiki DOES do, and how its multiple functionalities easily make up for not actually sending the text of the diff in e-mail. Sending me one-click access to the diff is a very big improvement over sending nothing at all.
Bugzilla gave me what I want for this, which was a simple HTML table that shows the old version and the new version. (It didn't do that for task descriptions, because they couldn't be changed.) If a MediaWiki-style diff is impossible, then how about we just send a copy of the entire task description along, with the first part labeled "NEW VERSION" and the second labeled "PREVIOUS VERSION"? It doesn't really sound that hard to me.
For what is worth, it is possible to configure the option for sending diffs of code patches via email: metamta.diffusion.inline-patches
This is for code in commits, not for text in comments, but at least it is a precedent that might be useful to sell the idea.
This is probably the maximum time-waster in Phabricator for me. I can ignore other bugs that mean that an action takes x + n seconds instead of x seconds because they affect me only when I want to do something and the extra n seconds are not that important, but this bug breaks my whole workflow where I (only) need to read my mails to see if I need to react to something. If someone would fix this, either upstream or locally, highly appreciated.
This is really, really, really annoying. I usually do my basic phabricator stuff in my mail program and only use the browser if I'm further interested or want to write something. The Edited-Mails are the only ones that break this workflow.
I agree that these task edit e-mails are aggravating. It's especially frustrating that, when discussing whether Phabricator should e-mail users by default about their own actions, the argument put forward was that the generated e-mail thread should be a full accounting of what happened to a task. And yet these incomplete task edit e-mails directly stand in the way of providing a complete record of actions to a task.
JIRA has this functionality. For HTML e-mails, JIRA does a visual diff, with red strikethrough for removed parts and green highlighted text showing what was added. For plaintext e-mails, JIRA simply includes the full text of the previous task description and the full text of the current task description. This is a bit ugly, particularly for tasks with long descriptions, but it's still better than Phabricator's current behavior.
@scfc, do any of these unicode-combining-character plain text diff variants render in a reasonable way in your plain text mail client? The intent is that the text "meow" is marked as removed, and the text "woof" is marked as added.
If not, can you suggest a way we could present diffs which would work well (e.g., be readable and relatively unambiguous) in plain text mail?
(They seem fairly bad to me on my system, but I'm having a hard time coming up with any better ideas.)