Redmine best practices

ChuckB_5281 0
Viewed 61590

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.

redmine project-management
11 Answers

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.

Eric_Davis_1830

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!

user_119880

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)

VonC_63090
user_408530
Related