Drupal 9.0.0-beta2 was released this week and there are only 63 days to go for Drupal 9.0.0's release. Many product developers, distribution authors and so on are now looking at what is left to be Drupal 9 compatible and which of their dependencies are doing what where. So effectively tracking a list of drupal.org issues somewhere is on many people's minds. While you can follow issues on drupal.org that only works for your personal needs. Actually Surabhi Gokte asked me yesterday about tools for group issue tracking, and I decided to write up a quick blog post because the answers are likely useful for many people. Here are two public and two possibly private ways to track drupal.org issues. I've used each in some form throughout my years with the project and you may find some of them useful.
Public: use a drupal.org META issue
Drupal.org project developers, this is a good way to track your tasks belonging to a larger goal like Drupal 9 compatibility. Create a regular drupal.org issue for your project and use the issue link filter.
[#123456] is the format to use to link to issues and get their title and even status colors represented on your issue. The only thing you need to keep an eye on is that issue summaries are cached, so as the status/title of listed issues are updated, that is not reflected on the summary. As you are likely to adjust the list as things get done and new things are discovered, the status and titles of the listed issues should get updated in the meantime. An example of this technique is [META] Requirements for tagging Drupal 9.0.0-beta1. This technique allows anyone with a drupal.org account to help maintain your list of issues.
Once you have a META issue like this for Drupal 9 compatibility, please link it from your Drupal 9 plan on your project page, see:
Public: use Contrib Kanban
Contrib Kanban is a great service developed and ran by Matt Glaman of Centarro. You can register and create custom boards based on a list of issues, such as this kanban board for Umami's Spanish translation. Only you will be allowed to maintain your issue list but the results are shown very visually and dynamically in a kanban board style.
Public/Private: use any tool with the Drupal issue Chrome browser extension
Matthew Grasmick built the Drupal Issue Chrome browser extension which turns links to Drupal.org issues on any webpage to their colored and titled forms very much like in the META issue method. This will pull the data for issues live, but only people with the extension installed will see the titles and statuses. You can use this for private tracking or public tracking. We use it at Acquia to track some drupal.org issues through Jira tickets.
Public/Private: use a scripted spreadsheet
This method could work in any scriptable spreadsheet system. We used it extensively at Acquia with Google sheets and I believe it originates from Andrea Soper (ZenDoodles) and Jess (xjm) from several years ago. Set it up like this:
- Assuming an empty spreadsheet, designate a column for issue numbers. You will use this column to enter the ID of issues you want to track. Let's assume this is column E for the rest of the example. Also let's assume you use the first row for header text for the columns.
- Add this to F2:
=IF(E2="","", regexreplace(importxml(hyperlink( concat("https://www.drupal.org/node/", E2)), "//*[@id='block-project-issue-issue-metadata']/div/div/div/div/div/text()"), "\n","")). This column will be your issue status.
- Add this to G2:
=if(E2="","", hyperlink( concat("http://www.drupal.org/node/",E2),concat("#",E2))). This will be your issue link.
- Add this to H2:
=if(E2="","", substitute(regexreplace(importxml(hyperlink( concat("https://www.drupal.org/node/", E2)), "//title/text()"),"\n",""), " | Drupal.org","")). This will be your issue title.
At least in Google sheets, you can hold-drag these values to fill in the rest of columns F-H with appropriate computed values. You can also apply conditional styling to status values, etc. A clear benefit of this approach is that you can assign tabular metadata to issues, like your private severity or priority information or assignments within your company as to who is planning to look into it without getting into a priority argument on the issue.
By the way it would definitely be more reliable to pull this data from the Drupal.org REST API. We used this method extensively for years at Acquia to track high priority issues leading up to Drupal core releases. However we are not currently using this method and I did not go to convert the logic from our old sheets, so improvements welcome.
These are methods I used that are still available and work fine. Do you have better ways to do issue list tracking? Let me know in the comments.