I also understand that the second tag is named somewhat vaguely, although there are some internal intentions behind that.

What if a wikimedia project wanted to host an event?

It sounds too vague to me. Is there a guideline on when it should be used?

Hi, please see https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects for required information (e.g. a description).
Also, secteam-reviewed sounds like a status (e.g. workboard column) and not like a project tag to me? Thanks!

In T271729#6736709, @RhinosF1 wrote:

It sounds too vague to me. Is there a guideline on when it should be used?

It's primarily internal to the Security-Team as a means of tracking certain on-wiki events which have corresponding Phab tasks. But we'd really prefer to NOT be alarmist in the naming, thus wanting to avoid names like on-wiki-security-event or on-wiki-security-incident, which mean different things to our team.

In T271729#6737538, @Aklapper wrote:

Hi, please see https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects for required information (e.g. a description).

Thanks - I didn't really have descriptions ready when I created this task as I had wanted to work through those after the project tags had been created. But I can work on them now and update the description if that's the best practice. Now updated.

Also, secteam-reviewed sounds like a status (e.g. workboard column) and not like a project tag to me? Thanks!

The Security-Team primarily wants this tag to be able to effectively track and run quarterly reports on items we triage in our clinic (or as individuals). Via the standard maniphest search query form, I am not aware of a way to select tasks based upon their current workboard column.

In T271729#6740716, @sbassett wrote:

In T271729#6736709, @RhinosF1 wrote:

It sounds too vague to me. Is there a guideline on when it should be used?

It's primarily internal to the Security-Team as a means of tracking certain on-wiki events which have corresponding Phab tasks. But we'd really prefer to NOT be alarmist in the naming, thus wanting to avoid names like on-wiki-security-event or on-wiki-security-incident, which mean different things to our team.

Thanks for the explanation. Noting a quick discussion about naming in -releng I had with you that also suggested #wikimedia-cyber-event but I fully understand the desire to avoid the terms "security" and "incident"

Ping @Aklapper, @Reedy - are we ok to create these tags now? The Security-Team would like to start using these soon, if possible. Thanks.

The description of wikimedia-project-event implies that it should be a subproject of Security-Team if it's only ever relevant to the security team to have it on their (sub)board?

If SecTeam-Processed implies that it has been accepted to a backlog of some existing project tag or some column of some existing project tag's workboard, and if it's not in scope so the Security-Team tag has removed anyway, why is that tag needed at all?

"Reviewed" seems to be meaningless. Either it's "accepted" (ends up in a workboard column) or "nothing to do for us" (tag gets removed)?

In T271729#6773883, @Aklapper wrote:

The description of wikimedia-project-event implies that it should be a subproject of Security-Team if it's only ever relevant to the security team to have it on their (sub)board?

Sure, that's fine.

In T271729#6773897, @Aklapper wrote:

If SecTeam-Processed implies that it has been accepted to a backlog of some existing project tag or some column of some existing project tag's workboard, and if it's not in scope so the Security-Team tag has removed anyway, why is that tag needed at all?

"Reviewed" seems to be meaningless. Either it's "accepted" (ends up in a workboard column) or "nothing to do for us" (tag gets removed)?

Given the Security-Team's unique mandate of triaging tasks that come in tagged with either Security / Privacy and/or are submitted as protected tasks, we need some way to track and statistically report upon these tasks on a quarterly basis and to visually indicate to anyone who cares that, yes, our team did actually review a given task. This is a little more challenging in our team's case since a large majority of these tasks do not end up in our backlog and/or are easily forgotten once we untag our team or even place a task within our team's watching column. Creating a new Phab tag, which would allow us to easily track and report upon these tasks, seemed like the most sane approach. If there's a better available option, which satisfies all of these requirements, I'm certainly willing to evaluate it. Tracking these tasks manually (in a Google sheet or something) or within another system seems like a far more irritating and work-intensive approach for our team. And there would be some conflicts and workflow breakage if we simply tried to add another column to the Security-Team's workboard.

<tl;dr>: Big thanks for providing the additional background here. I'm still not fully convinced but let's try and feel free to create those.

Longer version / thoughts:

I do see how some kind of project tag to mark tasks as "Security looked at this; nothing to do for us" makes sense, but in that case "reviewed" would be a vague term compared to e.g. secteam-nothing-to-do (for some context: I've seen patch review systems with status entries like rejected, accepted, needs-rework but also reviewed and the latter term left everyone baffled what that's supposed to mean for who, so things were often just left lingering due to ambiguity).

I'm still not convinced that secteam-reviewed makes sense if it e.g. "implies that the task has been accepted into one of our backlogs", because that's already expressed by a workboard column move or by adding some Security related project tag.
If you intend to tag every task ever looked at by the Security Team, then this feels like a work-intense and error-prone way to gather statistics.
For those folks who want to know that the Security team reviewed a given task, I'd have expected folks to look at the task and spot a comment or an action by the Security Team in there, e.g. removing the Security Team project tag. But people might not even open tasks and only look at workboards, so you might have a point.

(PS: I shortened the beginning of the descriptions a bit ("This project tag indicates that a task has been..." 🡒 "Tasks that have been..."), as space is precious in the description preview.)

In T271729#6773883, @Aklapper wrote:

The description of wikimedia-project-event implies that it should be a subproject of Security-Team

Have to correct myself: No, subproject is a bad idea as there are no subprojects yet, so all its members would be moved. Sigh, not so great Phabricator limitations.

I created SecTeam-wikimedia-project-event and SecTeam-Processed; please review.
Thanks (also for the patience)!

What about SecTeam-Seen or SecTeam-Processed as alternatives to SecTeam-Reviewed?

In T271729#6775487, @Aklapper wrote:

I created SecTeam-wikimedia-project-event and SecTeam-Processed; please review.
Thanks (also for the patience)!

Thanks, these should work great.

In T271729#6775538, @Legoktm wrote:

What about SecTeam-Seen or SecTeam-Processed as alternatives to SecTeam-Reviewed?

Those would likely be fine as well. Since @Aklapper just created SecTeam-Processed, maybe we can try that for a while and if it's too confusing, we can rename it.

I favor processed"(thanks for finding better words!) as it implies a process has finished in contrast to reviewed's "we took an initial first look", so I renamed.

@sbassett: Hmm, why were Edit Policy and Join Policy of SecTeam-Processed and SecTeam-wikimedia-project-event changed to acl*security ? Which problem does that solve, apart from blocking interested people to join/follow that project?

In T271729#6790352, @Aklapper wrote:

@sbassett: Hmm, why were Edit Policy and Join Policy of SecTeam-Processed and SecTeam-wikimedia-project-event changed to acl*security ? Which problem does that solve, apart from blocking interested people to join/follow that project?

Paranoia on my part if those tags are applied to protected Phabricator tasks and thus allow lower-privileged members/watchers to view sensitive or PermanentlyPrivate tasks. These tags should really only ever be used or cared about by Security-Team members, but if there is a desire to have them as open as possible, I'd want to confirm that some random Phabricator user couldn't join them and then view protected tasks to which they may be applied.