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:
function drupal_org_issue_fetch(issue_number) {
if (issue_number == "") {
return "";
}
var response = UrlFetchApp.fetch("http://drupal.org/node/" + issue_number + "/project-issue/json");
if (response.getResponseCode() !== 200) {
return {};
}
return Utilities.jsonParse(response.getContentText());
}
function drupal_org_issue_property(issue_number, property) {
if (issue_number == "") {
return "";
}
if (typeof issue_number != "number") {
return("error: input must be a number");
}
var issue = drupal_org_issue_fetch(issue_number);
return issue[property] || "";
}(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?
Thanks for sharing!
Thanks for sharing!
I used to have a Trello board with different columns: to watch, for those that I had interest but couldn't actively work on; postponed, for those that are postponed but I had some interest; work, for those I'm actively working or where I could contribute; review, with those that I worked on and needs review, and also those that I want to help with reviews; RTBC, for rtbc'ed issues and Done, for tracking the rest of columns when they are committed.
In each card I had the title of the issue and in the body only the link to it. Status is marked by the column itself.
My biggest issue with this approach is that it requires too much in maintenance and manual sync.
I will try to complete my workflow with your experiences, thanks!
Diigo can help, too
Lots of great tips here, thanks for sharing! A few months ago, I blogged about how to Manage the Drupal core issue queue efficiently.
Turns out using Diigo helps greatly by adding some visually compelling highlighting and side notes.
Great post!
Further to your 'automated tag' system, I actually manually tag the issues - which is great until someone changes the issue title (gmail labels don't seem to survive subject changes). Some of my tags include 'priority', 'needs patch', 'patch failing', 'review', 'patch a day' and then I tag for the modules I maintain eg 'comment', 'forum' - that way in the sea of emails I get a day I can identify important ones by colour and read the rest in bulk at a later date (where I just want to track what is changing but don't intend/need to do anything). Also I have a filter to auto-move them out of my inbox into a Drupal.org folder. That way they don't interfere with work priorities and I can maintain zero inbox.
KanbanTool
Tried Trello for a while, but found it not flexible enough (mostly : the lack of horizontal swimlines)
Settled on Kanbantool for now, quite happy with it.
The flipside of either solution, of course, is the completely manual maintainance. But having some degree of manual control was the reason I moved away from Rocketship.
Kanbantool has a nice API though, so I guess with d.o providing rich json data and user custom tags, some level of automation could be attained - basically, a kanban-style version of the Gdoc spreadsheet solution mentioned in the post.