Work culture – Page 9 – Learning (Lib)Tech

Implemeting an Issue Tracker (Redmine)

For more than half a year now, I’ve been trying to get an issue tracker fully implemented for our IT team within the library. I admit that I’m still working on it. Getting the system up and running was easy enough, but trying to work it into people’s workflow isn’t so easy.

Choosing the Issue Tracker

There are a lot of issue trackers out there, but we are a small team and I wanted the issue tracker running easily and quickly. It’s not something I wanted to spend a lot of time getting up and running, because we had a lot of other projects happening.

Other requirements included:

support multiple projects
non-members being able to report issues
support email issue management (either built-in or plugin)
low to no cost

preferable

support CAS or LDAP login (either built-in or plugin)
documentation area and/or wiki
code repository integration
open source

I asked around a little bit, and these were the recommendations I got:

Asana: 2
FogBugz: 1 Against: 1
Footprints: – Against: 1
Github: 2
JIRA: – Against: 2
Pivotal Tracker: – Against: 1
Redmine: 5
Request Tracker: 1 Against: 1
SupportPress (for WordPress): 1
Trac: 3 Against: 1

Trac and Redmine seemed to be the two forerunners. My problem with Trac was that it didn’t have clear project organization, and no one could confirm that the email issue management plugin worked.

Installation & Setup

Our system administrator took a couple of (not full) days to get it installed and going, and following the instructions were apparently fairly easy. Then it took me maybe half a day to set up all the projects and users with the settings I wanted. The e-mail creation also worked well out of the box. We just had to make sure we had the right settings for what we wanted.

Staff Issue Creation & Management

In order to make it so that staff can file issues without ever having to see Redmine, I created a form in our Intranet (webform module in Drupal). The form had most of the standard fields:

Name: automatically filled in with username
E-mail: also automatically filled in
Related to: options which were essentially the project names
Need: options equivalent to tracker e.g. Support, Bug Fix, etc.
Priority: options equivalent to priority
Summary: email subject line, which then turns into issue name
Description: issue details

Once it’s submitted, a copy is sent to our team’s email. Through a cron job (every 5 minutes or so), the email is picked up, and filed.

If the user already exists in the system, Redmine will use the email from the user account to match it to the user, they will automatically become the ‘reporter’ of the issue, and get a copy.

If the user does not exist in the system, Redmine will say that ‘Anonymous’ reported it. This will always happen the first time someone reports an issue as I did not add everyone on staff to the system. So, the first time this happens, I then add the user to the system, and add them as a watcher to the issue.

The one issue I ran into was that I forgot you have to set both the email plugin and each project to accept issues from anonymous users. Simple carelessness really.

Getting Staff to Change their Workflow

I think the hardest part with implementing any issue tracker is getting staff to use it. Within the team, it hasn’t been too difficult. We have a small team and the developers in particular have no problems using it. The only problem I sometimes have is making sure they close issues when they’re done with them.

But even within the team, sometimes it can be difficult to get people to report issues using Redmine. While our manager wanted us to start using it just for the website, it has worked well enough, so we’re strategizing how to get the rest of the staff using it now.

We’ve concluded that it kind of needs to be an all or nothing. So we’ve decided that all non-urgent issues should be done through the intranet form regardless of the project, and that should people email us, we’re going to be emailing them back to submit it through the form.

For any urgent issues and for immediate support, they can still call us. After all, trying to walk someone through editing something on our website or intranet is much easier by phone anyway.

Before we start enforcing it, we’ll be introducing this workflow to staff through various committee meetings in part to gather feedback.

So… we’ll see how it goes.

MozFest 2012: How to Work Open

by Matt Thompson (absent), so actually Gunner

Processes & Tools

The process and tools, and how things are done should be open. Etherpad – like a google doc. Collaborative, and in Mozilla, tied to conference calls.

Give guidelines, not direction.

Open Philosophy

Some are a little open, but to be truly open, everything is open not just the nice looking bits. For example, the Firefox mailing list is open. The discussion on Chrome “kicking their butts” was a public discussion.

Need to pro-actively report out, especially for offline conversations.

Community

If you’re going to work in the open, it’s about the community. Have to ready to share: ownership, control, everything.

How to contribute from day one. Make a wishlist (e.g. documentation, testing – never done). Ask for things to be added to the wishlist.

Have core community values.

Motivations

Pain
Passion
Fame
Fun

Having a Narrative

Naming the contributors, and having an ongoing story.

Give other voices a channel. Invite others into the narrative. e.g. put someone else’s story into your blog.

Governance Model

Still have to have governance though. Study other successful projects, e.g. wikipedia. Key is a benevolent dictatorship with radical openness.

Risk

Risk aversion and fear is failure before even beginning.

Study the licenses and pro-actively license your content. e.g. GPL, Mozilla

Disagreements

Leading with questions to ask one-on-one why they

E-mail and IRC suck.

Best practice is to move to audio/video if the e-mail and IRC is not working.

Setting frame for discussion. Turn it from “Do you want a vitamin?” to “Do you want the orange or purple vitamin?” Another example would be to share only benefits of two choices.

Open Corporations

Use open paradigm. For example, Twitter uses volunteers to localize, so even though it doesn’t use an open platform, it uses an open model.

But propriety, locked down systems are in the process of dying. There are companies that are open software corporations e.g. Firefox, Redhat. What really makes you special is customization, service, etc.

Start internally. It doesn’t need to be open externally. It can open within the organization first.

Learn from Others

Study the successful open companies and organizations.

Model

Model for success, status quo and failure as a win, because you have learned what not to do again.

Think ahead and think aloud.

Going Google at Ryerson University: Sync’ing Work Back to Usual

I have found some things on the Going Google site a little incomplete, so I thought I’d supplement it with a blog post.

Set up your Google Token

This is really easy. Just sign into the Apps tab, click on Activate Google Token, and hit Activate. One important note,

you will not be able to see your Google Token again after activating it the first time (and you close the window).

So, write it down in a secure place in case you ever want to sync your accounts with anything else.

Sync Apple Devices

So which method you choose depends on what you want to sync. Both will sync mail and calendar, but for:

Notes use Gmail option
Contacts use Exchange option (follow the instructions on the Going Google site)

I personally only read and reply to emails on mobile devices, so I chose the Gmail option so that I could sync Notes. Google provides instructions on using this method (it’s essentially the same process), and here are the details you need:

Name: your name
Address: full email address
Password: Google Token
Description: account display name on your device

Multiple Calendars

To sync multiple calendars, you can still do that using the Gmail option, but to change which calendars you want sync’ed:

sign into your Gmail account using a browser
then visit Google Sync for Apple to choose which calendars you want sync’ed

Getting Calendar in Thunderbird

UPDATE: If you’re having issues, it provides less integration into Thunderbird, but try ‘Google Calendar Tab’ which opens GCal like it would in a browser minus Settings/Labs.

I warn you now. Google Calendar in Thunderbird still has a number of issues. If you’re on a MAC, I suggest using Google Calendar in iCal instead. I prefer having everything in one client, so I’m willing to live with and report bugs when necessary, but who knows, I may change my mind.

Step 1: Install Lightning

The Lightning add-on page actually gives the newest stable version of the add-on (for Thunderbird 16), but the newest official release of Thunderbird is 15, so head over to the Versions list and find Lightning 1.7. Install it according to the instructions (using the Install Add-on from File option in the Add-ons settings).

Step 2: Install Provider for Google Calendar Add-on

This step is actually optional depending on what method you want to use. Google Calendar now supports using CalDAV in Thunderbird, but it’s marked as experimental.

Just search for Google Calendar in the Add-ons tab and install from there.

Step 3: Add your Calendar

If you chose to install the Provider for GCal add-on:

Open your Google Calendar
Click on the Settings link located in the box at the right of the page.
Click on the calendar you want to use with Thunderbird Lightning or Sunbird.
Copy the link from either of the two XML buttons shown at the bottom.
In Thunderbird: File > New > Calendar > On the Network > Google Calendar
For Location, paste the link, but change http:// to https://

For more information, visit the Provider wiki page.

If you chose not to install the add-on, follow the instructions from Google.

Testing Needed

So, I’m going to be using Thunderbird, and hopefully it’ll work out, but there are one or two things I wish it had already (like popup reminders for events others created). It is supposed to work better than through CalDAV. I’ve heard iCal has pretty good integration though so I might still switch to that if I’m unhappy with GCal in Thunderbird.

Getting Staff on Board and Using a CMS: Moving to WordPress

The hardest part of moving any website is getting staff trained and changing their workflow to actually use the CMS. We previously had a static HTML type site, so everyone would email changes to one or two people. It was a big shift to suddenly have people take care of their own content.

As part of the training session, I briefly reviewed why we moved the website to a CMS and more importantly, how it benefits our patrons. It covered the usual, shifting resources and staff time, less maintenance, keeping content current, etc.

Tutorials

I found the best WordPress tutorials for staff were the WordPress.com support articles related to creating content. The only differences come from the plugins that are installed, but in our case, this only affects the “Upload/Insert” section above the editing area.

We also have access to lynda.com video tutorials, so I suggested the relevant sections (5 + 6) of the WordPress Essential Training.

I also wrote up a short blurb on how to check for broken links in a more visual way (and for our non-WordPress pages). I basically referred them to install and use LinkChecker (a Firefox plugin).

Content Guidelines

In addition to training staff on the actual CMS, I wrote two sets of guidelines for them to follow.

General Guidelines on ‘Writing for the Web’
Using WordPress to Make Content Accessible (to come in a future post)

To make it easy for staff to use, I wrote it as a page on the intranet (with anchor links for a short table of contents), and also made a PDF version for them to easily print it off.

Making Staff Responsible

I think the most important step in shifting web content management from a single team to the entire staff is assigning responsibility. If no one “owns” a page, it will not be regularly reviewed. If you assign ownership, at least it increases the chance of that happening. Here are the short blurb I wrote on staff’s responsibility of content:

Page Ownership Responsibilities

While you may delegate the task of creating or updating content on any page you own, you are ultimately responsible for it. This includes:

Content is up to date

Content, especially audio/visual, conform to Accessibility Guidelines

Copyright is cleared for all content (if applicable)

Transferring ownership when needed (long term leave, end of term)

Please Note: When links are found to be broken, you will automatically be notified via e-mail. However this is not a full-proof system as many broken links will not be “marked” broken. See the ‘How to Check for Broken Links’ page for more information.

Assigning Ownership

We explicitly mention that editing of pages can be delegated, because we decided that librarians would be responsible for pages. We identified and changed each page’s author to the librarian who would become the owner.

We still have about a dozen pages outstanding in which our team maintains as needed, but we also expect that staff may edit it if they find mistakes.

The Result

So far, it’s been fairly successful (yay!). While I get calls on occasion for help, staff seem to be finding it easier to use than Drupal (which we have for our intranet), and most seem to have no problems using it.

Content on a lot of pages are being updated, though as always, it really depends on the owner. One of the problems is that we migrated the existing pages, and there’s a lot of overlap in information, which we really need to consolidate. So, making the website better as a whole will take a bit more time, but at least content is now being updated on a more regular basis.

Guidelines on Writing for the Web

So as part of the website redesign and working on making the site WCAG compliant, I wrote a couple sets of guidelines. One of them was on writing content for the web. Some of the points and the example I got from a coworkers, but most of it I just consider sensible advice. Overall, I tried to keep it fairly short and simple in the hopes that staff members will actually read it!

Writing for the Web

Web readers skim pages and look for keywords, links, and other information that will help them find what they’re looking for quickly. Therefore, when writing new or revising content:

1. Be Clear and Concise

Make your page title descriptive and concise, keeping it fairly short.
Keep sentences, paragraphs, lists, and other information short and simple.
Use lists wherever appropriate, especially when users have choices. Use numbered lists for complex instructions and include important screenshots.
Unless you’re creating a policy page, keep the entire page short (e.g. 2-3 screens worth).

Bad Example:
To find information on citation styles, go to the Library’s Home Page, click on Research Help, then click on Citations and Style Guides and choose APA Style Page, MLA Style page or RefWorks.

Better Example:
For more information about citation styles, check the

APA Style Page
MLA Style Page or
RefWorks

2. Speak to Your Audience

Avoid acronyms and “library” vocabulary when writing content for the library’s webpages.
Write at a Grade 7-8 level in a direct voice, using “you”. For example, use “get” not “obtain”.
Because users scan pages and don’t read them, information needs to be written clearly and concisely and at a reading level that doesn’t impede typical user behaviour.

3. Be Meaningful

Links, in particular, should be meaningful. The words of a link should tell your reader what the link is about.
Screen readers have the option of listing all of the links on a page, so think about whether a user would know what your links refer to out of context.
In addition, don’t overuse links. Only use them where it makes sense, such as for a list of resources.