Kreynen asked me to organize some notes on how MNN is using Mantis (Free Software/Open Source issue tracking tool) to sort/tag issues from their internal CM-drupal based projects that should be posted publicly on issue queues at drupal.org -- as well as step by step instructions for how to set this up in mantis.
The human process is simple, if an issue is about a module that is part of the starter kit and not specific to MNN, the Community Manager (staff member at MNN that is responsible for managing MNN's interaction with the larger CM community) will update the issue and set the "Post to Drupa.org" field to 'yes.' Either that person or someone at Openflows (or another contractor working with/for MNN) will then post that issue to drupal.org and update the issue with the url of the post on Drupal.org. When issues are updated internally or even fixed, those fixes and/or information related will be posted to the d.o page and possibly info from d.o will be pasted in as comments in mantis for future reference.
The custom field for 'post to Drupal.org' allows for all issues to be searched based on that field, the issue queue filtered by that field, and a custom rss feed is generated only for issues that have their post to Drupal.org field set to yes.
Here's the step by step for making this happen in mantis 1.1.8
Step 1: log in and click 'Manage'
if you don't have a 'manage' link you need a higher level of access to mantis
Step 2: click 'manage custom fields'
Step 3: Creating the custom fields
Click on 'manage
Make a new custom field called 'Post on Drupal.org'
set that field to be a list with options of yes and no with default set to no, and set the field so it shows up on submit, edit, update and close
Make a new custom field called 'Drupal.org issue url'
set that field to be a string, with the same display options as the other field we just created
Step 4: add our custom fields to our project
Click 'manage projects' and then click the title of the project that we want to add these fields to
Scroll down and find the 'Custom fields' section of the manage interface and then select the fields to be added.
You should now see our fields listed.
if you want, you can add in sequence values so your custom fields show up in the order you want. In this case, I wanted our existing custom field of issue type to be first, followed by the yes/no field and the url
After this step you can verify that the new fields are showing in the view and edit/submit forms for an issue.
Step 5: Create a stored filter for issues marked "post to drupal.org"
Go to the View Issues page and make sure your filter list is set to show (the + or - in the lower left)
Then select 'yes' under 'post to drupal.org' and click 'apply filter'
Then click 'save current filter'
Then give that saved filter a name
Step 6: you can either just log into mantis and use the filter from the 'use filter' saved filter list or you can watch the issues in this category via an rss reader. To find the rss feed url, click 'manage filters'
find the filter you want and either copy the url/link of the rss icon or click the icon to go to the feed.
DONE
While adding in these fields and filters to mantis (or whatever issue tracker you use) will help, nothing here is automatic -- it all requires attention and people to follow through and post things to drupal and keep the issue tracker up to date. It's more effort but worth it for the health of the CM Drupal collaboration as a whole. Happy bug-squashing.
Comments
So.....are you suggesting....
We try this out? I see Mantishub - which would be one major tracker to rule us all, or do we each just go our own way with a single instance of Mantis?
I'd be glad to do something new with bug reporting.
Thanks Eric.
mainly this was for Portland which has started using mantis
Kreynen was eager for me to get this posted since Portland Community Media is now using mantis as well and it made sense to share MNN's configuration with them.
From my perspective, I feel strongly that organizations should control the key parts of their infrastructure and SAAS options like mantishub (or github or pantheon for that matter) while convenient create a potential single point of failure where one network/company/site going down impacts far too many people. I could be persuaded that in this case that's not a big worry but I feel the need to raise that issue.
I think the 'one tracker to rule all' needs to remain drupal.org, but it's not reasonable for all of us to track our own issues there, only those that are shared in common and directly related to the shared code and modules.
If you are interested, mantis is available as an installable package on Debian, ubuntu and likely other distros as well (apt-get install mantis) so it's a really simple thing to get up and running if there's a server available. It's also a very simple install if you want to download the latest version and do it manually.
Different orgs have different choices for issue trackers, from Openflows perspective, we've found that the simplicity of mantis's interface has made it quickly adopted by our clients' staff, the multi project functionality makes it easy to section off subsets of tasks, and it forcing people to log in and not reply via email tends to keep the discussion clean and focused.
No matter what issue tracker a group goes with, I hope they would all adopt a similar process of sorting out issues and making sure that bugs they are working on that are of interest to the entire community get posted as soon as possible publicly on d.o issue queues. If my post has a primary goal, it's to start that discussion.
Rounding out a bug tracker
Could you just dive a bit deeper into the server question? Does there need to be a server running somewhere that runs Mantis?
The 'one tracker to rule them all' comment was also meant to encourage medium sized orgs to be transparent with their issues. Chances are we all have been in a position where we could help someone out had we known. Of course, as you said, there needs to be humans using this to make it work.
We had a discussion a few months back about just a plain old email list for the cm_drupal community. Not every question is right for GDO. However, ultimately, I settled on Google Groups because I wasn't in a position to set up a server to do this. I wonder though, small incremental changes like Mantis or an email list can help to solidify some structure to this effort.
Mantis "Appliances" or VMs
Mantis has been around long enough that there are Virtual Machines images or "appliances" available. These images allow you to run a single purpose linux distribution (for hosting Mantis) on another operating system.
see:
http://www.turnkeylinux.org/mantis
or
https://bitnami.com/stack/mantis/virtual-machine
for more info
Thanks @ericG!While Mantis
Thanks @ericG!
While Mantis is a great FOSS solution for issue tracking, there are several other free and open options including Trac and the Drupal based OpenAtrium distribution. There are also commercial solutions including Unfuddled, ZenDesk, BaseCamp, Jira and GitHub. The point isn't to find the best issue tracker and get every organization involved to use it.
Mantis is great for organizations who want to manage their own issue tracking server, but there is no one-solution-fits-all. As long as the code is hosted on Drupal.org, the module, theme, and distribution queues on Drupal.org will continue to be the main public issue queues.
Getting every organization using the same issue tracking system shouldn't be a goal for this project. There is just way too much internal, organization specific history to many issues staff post. Getting all issues posted publicly on Drupal.org isn't my goal either.
My goal is some balance between an organization's needs and the larger project's needs.
Every issue tracking system I've used has a way to configure the type of workflow MNN is now using. We already have the Post to Drupal.org option on all our Unfuddled project. It's this type of configuration that allows organization specific issues to be handled consistently while still getting issues that could be impacting other organizations shared publicly.
The problem with only answering questions within private issue queues is the answer remains private. Any vendor who requires station staff to use private issue tracker without posting to Drupal.org or CiviCRM.org is contributing to the tragedy of the commons effect. In this case, the commons being an open database of problems and solutions that anyone can search. It's a fallacy that because you've always been able to use Google to find the answer to so many technical questions, you will always be able to do that.
You can do that today because so many people ask and answer questions publicly in the past.
As more knowledge gets locked up in private issue trackers, the commons stops working. Getting staff from community media groups to post issues publicly on Drupal.org has been difficult, but I think we've reached a critical mass of people that "get it" now. There are a lot of reasons people might prefer talking about a problem w/ smaller groups on Skype or a private email list, but project suffers when that problem/confusion isn't converted to public documentation. Posting issues publicly isn't the same as writing documentation, but it happens automatically. The next time someone asks me (or Google) about customizing event titles in CiviCRM Multiday Event, they should find the answer.
I use IRC, but I know Twitter can serve the same purpose. I'm not going to try to stop people from using new channels to ask questions, but I will try to convert them into using Drupal.org for posting answers in a way that contributes to the commons we've all benefited from.