Redmine best practices

Question

What tips and "standards" do you use in your Redmine project management process?

Do you have a standard wiki insert template you could share or a standard way to work a project using bugs features tasks and support issues?

Do you let issues and updates get emailed into Redmine? Do you use the forums? Do you use SVN repository? Do you use Mylyn in eclipse to work the task lists?

I'm trying to drag our dept. into some web based PM instead of emailed Word docs of vague requirements followed by Word docs explaining how to QA and Deploy that all get lost in a pile of competing updates and projects so that by the time I have to fix something, no one can find any documentation on how it works.

Answer 1

We are using the Roadmap section as a clear way to display:

• bugs
• features (that would be references to your word document, or link to html requirement pages)
• reconciliations (differences between production values and test values)
• and so on...

That is the main point of consolidation for us. The rest is used in relation with that (for instance, the 'announce' section is used to define the main milestone/release dates used in the roadmap)

Answer 2

I'm a freelance Ruby and Redmine web developer who runs a development business of one (me). So my Redmine is setup to be pretty lightweight and customer focused. My Redmine also serves double duty for hosting my Open Source projects.

I do allow new issues and updates to be emailed and it works great for email connected users (or those who are always on their iPhones).

I've been using the repository view with git repositories and it's working great. With every checkin I reference the issue with #nnn so the actual issue page will show all the commits to implement the feature.

I found the forums are underused. I think if there was some email integration, they would be more useful.

Answer 3

We have found useful the following practices:

1) Hide "Issue" and "Support" tracker, and file everything as a bug:

• time-saver for developers, testers, management;
• if some activities are to be billed as "extra" or "new feature" or anything else, quick meetings are arranged to assess them.

2) milestones & versions I love this, you can easily track down the status of each release and at any time you can download an older package, i.e. to test a bug filed by client.

3) "save" function on "issues" tab: another big time-saver, I have different queries saved for many day-to-day reporting tasks and that's all I need.

4) versioning integration, i.e. using "#123" in comments creates a link to corresponding issue: simply clever!

Answer 4

In addition to the other comments I recommend the use of the "Stuff To Do"-Plugin (written by Eric Davis I think :) Using that plugin allows you to drag-and-drop sort the order of issues across multiple projects.

https://projects.littlestreamsoftware.com/projects/show/redmine-stuff-to-do

Answer 5

I develop and maintain internal applications for a family of manufacturing companies. As of the time of this comment, I'm the only developer/analyst on the IT team. During the worst of the recession my project demands exploded. As such my project AND issue backlog is quite unwieldy. We are currently in the process of restructuring to expand the team.

Here's how I use Redmine to keep my head straight (to the extent that is possible), my users at bay, and hopefully prevent too much hand-holding of new staff in the future.

• I use Subversion for source control, with TortoiseSVN and the aptly named Tortoise-Redmine plugin. Refreshing the Repository on the Redmine project after a commit links the issue, which shows the revision on the issue, and updates my stakeholders via email notification.
• I treat the project description as a means of communicating the project's purpose, scope, and lifecycle stage to those who are not involved. That way my users know what I've got on my plate, and what's still on the buffet that I'm eyeballing from a distance.
• I use specific role names for my permission sets that indicate more than a set of permissions -- again, as a means of documentation. My roles include the following: Project Manager, Project Team Member, Owner, Primary User, Secondary User, Observer, Overlord (for my bosses...both fun and undeniably correct).
• I use the Wiki and Documents for documentation, as I feel is appropriate.
• Versions are pretty much useless to me, so instead of using that for planned releases, I use it to group related issues into sprints.
• I use Eric Davis's fabulous Stuff-To-Do plugin to organize/re-organize the aforementioned sprints before mass-editing the Target Versions on my issues. This also lets my stakeholders know what I'm working on and how I've prioritized their interests (for better or worse).
• To encourage user interaction, I added links to the Redmine project into my applications' Help menus (see erichollering.com/Code/RedmineHelpMenu.gif - sorry, new poster). The "About" box also contains a link to the Redmine project.

Future Plans

• I hope at some point to finish my Visual Studio extension for Redmine integration.
• Build a code library to loosely couple my application with its Redmine project: automate bug submission, alert subscribing stakeholders from system tray, reusable interactive Help menu driven by Redmine's REST API, etc. (Maybe automate portions of documentation with the Wiki?)