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.

Interesting... this happens consistently for certain diffs (for my own reference, D22362) but works fine for others.

Isn't Phragment the right application for this purpose?

That's supported after D13618.

Yeah. I will probably end up just writing my own NodeJS script to parse and interpret the CSS documentation.

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

Ah yeah, I'm not really talking about HTML within the comments themselves (although I'm sure we will have to deal with that as well). Specifically, this is the tool that has I have been referred to: https://github.com/kss-node/kss-node

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

Yeah, agreed on avoiding it if possible. I just got asked about CSS documentation which I have no idea about but there are existing tools which spit out HTML. I will look into what would be involved to parse the HTML.

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

What about the ability to publish arbitrary HTML into Diviner? This is not ideal, but it means that any documentation system can be integrated.

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 you did this, wouldn't users just remove the blocking task relationship so that they could close the task?

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:

But I guess that works.

Tables? Eww.

Poster child for "describe problems".

My specific use case is to show a "before and after" comparison. Ideally, I'd want to show two images side-by-side with the left image captioned "Before" and the right image captioned "After".

Cool. I'm going to merge this into T9128 since I think it's almost certainly the same issue and now resolved, but let us know if upgrading doesn't fix things.

You're a little out of date, can you try upgrading to HEAD (rP53ffaaa8)? I think that commit should fix this issue.

What version of Phabricator are you running?

See T8957.

I think (?) these are different rules, none of which have names, but this UI can clearly be improved.

Mock from @nickz:

I'm just going to merge this into T3980, since projects can be owners and that would allow projects to have dynamic membership. I don't plan to implement a separate mechanism in Owners.

I plan to just improve documentation to address this.