In D25926#24898, @valerio.bozzolan wrote:

• more search engine rabbit holes (but maybe not that bad)

robots.txt can have the solution for that (see below).

Uhm. Good points:

In D25926#24895, @aklapper wrote:

Why would a logged-out user (who does not want to or cannot create an account) want to know about Repository management log or Repository limits? I don't see how that's their business (or interest)?

In T15999#21434, @aklapper wrote:

Some items in the task description make me a bit uncomfortable in my instance.

I don't think you need to be uncomfortable on your instance (phabricator.wikimedia.org)
For Herald, it looks to be restricted to trusted contributors to restrict who can create personal rules (they actually can vandalize tasks via personal rules with the action set to claim the task), that's not something to take care of at all on your instance.
Project members, maniphest reports, user tasks and badges are actually useful for logged-out users.
But everything that's Diffusion-related sounds pointless for your instance as every repo is a read-only mirror of the repos on a Gerrit instance.

Why would a logged-out user (who does not want to or cannot create an account) want to know about Repository management log or Repository limits? I don't see how that's their business (or interest)?

Some items in the task description make me a bit uncomfortable in my instance. Why does everyone need to see Diffusion sync, pull, and push logs? Why Herald transcripts? Why repo management if you cannot manage? What are actual use cases which outweigh security implications?

In D25926#24890, @avivey wrote:

There might be some security implications to this.
Why is this needed?

There might be some security implications to this.
Why is this needed?

git rebase master

git rebase master

git rebase master

Makes sense thaanks, 0s seems also the documented default

Don't change URI path /people/tasks/{$id}/ of assigned tasks not to break potential external linking

git rebase master

• Rebase

Nice

(and well done Herald²)

(And well done Herald)

Go back to previous khtml only change

Great, Phorge. So much for stacked patches... Looks like git checkout -b mozPrefixedCss cssKhtmlOpacity did not do what I had expected it to do.

Remove pre-2013 vendor-prefixed -moz- CSS properties

@valerio.bozzolan could you please add to either H28 or H29 Affected files contains none of map.php?

Marking as "probably my previous block is now nonsense - but still not reviewed sorry" asd

Uhm yes thanks

In D25912#24622, @aklapper wrote:

In D25912#24618, @valerio.bozzolan wrote:

P.S. maybe if the task number is very small (e.g. 2) maybe we can still allow that.

I'd prefer not to introduce non-obvious confusing behavior (sometimes it does, sometimes it doesn't?) to increase code (and testing) complexity for no good reason...

It works on my computer and it makes me feel like a happy Phorgi unicorn running in a Phorgi golden forest, whoa

Another good simple candidate GDPR-friendly:

This is one great Wikimedia patch being upstreamed. Should I make this a sub-task of T15081?

Took the opportunity to fix a typo in the summary.

In D25912#24618, @valerio.bozzolan wrote:

P.S. maybe if the task number is very small (e.g. 2) maybe we can still allow that.

(Feel free to copy-paste the downstream task in Phorge - so the lack of task is not used as blocking reason - maybe title "Allow to mitigate spammers from workboard bulk move" or something similar)