The example is pretty descriptive, I'd say. Because of linking to the description of that exact part of the word.

Thank you for exhaustive description. One more question:

Great and very helpful change, thank you!

In T11405#188030, @epriestley wrote:

How about this: we'll play the "5 whys" game described in Describing Root Problems to get to bottom of this problem. After we figure it out, you tell me why you didn't provide that information in the first place and how to improve the documentation so that it's clear what we're after. Sound good?

Fair enough. I'm totally willing to sprinkle my head with ashes after I'll find out what exactly is causing the misunderstanding of what "root cause" is. ;-) But not knowing it is obviously not helpful and leads to the same situation again.

Come on, Evan, seriously? :-/

A small (partially off-topic) note about feed - in such a high traffic Phabricator instance like ours (WMF), it is nearly unusable. Fortiori if there is no (preferably customizable) real feed (Atom, RSS). Lack of feed support in Phabricator is one of its biggest disadvantages. I know there was some task here about it but I can't find it now.

@epriestley When merging task which is clearly speaking about something else (although related), please update the task title and description to contain the data from merged task so they won't get lost. Thank you.

I don't have any idea where further/deeper to go than to what I already described in the description:
User is not interested in being notified about all tasks of the given tag, but only on those which are in particular column.
If you ask "why", I can imagine perhaps "I don't want to be spammed by things I am not interested at".
Perhaps might yet be worth to note, that it obviously applies to boards sorted by categories/area, not progress-wise (Kanban).
I can also assume it is related to discouraging of "tracking tasks" (ie. due to many issues with task graphs) which are typically exactly equal to such workboard column - they "monitor" certain area of the project, so user is subscribed to them, but not watching the entire project.
I don't know what to add more. Better if you ask.

In T4788#185851, @chad wrote:

If you have more than 100 subtasks, the task should probably be a project so it can be properly organized.

And what is the intention behind that? None of those requested information are sensitive.

Also, before that is done, rather than showing "Task graph too large to display ..." message, have fallback to the old plain list of tasks. Therefore the information will still be available, but just simply not provided as fancy...

Re the limiting to hardcoded 100 nodes without any criteria:

The best of the best is of course our https://phabricator.wikimedia.org/T4007 ;-)

All your ghost are belong to us!

Will try to get more details for you from colleagues.

Just found another account disabled couple days ago which also says that doesn't belong to any projects, but some projects list him as a member. So the issue is in current version still present.

Please reopen. It's holidays / long weekend nowadays (CA, US, CZ), so I can't provide ther required stuff immediately. We'll get back to it with more descriptions soon. Thanks.

I found a workaround in the meantime: Press ` and then space (or any other key). The issue obviously is that ` is being sent like dead (combining) key on en-US keyboard layout.

...which takes us back to accesskey...

Ah, then it will be some of our local enhancements... Sorry for bothering then.

Good point, thanks for research. I was looking in some notes from research done several years ago, thus obviously no longer accurate.

Those are all about preferences and JavaScript handling...

That's what I plan. Just tested it on WXPx86 and FF 47.0.1 32bit and it works there.

And FF? And 32 or 64 bit?

@chad Which version of Win & FF you use?

I don't see anything relevant there actually, could you please elaborate?

Tested in both en and cs layouts.

Suggestion from one chat I had:

I mean even having just a "Revert" button for each change would be easier
Even if you had 50 to click, it's better than manually undoing :)

In T10989#176072, @epriestley wrote:

These are third-party extensions, not other upstream applications, right?

Yes.

Why do you consider this to be a bug in Phabricator rather than in those extensions? Does the documentation say "this field is updated only when a 'meaningful' update is made to an object, and you can and should rely on it to have this behavior when extracting data from Phabricator" somewhere?

It's logical - you can not build reasonably working application on wrong dataset. One would assume, that maybe in future, Phabricator (either directly or via an extension) will have support for such stats too (as it currently already has some stats such as burnout charts or so...)
Inability to do such stats due to unreasonable dataset below makes Phabricator (otherwise good application) useless for teams which are trying to improve (read: shorten in this particular case) the task life-cycle - and that's pretty much every team since noone wants to have long time untouched tasks without any action taken... ;-)

But moving on the workboard is no update at all... It is null action.