Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
In s.d.o, we currently have these statuses:
- Needs triage
- Needs work
- Needs review
- Needs maintainer response
- Needs team response
- Needs reporter response
- Needs public followup
- Reviewed & tested by the community
- Ready for SA to be Published
- No maintainer response (unsupported)
- Postponed
- Closed (fixed)
- Closed (can be public)
- Closed (duplicate)
- Closed (won't fix)
In Gitlab, these labels are set currently:
- D7 / affected (Tracking for D7ES vendors)
- D7 / needs evaluation (Tracking for D7ES vendors)
- D7 / only (Tracking for D7ES vendors)
- Needs attention (Automatically added when an issue has not had a timely response)
- Needs maintainer response
- Needs public followup
- Needs reporter response
- Needs review
- Needs security team response
- Needs work
- Project to be unsupported
- Security advisory / drafted (Automatically added when a security advisory draft is created on Drupal.org)
- Security advisory / needed (Will prompt maintainers to draft a security advisory)
- Security advisory / published (Automatically added when the security advisory is published)
- Security risk / Critical (Automatically updated with the risk score from draft security issues)
- Security risk / Highly critical (Automatically updated with the risk score from draft security issues)
- Security risk / Less critical (Automatically updated with the risk score from draft security issues)
- Security risk / Moderately critical (Automatically updated with the risk score from draft security issues)
- Security risk / Not critical (Automatically updated with the risk score from draft security issues)
- Security status / can be public (A security fix is not needed, further work can happen in public issues)
- Security status / evaluating to be public (2 weeks are allowed for security team feedback on potentially handling the issue in public)
- Security status / unvalidated (The issue is newly reported, the first step is to validate the issue)
- Security status / validated (It's been confirmed that an issue is in fact valid)
-----------------
The missing original statuses are:
- 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
Proposed resolution
Decide which additional labels we need to add and add them.
Comments
Comment #2
poker10 commentedMy 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?Comment #3
poker10 commentedComment #4
poker10 commentedComment #5
drumm#3519593: Update automated messages in Security Team's Gitlab 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:
We can add additional daily notifications leading up to the scheduled security release date, if either tag is missing. Those can be drafted in #3519593: Update automated messages in Security Team's Gitlab or a separate followup
Comment #6
drummI 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.
Comment #7
drummWe should add both of these, I imagine they will be useful for retrospectives.
Comment #9
drummThe missing statuses are filled out now:
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.
Comment #10
drummIt's been awhile with everything known resolved, so calling this fixed. We can always open followups when needed.
Comment #11
drumm(Forgot to update credit)