How to manage drupal.org issues according to your priorities

Drupal.org provides an amazingly flexible issue queue and is the backbone of most community activity around code, community, policies, drupal.org itself and so on. Each issue has a priority value which can be one of Critical, Major, Normal and Minor. Even more interesting is the tagging system we use with some commonly used tags like 'beta blocker' or 'beta target' or 'revisit before release' which add extra priority on top of the single value field. The drupal.org issues however don't lend themselves to supporting working on your priorities. Here are some options and tools I used so far that help solve this issue.

Strategic tagging

Some people have their own tags, but this is very limited. You likely would not get away with using your own tag like Favorite-of-Dries. Instead people use tag combinations to express priority on other scales (eg. time vs. severity). I've first seen Jacine Luisi (HTML 5 initive lead at the time) using the 'sprint' tag in combination with other tags to express priority in time. Issues tagged 'sprint' would be reviewed on meetings. This is good for expressing priority of a team.

Following issues and the dashboard

However, if you are not working as part of an integral team working in sprints and maybe just want to keep tabs on issues important for your projects, this will not work. Enter the Follow button. On each issue (when logged in) you can find a follow button to follow updates on those issues. All the issues you follow show up on the Your issues dashboard block. Access the dashboard using the big blue Your Dashboard tab from the header. Several people use this to keep tabs on issues they are interested in.

The first problem with this approach is this does not allow segmentation of the issues (eg. ones you work on vs. ones you follow out of interest). A much bigger problem is that the Your issues block/view in fact reflects priorities of others. Issues that people work on will show up higher in the list pushing others down.

Externalizing issues #1: email

So how to reflect your own priorities then? Well, drupal.org has a very easy way for you to get emails about all the updates on issues. This is super-useful even if it sounds very old-school. Who wants issue updates pushed to them? Well, several people in the core development community. Why? This easily creates copies of issue data in your own system that you can then use to tag, prioritize and follow up on as you see fit without issues scrolling by in the Your issues view.

To get email updates, go to your profile and in editing, hit the Notifications tab. This will let you subscribe to issues per project (and even have a global default). Then you can use your own email system's ways to tag issues and prioritise them. You don't even need to make them show up in your inbox. Cathy Theys (@YesCT) says she likes this solution because it lets her search in issues she cares about locally, which is blazing fast. Lee Rowlands (@larowlan) manages his daily issue contribution with tagged emails. I like it because I can keep issues I care about tagged and reply on my own schedule while I can ignore issue updates I merely follow on the side. Here is how autotagged emails look in my inbox:

I set up filters for tags showing up in the tag list in the email, for example contents matching "Configuration system [", "Entity Field API [", etc. get their respective cmi and entity tags. The drupal.org tags show up suffixed with a number in brackets (therefore the opening bracket in the filter). These filters are not 100% accurate but they almost never failed for me.

Externalizing issues #2: Google docs (temporarily not applicable)

Email is good if you need your personal priorities reflected. However if you need to coordinate a team working on a project and contribute to drupal.org at the same time, sharing an email account sounds stone-age. And it is. Roger López (@zroger) originally created this quick little Google sheet script that used to pull JSON issue data from drupal.org into Google Spreadsheets:

(This script can be added to a Google Sheet in Tools > Script editor...). At Acquia we used to use this script a lot for reflecting priority of the team when the priority of the team did not necessarily blend with global priorities. A bug may be minor for a module, if the success of your project depends on it, it will be critical for you. It was very easy to use this to build a sheet with all kinds of additional information on issues. Just enter the issue numbers verbatim in cells A2, 3, 4, 5, etc. (assuming the first row is used for a header) and use the drupal_org_issue_property() function provided to fill in dynamic values in other cells. Such as fill in B2 with =drupal_org_issue_property($A2, "title"), C3 with =drupal_org_issue_property($A4, "status"), etc. Add any cells that reflect local information to your team, such as your internal priority for your convenience. Of course you should always, always post updates on the issue each time you have something useful to say and not use this internal copy as an opportunity to fork the issue. That would be against your best interests.

Unfortunately this method cannot be used right now. The issue JSON output went away with the Drupal 7 upgrade of drupal.org quite a while back. So there is no way to programatically request issue metainformation now. Deploy RestWS for D7 project issue JSON is an issue to get this feature back. As soon as that is fixed, you will be able to use this technique (adjusted for the format of the JSON at the time).

Externalizing issues #3: Rocketship

While I am happy with the email solution for my own priorities, I also built a tool to help the multilingual team manage our priorities and to communicate them to the wide world. That is why I built Rocketship, a tool to pull in issues from drupal.org to a site and create custom issue boards out of them. This tool builds on the structured tagging concept for teams (although by treating status, priority, etc. as tags it expands the boundaries a bit). Several people see the main benefit of Rocketship as a Kanban-like board builder that is a better visualization of issues tagged in certain ways. On top of that I see it as a great way to augment issues with external information and put them into context. For example Multilingual novice issues are augmented with information on where and how to get help. The base language services page explains the overall plan in Drupal 8 for that area.

What's even better is that overall we are putting the issues in context with all the rest of the information of the initiative. The whole site that has the Rocketship generated boards serves as an overview for visitors on what we do (video and text summary), who we are (a friendly and welcoming team ideal for Drupal 8 first-timers to work with) as well as where and when we meet. In summary this allows us to put issues in context, reflect our own priorities and augment with information most relevant for the initiative. Basically the same as the Google sheet or the email solution but this is for the wider world.

Your solution

The common element in these solutions is externalizing issues in another system so you can maintain/list issues with your priority in mind. It is not very likely that drupal.org will get personal / shared team tags anytime soon so these tools will have great use for quite a while. Again, I'd like to point out that all updates should be posted on the issues themselves, it would be against your best interest to not maintain the best information as applicable to drupal.org so you can work with other interested parties in the community best. What methods are you using to reflect personal / team priorities which cannot be represented on drupal.org?