The reason they're not tied to a project is because often people have
multiple projects working towards the same milestone. It depends how you
use your projects - for example, you might have a project for the API side
of a software system, and another project for the front-end for example -
they would both have tasks needing to be completed in the same milestone.
In saying that, we have had a few people requesting milestones tied to
projects. I don't really see the need to tie them to projects yet though -
if you only want tasks from a particular project to go into the Milestone
then put tasks from only that project in it. If you have a convincing
reason for locking them down let me know.
My primary reason is clarity in labeling. I might have several
projects with "Alpha", "Beta" and "Launch" milestones, for example.
To tell them apart when assigning issues, I need to relabel
"Project A Alpha", "Project B Alpha", etc. and set manually set
each client group's visibility into milestones. Not sure if that's
sufficiently convincing, but that's my reason for wanting the
direct project-to-milestone relationship.
Thanks Matt. That is a good reason.
I'm unsure if we should be allowing you to choose if a milestone should be
per project or global, or making every milestone per project. I'm worried
that giving people the option might cause more confusion than relief, but
because we already have global projects we can't really take that feature
away. It might be something that has to wait until v2 as that gives us
almost a clean slate to work with. Hopefully until then, the way it
currently works doesn't cause too much hassle for you.
on 06 Feb, 2015 07:41 PM
What about milestone bound to a group? Because that is THE method to divide spheres of visibility in the application and I think it would solve the main issue -- clients being able to see milestones of other projects. And I did not have time to dig to the sources (and I don't see myself doing it if not completely necessary), but it should not be that hard to implement as well.
on 06 Feb, 2015 07:44 PM
ADD: actually, it should not be hard to implement AT ALL, as the functionality is already implemented (in group properties); it just needs UI on the milestone properties side, so one can bind it when creating new milestone.
I agree that milestones should be bound to projects. Milestones are directly linked to project management. In the project management field If people work towards the same milestone they work on the same project, maybe different aspects of it, but that's why there are milestones. The fact that they might separate their code as you mentioned (or it could be software - hardware...) should only be done on the code side (like branches).
On the bug/feature tracking side, it can easily be tracked by your "label" then people can just search for the label they are interested in. In any case I cannot deploy that product that seems very promising otherwise (I just installed the trial version) for the whole institute. I was looking for a php-base option to replace our current "trac" instance. Well, hopefully you'll be able to integrate the change in version 2. Is there actually a place to request new features? I'd like to see an ldap connector too. Thanks.
I have asked the question from Robert if Bugify is still alive and if this feature will get implemented. He wrote yes, it will be in Version2.0 although there is no ETA for that. Which for me seems to be the polite way to say: "no I dont develop bugify anymore"
...sigh. What so hard about putting..."no longer actively being developed for the time being(if thats the case)" ...so no one else waste time and money. Honest opinion: the app is great it just lacks a lot of basic customization that most of us in this forum could write ourselves...an easy way to solve this issue it is by the use of plugins which would allow the community to just do this ourselves. There is no credibility because there are no upcoming change logs, development road map, or GIT repo we could look at. I found this https://github.com/bugify but there nothing in there. It saddens me that I will be end up changing my src code after paying $70 to not have to write any code in the first place. I mean like something as simple as uploading an image and being able to click on it so that it shows in a modal is something so basic. It's ok to send us minor updates...anywho I'm off my soap box.