Page MenuHomePhorge

Allow for reordering of milestones
Closed, DuplicatePublic

Description

Originally reported on upstream: https://secure.phabricator.com/T12144 - which was closed as "Won't fix"

I use milestones to track versions of an app I'm developing. Multiple times, I've needed to add milestones to represent new versions of the app (for example, I've created a 1.0 milestone to track release tasks but I've needed to create a 0.5 version to handle more pressing private beta bugs). The current workflow is:

  1. Choose "Create Next Milestone"
  2. Connect to my database, SELECT id, name, milestoneNumber FROM phorge_project.project WHERE parentProjectPHID="PHID-PROJ-XXX" AND milestoneNumber > 0;
  3. Edit the milestoneNumber field for the milestone and all milestones after it to implausibly high numbers. (This step is required because of primary key checks)
  4. Save.
  5. Edit the milestoneNumber field to represent my desired ordering.
  6. Save.

This could be easily automated. There is a concern about other parts of the UI being broken by this change, so we should do some testing before pushing to stable.

Event Timeline

The original discussion in T12144 is kinda convincing to me, although it's mostly convinces me that the term "milestone" doesn't match these objects.

tl;dr:

  • "milestones" are subprojects that are strictly ordered in time, like "sprints" - they may one day be automatically created, etc.
  • so they track not "progress to a goal" but "ordered work chunk", like "week"
  • other then that, they're just regular "subprojects", and users that ask for "reordering milestones" should just use subproject.

To me, the term "milestone" means "X is done/ready", and by extension, "the collection of work that needs to happen so we can say X is done" - and this isn't time-based but content-based.

So maybe we should:

  1. Add some tooling to convert milestones to regular subproject / subproject of a new "type" that's visually distinct, but otherwise is basically a "subproject" - for users that were expecting this behavior.
  2. Rename "milestones" to something that's more obviously time-ordered ("sprint"? what other names people use for this concept? do they call it "scrum"? "month"?), with possible start- and end-dates. These can't be ordered normally, but maybe we can allow editing start/end dates and have that reflected in the UI.

I feel like the idea behind milestones being strictly ordered is from the viewpoint that milestones are sequential "events" that happen in development one after another in a given order.

Things like "Product Proposal" "MVP" "Incorporating Feedback" etc. would be an example of milestones that happen sequentially.

Version releases would be another example of milestones that happen sequentially.

In essence, IMO, MIlestones the way they are is correct and don't need renaming, but we need a different kind of object to group objects related to things like features, etc. - I suggest we take an example from GitLab and use the name "Epics" for such groups.

Also, this is fairly similar to T15082. Having Epics would probably also resolve that.

If the users want to use milestones instead of subprojects, can they not change the language settings to Pirate English or something and go from there?

FWIW even in the case the milestones are strictly ordered, it's incredibly inconvenient to sort out a situation where you need to add one to the middle of the list - forcing the user to rename a bunch of them to get things straightened out.

Thanks. I think we should mark this Task as duplicate of T15082

Also, this is fairly similar to T15082.