Decide which labels are needed for

My thoughts regarding the missing statuses:

Reviewed & tested by the community - I think that we discussed to use milestones to schedule releases. So adding an issue to a milestone can be probably considered as RTBC?

Ready for SA to be Published - We used this status when maintainers actually committed the fix and created release. Can this be automated somehow, so that we are notified about new private releases in the Gitlab issue? If so, then web probably do not need this?

Postponed - Not sure how to label such issues. Probably need to add this?

Closed (duplicate) - We can link another issues in Gitlab, but there are only three options: relates to, blocks, is blocked by. If it will be sufficient to mark it as "relates to" and close it with a comment that it is a duplicate, then we probably do not need this label.

Closed (won't fix) - Not sure how to label such issues. Probably need to add this?

Ready for SA to be Published - We used this status when maintainers actually committed the fix and created release. Can this be automated somehow, so that we are notified about new private releases in the Gitlab issue? If so, then web probably do not need this?

📌 Update automated messages in Security Team's Gitlab Active did automate this, https://git.drupalcode.org/project/drupalorg/-/commit/47f37bb9 is the message added. It does not currently add a label. It was not working for the one_time_password issues since the advisories weren’t drafted starting from the GitLab issue, so there was no link from the advisory to the issue.

Ready for SA to be published also needs the advisory to be drafted. I think what I’ll add is:

• When a release is made, also add a label that the security release is done
• Add a “Ready to publish” label (trying to keep labels as concise as they can be)
• When an issue has both release done & advisory drafted, automatically add ready to publish. There isn’t a security team member has approved the SA draft state, but I think that’s fine to leave loose, as it will get a final review on security release Wednesday

We can add additional daily notifications leading up to the scheduled security release date, if either tag is missing. Those can be drafted in 📌 Update automated messages in Security Team's Gitlab Active or a separate followup

Reviewed & tested by the community - I think that we discussed to use milestones to schedule releases. So adding an issue to a milestone can be probably considered as RTBC?

I think we do want to add a label, that can have an automated response to tell everyone the next steps. That will be a bit better UI, labels are easier to remember and look for, and there is sometimes negotiation around which Wednesday a maintainer wants, or the team coordinating with something else. We could have the automation follow up if a ready issue is not assigned a milestone within a certain amount of time.

Closed (duplicate) - We can link another issues in Gitlab, but there are only three options: relates to, blocks, is blocked by. If it will be sufficient to mark it as "relates to" and close it with a comment that it is a duplicate, then we probably do not need this label.

Closed (won't fix) - Not sure how to label such issues. Probably need to add this?

We should add both of these, I imagine they will be useful for retrospectives.

The missing statuses are filled out now:

• Reviewed & tested by the community → Security status::reviewed & tested
• Ready for SA to be Published → Security status::ready to be published
• Postponed → Security status::postponed
• Closed (duplicate) → Closed::duplicate
• Closed (won't fix) → Closed::invalid, potentially might be other statuses

And what I mentioned in #5 is done by https://git.drupalcode.org/project/drupalorg/-/commit/109256299611a258d8... & https://git.drupalcode.org/security/triage/-/commit/cc6e081e6ab08d16f49b...

So I think everything we’ve thought of has been followed up on.