I'd like the following project created, so we can exclude some bugs from our reporting. These tags have to be in the Security project for access control reasons, but the Security Team is not working on them. I don't think a tag project is appropriate, so I think having it marked as a personal project might make the most sense.
Name: Security-non-WMF
Description: Personal project to improve tracking reports for the Security-Team
Type of project: Personal
I'm not sure this should really be a *personal* project. The difference between Security and Security-Team does bug me a little though.
Is the idea just that Security contains everything, Security-Team is also added to things involving WMF, and this new project would be added to all other Security tickets?
So all Security tickets would also have either Security-Team or #Security-non-WMF?
Security is everything that is software and needs to stay private. Security-Team is stuff that the team should give input or work on, which may or may not be private. And the Security-Team may or may not be working on a Security bug, depending on the nature of it (e.g., Moritz is a WMF security engineer, but not a part of the Security-Team, so most operations and labs security issues don't get tagged with Security-Team)
The issue that this tag solves is that our KPI's are tied to Security bugs, and some of those don't make sense for the WMF to be working on. So I would like a way to tag those and exclude them from our monthly reports.
It would be a more normal thing to create a WMF-Security-problem tag, and only report on issues that include that, but since something like 95% of Security issues are the responsibility of the WMF, it would be easier for me to exclude the ones that don't apply to us.
Security contains some public tickets. Moritz's case is interesting - he'd have Security tickets that are neither #Security-non-WMF nor Security-Team. But surely you'd want KPIs to be tied to Security-Team? Or you'd want them to include Moritz too?
FWIW, tasks don't actually have to be in the security project in order for the policy controls to do their thing.
We may want to move away from using the security project as any sort of security-related identifier if it confuses people.
Yeah. I prefer tasks with non-public policies have projects which identify them as such (you can't search by policy etc.)
It should probably become one of the acl* projects and have public stuff moved out into a new Security project. Or something.
I admit I've only been reluctant because it already feels too messy to me and I'd like to sort that out a bit first.
Apart from the Security dropdown, we have Security, Security-Core, Security-Extensions, Security-General, Security-Other, Application Security Reviews, Security-Team.
I wonder which are actively used, and if some should also automatically be tagged with others (e.g. should tasks in Security-General always also be Security?)
And Security should likely not be a team project but a normal blue project.
I would be fine getting rid of Security-Core, Security-Extensions, Security-General, and Security-Other. Tracking what is core vs. and extension vs "other" isn't something I use, and less and less reflects the the actual structure of mediawiki (doesn't account for libraries or services, and sometimes core vs extension isn't clear-cut either).
Can we rename Security to an acl project? It seems like we had some trouble with renaming projects previously. But it definitely should be acl, at least the way it's currently being used.
Can we rename Security to an acl project?
Assuming there are no negative side effects (like those tasks accidentally becoming public), then I'm fine with renaming it.
If we change the project name then the security extension will have to be updated, I believe it looks up the project by name. Regarding the naming convention, T126055: Allow the use of team projects as representation of teams suggests eliminating the acl prefix. For now I think the icon and color do enough to convey it's purpose so I've changed it to the red padlock "policy" project type. I am not hung up on the acl naming convention but others might be more attached to it.
@dpatrick: Any comments / opinion on this?
Also wondering how to tag tasks like https://phabricator.wikimedia.org/T107707 as "security related" if we archived those four Security-* tags (which do not restrict task access themselves).
It definitely should follow naming conventions and be named #acl*security. It is one of the only two exceptions (the other is WMF-NDA). #Security should be reserved for appropriate tag instead.
As an aside, I've made a column on the security workboard to sort non-wmf bugs into, so at least we can see what's what (I don't think statistic scripts know how to take this into account).
If we do do this (Is this still wanted?), maybe security-non-wmf should be one of those fancy sub-project thingies.
I would like to hold off on making any changes to existing Phabricator tags, projects, groups, etc. for a bit. @Bawolff has just reorganized the Security workboard, and I'm in the process of reimplementing how we gather metrics. Let's revisit this after some atime has passed during which we see how those changes meet our needs. I apologize in advance if this is annoying.
(As per last broader comments: Note that cleaning up "Security related Phab projects" would likely fix T109328: Undefined #Security-General and #Security-Other. T108360: Create "security pre-announce" group in Phab (to easier allow 3rd parties who get pre-release notifications to access Security tasks) is also related.)
Re-reading this task, I'm not convinced which problem would get solved by this (or I really don't understand the problem which is also possible).
You could easily search for tasks that are under Security but not under Security-Team, or apply that filter on the project's workboard.
Half a year later: Is this the time to revisit?
....or move such tasks to a dedicated workboard column, and existing problems on the Security workboard imply that this could work.
Hence I'm declining this task for the time being. Feel free to reopen once the request has been clarified. Thanks!