Nevermind I am wrong. Anyways, @epriestley can explain policies better. I think this is correct on our side.

Our corporate wiki is around 400 documents at the moment, around 15-20% of the documents are rather folders and me or our team members are adding a few new documents per week.
I understand second paragraph is not very easy to do, but first I guess is easy. Is there any reason to make the body for documents obligatory? Why the body can't be just an empty string if the person, who created the document wants so?

If I set "Can Edit" to Noone and "Can Create" to Admins, I can create repositories. But this is current Phabricator.

Yea I'm really sorry about March 4th. I'll probably look at upgrading in the following weeks. I slowed down updating because of the new UI layout to differential revisions which I thought would upset some people, needed to wait for warmer weather, etc. :x)

Anyways... this sounds correct. Why should a user be able to create something they can't edit?

March 4th?

Are customizing styles and retaining the Phabricator brand altogether mutually exclusive?

Specifically CelerityPostprocessor will let you globally change probably 99% of colors, backgrounds, and fonts. Then your local users can either select the built in default or the optional one you just built.

It seems to me that exposing a few classes for regular html colors, and a config form for editing them would not be such a killer big deal.

It seems to me that exposing a few classes for regular html colors, and a config form for editing them would not be such a killer big deal.
Form -> Header Color #______
Phabricator CSS -> .header_color { color: YOURCOLORFROMFORM};

I can't reproduce this on your linked install.

Nope. We don't add padding to the outer container, it's handled on an object by object basis.

T10433?

I feel like he should be "N + 1 Raccoon" instead of "No 1 Raccoon"

Yes, this was implemented in T10694.

I'll comment on the remainder later.

We discussed this briefly out-of-band, but the draft part of this is probably only sensible as "soft" prioritization:

• Does that description sound approximately like what you're hitting?
• Are both smarter arc land and arc cascade interesting, or are you only running into pain in one of the cases?
• Do you anticipate cases where git reflog and local notes could fail as sources (lots of pushing/pulling to different working copies, I guess)?
• Anyone know offhand how to git rebase -i master; delete the first few lines; save and exit; non-interactively?

I think the immediate issue here tends to manifest as arc land requiring users to manually rebase before it will work.

@eadler Did you have enough insight/recollection as to whether all our reported cases were due to users editing in the web UI?

Here are the interactions I can come up with which we'll potentially get wrong by implementing this naively:

From a technical point of view I think the ideal solution to this is to make the commit message format unambiguously parseable, but I'm not immediately sure how to do that without making other things worse. It's valuable for messages to be human-readable and human-editable, and I think we'd be worse overall if we tried to escape or encode messages in Git itself (or represent them as XML or whatever).

I'm not sure I have a good answer to that. :/

What's the behavior you'd expect or prefer when a user writes this commit message?

I can't reproduce this. Here's what I did.

My understanding is that the root issue here is that you're adding reviewers via Herald/Owners (per T10939) so the "no reviewers" warning is inaccurate or misleading in many cases because owners will be added automatically after the revision is created.

How often do you anticipate needing this functionality?

We require reproduction steps for bug reports. I would also use an up to date version of Phabricator before filing the bug report (it's required that you update before filing a bug).

Create a custom query inside Phriction, save it, then go to Dashboards and make a Panel with that query.

looks like an awesome feature to me

Configure pygments.dropdown-choices.

Thank you we basically created two projects to group the members into those two projects and i removed myself and only stayed in one and that seemed to kind of work. I see only the files i expected but also some deleted files history that is greyed out. It would be nice to have an easy place to put custom queries to be used for each of the apps but I love Phabricator so keep up the good work thanks.

This is expected. You do not need edit permission to comment on a task or take other actions available in the action dropdown.

In the case of Projects (v3) it looks like you used it to bucket things based on who was assigned, but this doesn't seem like a very feasible / useful thing to do until T5474 is done, because otherwise it's a very manual process.

It feels like the more formal / correct way to do it I guess? Like, I'd expect in future that reporting would occur over milestones in a project, and not columns on a workboard, because the columns don't have any relation between them (as opposed to milestones which explicitly have a "next" and "previous" milestone).

I guess another question is, what are you using Milestones for if they are just a column on the parent?

We used full workboards on our Milestone for Projects (v3). If we linked by default to the parent project, that functionality would be lost. Any sort of auto-redirect to the parent loses all project functionality and power.

As far as I understood it, milestones being projects were an implementation detail, because @epriestley didn't want to have two separate structures for sub-projects and milestones.

You can default a project's page to whatever you want in under Manage Menu. But I don't think that's what you want. I understand what you want, I just would have concerns that it might be unexpected in most cases, especially if you're running the Milestone as a full fledged project with it's own boards.

What's the point of it being a project then?

(I realise that milestones are projects, but I simplified my response to distinguish between the parent project and the milestone that is under that parent project)

No, I'm suggesting that when you click the "Project (Milestone)" tag in the UI, it should take you to the project's workboard.

You're suggesting Milestones should not be projects?

Where is this configurable?

It's configurable.

We should get this punted out of prototype status, don't think there is a lot to cover before that. See T11167 if you find additional items.

This spawned a healthy set of followups, but I believe the core work described here is now resolved and accounted for and all future work is covered in narrower followup tasks.

Appears resolved and accounted for.

I believe this is resolved and accounted for, let us know if anyone runs into issues.