Improve Drupal core issue version guidance and selection

Created on 25 June 2024, 4 days ago
Updated 27 June 2024, 1 day ago

Problem/Motivation

As someone who has only really created issues for contrib projects, the issue creation process in regard to which version to choose is too confusing for Drupal core.

For example, for Webform, if I am using their current latest release of 6.2.2, I would report an issue against 6.2.2 or the related dev branch of 6.2.x-dev. Looking at the open issue queue, both appear to be acceptable.

Using that same logic, if I am using the latest Drupal core release of 10.3.0, I would report an issue against 10.3.0 or the related dev branch of 10.3.x-dev.

I found a minor issue with 10.3.x and reported it in 🐛 "Undefined array key 1 in template_preprocess_html()" on the 404 page when adding extensions to index.php Needs work . But another contributor changed my issue to 11.x and said:

11.x is the current development branch so fixes need to land there first and be proven there also, just FYI

This described 'need' is not documented in the issue creation workflow nor is it even suggested or recommended with any default version in the dropdown selection.

When creating a new issue, the issue creation form describes 3 things: security issues, learning how to report, and information needed for a bug report.

Security issues should not be reported here. Follow the procedure for reporting security issues.

Learn how to report an issue.

If you are reporting a bug, it needs to consist of three things:

What are the steps required to reproduce the bug?
What behavior were you expecting?
What happened instead?
Please include as much information as you can: OS, webserver name and version, PHP version, Drupal version, Drupal path, and everything else you might feel is relevant. There is no such thing as a bug report that is too detailed.

If you are submitting a feature request, please review the criteria for evaluating proposed changes.

Post general support requests in Drupal.org forum.

The bug report text says to include Drupal version, which is what I provided in the version selection: 10.3.x-dev.

The Creating or updating an issue report page has this to say about selecting version:

Version: Leave the default value. You can mention which specific version you're using in the issue summary field described below.

When creating a new Drupal core issue, there is no default value. The default value is "- Select a value -" which is marked as required. If I do as the page says and leave it on that default, an error is returned that says "Version field is required."

There is otherwise no indication nor guidance on this issue creation form about what the 'proper' version to select is. There is nothing in this issue creation workflow that leads me to believe that 11.x is the only version I am allowed to create new issue reports for.

In fact, there are version options in the dropdown for Drupal core versions as far back as 4.6.x-dev, which gives the indication that I could report a new issue against that branch which seems absurd.

In very small text, below the Issue summary box, there is "Drupal project issues documentation" which has more information. There, I have to drill down into "List of issue fields" to learn to "set this to the current development version of the project," which is still not helpful. My thought process is, if I am using 10.2 or 10.3, the current development version would be 10.2.x-dev or 10.3.x-dev.

As a new issue reporter for Drupal core, there is a significant discrepancy in expectations coming with experience reporting issues for contrib projects. For example, for the Chosen module, I can validly report an issue for stable version 3.0.5 to the queue under 3.0.5 or 3.0.x-dev, or stable version 4.0.1 to the queue under 4.0.1 or 4.0.x-dev.

As it is, the issue creation workflow is confusing for Drupal core when it comes to the version I'm allowed or supposed to report for. I want to report an issue against the latest stable version like I do for contrib projects, or at least the same related -dev branch.

As the other contributor admitted, it's possible my issue is fixed in a later version but may need a backported fix.

If fixed in 11.x but not 10.3 then should find out if something was committed that maybe didn't get backported.

They unfortunately did not consider that possibility before changing my issue to a version that I did not report for.

This confusion with the workflow, along with my issue getting pushed around with the version, leads to a poor new contributor experience. I am less inclined to report new issues to Drupal core when I can expect people to deny that my issue is valid.

Steps to reproduce

  1. Visit the issue creation page for Drupal core.
  2. Look for any default version or easily gleaned guidance about needing to report bugs against the latest 11.x dev version.
  3. Observe lack of sensible version defaults or guidance.

Proposed resolution

  • Set the version dropdown to a suggested/recommended default.
  • Disable/remove options for versions that should not get new issue reports (unless it's actually ok for me to create a feature request or bug report for Drupal 4, 5 or 6).
  • Add more clear version guidance in the issue creation form's bug report info block and the How to report an issue page.
Feature request
Status

Active

Version

11.0 🔥

Component
Ajax 

Last updated about 3 hours ago

Created by

🇺🇸United States joshuasosa

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @joshuasosa
  • 🇺🇸United States drumm NY, US

    The text at the top of the create issue form is set by core maintainers by editing the core project page.

    https://www.drupal.org/community/contributor-guide/reference-information... can be edited by anyone. Go ahead and make any clear improvements, and gain consensus on any changes that aren’t straightforward.

    In the future, issues are moving to GitLab 📌 Migrate drupal.org issues to gitlab issues Needs review . Version and other metadata will be labels on the issue, and we will be using GitLab’s UI for this, which is not customizable. For example, if the core maintainers remove the Version::5.x label, that may remove it from all historical issues, it would need testing before doing too much. I’m not aware of any ability to disable using a label on new issues, other than a triage bot to automate corrections.

    Since this is coming in the next few months, we are limiting changes to the issue UI on Drupal.org, to focus on the migration. This means we likely will not be setting the version dropdown to a suggested/recommended default.

Production build 0.69.0 2024