Decide which labels are needed for

Open on Drupal.org →

Created on 16 April 2025, 9 days ago

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
Ready for SA to be Published
Postponed
Closed (duplicate)
Closed (won't fix)

Proposed resolution

Decide which additional labels we need to add and add them.

📌 Task

Status

Active

Version

1.0

Component

Security advisories

Created by

🇸🇰Slovakia poker10

Live updates comments and jobs are added and updated live.

Sign in to follow issues

Comments & Activities

Issue created by @poker10
Comment 9 days ago →
🇸🇰Slovakia poker10
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?
Comment 9 days ago →
🇸🇰Slovakia poker10
Comment 9 days ago →
🇸🇰Slovakia poker10

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024