Redmine Recommendations

Question

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

Do you have a standard wiki template insert template that you could provide, or a standard way to work with a project using bugs, tasks, and support problems?

Do you provide questions and updates via email at Redmine? Do you use forums? Do you use SVN repository? Are you using Mylyn in eclipse to work with task lists?

I'm trying to drag our department. in some PM PM webs, instead of sending Word documents with unspecified requirements by e-mail, followed by Word documents explaining how QA and Deploy are all lost in a bunch of competing updates and projects, so by the time I fix something , no one can find any documentation on how it works.

Answer 1

I am an independent Ruby and Redmine web developer who runs the development business of one (me). Thus, my Redmine is set up to be lightweight and customer-oriented. My Redmine also has a double duty to host my open source projects.

I allow new problems and updates to be posted, and it works great for email users (or those who are always on their iPhone).

I used the repository with git repositories and it works great. With each check, I refer to the C # nnn problem, so on the real page of the problem, all the commits for implementing this function will be shown.

I found the forums underutilized. I think that if there was integration with email, they would be more useful.

Answer 2

I develop and maintain internal applications for a family of manufacturing companies. Since this comment, I am the only developer / analyst in the IT team. During the worst recession, my project requirements exploded. As such, my project and releasing the backlog is rather cumbersome. We are currently expanding the team during the restructuring process.

This is how I use Redmine to keep my head up straight (as much as possible), my users are in fear and hopefully will prevent too many new hands in the future.

• I use Subversion for version control, with TortoiseSVN and the aptly named Tortoise-Redmine plugin . Updating the repository in a Redmine project after fixing binds the problem, which shows the version of the problem, and updates my interested parties via email notification.
• I consider the description of the project as a means of conveying the project goal, scope and stage of the life cycle to those who are not involved. Thus, my users know what is on my plate, and what else is on the sideboard, which I am viewing from afar.
• I use specific role names for my permission sets, which specify more than the permission set - again, as a documentation tool. My roles include the following: Project Manager, Project Team Member, owner, primary user, secondary user, observer, Overlord (for my bosses ... so much fun and undoubtedly right).
• I use Wiki and documentation documents, depending on what I think is appropriate.
• Versions are practically useless for me, so instead of using them for scheduled releases, I use it to group related issues into sprints.
• I use Eric Davis incredible Stuff-To-Do plugin to organize / reorganize the above sprints before mass editing target versions for my problems. It also allows my stakeholders to know what I'm working on and how I have prioritized their interests (for better or for worse).
• To stimulate user interaction, I added links to the Redmine project in the help menu of my applications. The "About" field also contains a link to the Redmine project.

Future plans

• I hope that at some point I will finish the Visual Studio extension for Redmine integration.
• Create a code library to freely link my application with his Redmine project: automate error sending, notify subscribers of system tray stakeholders, an interactive reuse help menu managed by the Redmine REST API, etc. (Maybe automate parts of the documentation using the Wiki?)

Answer 3

We found the following practices useful:

1) Hide the tracks "Issue" and "Support" and record everything as an error:

• time saving for developers, testers, management;
• If some actions should be declared as “additional” or “new features” or something else, quick meetings are organized to evaluate them.

2) stages and versions I like it, you can easily track the status of each version and at any time you can download the old package, that is, check the error filed by the client.

3) “save” on the “problems” tab: another important time saver. I have different requests that persist for many daily reporting tasks and all I need.

4) version integration, i.e. using "# 123" in the comments creates a link to the corresponding problem: just smart!

Answer 4

We make extensive use of Redmine in our system. We even created the Sales project, which our sales team uses as CRM. We have a bunch of custom fields in this project, and it replaces the SugarCRM that we used before.

In our system, we have projects for Server and Client software. The server project is divided into submodules based on how I structured the system and subrepositories, since Redmine likes a separate repo for each project.

We use, as others have noted, #nnn codes in commit messages to refer to tickets. What's cool is that it doesn't have to be a ticket in the same project. Thus, a sales ticket can be blocked by a problem with an error or request for support.

We just started using Discussion Papers / Minutes. We use Versions to group in releases both on the client and on the server.

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

Email support goes directly to our support project, and if importing email was a little more reliable (sometimes it does not create new tickets properly if the line Project: is included in the email), we will automatically receive requests for the website to generate tickets for sale. Be that as it may, we just need to track support tickets and translate them into Sales, if applicable.

What I would like to do:

• We have a relationship between our system and redmine, so tickets can be associated with a user or company in our system. In addition, so that we can create a new company from a sales ticket in an appropriate place. It just requires me to work.
• We have a connection between our sentry error tracking software and redmine, so server errors generate a redmine ticket. Again, solvable using modern technology.
• Ask the desktop client to reprogram. The server is located on our local network, but the ability to have a more flexible way to access data other than a web page will be great. It’s not that I can’t do anything in the redmine web interface, but something like Things.app is much nicer to work with.
• Upload our support documentation to redmine and then create it on an open access server. Thus, our support staff can maintain the documentation, edit it in a beautiful way, and deploy the changes to the doc server.

Answer 5

Redmine was fantastic for us. We use it as the next priority queue for placing tickets or queues, and also tied it to the SVN. In particular:

• Installation / support via SVN was easy (I moved us from 1.1 to 1.2 to 1.3 to 1.4 using the svn switch https//.../branches/1.3-stable . Commands, followed by the rake migrate commands, only using separate random installations).
• Backing up the database and saved files is a one-line script execution
• We love Time Tracker and time spent plugins. I would kill for Mac OS X to track the fat client for some of our users, but it’s not :)
• We do not use forums much, but actively use Activity and Roadmap. Associating issues with specific versions is a godsend.
• We also have differences between the client and server, but use the target version to link tickets to indicate where it goes (and has an open end NEXT CLIENT RELEASE / NEXT SILVER RELEASE) to distinguish between working hours.
• We mix metaphors for statuses - we use our lists, first grouped by these (“Immediate”, “Rejected”, “Blocked”, “Workers”, “On deck”, “List”, “Waiting for assembly”, “Issued for testing "," Verified "," Put into production "," Closed "," Canceled ".
• Then in each group above we have this sorted list of Priorities: (“Immediate”, “Prioritize me”, “Design and size me”, “P1” ... “P5”, “P-Watch List”), This is plus the above makes it easy to handle all problems from the problem area.
• For the main list of problems, we sort by “Priority”, “Parent task”, then “Updated date” - we need the average one, so Redmine perfectly debugs the need for a child task in the same grouping.
• We use svn ci -m "This fixes #1733 @2.5, holy smoke what a weird foo bug. It is now bacon and unicorns." to fix errors (i.e. svn ci -m "This fixes #1733 @2.5, holy smoke what a weird foo bug. It is now bacon and unicorns." ) - and move this problem to "Waiting for assembly "(it was Solved, but I'm tired of explaining that Solved does not mean that someone can expect it to be released yet).

I think I will have to research the Redmine-stuff-to-do plugin. +1 Question.

Answer 6

My company works with developers of software and hardware of international origin. Before I joined the company, the email was used with MS Word documents to relay our problems and errors using software or hardware to request a fix. This process was not possible to track and support any process. I implemented RedMine as a tool for tracking software and hardware errors, and it has been working fine ever since. In my situation, there is a major language barrier. Fortunately, RedMine can display Sipmlified in Chinese, and feedback has shown that this is the case while I am from the developers.

Status - When I find a problem with software or hardware, the status is "New" - When my software / hardware developers saw this problem and they are working on it, they change the status to "In Progress". They can use% if they want 0 to 50. I set% Done to 50 when they think they solved the problem. - I determine whether the problem is fixed, and I change the status to "Allowed" and% to 100%. This allows me to filter out problems <or equal to 50% to find problems that are still open.

Priority - Low, Normal, High, Urgent, Immediately everything is well translated into Chinese.

Expiration Date - I use this to inform me when a patch was originally downloaded by my software developers. It may take me 4-6 days to check something and close the problem. I like my Gannt chart to reflect the responsiveness of my software development team, and not how long it took me to approve the fix.

Category - This always reflects the version of software or hardware where I found the problem. I use this to find out which version of the software contains the most errors, and to make sure that new versions of the software do not suffer from regression.

I have everything included in the RedMine observer list for all errors. The email is found as (new), (allowed) or (in progress), so my managers, supervisors and chief engineers of the teams involved can see the email and quickly read what progress is being made. Most of the other people involved have never logged in to RedMine, I am usually the only one. Emails are great for instant updates to everyone whose only problem is whether progress has been made.

Answer 7

As you mentioned, sending Word documents back and forth with your QA - I know this feeling, was there, did it. The main problem for me: QA people do not like to add problems to any error tracker, they mark them in the editor next to them during testing.

Now we use Redmine with a nice addition - Usersnap (Disclaimer: we created a tool to solve this problem for ourselves.

Usersnap is great for web developers - add it to your web project and you will get screenshots directly related to Redmine tickets, including meta-information about your browser, operating system, etc.

Our QAs / clients can enter errors right now in a web application, and it is easier for developers to reproduce error reports in Redmine.

Answer 8

We use the Roadmap section as a clear way to display:

• mistakes
• (this will be a link to your text document or a link to the html requirements pages).
• Reconciliations (differences between production and test values)
• etc.

This is the highlight of consolidation for us. The rest is used in connection with this (for example, the “announcement” section is used to determine the main milestone / release stages used in the roadmap).

Answer 9

In addition to other comments, I recommend using the “Stuff To Do” -Plugin (written by Eric Davis, I think :) Using this plugin, you can drag and sort the order of problems in several projects.

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

Answer 10

We use Versions as a way to determine sprints, so each version is a sprint with a Roadmap view that gives a clear illustration of progress. Sprint issues are marked as “ready to review” when they are completed and then closed when the QA is confirmed.

We use the Version as a lag for any problems that go beyond or lose priority, etc.

Answer 11

We have been using Redmine for about a year now and it has developed on its own. We use versions to group problems together for release, and categories for group problems by discipline.

Each problem goes through the workflow of the new> in the process> resolved. Then the tester will close the problem when it is happy.

We would like to update the way we use Redmine, there seem to be so many great plugins, but we find that many of them are broken or will not be installed.

We use the wiki comprehensively for developer documentation.