I suppose an example from the original ticket was:

I don't want to solve it anytime soon (and don't actually understand it, see bottom).

Even setting aside the intentional "Yes" -> "No" template edit, subtle changes to macro text over time could render it meaningless/confusing on old tasks.

So the idea is that you can either invoke a snippet as a macro, like:

Like, there's no useful {{changelog}} macro I can define, since tons of the internal text is different from page to page.

Well, what would the changelog one look like? If it looks like this:

I can create a "weekly_changelog" template which I use in Phriction to quickly apply the common markup I use when building a new Changelog page.

I'm planning to take these corrective actions:

Some contributing issues:

I cycled the host to trigger compaction and bring everything back up, which seems to have resolved the initial issue.

Getting arc test to use whatever method arc diff does for deciding which test suites to run

Just to clarify, you really mean arc test and that isn't a typo of arc unit?

In fairness, you can't dead them either.

Why are users updating revisions if they don't want reviewers to look at the changes yet?

Thanks!

A couple other things we could use soon in the upstream, although not requirements for v0:

Thanks for the report! I think your analysis is correct. D13893 should fix this.

We do record the originator of the mail internally, and could expose it in /mail/ or bin/mail volume, etc., without much work. For example, it would be easy to add:

bin/mail volume doesn't report what fraction of mail is generated by the user, if that's what you mean.

Yeah. I'd also really like the objective numbers from bin/mail volume, but they won't be very good for 30 days. Maybe we just wait that long to attack the "too much email" aspect of this -- role profiles and herald outbound rules are justified on their own anyway. I'd want to get this data:

Put another way, "send no mail by default" solves a different problem, which is "administrators complain to us that their users complain to them that they get too much email, but some of this is rooted in personal/emotional issues and has no technical/product solution".

I think there are a lot of reasonable things we can do to make it easier to get your settings set the way you want them, but they'll only help users who have a "oh, these settings aren't very good, let me go fix them" mindset. My concern is that the root of this problem may not be users having difficulty setting things up, it's users just feeling helpless and overwhelmed by the problem for essentially personal/emotional reasons which we can't easily fix.

One thing that I'll probably do for Herald, at least, is group some of the tags up so you can write this rule:

I think arc patch has some old, sketchy code around authentication. The problem is that arc patch is currently unique in that it wants to use authentication if it's available, but does not require it. This never really got built properly and is kind of a hack job.

I'm close to interacting with this stuff on Herald outbound rules -- do you have a general attitude toward the future of mail tags?

Cool, thanks for the followup!

I think projects/badges are a better approach for this.

Do you want this capability in general, or all your intended use cases also account attributes (e.g., administrators)?

Yes, T4103 is the task for this. I'm going to merge this there.

We could also split projects into two completely separate but essentially identical applications, "Groups" and "Tags". In the simplest form, both applications would run exactly the same code, except one would say "Groups" everywhere and one would say "Tags" everywhere, and each object would have an internal type flag specifying whether it is a "Group" or a "Tag".

Why are you destroying wiki pages?

There is only one flavor of "Visible To", which is the second, more general one:

We aren't interested in pursuing this for a bevy of technical and product reasons.

That's supported after D13618.

That looks like it could be pretty complicated to do safely.

Ah, interesting. The cases I'm familiar with are Javadoc, like this lovely example from Oracle:

My guess is that we can satisfy this by parsing a small, safe subset of HTML (bold, italics, tt, links).

I guess I don't really see any good ways forward here from the upstream perspective.

We have to send the initial welcome mail for unverified accounts, since obviously you can't invite new accounts without sending them an initial email.

The import process created accounts for users and sent them welcome mail. This happened to coincide with T9046, so none of the links in the welcome mail worked.

In the case of the user we're familiar with from elsewhere, it looks like this is what happened:

D13878 makes bin/mail volume look like this instead:

General feedback from @swisspol:

1. Spaces in themselves are not complicated to understand (just needs a bit of UI polish for integration in apps).
2. Visible To / Editable By are not complicated to understand either, I completely agree.
3. The *combination* of the 2 is complex: case in point the amount of explanation needed in "Space Policies” in https://secure.phabricator.com/book/phabricator/article/spaces/.

I would argue this is very powerful but needlessly complex for the average user: even tech people *cannot* know out of the box how these things interact together unless you read the docs. I’ll bet you lunch that showing this to the majority of tech people (phab users or not) results in them not being able to understand at a glance how this works - it truly is confusing:

Then you say spaces make it more reliable to enforce policies across the board and less error-prone, but not really: because visible to / editable by are still here, you can still get it wrong: e.g. someone sets them to something else than “all users” in a restricted space, then other people need access, that author changes the space: it still doesn’t work.

I would point out that the model of visible / editable by is simple and elegant. Same for a pure space model (i.e. no visible / editable by) which happens to be ideal for organizations that want easy/can’t-shoot-yourself-in-the-foot access control. The current space model is probably for orgs that have quite more complex access control requirements. I’m not suggesting to this take this off, just add a middle ground which I’m betting plenty of users would be happy with :)

I love Phab because it’s elegant, professional, reliable *and* doesn’t make it easy for average users to shoot themselves in the foot. IMO Spaces are not there yet.

@epriestley, do you have any suggestions on how we might work around this or fix it? The fact that we no longer have a working IRC bot is really painful for us. We don't have any php devs but if you were to pointed us in the right direction I'm sure we could make it work.

If this reproduces at HEAD, I'd guess you have a linter which raises lint messages without names. This field is required. We can improve the API so you're given a better warning about this which points at the problem more specifically.

If I put it in pre-push instead, I can get a more hang-like behavior, but the hang also reproduces with normal git push:

Can you simplify your hooks into a minimal test case which reproduces this issue? I don't have access to them, and can't really guess where to begin. I tried this:

Poster child for "describe problems".