- Please create space for SIEM (security information and event monitoring). The space needs to be private because it involves security work
- Please name the space SIEM
- Group lead is @dpatrick
- Specific Phabricator users who should be able to access objects in that space: @dpatrick, @bbogaert, and @ggellerman
More information on this project can be found here: https://office.wikimedia.org/wiki/Office_IT/Projects/SIEM_Project
Well, in this case that's less relevant, as the Space would be non-public too (however the associated project description itself would be visible, but not its tasks if they are both in the project and the Space).
This should be separate from Security. We track vulnerability metrics using the Security tag and the tasks created for the SIEM project should not be included in those metrics. Additionally, at this point, the tag is being used to notate a specific project that requires some collaboration across teams. At this point, only Foundation employees are working on this project so it's fine to reference Office Wiki for more information.
So the information about what is private... is itself private? That seems somewhat untransparent, and I don't think we should grant such requests. As an example, the fact that the Security private tasks are set up to deal with security vulnerabilities is itself not private information, and I think we should expect the same standard for any kind of new private area to be created.
- Regarding the project and its workboard:
- Public project WMF-SIEM created: https://phabricator.wikimedia.org/project/view/2355/. Public project description explicitly says that "Non-public tasks in this project are additionally in S11".
- Regarding the Space (a Space is not a project and hence there is no workboard):
- For access control, created #acl*wmf_siem_policy_admins. This defines access to tasks in the private Space. Description says: "Policy Administrators for the private space S11 related to the public WMF-SIEM project".
- Created the private Space S11 ("SIEM"). Its Join and Edit policy are intentionally set to #acl*wmf_siem_policy_admins and should not be changed.
- @dpatrick can add/remove users (who can create and access tasks in S11) via editing the members of #acl*wmf_siem_policy_admins. Note that Phabricator admins could also add themselves (this is a fallback for when a team lead has left; we had that situation); if you watch #acl*wmf_siem_policy_admins project you'd get a notification about such an action.
- Please do read Displaying and using a Space for more information. For example, when creating private tasks in that Space you must choose "Visible To: Space S11: Siem" in the task creation form to create private tasks only accessible to members of S11 and nobody else.
- For convenience, created Herald Rule H205: If Space is set to S11, add project: WMF-SIEM.
- Documented the creation of S11 on https://www.mediawiki.org/wiki/Phabricator/Spaces .
- Please ask if things are unclear.
@Krenair: Because minor problems like a description that can be improved do not block the creation of projects and because I am not the one to address your concern. The WMF-SIEM project is public and it has a public description that can be improved if more public info is wanted.
That comment is nowhere near sufficient for this kind of thing, it doesn't describe the scope of contained tasks. ACL projects/spaces need serious community discussion, you just did this single-handedly without even addressing my concern beforehand, let alone solving it and waiting for any other comments. This needs to be closed down again until it is done properly.
I am sure one of the Space members are happy to edit the description of the public project if a need for more info is seen.
ACL projects/spaces need serious community discussion
You are always welcome to encourage that discussion - I cannot enforce it though.
I don't see a "need" or even much sense in a "community discussion" whether parts of the Ukrainian chapter can have a private Space to handle their internal affairs, or whether parts of the WMF can have a private space to handle internal security information and internal event monitoring, or whether parts of $entity involved in the movement can have a private space to handle internal $stuff.
you just did this single-handedly
Indeed, after having this request lingering in public for nearly two weeks while everyone had the chance to take a look and provide feedback. At some point it's time to act on requests.
without even addressing my concern beforehand
As already explained, there was no need to address your concern beforehand, as per guidelines.
My point is this should be done *before* any private space is granted. The standards shown here are well below what I'd expect for a transparent, community-driven process.
You can though. You can say you won't grant such a space without one. If need be we can amend the guidelines to explicitly require full community consensus for such a thing, but honestly we really shouldn't need to be having this conversation.
It would matter a lot less if members of private spaces didn't have the ability to steal tasks out of the public space without a trace. As it is, we need some serious scope pre-determined and the ability to enforce that.
I don't think we need to write into the guidelines that outstanding serious concerns must be addressed. If admins aren't dealing with that we should be revoking their flags.
I don't agree.
(Edit: Well, I can agree on "should". Which is not "must". And has been explained various times in this task now already.)
I don't think we need to write into the guidelines that outstanding serious concerns must be addressed.
There was no outstanding serious concern.
I'm not sure how to phrase "should". Which is not "must". any clearer.
This task does not feel like a good use of my time. I've explained my views more than once, so I'm leaving this conversation.