A very rough version of things is available to play around with on this install, now. I've created two spaces:

Note that you'll be able to search for objects in a specific space using the query interface (T8441) independent of any global settings. So you can always explicitly search for stuff in the "Operations" (or whatever else) space, the product question here is just whether we need additional global/default settings to make "switching into a space" an (optionally) more all-consuming operation.

Thanks for writing that up!

We spent so much time on this it's almost nostalgic now :)

(This is only partially blocked by work described in T7715, but I'm linking it here for completeness and to make it easier for me to dig up.)

In T8434#118735, @Krenair wrote:

So... you propose that we simply kill the ability to add specific users to specific private tasks, is that right?

Users who don't understand it. And - off the top of my head - I'd quite like our custom 'security' option simply be the name of a pre-defined policy (we don't want unprivileged users to be able to set arbitrary policies, that can only result in a mess), but I haven't really thought through all of the implications of this.

In T8434#118741, @aklapper wrote:

In T8434#118719, @Krenair wrote:

In T8434#118707, @epriestley wrote:

• The original reporter can not see the task or any work done on the task, only the separate discussion on their original report. This allows security response to be separated from communication with the reporter.

That does not sound desirable to me in our context

It can be desirable. Being able to exclude reporters/ commenters on certain tasks from certain updates is very useful for handling procurement requests (such an RT feature was used at least by Wikimedia's Operations team).

In T8434#118738, @epriestley wrote:

How would you like the flow where you give permission to new users to work? In T4411, @chasemp expressed some concerns about using CC/Subscribers for this (particularly, that users can add other users to CC). Do you share those concerns, or is adding users to CC to give them rights satisfactory for you?

Fine with me personally, that was the system in BZ. I do wonder what Chris thinks about this now though.

In T8434#118719, @Krenair wrote:

In T8434#118707, @epriestley wrote:

• The original reporter can not see the task or any work done on the task, only the separate discussion on their original report. This allows security response to be separated from communication with the reporter.

That does not sound desirable to me in our context

From https://phabricator.wikimedia.org/T76401, maybe that's actually ideal/desirable, and @chasemp's concerns aren't related to this use case (or perhaps are allayed by "hard spaces")?

How would you like the flow where you give permission to new users to work? In T4411, @chasemp expressed some concerns about using CC/Subscribers for this (particularly, that users can add other users to CC). Do you share those concerns, or is adding users to CC to give them rights satisfactory for you?

In T8434#118721, @qgil wrote:

In general I also like the concept of "hard spaces", simpler to understand
and to protect.

There is this "misuse" case that hard spaces would about: Security team
member leaves the team for some reason while staying as a regular
contributor.... but keeps access to old tasks that he authored. It is
simpler if you are either in our out.

unless the Nuance entry was basically just a special task, where we could have to option to continue as normal while including the reporter

In general I also like the concept of "hard spaces", simpler to understand
and to protect.

In T8434#118707, @epriestley wrote:

• The original reporter can not see the task or any work done on the task, only the separate discussion on their original report. This allows security response to be separated from communication with the reporter.

That does not sound desirable to me in our context (unless the Nuance entry was basically just a special task, where we could have to option to continue as normal while including the reporter), what do you think @csteipp?

Development Log

Yeah, the "Security" use case is letting users see objects in a Space they normally don't have access to because they have some special relationship to those objects (for example, giving users access to security tasks if they reported them).

I read the Nuance description, but it is still unclear to me what it does.

Development Log

Development Log

Since this is a relatively large task that's likely to end up with a hundred thousand subtasks, I'll try to summarize progress here periodically.

This is really helping to improve the code readability. A big welcome change :)
A small learning curve to first discover the "hide comments" feature was needed in the team. [Maybe "X" was making people hesitant].
Not many noises to have the Hide All/Show All feature, but as you said it is a personal opinion.

At HEAD, each inline can now be individually hidden:

@avivey, added your case from D13036 above.

In T7447#112510, @jparise wrote:

I feel like I'm doing something wrong. Perhaps "Done" should only appear once for each group of comments?

In T7447#114151, @asteinlein wrote:

I just want to give a big +1 to this. Even though we don't practice two reviewers, I find it very useful to not be distracted with inline comments when doing a final, read-the-code-undistracted review. Just being able to globally disable forward-transferring comments isn't very useful to us: It totally disables a generally useful feature. Being able to temporarily disable inline comments would help a lot, i.e. as I mentioned before by adding a "view options" for the diff (preferably in addition to a keyboard shortcut, but just a keyboard shortcut is too obscure IMHO).

I second the suggestion to hide all inline comments in a diff view. This does give a easy reading if there are many comments one-after-one.
Something on the lines of D12650.

In T7447#113660, @alancrisp wrote:

Most of the issues our team run into stem from the fact that we can't toggle the comments temporarily in order to get a distraction free view of the code. Some of our inlines spark some quite lengthy discussions which can sometimes get in the way when you only need to see the code.

We do use the diff of diffs feature heavily which helps this, but it's not always an option for a reviewer due to the fact we generally require two accepts on a diff before it lands. It's not uncommon for a diff to be in a second or third iteration by the time a second reviewer starts their own review from scratch. For the second reviewer, seeing previous discussions isn't always useful - it can be, but we also find that often it's desirable just to hide the noise for a minute to view the current code in its entirety before continuing with the review.

Just to demonstrate, this one gave a couple of our devs some grief earlier today. The comments create so much noise you can barely see the loop being reviewed.

Most of the issues our team run into stem from the fact that we can't toggle the comments temporarily in order to get a distraction free view of the code. Some of our inlines spark some quite lengthy discussions which can sometimes get in the way when you only need to see the code.

In situations where ghost comments wind up doing more harm than good, it might be nice to hide them via a keyboard shortcut.

Played a bit with the most recent implementation of this (7c96ba4ced4825b659286f1ecd55e954408b685c) and it seems to work quite well for my use case. We had a few reviews with various comments on different versions, and for the most part, I'm pretty happy with how the current code is pulling them forward. It's not perfect, there are a few cases where stuff is out of context, but I'm partial to having the comment there anyway so I don't forget about it completely, and can go back to the previous diff to read it in context if needed.

I've been enjoying the combination of the "Done" flag and inherited comments, but one thing that I've found bothersome is that I need to click "Done" for each comment in a "thread" to "close out" that line of conversation (once I've actually done the requested thing).

I think we're just coming at this from very different use cases. If a diff has this line:

Let me be clear: I agree with you that there's no ideal implementation here, and it's quite possible to come up with something better/more natural.

Just to double check, you definitely don't want the example in T7447#112231 (where only one character was changed, directly addressing an inline) to port forward in an ideal implementation?

That's interesting, and kind of makes sense. You usually comment on the line that you want to discuss.

If you make a change after the comment, it still ports forward, but any change in the hunk prior to the comment seems sufficient to stop it.

Short answer: Yes.

Here, I directly addressed an inline by making a one-character change:

Here, I changed line 7:

@epriestly, it's doing it here:
https://github.com/phacility/libphutil/pull/45

Ah, I got some of them to port forward.

Given your experience with GitHub Enterprise, would you expect the comments on the pull requests I linked above to be porting across updates if GitHub had behavior equivalent to GHE?

https://github.com/jquery/jquery/pull/1241
https://github.com/blog/785-pull-request-diff-comments

I really suck at online communication, i was referring to Github _enterprise_ in my previous comments. I rarely use github.com, and can't speak to the behavior.

Chad's comment on the diff view didn't port into the file, and didn't port forward when I updated the diff.

None of the comments are visible on this view, either:

Can someone show me how to use this feature on GitHub? For example, my comment here:

It can not possibly do this

We can definitely do what GitHub does (or some reasonable approximation, at least), I just don't want to spend a lot of time implementing it without understanding what problem we're trying to solve here. I thought I understood the problem, but I think that I don't actually have a good understanding of the use cases. I'd like to step back, discuss the problem more to understand exactly what you're after and why what we have isn't working well, and then move forward from there. Specifically, what I'm trying to do is:

Actually, I'm wondering if it's possible to do what github does. I might be incredibly ignorant here, but since Phabricator abstracts over several version control systems, finding the correct context might not be possible in light of git rebases. This might explain why github can collapse (or not) across fairly drastic changes.

What's different about Phabricator which makes the ability to mark your own comments as done important here but not important on GitHub?

One of my main use cases is making sure that inlines survive a rebase, which we use frequently due to how unforgiving arc patch is. If that results in actual hunk changes, I'd still like to see the inline, and decide for myself if (1) it's still relevant, and (2) it still targets the right lines. If it's no longer relevant, it would be nice if I could "dismiss" it, which would stop it from showing up. If it no longer targets the right lines, it would be nice if I could "re-target" it.

Github actually has an algorithm for exactly this that's mostly good.
I've thought about this feature, and would be quite satisfied if I could mark things that I've requested as 'done'

In the general case, it is impossible to bring comments forward on the same line (the line may have been deleted, split into multiple lines, duplicated, completely changed, etc.)

Somewhat already mentioned a few times, but these are the two things me and co-workers noticed after using this feature for a while:

• The comments seem way too large to me. (We have a lot of inline discussion, probably a lot more than happens on this install)
• The "older"/"newer" comments appear on wrong lines a large chunk of the time. This is the most annoying part, I'd say, because a lot of inlines are really specific about what happens on a line.

Those two points aside, this feature is a huge win.

Also, to summarize the recent changes:

(In that mock, imagine that all the "reply" inlines appear in a thread, even though there's technically only one on the mock.)

In T7447#110475, @scohen wrote:

I don't know @epriestley, I found it really confusing to have my comment on a different line entirely.

Combining a coversation to a single box would also help.
+1 to links to the original context.

In T7447#111479, @epriestley wrote:

In T7447#111476, @avivey wrote:

Also, I'm missing a button to "see comment in original context", in cases where the current context is confusing.

I do think this is reasonable. If we un-fold, we could make "Older Comment" / "Newer Comment" be links to the comment in its original context.

In T7447#111476, @avivey wrote:

Also, I'm missing a button to "see comment in original context", in cases where the current context is confusing.

Fold “Done” comments only. Leave “Not Done” open.

Also, I'm missing a button to "see comment in original context", in cases where the current context is confusing.

Other random ideas:

I find that I expand everything I see, even things I "know" I wouldn't find interesting, but I blame this on my private OCD.

What about expand it if it is not done?