See T5162 for my current thinking there - you'd basically make a herald rule that says

• if task is newly created
• and if task has no project
• then re-assign to task creator (or other things that put it as a problem for them to fix.)

Why not just make it a "Required" field? The person filing it may not notice that it has been assigned to them.

I don't think projects should be required.

I worry about adding even more configuration.

The tools are built with a general design slant that people are smart, awesome, etc. so things like "people keep using the tools incorrectly so make the tool prevent them from doing something" are warily considered. On this point though we do want the software to be extensible such that you can get the productivity you want out of wild monkeys or whatever, but simultaneously these features aren't going to get in the way of the smart, awesome people we're building this stuff for. See https://secure.phabricator.com/book/phabricator/article/events/ for the really hardcore way to extend Phabricator.

The smartest, awesomest people in the world still sometimes make mistakes, and not having a way to catch these mistakes is a problem. When you're running many projects across dozens of teams and hundreds of people from within the same installation, mistakes can easily end up piling up. Having an optional config setting for flagging specific fields we want to make sure get filled out is no more proscriptive than a code linter (which you support).

See T5162 for the current way to catch these mistakes. Herald in general is where you "watch for danger."

(+@swisspol via T5162)

Maybe this is just something we aren't understanding:

If a user doesn't know which projects a task should go into, isn't it better for them to leave it empty (so triagers who do know can route it) than to take a guess? Are there users who know which projects tasks should belong to who are leaving that information off the task deliberately (or by accident or whatever) but who would fill it in correctly if required? If so, why?

My experience on this install (and with other bug trackers) is that users often don't do a very good job of filing tasks, on many dimensions. Beyond missing or incorrect projects they'll have bad titles, missing information, wrong metadata, conflicting descriptions, not attach files they claim they attached, post dead links which are critical to resolving the issue, not actually describe the issue, not have reproduction steps, report an issue against one project which is really totally unrelated, report 50 copies of the same issue, etc. My assumption is that all users filing issues everywhere do this, and that having someone doing something like triage is unavoidable. Is this not the case? Are triagers just adding projects to tasks, and not performing any other assessment steps?

That is, the general workflow assumption here is that users report a bunch of mixed quality bugs. Some of them go to a project or owner immediately, but random reports from users go to something resembling a triage queue where they get sanity checked, deduplicated, and properly categorized. Is this not how things work on your installs?

Or is this something like users filing tasks for themselves, and not including the project they're working on? (Are these not bug reports at all?)

Basically, can you walk us through a typical project-less task? Who files it, what information do they fill out, how good is that information, why is it important that projects be set, etc?

Overall, this feature sounds like you're saying "putting it in any random project is better than having a triage queue", which seems odd to us, and which is why we aren't philosophically very excited about adding configuration to make it required. Are we misunderstanding, or is this really the underlying request?

By analogy, "Assigned To" is also not required. If we made it required, I would expect most cases where it was previously left empty to be replaced with incorrect information, as users filing tasks take their best guess at whoever they know who works on some similar part of the project. What makes "Projects" different? From my perspective, these cases are very similar.

Our general flow:

• We have multiple teams and multiple projects in the same installation.
• Each team is responsible for triaging and managing the bugs for their projects.
• We file bugs with a priority of "Needs Triage".
• We try to encourage good bug writing (including enough content to provide context about where you're seeing the issue), but you still sometimes get a trace and a one-liner of "we hit an exception". Sucks, but it happens.
• We use projects both as categories and as tags:
  • Each team has a particular general project they use as a "bucket" to catch bugs related to their team.
  • Triage assigns priority, assign to someone to work on it, and tag with additional project tags as appropriate.
  • By having these "catchall" projects for each team, we're able to easily narrow searches to just bugs relevant to a particular product.

If a project isn't added, the bug ends up in limbo: since we search within projects to cut down on the noise of multiple teams in the same install, the bug is never seen, unless someone explicitly chooses to do a broader search, or search for bugs with No Project.

People on teams generally know what project should be assigned to make sure it gets to the right people for triage. We usually don't get bugs filed by people from outside the team. But what about bugs in limbo? You can make a cheatsheet of projects, but it's still not clear whose responsibility it is to wade through the No Project bugs and re-home them, and since you don't have the context someone on that team would normally have, it ends up eating a lot of time.

We've already started setting up Herald rules to spot cases where they included the project in the CC field and add the appropriate project, or catching bugs that include a project tag without including the project bucket as well, and similar things like that. We still end up with a regular accretion of bugs in limbo.

There are a few different ways to solve this:

1. Improve Herald to allow you to notify users (you can currently email a bug to someone, but not provide more info as to why you did).
2. If you CC a project, automatically add it to the projects field (you can do this in Herald, but not as a catchall as far as I can tell... you have to set up rules for each project).
3. Improve Herald to more effectively act as a linter for bugs/tasks.
4. Add a config option for requiring the projects field to be filled out and trust users to be smart and awesome and figure out what project they should assign (because, again, 90% of our bugs come from people who already know what project tag to include, and just sometimes miss it).

The exact solution matters a lot less than having something that works. If you genuinely think it would be more effective to significantly expand the capabilities of Herald than it would be to add a config option to enable a feature you already have implemented (other fields are required, and custom fields can be set to be required as well), that's your call to make.

I'm fine with having support for this in Herald vs truly built-in. What matters to me is having the automated ability to ensure every task is going to be looked at by someone. There's never going to be a 100% full-proof solution, but requiring neither project or assignee increases the probability of lost tasks which I have seen in practice. Having a designated task janitor to regularly look for tasks without projects and redirect them is not practical nor reliable IMO.

Keep in mind it's like we have dozen of tasks created every day without any project: the vast majority of people do it right after education. But some new person, or old person not paying attention one time, can create an important task without a project. And murphy's law being what it is, it is of course going to be a very important and urgent task, filed on a Thursday and not rediscovered until the next Tuesday.

We have an extension which fixed our issue AFAIK: if you file a task without a project, it bounces back to you with a big WARNING: ... comment explaining the problem and inviting you to fix it (and un-assign yourself).

Having a designated task janitor to regularly look for tasks without projects and redirect them is not practical nor reliable IMO.

This is surprising to me, since Facebook had people whose responsibility this was (from pretty early on, I think). I do most of it in this project. We don't have a huge volume of tasks (about a dozen a day) but triage takes very little of my time.

Improve Herald to allow you to notify users (you can currently email a bug to someone, but not provide more info as to why you did).

The X-Herald-Rules header shows which rules triggered, but probably isn't a very good fit in this case.

We could let rules add notes or something to email, maybe, but I'd worry it would get ignored.

We have multiple teams and multiple projects in the same installation.

Depending on how isolated your teams are, T3820 (which will add top-level namespaces on top of all objects, where each object is in exactly one namespace) might be another approach.

a very important and urgent task, filed on a Thursday and not rediscovered until the next Tuesday.

Couldn't this just as easily be filed to the wrong project?

If you genuinely think it would be more effective to significantly expand the capabilities of Herald than it would be to add a config option to enable a feature you already have implemented (other fields are required, and custom fields can be set to be required as well), that's your call to make.

This is more an issue of configuration having a high lifetime support cost. Phabricator is relatively difficult to configure, and we already have way too much configuration (see T5703 for a good example).

There are currently 231 configuration options. Partly, this is because we were more lax about adding options early on. If we'd never raised the bar on configuration options, I'd guess we'd have more than 500 now. Beyond making Phabricator more difficult for users to configure, having more options also makes Phabricator more difficult to test (in some cases, complexity explodes: 5 relevant options with 2 states each can mean 2^5 = 32 possible configurations, which is usually too many to test manually and can begin to strain automated testing not long afterward).

We can support this and reduce the number of configuration options by allowing fields to specify options (like "required") in the field selection configuration. In particular:

• Allow custom fields to expose configurable properties (like "Required") and render controls for them when editing, e.g., maniphest.fields.
• Express differential.require-test-plan in terms of field configuration and remove the option, leaving us with a paltry 230 configuration options.
• The warnings that DifferentialReviewersField emits can also be turned into options, partially resolving T5786.
• In Maniphest, builtin fields may need to move to CustomField before "Projects" can be made requirable.

This is surprising to me, since Facebook had people whose responsibility this was (from pretty early on, I think). I do most of it in this project. We don't have a huge volume of tasks (about a dozen a day) but triage takes very little of my time.

Regular triage of tasks within a project is one thing which is part of the core responsibilities of whoever manages it. The problem here is about tasks not having any project to start with. Having someone on the team look at such tasks regularly seems inefficient when you have a small team. If you have a 1,000 people, sure it's worth having someone who can do this every day and won't forget, but if you have 25 people and a handful of tasks a week that are created without a project, just automate it.

Couldn't this just as easily be filed to the wrong project?

Again we're just trying to reduce the probably of an error, not design a 100% full-proof system :) The point is you want someone to look at it: if it's the wrong project, it will be redirected. If there's no project, it's just likely lost.

Basically, turn this:

...into this:

...
+-----------------------+
| = Favorite Dinosaur   |
+-----------------------+
+-----------------------+
| = Projects            |
|   [√] Required Field  |
+-----------------------+
+-----------------------+
| = Peanut Allergy      |
+-----------------------+
...

I like it! Thanks for listening, looking forward to this (and top level namespaces so we can stop overloading the Projects field). :)

...and even more depending on how isolated your teams are, you might just want separate Phabricator instances. Basically, namespaces, other features will never let you reinforce your silos like separate instances will.

Via email, a specific requested option is [ ] Publish in Commit Messages (or similar, wording might not be great) in Differential, to allow installs to trim down the message-of-record that arc lands.

Some of the fields today are fairly superfluous ("Subscribers", "Reviewers"). IIRC, some people at Facebook wanted them to always get written but I don't think they're useful to most installs. I'd favor turning them off by default once the option exists.

T7329 is like T7327 basically; the user in T7329 was hitting the "Projects:" field and I'm guessing would want to get rid of it for their workflow purposes.

Yeah, we can let you disable the commit message integration of fields without getting rid of the web UI integraiton.

Via IRC, the account.editable option currently locks "Real Name", but it would be more flexible to make this an option on the field itself.

Having the ability to mark certain fields as required would certainly address the root issue but looks like it might be a long time before this is addressed no? This task is close to a year old.

What I was trying to suggest with T8905 and T8906 is to at least have the ability to build a simple system to bounce back tasks without project to the author and add a comment. It's way better than nothing. At my previous company, we did that using a custom Herald PHP extension, but now that we're on Phacility at my new company we can't.

In my current company we are just starting with Phabricator. People are still learning their way around, but I already have few engineers (smart, awesome, capable, etc.) coming up to me and asking if it's possible to have project field required(maybe soft with a rule in Herald). Having a rule that send notification / email doesn't really do much - engineers tend not to notice notifications when tasks bounces back to them or they notice that in a few days. And having someone on the team look at such tasks regularly seems inefficient when you have a small team.

PHI781 asks for [ ] Show on commit message template. for "Maniphest Tasks:".