@atgo, is the description here your understanding as well?

@chasemp yep, that looks accurate. Thank you.

Note that "Fundraising-Backlog" was initially the Fundraising "people" project. There is also "Wikimedia-Fundraising", which is the backlog new bugs... Maybe these two could be organized, so one if for people and one is for backlog?

@Qgil I guess we could do that, but I'm not sure how that addresses this need? As @chasemp said, our confidentiality needs are somewhat fluid so a static group would miss the mark.

So you want to be able to define custom visibility policies with only user-based access on each object, not against just a restricted-join project?
That sounds like a good way to loose history when people leave teams etc. Also, remember that you may have to go around manually removing people from each object when they do leave WMF in some cases - Phabricator accounts cannot be closed during WMF offboarding (maybe if they're specifically marked as for WMF work only, but I can think of about 5 people who actually have that).
Not sure I'm happy with this idea.

I'm happy to start with visibility based on a "people" project as a first pass if that makes people more comfortable. If we get into problems from there, we can revisit.

I should have mentioned I assumed this would be mostly facilitated by a fundraising "people" project, and that the "adhoc" stuff was pulling in non-fundraising technical resources as they were applicable kind of thing.

It's a good point @Krenair raises that post-WMF employment leaves a question mark on access. This seems like a legal question I don't have the answer to.

It seems like we should say the appointed fundraising folks can modify policy, but should only do so to restrict to the Phab fundraising group as necessary.

It should be noted we have special exceptions by user all over the place for Security though. Which is interesting considering.

Yeah. I don't know if we necessarily need to remove WMF staff access to restricted tasks when they leave - NDAs etc. should all still be valid. But since Fundraising wants this to be super-private (probably reasonable for them) it could still be an issue for them, which is why I brought it up.

I agree that all users (including appointed fundraising people) with the ability to make arbitrary policy changes in Maniphest should be aware that it's a restricted action and to only do it where appropriate.

What does "restrict access to tasks that could be misfiled" in the description mean exactly?

In T88762#1028462, @Krenair wrote:

What does "restrict access to tasks that could be misfiled" in the description mean exactly?

This is meant as "$user requests some private thing that can't be exposed but only Fundraising would understand the context" or "$user makes an issue for fundraising including details that they don't even know are sensitive". In these cases, a Fundraising representative should seemingly have the ability to restrict the policy to either a) effectively respond with the relevant private info or b) make a request that by it's nature is sensitive hidden.

In T88762#1028462, @Krenair wrote:

Yeah. I don't know if we necessarily need to remove WMF staff access to restricted tasks when they leave - NDAs etc.

The reason I mentioned it is that there has been talk of a post-employment volunteer-nda that needs to happen to maintain access to RT type things. So I don't know how things work, only that there is a transition.

Barring objection here I am going to go ahead with this approach when I have time. Note some bleed over of this topic here: https://phabricator.wikimedia.org/T823#1032703

Hey @chasemp - do you have a sense for when you might get to this? Thanks

I see no one waving their hands in objection so I think we are cool. The idea is generally sound and supported. Do you want to schedule a "heres how policy works" call or do you otherwise need some guidance to get started?

Awesome. It seems like there is some concern about using this, so I think a "how to" would be great. When's good? I've got from 2-3 today and after 430. Tomorrow's pretty open, too.

In T88762#1047361, @atgo wrote:

Awesome. It seems like there is some concern about using this, so I think a "how to" would be great. When's good? I've got from 2-3 today and after 430. Tomorrow's pretty open, too.

what timezone is that? :)

PST :)

We made a template task: https://phabricator.wikimedia.org/T89899
We added @atgo and @K4-713 to the list of people who can modify policy
We discussed having a "people" project for fundraising to make this more sane (one that is discretely named)

Chase got me set up today and gave me a very helpful walkthrough and template task T89899. I'll walk @K4-713 through it, too.

We were talking through what the best ways to use this are and agree with some earlier comments from T823 that a "people" project would be helpful. That said, we already have a bunch of "fundraising" projects and it would be nice to not have bugs filed into the "people" project.

What about the idea of a (slightly) obfuscated name like "WMF-FR" or "FR-People" that wouldn't get returned in results as people type "fundraising"? @Qgil @Aklapper?

Since we are experimenting, I'm fine with experimental project names.

Thanks, team. I've made acl*WMF-FR for this purpose. It is not joinable and the template task T89899 now sets policy such that the members of that group are the only ones that can edit and view.

Really appreciate everyone's help and time with this!

In T823#1106786, @atgo wrote:

@DarTar @Qgil 'm pretty happy with it, though I would like to expand the
group who can write policy a little bit to include a few more people. I'll
follow up with Chase about that when I have a chance.

Can this task be resolved, then?

@chasemp can we add @awight to the list of Policy holders?

Can we just give @atgo the ability to modify the acl group?

Otherwise phab admins have the responsibility of maintaining something we aren't in a position to make policy decisions about, and fundraising is blocked / delayed by waiting for the attention of phab admins.

That does sound like a nice shortcut for this going forward. It's becoming helpful for more and more of our team to have the ability to make tasks with custom policy settings.

Can we just give @atgo the ability to modify the acl group?

Yes. Done.

#acl*fr_policy_admins in https://phabricator.wikimedia.org/project/view/1142/ had "Editable By" set to "administrators" only. I have now added @atgo so it's @atgo and admins.
@atgo: You should be able to add/remove members via https://phabricator.wikimedia.org/project/members/1142/

(When I created #acl*communityliaison_policy_admins I already set "Editable By" to "Custom Policy: User rdicerb && administrators" to allow rdicerb (head of CL team) to add/remove members, to allow them to access tasks in their space S2. Hence adding atgo is rather consistent here.)

Thank you! This is super helpful.

@atgo, are you using Phabricator Spaces yet?

I'm not! Looking into it now, but if someone has 10 min to show me around
some time, I'd be interested.