I assume it should be separate from the normal fundraising space (I presume there is one)? If so (eg: not everyone in fund-research should know everything in fundraising), then this seems obvious to me.

Weren't normal fundraising just using ad-hoc policies for everything?

@Krenair fundraising is using ad-hoc policies, displaying only to the
acl*WMF-FR group. If there's a better workflow I'm open to changing.

(bad assumption by me, I didn't know the details, sorry for the confusion! I still think this is a good idea and should be done asap)

See https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Requesting_a_Space for needed information.

Thanks, @atgo!

@Aklapper Is what's missing the description which specific Phabricator users should be able to access objects in that space?

If anything else is missing, then please advise what is. Many thanks for your help- as @DarTar mentioned this is high priority request for Big English FR campaign which is starting now.

In T119258#1828433, @ggellerman wrote:

Is what's missing the description which specific Phabricator users should be able to access objects in that space?

Yes (though less important, someone could add them later to the ACL project members) though even more a name for that Space.

Thanks for the quick reply @Aklapper!

@atgo Could you suggest a name for the Space and provide the list of who should have access? Thanks!

@Aklapper Thank you so much for taking care of this!

Hey @Aklapper - thanks for making this work. So just to make sure I understand, anyone who is in the #acl*fundraising_research_policy_admins project can both see and make tasks into the Space?

Then from there, the tasks will be visible only to members of the space but can be filed normally in other projects, too, right?

What's the reason for doing this vs. what we have with fundraising (making custom policies without Spaces)?

Also I was able to add @ggellerman to the group and everything seemed to work as expected, so yay

In T119258#1830074, @atgo wrote:

Hey @Aklapper - thanks for making this work. So just to make sure I understand, anyone who is in the #acl*fundraising_research_policy_admins project can both see and make tasks into the Space?
Then from there, the tasks will be visible only to members of the space but can be filed normally in other projects, too, right?

For both questions: Yes, that should be the case.
Clarifying edits to those docs I once wrote are welcome as I'm probably too blind now to still recognize basic questions or concepts to explain...

What's the reason for doing this vs. what we have with fundraising (making custom policies without Spaces)?

And here I admit that I never dived (dove?) enough into our custom "FR tasks in Phab" setup (T88762) which predates upstream's "Spaces" implementation.

Sorry for chiming in so late, but the name "Fundraising-Research" is misleading. This board is for coordinating fundraising analytics tasks between Megan and fundraising analysts. There is a clear distinction in the org between research and analytics. To clear any confusion, this board should be called "Fundraising-Analytics" if at all possible. Can we change the name?

@ellery I am changing the component name to Fundraising-Analysis for consistency with other audience teams' project names (e.g. Contributors-Analysis ).

@ellery @atgo @mpopov this will also need to be changed from a component to a team-type project with an active board.

In T119258#1830192, @DarTar wrote:

@ellery @atgo @mpopov this will also need to be changed from a component to a team-type project with an active board.

I've done that by changing the color and icon of the Project.

To change the name of the Space, a member of the Space needs to go to https://phabricator.wikimedia.org/spaces/edit/5/

I've updated the space. @DarTar @ggellerman I need to know who should be in this space.

Or possibly @ggellerman can add people since she's already there.

Thanks @Aklapper and @atgo.

@atgo @ggellerman: please add

• @ellery and myself from research
• @mpopov from Discovery
• all FR-tech
• @MeganHernandez_WMF + anyone from her team she would like to have there

It might be useful to have someone from Analytics too in case there are questions about Analytics-managed infrastructure (I suggest adding @Nuria).

Why has Fundraising-Analysis been marked as a private project within the last week? We do not permit this.

It's been fixed. I have left a note on the project description. Please do not try that again on any project @ellery.

In T119258#1860818, @Krenair wrote:

Why has Fundraising-Analysis been marked as a private project within the last week? We do not permit this.

It was done yesterday morning when you noticed, by @ellery. I imagine the reason this happens is the common misconception that "Viewing a project" is correlated with having a project member's being given view rights to tasks. This is incorrect.

I've unlocked the object as projects are not permitted to be hidden entirely, you're right. It confuses dump scripts and causes heartache. Now, since this project is clearly being used as an ACL for access to tasks, we'll want to control who can add/remove members, but the visibility problem should remain.

Is Fundraising-Analysis itself actually being used for ACL? It's not supposed to be, that would be a violation of the guidelines.

In T119258#1863870, @Krenair wrote:

Is Fundraising-Analysis itself actually being used for ACL? It's not supposed to be, that would be a violation of the guidelines.

Maybe not, I just skimmed this task and saw "We would like a specific set[...]to be able see and participate in these tasks."

The instructions to manage S5 private space and the members of #acl*fundraising_research_policy_admins who have access to it have been explained by @Aklapper above, at T119258#1829987. Basically, only creating or moving tasks to S5 you make them private.

Tasks associated with Fundraising-Analysis but placed in the Public space will be Public, regardless of the policy of Fundraising-Analysis itself. The only thing made private when setting that project to private is the container, not the tasks contained. There is no security/privacy reason to make any project private, and this might cause the technical problems described above.

For these reasons, @ellery changing the visibility from "Public (No Login Required)" to "Custom Policy" was an action that surely didn't bring the result intended, and also was against our policy. Reverting that change of policy back to public is correct, and does not affect the existing privacy policy of the tasks associated with that project, regardless of whether they were public or private (in the S5 private space) all along.

@Krenair, let me add that your style resolving these situations comes across as unnecessarily harsh. Expressions like "we do not permit this", "unacceptable", "violation of the guidelines" make the problem bigger than it actually is. A Phabricator project has been made private by mistake: that action doesn't cause any harm and can be easily reverted. Meanwhile, people's feelings can be hurt when speaking to them in that tone, and the result is more difficult to revert. Please take it easy. My rule of thumb is to speak to others using the same words I would use if they were regular colleagues standing in front of me.

Alright, I hope everything is clear and resolved now. Let's move on, please.

@ellery: https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Project_Policies says:
"IMPORTANT: these policies apply to a project (and its page) itself, not to the tasks assigned to a project!"
Not sure how to make that more clear. If there are questions please just ask on https://www.mediawiki.org/wiki/Talk:Phabricator/Help

In T119258#1863870, @Krenair wrote:

Is Fundraising-Analysis itself actually being used for ACL? It's not supposed to be, that would be a violation of the guidelines.

It should not. For this specific space, #acl*fundraising_research_policy_admins is used (see previous comments).

Update: I had not seen Quim's comment when I wrote mine here.

In T119258#1864061, @Qgil wrote:

@Krenair, let me add that your style resolving these situations comes across as unnecessarily harsh. Expressions like "we do not permit this", "unacceptable", "violation of the guidelines" make the problem bigger than it actually is.

It should be obvious that you should not mess around with transparency-sensitive things such as visibility policies unless you know what you're doing. We should not even be allowing anyone to touch this field at all on any project in our Phabricator instance.

In T119258#1864061, @Qgil wrote:

A Phabricator project has been made private by mistake

Seems more like a fundamental misunderstanding by someone who did not know what they were doing.

In T119258#1864061, @Qgil wrote:

that action doesn't cause any harm

It's harmful to the transparency about what types of tasks are being tracked in Phabricator, and since a custom policy was used even the list of people able to view the project was hidden itself.

In T119258#1864061, @Qgil wrote:

that action [...] can be easily reverted.

Actually I ended up having to get someone *with phabricator server access* to intervene to fix this.

In T119258#1864061, @Qgil wrote:

people's feelings can be hurt when speaking to them in that tone

Since I didn't have access to fix this myself, and someone *had* to do it, I resorted to a more demanding tone than requesting.

I apologize for the confusion I have caused. I learn through experimentation and tend to bias towards action instead of sending out emails to do something I can try myself. Also, I learn to use UIs by using them, not by reading documentation. I will tread more carefully with using phabricator.

We have had a need for replacing the private Trello board for months. I did not realize that Trello boards do not map to phab boards and that privacy is a property of a card, not a board. It still seems strange to me that a board that is supposed to contain only private cards is public. In any case, I put all the cards I made in S5, so no private information has been leaked on my end.

@Krenair Please do not assume I am acting in bad faith, knowingly breaking rules and trying to get away with it. If you see me making a mistake, consider reaching out to me on irc, gchat or google hangouts so we can resolve any issue in a friendly manner.

In T119258#1864164, @ellery wrote:

@Krenair Please do not assume I am acting in bad faith, knowingly breaking rules and trying to get away with it. If you see me making a mistake, consider reaching out to me on irc, gchat or google hangouts so we can resolve any issue in a friendly manner.

I only knew it was you once I'd gone to the effort of getting a server administrator to remove the visibility policy you set (actually the initial assumption in my head was someone in fundraising was responsible). At that point it was already resolved. It's not personal, I'd be saying the same thing if anyone else had done this.

@Krenair

It should be obvious that you should not mess around with transparency-sensitive things such as visibility policies unless you know what you're doing.

allow me to respectfully disagree. As it emerged from a brief post-mortem about this incident, it's clear that this is a major gap in the software and you should never assume that something is obvious when it requires reading policies or understanding complex ACL design, particularly when – as you note – user rights do allow people to perform actions that may compromise security or privacy. Even if there was no data leak, the team is considering reverting to Trello for handling these requests: the Fundraising team doesn't have the luxury to study policies at the moment and I'm afraid tool usability takes precedence over everything else. I too feel your language is inappropriate and invite you to reconsider how you address your coworkers.

@Krenair I think you are missing my point, maybe we can chat in person during All Hands.

It seems like the one thing we can agree on is that any UI actions that are "forbidden" should be hidden. Maybe that change will be the silver-lining of this episode :).

In T119258#1864186, @DarTar wrote:

it's clear that this is a major gap in the software and you should never assume that something is obvious when it requires reading policies or understanding complex ACL design

Phabricator's ACL design seems simple enough to me. I expect people wanting to change policies to either understand how it works, or to not change policies.

In T119258#1864186, @DarTar wrote:

particularly when – as you note – user rights do allow people to perform actions that may compromise security or privacy.

? Not sure what this is referring to.

In T119258#1864186, @DarTar wrote:

the Fundraising team doesn't have the luxury to study policies at the moment and I'm afraid tool usability takes precedence over everything else.

Project policies being separate to task policies is not a particularly hard concept to understand. A similar system that comes to mind is directory permissions vs. permissions on the files in the directory. I hope your team understands those.
Also, tool usability can't take preference over the Wikimedia movement's values and the WMF guiding principles, which a move to Trello would violate (transparency, freedom and open source, etc. etc. etc.).

In T119258#1864186, @DarTar wrote:

I too feel your language is inappropriate and invite you to reconsider how you address your coworkers.

I've already addressed comments about language. Do you have something else to add?
Also, this is not about coworkers - I am a volunteer here. And I would certainly not treat coworkers and other users of Phabricator differently purely on that basis.

In T119258#1864196, @ellery wrote:

@Krenair I think you are missing my point, maybe we can chat in person during All Hands.

Nope, I am attending as a contractor (they don't send volunteers to All Hands). If you think I am missing the point, you should write about it here.

In T119258#1864196, @ellery wrote:

It seems like the one thing we can agree on is that any UI actions that are "forbidden" should be hidden. Maybe that change will be the silver-lining of this episode :).

Sure, and I would make that happen if I could. But AFAIK you'd have to argue it to upstream instead of me.

Really no harm was done.

On the internet it is difficult to tell whether a comment is only matter-of-fact bluntness or intentional rudeness. I try to always assume the former until I learn otherwise. @ellery, definitely don't take it personally, nobody is mad about it, at least not as far as I can tell, and certainly there isn't anything to be upset about.

Personally I don't feel there is anything wrong with learning by using the software. The phabricator use guidelines are not presented as part of the phabricator interface. It isn't entirely obvious to every phabricator user that we even have guidelines.

In T119258#1864196, @ellery wrote:

It seems like the one thing we can agree on is that any UI actions that are "forbidden" should be hidden. Maybe that change will be the silver-lining of this episode :).

I can look into what it would take to hide the policy controls on projects, that might be easy enough to change in our fork of phabricator.

T120903: investigate hiding the policy controls for phabricator projects.