Redmine

Hi everyone, related to versions and milestones, I've developed a Redmine plugin for this stuff, if you're interested on it, you can check it on this link:

http://ociotec.com/redmine/projects/show/advanced-roadmap

• Milestones associated to projects.
• You can add versions to milestornes (even from other projects).
• In roadmap view you can see the normal roadmap, versions, and milestones of the project (like a mini roadmap only showing the versions of that milestone).
• Easy milestones edit.

I hope it can be helpful for you.

Hey Emelio,

That awesome. Looking it over briefly, it appears to me that in your plugin a milestone is a parent set grouping of versions. Could you post a screen shot of the milestone edit form to this thread (so I don't have to install it to see it)?

As I think about it, I find that I interpret a milestone as a point on a calendar (see peter's wikipedia link). While that can easily be a grouping of versions, it could just as easily be 1 version (which your plugin could cover) or a subset of issues in a release or even an issue or piece of an issue. Mostly importantly to me though is tracking the milestones what are not part of issues, payment milestones for example, or client dependencies. Some of which I would not want as issue as to avoid the wrong person seeing sensitive information.

In short, good start. Thanks for contributing to the redmine community. I think when we start dev-ing this, we will probably take a different route.

Project.net PMS manages phases with deliverables and milestones. Maybe some good ideas to take inspiration from...

http://www.project.net/phase_review
http://doc.project.net/9_0_UG:Manage_Phases

Their Workplans are cool too:
http://www.project.net/project_workplans

Eric

Just FYI,

I started a plugin project at http://dev.holgerjust.de/projects/redmine-milestones. I had not yet time to do much work here, but am looking for to have some this weekend :)

--Holger

Great, I'm impatient!

I was again thinking about what milestones represent and from all what's been discussed here, I think we agree they are just markers in time, of many types. Then they can be software versions or other deliverables due/release dates, start/end dates of a project's phases, or payments or client dependencies as Shane said.

I think we should be able to put markers anywhere on a timeline (calendar). Freely. If any date has any special meaning to us during a project, then we should be able to make it a milestone.

In that case, I think milestones should not have to be tied to the beginning or to the end of the different phases of a project. But this wouldn't prevent beginning/end of phases of being "natural" milestones.

Then, in a roadmap (maybe not in Redmine's sense), we should be able to track this collection of milestones of various type and to display them chronologically.
The view could be made different depending on filters (by phase, by version, financial, etc). A treeview of the project phases could show all milestones in each phase, etc...

They should be displayed in Gantt charts and calendar too.

A feature would be to be able to define due dates for issues, versions, etc not by selecting a date, but a predefined milestone. If we have to slip a milestone date, due dates would slip too...
If we slip the end of a phase, issues, versions, etc, that have their due dates set to the milestone that marks the end of this phase would slip too...
We could also filter issues or versions by milestone (when they are tied to a milestone)

Eric (still thinking loud :-)

Eric, I'm 100% on board with your proposal. Holger! that sounds like an awesome weekend project!

One other addition that I think would be really helpful is to have a "Completed" checkbox on milestones. That way Milestones could be listed in groups of completed, not completed and overdue.

Beyond that, Shane and I were thinking eventually to have even another checkbox for financial Milestones whereby the PM can mark a billing milestone as complete such that they are effectively approving the billing but then the finance person can mark them complete as being paid. that way a finance person can see all financial milestones that have been approved by PMs but not paid, or all milestones that will soon be completed by PM, or all milestones that have been paid, or all milestones that are overdue but not yet approved by PM, etc... Obviously this would take place at some sort of global admin view where as normally Milestones would fit in the realm of a project.

Peter, maybe you, Shane and Holger should agree on the structure of a milestone "base class", in order to ensure interoperability between both your plugins... I mean the financial milestone you need for your budget plugin might derive from Holger's base class (or module?)...

Eric

Eric Voisard wrote:

Peter, maybe you, Shane and Holger should agree on the structure of a milestone "base class", in order to ensure interoperability between both your plugins... I mean the financial milestone you need for your budget plugin might derive from Holger's base class (or module?)...

Eric

that sounds great! how do we do that? :)

One thing to that point is we had hoped to use milestones within contracts that are within projects. This means for us it will be ideal if milestones can be a grandchild of a project, as opposed to a child. Not sure if that matters or not but I figure I should throw it out there.

ex: Projects have Contracts which have Milestones.

To elaborate on Peter's description, the classes and relationships we are envisioning are as follows:

Project [exists] has many Contracts [new]
Contract [new] has many Milestones [new]
Contract [new] has many Deliverables [new]
Deliverables has many Issues [exists]

At the moment we were not planning any specific relationship between milestones and issues. Can anyone give me a good use case out of curiosity?

Attached is a working comp of what we imagine would be a new milestone form. A few changes I have yet to make to the comp include: rename "Client Dependency" to "Dependency", remove "approved" and "invoiced" and adding watchers (should only show managers and admins).

I imagine alerts would send a notification email in the timeframe chosen in the dropdown to anyone who is watching. (for the full list of fields check out comment: http://www.redmine.org/boards/1/topics/214#message-10332)

As for the methods a milestone would need aside from your standard crud would be one handling a change of status and the proper behavior (alert), one for completing and perhaps some finance ones.

Hi all,

first thank you for all the ideas and feedback. It would be great if we could coordinate our efforts.

Peter: I like your idea of having an elaborate status on a milestone. However, I think, we should then come up with a real workflow system (like the one for the issue status). Additionally the status could automatically change based on events (like arriving at the defined deadline. This could be implemented using a callback mechanism to allow other plugins to register additional logic.

I'm sure, different people will use milestones differently. E.g. at our company we use some other system for billing and cost control (which I can not disclose currently) so your (or Eric Davis') system of contracts and deliverables is not used by us.

I currently envision the following data relationships:

Project [exists] has many Milestones [new]
Project [exists] has many Project Phases [new]
Project Phase [new] belongs to Starting Milestone [new]
Project Phase [new] belongs to Finish Milestone [new]
Issue [exists] has many and belongs to / has many (still undecided) Project Phases [new]
Milestone [new] depends on (i.e. has many and belongs to polymorphic) Issues|Milestones|Project Phases
Version [exists] has many Project Phases [new]

Issues can be assigned to project phases (in much the same way they can now be assigned to versions. The notion of a project phase is going to replace much of the versions scope in Gantt charts. It will also extend the roadmap view with the finer structure of the phases. Having issues assigned to phases, we can then automatically decide on the ending milestone based on the closing of issues (e.g. slip the milestone date, force a deadline and issue a warning email, ...)

I'm still thinking about whether issues should be assigned to phases or just to the ending milestone (having the project phase just as a small usability layer above the two milestones which is automatically derived).

Shane & Peter, I really like your UI. However, from my proposal, the type field field could be one of "Fixed date" or "Floating" (depending on the assigned objects, could be combined with a fixed "last date"). The financial stuff could then be added later maybe (as some sort of a plugin-plugin?).

Additionally, I am not sure, I understand how you are going to implement your "Client Dependency" as milestones. From my perspective, it would be much more common to use issues for that and add maybe some kind of reminder function to them (there is already some plugin for that, I believe). If the client is late, the issue date slips and thereby the milestone.

All together, I would see a milestone just as a single point in the project (in the first step defined only by date, later on by other means). Therefore, I would try to decouple the milestones from your contracts. I think, we should come up with a STI-friendly way (whatever that means) to design the milestones so that other people can later on extend its scope.

Hey Holger - this is going to be fun!

QQ (I have to go into meetings this morning but will come back to this in more detail this weekend)

1) How does your Phases differ from the current implementation of Versions? Can we repurpose versions?
2) What are the implications of relating Milestones Either to Phases or to Contracts or to Both in a many to one?

1) How does your Phases differ from the current implementation of Versions? Can we repurpose versions?

My phases are in most ways the same as versions. What I'm trying to achieve is to use the term version only for real versions of a software, a device, etc. They should merely be used as a mean to track different parallel revisions of the project artifact and not as project phases. In the long run, I think, we should strip down the current Versions and move some of its functionality to the phases.

2) What are the implications of relating Milestones Either to Phases or to Contracts or to Both in a many to one?

I want to have flexible milstones. I.e. milestones that are defined only by their dependant objects. As such, an example milestone could possibly depend on the completion of 3 issues and previous milestone. If the completion of the issues ceases, the milestone (and all dependent milestones) could then be automatically arranged. To keep the flexibility it should be possible to define all relevant object types as prerequisites.

Phases thereby are defined in length by its starting and ending milestone. Furthermore, I think, we should be able to create arbitrary additional milestones and relate then to any needed objects (like your contracts).

--Holger

P.S. Just noticed the 11 hours time difference. It's almost weekend here in Germany :)

This is one of the most interesting threads in a long time, seems like it might be possible to reach a critical level of interest here .. Good luck and hopes for continued inspiration! :-)

Some more interesting reading about Milestones (derived from Peter's Wikipedia link above)

http://en.wikipedia.org/wiki/Milestone_%28project_management%29

http://www.pmhut.com/managing-project-boundaries-stages-phases-milestones

http://www.pmhut.com/project-milestones-and-the-project-team

Milestones should indeed be either of flexible (achievement stages) or fixed (target stages) types. Though we should be able to slip the date of the fixed type ones.

Eric

"Milestones should indeed be either of flexible (achievement stages) or fixed (target stages) types. Though we should be able to slip the date of the fixed type ones."

Good quote Eric. It made me ask the question - what is the real world difference between flexible and fixed? Practically, why does a milestone even exist?

• Measure progress vs expectation
• Trigger an activity (switch of ownership, beginning of another action that was dependent)
• anything else .. that the only two that came to mind?

What is tough to me when mixing milestones and versions is that a version in my head is actually a software release. It has a very specific pattern in our company, with pre-release, release and post release actions and requirements. I would not want to loose that, I would actually prefer to have it become more specific and specialized.

A release is a very very specialized form of milestone. The question I am struggling with is: should release be a child class of milestone, adding all its forms of specificity, or should it simple be something separate? Can we even get enough support in the redmine community to re-evaluate this feature or do we simple code around it? This is probably a question for the core team.

It sounds to me like we are coming to the conclusion that ultimately what many of us desire is a re-examination of the scope and purpose of the Versions class.

Shane Pearlman wrote:

Practically, why does a milestone even exist?

• Measure progress vs expectation
• Trigger an activity (switch of ownership, beginning of another action that was dependent)
• anything else .. that the only two that came to mind?

I think there is much to be said for awareness / mission. Measuring progress and triggering things are functional, but i want to also have milestones for events that the team needs to be aware of but have no specific functional resolution. Examples include:

• Tradeshow
• Boardmeeting
• Any other event that might be good to observe but might not have any specific impact on the project.

I could also see this also applying to things like "Dev Team OOTO for a week". That's really more of a calendar event than a "Milestone" but it is a noteworthy event that needs to be accounted for somewhere. And often it's the type of thing we actually have in our contract.

Basically, I'd love to see Milestones include any time based event that is noted in our contracts. In the case of Versions, I see them as a subset of milestones.

Peter Chester wrote:

In the case of Versions, I see them as a subset of milestones.

I tend to disagree. As stated above, I would use he term "Version" as a software release (or something like that). To reach a state were I can actually release an artifact, I would have to go through various project phases which each could also produce an artifact (like a draft or a beta release). Personally, I would use versions as a mean to track the life-cycle of a project and its potentially multiple incarnations (think supported software versions, branches, ...)

The plugin I started to write currently does the following:
You can defined milestones. At fist, these are objects without any meaning for a workflow or project planning. You are however able to define certain objects (like other milestones, versions or issues) to be a dependency of a milestone. Based on the definition of a closed state of these objects, the system is able to automatically derive the status of each milestones (passed or open).

• flexible: The passed status of the milestone is only dependent of its dependency objects. Once the last dependency is closed, the milestone passes.
• fixed date: The milestone is bound to a user defined date. The milestone is passed, once the date is reached. If there are still open dependencies, this is considered as an error, the PM has to fix
• restricted: This is a mixture of the two above cases. The passes status is derived from the dependencies until the fixed date is reached. That date is considered the last possible pass date.

I plan to implement some kind of time planning. This could be in a form like in the schedules plugin by Eric Davis. In the simplest form, the PM could assign a man-hours-per-real-time-hour ratio to a milestone. Using this and the estimates on e.g. the issues, an estimated finishing date could be derived.

We could also create other types of Milestones (like financial events or contract events as Shane suggested). As they would all derive from the basic milestone model, these could be simpley pluged into the existing code.

Next to the project phases. These are currently defined through two DateMilestones: Start and End. The end milestone depends on the start milestone. Dependency objects are assigned to the end milestone internally. In the UI, the life-span of a phase could be displayed more prominently. As such, the project phases should inherit most of the usage scenarios, that Redmine Versions inherit today.

The Redmine Versions should be extended such that their life-cycle is defined by various project phases (which the define various milestones by default). Issues could then be assigned to one or more Versions (and thus to the respective project phases), to a specific project phase or as a dependency to a milestone (which would be the internal representation on the project phase case. Using the various milestones and its dependencies (and a more flexible Gantt chart), the users could track the project progress much better. The system could then even emit warning mails for things like delays on the critical path or could be used to track the accuracy of time estimates.

Concluding: This could be a really impressive tool. I'm very excited!

Right, it's exiting! All this put together will be a great step forward for Redmine!

Regarding basic Milestones without any special meaning, say "general purpose" Milestones (e.g. for meetings, events such as big boss visit, etc), the only dependency could be a checkbox (if manually checked => status = passed) so that they don't remain marked in red in views.

As for Versions, with actual scheme, I tend to agree with Holger: if we agree that a Milestone is nothing else than a date, then a Version of something is not a date, it's "the product" which by itself in independent from time. Otoh, the release date for a given Version is a Milestone, for example...
Hence: Version [exists] has many Project Phases [new]

If we (well, you :-) implement Milestones (and Phases), then we could uncouple Versions from time and hand over their actual time related properties to the Milestones (and Phases). Versions would be intrinsically independent from time, but not from the time in associated Milestones. Does this make sense?...

Eric

Eric Voisard wrote:

the only dependency could be a checkbox

well, it wouldn't be a dependency in fact, just a mean to force the status...
Eric

Hi,
I'm really interested in the features you've mentioned above, especially defining dependencies between versions (current name in redmine). Did you make some progress on that topic ?
thanks
gabriel

I haven't seen this concept out there, but how I use version and milestones in trac is as a reporting vs planning tool.

Version is used to report what version the bug is reported on, while the milestone is used to triage/plan features. As I get near to the the end of tickets in the milestone, I can see how close a release is.

I'm guessing then that maybe I'm using milestone for what you have as version, but sometimes it's handy to have them separate so you can see when a report came in, in terms of a version and not just a date - especially when there are multiple versions in play being supported.

Also, as I near a release, sometimes I create a special triage milestone that I move tickets to if I thinnk they need to be postponed for a later release.

Is Holger still around here?
Because I must say that since we had this fruitful discussion, I'm cruelly missing this Milestone feature, for each new project we start :-)
Any progress with your plugin Holger?

Eric

Eric Voisard wrote:

Is Holger still around here?

Yeah, I am. I had not much time recently, so the development was a bit slow recently - a.k.a. no development :(
Sorry...

Because I must say that since we had this fruitful discussion, I'm cruelly missing this Milestone feature, for each new project we start :-)
Any progress with your plugin Holger?

/me too. I will try to set aside some time for development on this. I think, I will create a remine fork on github and develop a patch directly, as the split up between versions and milestones will touch a large amount of code. Let' see if JPL approves...

--Holger

Hi Holger, thank you so much for attending to the community like this. For what it's worth, we're working on a financial plugin that will feature "Milestones" but as per our previous discussion, we think of milestones differently than what you're thinking of them as. IMHO I'd prefer it if possible if the code that you write for milestones was not baked into the core code. Otherwise we'll be soon finding ourselves in a very awkward position, especially since we've been putting a lot of time and money into building this plugin.

-peter

What about baking some hooks into the core and then making a plugin that works with those hooks?