Redmine

Hi Dave, unfortunately I don't have any diagrams to hand, but perhaps I can enlighten you a bit with the following descriptions.

The basic concept of Redmine is issues. Issues are just forms with a unique number attached to them. In Redmine it is possible to have different types of issues.
They basically differ in the structure/fields of the forms and the process of how they change their status. This is called a tracker. You can fine-tune who can see and edit an issue. Not everything needs to be visible and editable by everyone.

Issues are grouped into projects, which can also contain additional information such as a wiki, documents or other modules.
Projects can have sub-projects to divide a larger project into smaller parts. All issues in the sub-projects can be viewed and filtered in the parent project.
By default, issues are not visible to members of neighbouring projects.

Greetings,
Bernhard

Bernhard,

Your description is very helpful. If I understand, a tracker associates a workflow with a class of issues, right? It's good to know how the pieces are internally connected.

Regarding the other part of my questions: I have a set of daily and ongoing processes that I would like to map into Redmine. These are IT related, but not software development. Maybe some are slightly like HelpDesk, but others go in the direction of systems and data center management, large deployments, or procurement activities.

I have a sense that Redmine can be useful for the above. I'm looking for some examples of how others have done this to help me try to 'do it right the first time'.

Thanks.

-Dave

I have a small IT shop where I do exactly this with Redmine. Tracking my work and collecting information about my tasks.
Redmine isn't just tied to software development. It's just the terminology like "target release" that makes it look like it is.

To start, I would do the following:
- Collect your task categories and create trackers for them.
- Design the workflow for each tracker. Create custom states as needed. (Keep it simple. New -> In progress -> Done is sufficient for most tasks).
- Specify form fields as needed.

And I highly recommend playing around with Redmine at least a little.
There are virtual machine images from Bitnami or Docker images that you can use to spin up an installation and start playing around with Redmine.

Bernhard,

Great to know that you are doing something similar. So to start, one project, but "task categories"==trackers, and tasks==issues. Thinking of the Gantt charts, is there a sense of a sort of long term or ongoing 'project' that has occasional tasks and time spent? One of the things I need to characterize is the amount of activity (issues) and time for certain categories of activity. The other is for some more consequential tasks that aren't getting addressed due to other workload.

Regarding the Redmine VMs, I have 3 Bitnami Redmine VMs - one 'production', a clone for backup, and a separate one for playing and breaking.

Thanks for your input and support.

-Dave

Regarding long-term projects/tasks. There are a number of things you can do. Firstly, you can break up a large task by adding subtasks/issues to a parent issue. The overall progress of the task is calculated by the progress of its subtasks.

For long-term planning, the roadmap/versions come in handy. You can create versions (like work packages) with due dates and assign issues to them. The Roadmap tab shows the list of planned work packages with their progress, estimated time and time spent on the package. The Gantt chart also shows the versions and their overall progress. I personally have versions for every quarter of the year and one backlog version for collecting future tasks.

Each issue may have a field for the estimated time required. If the issue has subtasks, all the estimated hours are aggregated to the parent issue. You can easily see the estimated and actual time next to each other in the issue list.

Bernhard,

Please pardon another basic question: I just noticed that issues have a category field. Since you are using Redmine for something similar to what I plan, how do you use this category field?

Thanks.

-Dave

Hi Dave,

no Problem. :-)
Categories can be used to collect issues of the same kind (tracker) under a specific topic. For example I have "Infrastructure", "Services", "Support", "Documentation" as categories for my issues. Just to get a better overview for what the most work is done. This could be realised with custom fields, too but the advantage of the categories is that they are project specific. So every project can have its own list of categories. One project can have different servers as categories, another project likes to categorize the tasks for different facilities, you name it.

You can group your issues by category in the issues list, generate reports about spent time by category or show a graph of open and closed issues by category in the roadmap.

Greetings,

Bernhard