Redmine best practices [closed]

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.

Solution 1:

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, depending on which 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. 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?)

Solution 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.

Solution 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!

Solution 4:

We use Redmine extensively on our system. We have even set up a "Sales" project for our sales team to use as a CRM. We have a heap of custom fields in this project, and it replaces SugarCRM which we were using before.

Within our system, we have projects for Server and Client software. Server project is broken up into submodules, based on how I have structured the system and sub-repositories, since Redmine likes a seperate repo per project.

We use, as others note, #nnn codes in commit messages to reference tickets. What is cool is that it needn't be a ticket in the same project. Thus, a sales ticket can be blocked by a bug issue, or a support request.

We have just started using Documents for agenda/minutes of meetings. We use Versions to group into releases, on both client and server.

To try to use Redmine Time Tracker plugin to track time, but I always forget to click start or end. We get daily emails about issues that haven't been touched in a while (Redmine Whining, I think), and that have due dates in the past or near future (Advanced Reminder).

Support emails go directly into our Support project, and if the email importing was a bit more robust (sometimes it doesn't create new tickets properly if the Project: line is included in the email), we would have website inquiries automatically generate Sales tickets. As it is, we just have to monitor Support tickets, and move them to Sales if applicable.

Things I would like to be able to do:

• Have relationships between our system and redmine, so that tickets can be associated with a user or company in our system. Also, so that we can generate a new company from a Sales ticket at the relevant point. This just requires me to do some work.
• Have a relationship between our error tracking software (sentry) and redmine, so that server errors generate a redmine ticket. Again, solvable with current technology.
• Have a desktop client to redmine. The server is within our LAN, but being able to have a more flexible way to access the data other than the web page would be great. It's not that there is anything I can't really do in the redmine web interface, but something like Things.app is so much nicer to work in.
• Have our support documentation all within redmine, and then generated out onto a public-facing server. That way, our support staff can maintain the documentation, edit in a nice way, and deploy changes out to doc-server.