In T10939#175260, @epriestley wrote:

Pretty sure D15918 is the right/expected rule: if you're an owner of "CSS" and "CSS" is set to "Auto Review: Review Changes (Blocking)", it doesn't trigger for your revisions: you don't need someone else who owns CSS to unblock your changes. Let me know if that defies expectations.

This is being worked on in conjunction with T10939

Yeah, that setting is exactly what I'm getting thanks. Thanks for the info.

This isn't required for our workflow but something that would simplify the implementation for us.

You can edit the urls here: ..../diffusion/..../manage/uris/
The first .... is your domain. The second is the name of the repo.

In T10939#174449, @epriestley wrote:

I guess we could have a third mode like "exclude, sort of". It's intentional that / owns everything by default so I can't go create a /src/ package and steal ownership of all the important code.

In T10939#174447, @epriestley wrote:

Wouldn't that result in aaa getting added to 100% of reviews in a given repo?

They wouldn't be added for changes to /a/e/, but they'd be added to everything else, yeah (albeit indirectly, via packages).

We could possibly encode a "if you own a package which owns some parent directory, even if that package excludes the subdirectory, you can 'clear' instead of 'force clear' the block" but maybe we could just use a soft social sort of hint on that? Like when you go to clear the block, it says "you own a parent thing so this is probably OK" instead of "you'd better be sure or you're gonna get fired".

We don't care about permissions for force-clearing blocking reviewers at all.

In T10939#174442, @epriestley wrote:

I think that already is expressible:

• Package "/": Include /, exclude /a/, exclude /a/b/, exclude /a/d/, exclude /a/e/, owners: aaa
• Package "/a/": Include /a/, exclude /a/b/, exclude /a/d/, exclude /a/e/, owners: aaa, bbb
• Package "/a/b/": Include /a/b/, owners: aaa, bbb, ccc
• Package "/a/d/": Include /a/d/, owners: aaa

In T10939#174438, @epriestley wrote:

This would solve other issues with root owners accepting on behalf of everyone accidentally

This probably is also not really covered by the above, and I think some "Clear (some of the?) blocks I am responsible for, but do not actually accept the revision" is perhaps the best way forward.

In T10939#174439, @epriestley wrote:

Can you walk me though the /a/b/ case in more detail? Maybe I'm misunderstanding.

In T10939#174435, @epriestley wrote:

Another issue that I can't find an existing task for already is that OWNERS are non-hierarchical.

This is only a partial fix, but you can exclude /a/b/ from package /a/ if the owners are disjoint (add it as an "exclude" path instead of an "include" path).

This means "/a/b/ is not part of /a/", not "/a/b/ and /a/ are kind of the same except not really", but I think your wrapper script can express this by making all of the /a/ owners also owners of /a/b/, and then excluding /a/b/ from /a/.

general note here: while I've called out a number of specific tasks we (a) don't require the entirety of the tasks to be fixed and (b) we can write a lot of code ourselves thus obviating the need for phabricator fully grok our use case, so long as its emulateable.

While I agree it would be nice to have some control over this in the UI here are two comments:

1. This can be done via the CLI: ./bin/differential attach-commit
2. It would help if you could articulate the "benefit in having commits and diffs cross referenced outside of just autoclosing the diff". See https://secure.phabricator.com/book/phabcontrib/article/describing_problems/

Please open a new test instance on phacility for playing around. This is a real, live, production instance.

I'm not commenting as a new user but as a power-user and sometimes admin. I like having the ability to have both tiles and double-length icons. By default I'd put very few applications up.

also cool in this mock is that you can press the + on maniphest and macro really easily: beta applications are clear, etc.

@chad: the old sidenav - yeah, the old one. I really like that (a) the types of applications are grouped and (b) I keep could the important ones long and at the top while the less important but still useful ones are smaller.

FWIW I like this left side dashboard a lot better than the current one.

T4103 is related

I merged this into T10366 which is addressing related work.

you can likely manually modify the conference_participant table in ${NAMESPACE}_conpherence. The structure is straightforward.
This is likely not a good idea to do on a regular basis.

I'm going to close this since the upstream is going in a different direction. There may be some confusion around diffusion and differential, but I think @chad wanted to use the term "project tags" for that.

The upstream is moving to a direction where "Tags" are being used in situations where a project is being associated with a thing. This is because (I think) because people assumed objects could only be associated with a single project.