Thanks for writing that up!

We spent so much time on this it's almost nostalgic now :)

In T8434#118735, @Krenair wrote:

So... you propose that we simply kill the ability to add specific users to specific private tasks, is that right?

Users who don't understand it. And - off the top of my head - I'd quite like our custom 'security' option simply be the name of a pre-defined policy (we don't want unprivileged users to be able to set arbitrary policies, that can only result in a mess), but I haven't really thought through all of the implications of this.

In T8434#118741, @aklapper wrote:

In T8434#118719, @Krenair wrote:

In T8434#118707, @epriestley wrote:

• The original reporter can not see the task or any work done on the task, only the separate discussion on their original report. This allows security response to be separated from communication with the reporter.

That does not sound desirable to me in our context

It can be desirable. Being able to exclude reporters/ commenters on certain tasks from certain updates is very useful for handling procurement requests (such an RT feature was used at least by Wikimedia's Operations team).

In T8434#118738, @epriestley wrote:

How would you like the flow where you give permission to new users to work? In T4411, @chasemp expressed some concerns about using CC/Subscribers for this (particularly, that users can add other users to CC). Do you share those concerns, or is adding users to CC to give them rights satisfactory for you?

Fine with me personally, that was the system in BZ. I do wonder what Chris thinks about this now though.

In T8434#118719, @Krenair wrote:

In T8434#118707, @epriestley wrote:

• The original reporter can not see the task or any work done on the task, only the separate discussion on their original report. This allows security response to be separated from communication with the reporter.

That does not sound desirable to me in our context

From https://phabricator.wikimedia.org/T76401, maybe that's actually ideal/desirable, and @chasemp's concerns aren't related to this use case (or perhaps are allayed by "hard spaces")?

How would you like the flow where you give permission to new users to work? In T4411, @chasemp expressed some concerns about using CC/Subscribers for this (particularly, that users can add other users to CC). Do you share those concerns, or is adding users to CC to give them rights satisfactory for you?

In T8434#118721, @qgil wrote:

In general I also like the concept of "hard spaces", simpler to understand
and to protect.

There is this "misuse" case that hard spaces would about: Security team
member leaves the team for some reason while staying as a regular
contributor.... but keeps access to old tasks that he authored. It is
simpler if you are either in our out.

unless the Nuance entry was basically just a special task, where we could have to option to continue as normal while including the reporter

In general I also like the concept of "hard spaces", simpler to understand
and to protect.

In T8434#118707, @epriestley wrote:

• The original reporter can not see the task or any work done on the task, only the separate discussion on their original report. This allows security response to be separated from communication with the reporter.

That does not sound desirable to me in our context (unless the Nuance entry was basically just a special task, where we could have to option to continue as normal while including the reporter), what do you think @csteipp?

Yeah, the "Security" use case is letting users see objects in a Space they normally don't have access to because they have some special relationship to those objects (for example, giving users access to security tasks if they reported them).

I read the Nuance description, but it is still unclear to me what it does.

good task

Basically the short answer is, if you need clean/simple creation for "non-company" folks, that to us is Nuance, or maybe also Spaces depending where that goes.

See T3320 for prefilling.

You can already template some things with url parameters. For example /maniphest/task/create/?projects=foo. I'm not sure that's documented anywhere or which php file to pull the full list of possibilities from.

This request is too specific since different organizations might need different things. However, what about offering a configuration option to pre-populate Maniphest tasks with a template?

I think a critical feature of Nuance is being able to create "contact forms" -- like a form to submit a user story -- and then these forms should be iterated on as necessary to improve the signal to noise ratio. Probably not V1 but definitely V2 type stuff in my opinion.