Added to https://phabricator.wikimedia.org/project/manage/30/

In T244156#5845671, @chasemp wrote:

Added to https://phabricator.wikimedia.org/project/manage/30/

The form itself is still restricted (presumably to members of WMF-NDA): "You do not have permission to view this object."

In T244156#5845678, @DannyS712 wrote:

In T244156#5845671, @chasemp wrote:

Added to https://phabricator.wikimedia.org/project/manage/30/

The form itself is still restricted (presumably to members of WMF-NDA): "You do not have permission to view this object."

Ha. Thanks for letting me know @DannyS712. We need to write down the process and expectations there.

*If* converting (instead of initial creation) also falls under this task, then T244609 would have been another use case

@mmodell not sure if warranted, but I'm wondering if a "Protect as NDA task" under our current "Protect as security issue" is a good idea?

In T244156#5907507, @chasemp wrote:

@mmodell not sure if warranted, but I'm wondering if a "Protect as NDA task" under our current "Protect as security issue" is a good idea?

The initial create as NDA task is still restricted (I cannot use it) so protect as NDA task might prohibit the user from seeing the task

@DannyS712 in this case it would, I assume, work similarly to #acl*security protected tasks in the author would be added to teh CC list (for which there is a reflective acl entry). This would in effect get past the current issue of NDA members only seeing the option to file that form type, as well as put the option in the same place as the other mechanism for task protection.

In T244156#5907559, @chasemp wrote:

@DannyS712 in this case it would, I assume, work similarly to #acl*security protected tasks in the author would be added to teh CC list (for which there is a reflective acl entry). This would in effect get past the current issue of NDA members only seeing the option to file that form type, as well as put the option in the same place as the other mechanism for task protection.

For general security tasks, there is a understand standard of when to use. For NDA, its not obvious when it should be used, because its not available to non-NDA

We already have https://phabricator.wikimedia.org/maniphest/task/edit/form/23/ but it seems the discoverability on that isn't working out.

I made another edit to https://www.mediawiki.org/wiki/Phabricator/Help#Restricting_access_to_tasks to explicitly mention the NDA option in the dropdown.

In T244156#5907507, @chasemp wrote:

not sure if warranted, but I'm wondering if a "Protect as NDA task" under our current "Protect as security issue" is a good idea?

I'd prefer to avoid this. I know that people often don't read docs, but adding more corner cases [?] to the UI isn't a great workaround either.

I think that's a fair take. I'm not sure what the 'right' thing is here, I'm working mainly from the litany of "why can't I protect something without it being treated as a security task' comments. But that's anecdotal. I'm satisfied with members of NDA being able to file NDA tasks for now then.

I'm not sure I understand what the use-case is. Why would a non-NDA user need to file an NDA task, and if they do, why should they be able to see it if they aren't under NDA. I can remove the NDA restriction on the NDA task form, without removing the restriction from the tasks created by that form. But I guess I want to understand the use case before I would make any changes.

I guess I don't think we should further facilitate any "private" discussions in phabricator among arbitrary groups of users. Our guiding principles include Transparency. My understanding of that principle is that we do everything in public unless it would endanger the privacy of an individual or organization.

NDA tasks are intended for protecting privacy when it might otherwise be violated, however, an even better solution is to avoid posting the information at all.

Thinking this through, I can see a use-case for a "Convert to private" button, because it would allow any trusted user to proactively protect the privacy of another, in case they see something in a public task which shouldn't be there.

More generally though, I think that trusted contributors who need to post potentially sensitive information should probably sign the NDA.