Mathnet currently uses Perfect Tracker to manage trouble tickets, and there is no formal project management or planning software. Perfect Tracker is unsatisfactory in several ways and has not been updated since 199x, and is slowly collapsing under its own weight. We intend to improve this situation.
We want to track trouble tickets. This includes these sub-goals and issues:
We want users to create tickets using a web form.
We want users to create tickets by sending mail to an alias. They're trained now to send to bugs, and likely we will not change this, but many messages to bugs are not supposed to generate tickets.
We want MCG members to create tickets on behalf of users who mail in trouble reports to the bugs alias. One possibility is for the bugs manager to forward the message, possibly with initial comments, to a different alias.
Do we want users to be able to view only their own tickets? Or are tickets public record? Of course MCG members should have access to all tickets.
Jimc at least has never figured out how to get Perfect Tracker to show a list of tickets assigned to jimc. We hope for such a luxury feature in the new software.
In back-and-forth mail with the user, there's a tendency for the entire conversation to be reiterated backwards (top posting) in each message, leading to excessive repeated verbiage obscuring the record. Automated filtering would be appreciated.
We want some automation and transparency in project planning. These are the subgoals and issues:
We want both worker bees and the manager to be able to see what projects we are working on and what progress (if any) is being made.
Elaborate cost tracking and reporting is overkill in our context.
We need to decide issues of write access, i.e. who is authoritative for what.
We probably don't want general users to have read access to the project pages, but it would be a good idea to show publicly a page of project summaries. Keeping it up to date is always a problem; automation would be welcome.
We have a knowledge base
which is a little like a wiki but
is less flexible. If Perfect Tracker goes away then the knowledge base
has to move elsewhere, preferably to a real wiki.
Additional issues for this project:
MCG members will use this software frequently, and facile authentication is important; a loginID and password on every access (as with Perfect Tracker) is going to be a royal pain. With some choices it will be necessary for ordinary users to authenticate; other scenarios only require authentication from MCG members.
Primary authentication can be done using SASL, LDAP, Kerberos, or X.509 certificates. We would really like to avoid managing a separate identity in the software, even just for MCG members, as we have to do with Perfect Tracker. If the software supports SASL or LDAP, we can deploy them right now.
The infrastructure for Kerberos and X.509 authentication is in place, but only a few users have credentials on file. These would be most useful for authenticating MCG members.
Shibboleth and OpenID are other possibilities, but this will be the first time we've really relied on them for anything except Moodle.
While it is generally bad practice to pick the software before
laying out the goals and issues of the project, Nick has extensive
experience with Jira (and with the goals and issues) from his previous
job, and it's a foregone conclusion that Jira is what we're going to
use. Jimc and Linda have no choices to offer beyond something
better than Perfect Tracker from 199x
.
However, the possibility exists of upgrading Perfect Tracker to a recent version. As jimc understands it, Nick is not enthusiastic about this possibility.
Jira is a proprietary product of Atlassian.com. This is a company with offices in Sydney, San Francisco and Amsterdam, about 400 FTE. The price is nonlinear in the number of users: 10 users = $10/mo, 15 users = $50/mo, 2000 users = $1000/mo. There is a free license for educational institutions, and we believe we qualify for it. Product root page is here.
What JIRA can do:
Brilliantly simple to use. Configurable web interface.
Track issues, tasks, features, bugs; define custom issue types.
Workflow management (customizable) with visual designer.
Put the ticket number in a commit message; this links the source code to the ticket. Includes a source code browse CGI.
Search everything using "Jira Query Language" (Apache's Lucene).
Kick-start user (MCG) adoption with their library of tutorials.
Notification of events by RSS, e-mail, (etc?)
Supported Platforms, Java: Oracle (Sun) JDK/JRE 1.6 u24+ (we have u29). Not 1.7 yet. Watch out, the installer may try to install its own JDK.
Supported Operating Systems: Windows, Linux, Solaris
Apache Tomcat 6.0.32 (not lower) (we have this) or 5.5.{27..29}. Standalone version has its own preconfigured Tomcat. They recommend that you at least start out with the standalone version. JIRA WAR is for an existing application server (Tomcat + JRE).
Selection of database:
Browsers: MSIE 7.0, 8.0, 9.0; Firefox; Safari; Chrome. Needs 1024x768 screen to fit. Requires Javascript.
Hardware officially supported: x86 (i586) or x86_64.
Needs its own special user.
Strongly recommended to have a separate Tomcat container for Jira.
Pre-create an account for <jira> and apparently a separate one for jira-tomcat (let's change to jiracat). No, that's for JIRA WAR.
Download and execute the standalone installer.
It will want to know:
Then run the JIRA Configuration Tool.
You need to tell it what database you want and the relevant parms. For MS SQL Server 2008 (PostgreSQL is essentially the same): Hostname, port, database (jiradb), user (jiradbuser), passwd, schema, connection pool size (15)
Set up the homedir so it gets backed up.
We back up our databases by dumping them, i.e. SQL statements that would rebuild the database if replayed. (And compression and in some cases encryption.) Restoring the database from such a dump has actually been done a few times. Make sure the dump is happening and is getting onto the backup media.
Log rotation: Find where it's putting logs and either provide our own /etc/logrotate.d/jira or hack theirs to fit with our parameters.
We'll run Jira on Arachne but using its standalone configuration, not integrated with Apache. At least at first. However, if we want to get access from off site, using port 443 is really helpful because the firewall is open. An Apache proxy is relatively easy to set up, passing traffic to Tomcat's HTTP port. Update: Jira's port was opened to the outside.
Database: Defer to Linda on this, but Arachne has PostgreSQL already. Not exactly sure if we have the required JTS 1.2.4 driver for MS SQL. Update: We're using PostgreSQL.
We will provide the Jira special user in advance, in /etc/passwd.
We will rely on Nick to configure workflow, custom issue types, etc. etc.
Migrating from Perfect Tracker to Jira: giggle, giggle. Update: The adopted solution was to just junk all the Perfect Tracker information: not useful enough to save, too hard to bring over.
For our knowledge base and public help pages we still need a wiki. The JIRA product page says: "Powered by Atlassian Confluence 4.1.3, the Enterprise Wiki". I would be happier with an open-source wiki.
Now that we have been using Jira for a month, we are starting to recognize some problems.
It's turned out to be somewhat unnatural to use Jira for two purposes: project management and trouble tickets. It's working, but the need to support both functions makes it not quite smooth.
There is a specific minor requirement: Suppose a user sends mail
to the trouble ticket alias (helpdesk) with additional recipients on
the To
and CC
headers. Jira 4.x tosses the additional
recipients. Jira 5.x (and some competing software) marks the other
recipients as watching
the ticket, i.e. they receive copies of
the e-mail traffic. However, for this to work they have to be enrolled
in Jira, which would put us over our license limit. This issue is not
a showstopper, but is annoying.
Jira's prices have gone up. To cover the whole department we would need about $4000 per year, which we don't have.
Therefore we are looking at two issues: using a different, more informal paradigm for trouble tickets, like we did before Jira, based on manual e-mail, and open source project management.
Wikipedia article about project management software. To summarize:
Project management has two major aspects: scheduling (e.g. which subtasks are on the critical path, or estimate when the project may be finished); and static information such as:
The software can be implemented with various design choices:
The article gives a number of generic criticisms of project management software:
project managementpoorly describes ongoing activities, such as sales, which even so need to be managed.
Wikipedia article comparing project management software.
146 packages are listed. Of these, I filtered on open source, web based,
locally hosted (vs. cloud service on vendor's servers), and excluding
community editions
. And it has to be collaborative (vs. single user).
This leaves 20 packages, with Jira included for comparison.
Of these, many are mainly for document management or are otherwise obviously
unsuitable for us (12 packages). Of the remainder, some are mainly issue
trackers, some are for real
project management, and some are combined
like Jira is. The features reported in the Wikipedia article were:
Issue tracking; Scheduling; Project portfolio management; Resources; Document Management; Workflow system; Reporting and analysis.Here's a summary of the 8 survivors (and Jira). They are ordered according to jimc's judgment of how worthwhile they seem for further investigation. The last two items are much stronger in issue tracking than
realproject management, and we could consider them for that purpose.
Proprietary (it's what we have now). Actively developed. In Java. Includes integrated issue tracking and project management with workflow. No resource management or document management. Reporting, such as it is, is sufficient for our purposes. I think it has scheduling modules but scheduling is not very important for us. The problem we're having with it is licensing and expense.
Actively developed. In Java. Uses any
database. No OS
or browser limitations. Intended for software project management,
issue tracking, and managing software testing. Has an integrated wiki.
No workflow module. It does reports but not extensively. Weak on
scheduling. This one is worth a closer look.
Actively maintained and funded by the Galician Coast Guard (naval auxiliary). In Java. Cross platform. Specifically for project management with scheduling and resource allocation. Progress and resource utilization monitoring and reporting. Jimc feels that it is too focused on resources and scheduling.
Actively maintained. In Python. Cross platform. Licensing: AGPL and proprietary (openerp.com). Mainly for business: sales management, warehouse management, point of sale, human resource management, project management. It has modules for all the listed activities. Jimc feels that it is too focused on scheduling and sales-type activities.
Actively developed. In PHP. No OS or browser limits. Its main function is PIM, i.e. contacts, calendar, projects and to-do lists. Can be used from the web interface or on 3rd party generic PIM clients via SyncML. No scheduling, workflow or reporting. I think this is related to Horde.
Part of the DotGNU project, in PHP, has about 50 various modules
including a Calendar, Addressbook, an advanced Projects manager,
Todo List, Email, and File manager
. In other words, it's a PIM suite.
No scheduling, workflow or reporting. This sounds a lot like Horde.
Actively developed. In Java. Cross platform. Hard to understand what it really does, but all entities are indexed by Apache's Lucene. Allegedly it does all titled features except workflow.
Actively developed. In Ruby on Rails. Cross platform, can use
a variety of databases. Significantly influenced
by Trac. Includes
issue tracking, simple time tracking, Gantt chart and calendar. Looks
like it is not that strong on real
project management, although
the Wikipedia comparison shows it with all features except
resources and reporting. We could consider it for issue tracking.
Actively maintained. In PHP. Cross platform. It is mainly for issue tracking, though they say it can be used for other things too. We could consider this one as our issue tracker.