#8936 closed enhancement (wontfix)
Term "milestone" is a bit special
Reported by: | anonymous | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | general | Version: | |
Severity: | normal | Keywords: | |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
Why not use a more general term "appointment" or just "date" instead of "milestone"? We tried to use trac as simple task-tool (without SVN sources) but the users wondered about that "milestone" which is a bit inappropriate in such use of trac. Such people don't know about what trac actually is but just want to have a webiface based task tool.
Attachments (0)
Change History (8)
comment:1 by , 15 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 15 years ago
But we have trac-"milestones" where tickets should be assigned to, so I want to keep that feature. But such appointments haven't such special name "milestone" here but another one our users are used to. They are just appointments like quarterly billings. Just the term "milestone" has another meaning here, and its use in trac confuses people here. That's why my need for renaming. I hope my problem is described clearer now. Well, I don't dare reopen this ticket though :)
comment:3 by , 15 years ago
You might be able to change all occurrences of "Milestone" into "Appointment" by creating a dummy English translation, and translating only those terms. See TracL10N for more information.
follow-up: 5 comment:4 by , 15 years ago
Thanks, that looks like a good idea.
Well, we have also this problem with the term "milestone" even for our SVN-based software project. We create trac-milestones for each release, but actually those are just certain appointments/dates in our release cycle. The term "milestone" is actually only used in the sense of ISO9001-milestones (M1,M2,…,M5) in our organisation. Until a next ISO9001-milestones we have several releases (release candidates, bugfix versions,…). So a ISO9001-milestone is like a master milestone among the trac-milestones. Though that's why more often the several meanings of "milestone" cause little difficulties when speaking with other people about trac…
follow-up: 8 comment:5 by , 15 years ago
Replying to anonymous:
Thanks, that looks like a good idea.
Well, we have also this problem with the term "milestone" even for our SVN-based software project. We create trac-milestones for each release, but actually those are just certain appointments/dates in our release cycle. The term "milestone" is actually only used in the sense of ISO9001-milestones (M1,M2,…,M5) in our organisation. Until a next ISO9001-milestones we have several releases (release candidates, bugfix versions,…). So a ISO9001-milestone is like a master milestone among the trac-milestones. Though that's why more often the several meanings of "milestone" cause little difficulties when speaking with other people about trac…
We have this same issue and since Trac doesn't yet support sub-milestones, we ended up naming our milestones as follows:
<Project Milestone> - <Sub-Milestone/Component-Milestone (e.g. Software Milestone)> - <Iteration>
For example,
M1 - DER - Refactor Hardware Interface
is one of the "Milestones".
So in our case, we are really using the Milestone field to name Iterations, with the Project milestone and Sub-milestone contained in the name of the iteration.
follow-up: 7 comment:6 by , 15 years ago
I don't know if it's easy, but what about the idea to offer a possibility for remapping a small defined set of strings in trac.ini? Just for displaying, of course tag names must not be changed.
Candidates are the names of the main menu items and that string "Milestone" displayed on the Roadmap page. E.g. something like:
[string remapping] mainmenu.Journal=Log mainmenu.Wiki=News page[Roadmap].Milestone=Appointment
comment:7 by , 15 years ago
Replying to anonymous:
I don't know if it's easy, but what about the idea to offer a possibility for remapping a small defined set of strings in trac.ini? Just for displaying, of course tag names must not be changed.
For the navigation entries, it's already possible, see TracNavigation.
Beyond that, I think it's not a good idea, as you would have to duplicate what's already done by the i18n framework. Just modify your translation files, and only the terms you're interested to change (10 minutes to read TracL10N, 5 minutes spent in a good text editor, and you're done).
comment:8 by , 15 years ago
Replying to Ryan Ollos <ryano@…>:
Replying to anonymous:
Thanks, that looks like a good idea.
Well, we have also this problem with the term "milestone" even for our SVN-based software project. We create trac-milestones for each release, but actually those are just certain appointments/dates in our release cycle. The term "milestone" is actually only used in the sense of ISO9001-milestones (M1,M2,…,M5) in our organisation. Until a next ISO9001-milestones we have several releases (release candidates, bugfix versions,…). So a ISO9001-milestone is like a master milestone among the trac-milestones. Though that's why more often the several meanings of "milestone" cause little difficulties when speaking with other people about trac…
We have this same issue and since Trac doesn't yet support sub-milestones, we ended up naming our milestones as follows:
<Project Milestone> - <Sub-Milestone/Component-Milestone (e.g. Software Milestone)> - <Iteration>
For example,
M1 - DER - Refactor Hardware Interface
is one of the "Milestones".
So in our case, we are really using the Milestone field to name Iterations, with the Project milestone and Sub-milestone contained in the name of the iteration.
Exactly. This ticket also made me think about sub-milestones (and milestone "types"…). See #2344.
Well, I guess Trac may not be the right tool for you, then… Note that if you remove all milestones, the field will disappear from the ticket page. You could then add a custom ticket field "Appointment" as a replacement.
For the primary usage of Trac, the term "Milestone" is adequate.