[Connect 2.5] Workstreams - Timeline

[maxceem]

Currently, when we are creating a project, we create timelines and milestones for each phase's product.

In the new work management functionality, we are showing a timeline for the whole work instead of workItems https://marvelapp.com/54cf844/screen/59214005. So we should update project creating functionality to create one timeline for work instead of creating several timelines for products/workItems.

We should also, decide, whether we should keep the old way of creating projects with phases or no. This decision depends on whether we keep this functionality server-side and is being discussed in this issue https://github.com/topcoder-platform/tc-project-service/issues/358

[vikasrohit]

As I said in https://github.com/topcoder-platform/tc-project-service/issues/358, we don't need to support the phase creation for old projects, we can remove the code for creating timelines and milestones automatically as well for phases. For work cards, I think we still need to create a timeline on work card creation and I guess we need to think over what default milestones we need to create to support the new timeline and its representation.

[maxceem]

As per the design, by default, we have an empty timeline: https://marvelapp.com/54cf844/screen/59213996. And I think we can start from such approach.

Later, I guess, for the first work of the Design workstream we can create a default timeline for a design challenge as shown on this design https://marvelapp.com/54cf844/screen/59213988. This would require us to think about keeping timeline date in sync with work. As if we create timeline with milestone during project creation, most likely the work wouldn't start immediatelly, so the timeline would become outdated if we create it from the beginning but actual work will start later.

Questions:

1. I'm confused with one thing. On some designs, the timeline has default "START" and "COMPLETE" labels, like:
   

   So it looks like we can add just some "milestones" in the middle which wouldn't cover the whole timeline.

   But on the other hand, we can add milestones which would cover the whole timeline without "START" and "COMPLETE" labels.

   

   Note, that in the UI we don't have ability to define start and end dates of the timeline, so it looks like timeline should be always covered by milestones.

2. Before we had the ability to complete milestones. But now it looks like we just create them and they show the progress without us marking them as complete. As a result, now milestone can be delayed. Even if didn't finish the job for milestone it would just show that next milestone in the process using today's date. Only the milestone can be marked as delayed because there is no next milestone.

[maxceem]

3. When we edit milestone we have 3 buttons to go "back":

   • back
   • cancel

   • close

     When we click "back" or "cancel" we should go back to previous screen where we show timeline. But what happens when we click "close" button? Usually, this button supposes to close the work and bring us back to the Dashboard page. Should we also close work and got to Dashboard from here?

   

[maxceem]

4. What should be the possible values for milestone type. I see the next list:
   • phase-specification: Phase Specification
   • community-work: Community Work
   • checkpoint-review: Checkpoint Review
   • final-designs: Final Designs
   • final-fix: Final Fixes

[maxceem]

5. @vikasrohit so far I'm aiming implementing timeline with milestones editor just with a manual way to control it. And after we would automatization for the timeline based on the challenges/task which I think should be done, as per the document you've shared with me.

[vikasrohit]

Sorry @maxceem it took time to reply to the queries.

1. It is tricky and I think it is most confusing part for timelines as well because there are multiple ways people read a timeline and milestones. Most of the time milestone in a timeline is just a point, while we treat them as timespan on the timeline. So, it makes things more difficult to understand. For now, I think we can create a timeline without any milestone at first. And when user add a milestone, it would start behaving just like we have it right now. The only confusion with this way is that we have only one label of a milestone while when we have only one milestone in the timeline, we can show only one label either at start of milestone or at the end of it. May be we can always show the milestone title at the start and always label the end of the timeline as COMPLETE (with no option to edit it). User can edit the first milestone's title to be START or ROUND1 as per requirements. Other option is that we can add one default milestone Complete by default when the first milestone is added so that user can edit the text of the last milestone to DELIVERY instead of COMPLETE.

2. I think your assumption and strategy mentioned in point#5 is good and what I would have suggested as well.

[vikasrohit]

3. Lets close the work card on close icon click.

4. Although the only milestone type I can see practically being used in new UI is design-review (checkpoint-review or final-designs), lets keep the support for all existing ones as is.

5. Agreed. I think we need to have the buttons for manual control of milestones even after automation.

[maxceem]

@vikasrohit from your input on Slack:

Yep, I wanted the lifecycle of milestones to be controlled via backend so that caller of the API does not let the milestones in inconsistent states e.g. two milestones having gap of more than a day or overlapping milestones.

As a result of this we should:

1. remove ability to control start/end dates from milestone edti UI, and only allow to control milestones duration:

   

2. so we only could control the Start Date of the whole work timeline by editing the start date of Work:

   

3. Also, work duration, should be non-editable and calculated based on the timeline, similar like for phases:

   

[vikasrohit]

Agreed for all 3 points. I haven't got confirmation on this behaviour from the product managers yet after I raised the question of the way we want to control the milestones (considering the possibility of leaving gaps or creating overlaps between milestones), but I think we should keep the bheaviour as we already have and as you defined above. We can revisit it later if product managers want it really in the way the designs shows it.

[maxceem]

@vikasrohit another question.

Before all the phases were initially created with timeline and milestones. So when we activate a phase, we activate the first milestone.

Now, we can create a work, activate it and only after create a milestone. So now we need a way to activate the first milestone of the work.

1. Should we let users to activate a work without milestones? - I think yes.

2. If we have active work and later we add milestones. As soon as we have active work with at least one non-active milestone we can show a button to Activate the milestone like this:

   

   • Note, that such button will be shown only for the first milestone. The rest of milestones would be activated automatically when we complete the previous milestone.
3. To confirm. If a work already has milestones. Should we activate the first milestone automatically as soon as we activate the work? (same like we do for phases).

4. I think if there are no active milestones, there is no sense to show the current progress like this:

   

   Instead we should show timeline without progress as long as there is not active milestone:

   

   The reasons for this is that it doesn't make sense to show milestones as past just because the time has passed for them if they are not yet marked as completed. Also, there is no sense to show milestone progress if it's not yet active. And no sense to show milestone as delayed if it's not yet active. Because it's just planned.

[vikasrohit]

1. I don't want to have a work being active without any milestone to be sure that we always have a timeline to show the progress i.e. I don't want to have a situation which you mentioned in the point 4. What we can do when user tries to activate a work card without a milestone, is to add two milestones, start and complete by default to the timeline and activate the start milestone. Now we can show the progress bar as well with number of days elapsed for the active milestone.
2. As said in 1 above, I don't think we need it any more
3. Yes
4. Agreed, but as per 1 above, we should not have such situation now.

[maxceem]

5. So far for milestones plannedText,activeText, completedText and blockedText are required at the Project Service. But we don't use them in the new UI. Should we make them optional in the Project Service or fill with some dummy data for now?

[vikasrohit]

5. Yep, please make them optional now.

[maxceem]

Current implementation of milestones API doesn't let us create new milestones.

When we have one timeline with one milestone, endDate of timeline match endDate for the only one milestone. If we try to add the second milestone, its endDate would be for sure after endDate of timeline which would cause validation error here: https://github.com/topcoder-platform/tc-project-service/blob/dev/src/routes/milestones/create.js#L68

Theoretically we can create a timeline without endDate. But as soon as we update any milestone, the endDate for timeline would be set automatically here https://github.com/topcoder-platform/tc-project-service/blob/dev/src/routes/milestones/update.js#L301

So we should either remove validation, or remove automatic timeline endDate updating, if the endDate of timeline is null.

[vikasrohit]

I think getting rid of validation https://github.com/topcoder-platform/tc-project-service/blob/dev/src/routes/milestones/create.js#L68 is going to work for us better. I don't see any negative of removing this validation. But we can keep the logic of updating the end date of the timeline https://github.com/topcoder-platform/tc-project-service/blob/dev/src/routes/milestones/update.js#L301 and in fact we need to update the end date of the timeline now when a new milestone is created which has end date outside of timeline.

[maxceem]

@vikasrohit I've removed the validation during milestone creation as a quick solution in the next commit https://github.com/topcoder-platform/tc-project-service/commit/e54c7ba3d3a6e140355b421baae37d65608dcd27

But now we have to implement updating endDate for timelines during milestone creation, as for now we only have this functionality during milestone updating https://github.com/topcoder-platform/tc-project-service/blob/dev/src/routes/milestones/update.js#L301

I think this functionality is not critical, as we don't really use timeline.endDate so I've logged a separate issue for this https://github.com/topcoder-platform/tc-project-service/issues/378

[vikasrohit]

Yes, we need to update the endDate of the timeline when creating milestone. And agreed that it does not seem critical for now to have the end date of the timeline updated because the place where it was used is the validation which we just removed.

[maxceem]

Few notes about current implementation:

1. If we create work with status = In Progress or if we change status of existent work without milestones to In Progress we automatically create two milestones and make the first one active.
2. If we change status of work with milestones to In Progress we active the first milestone.

3. When we add a workItem, we automatically add milestones associated with the related product template. For example, search for challenges with name containing web design and add one. It should add 4 milestones per next milestone templates:

   

4. For now milestones only support dates up to one day. We always reset hours, minutes seconds and milliseconds. This leads to the fact, that we cannot show continuous progress bar, and we can only jump day by day. I think this is not what users are expecting to see. Also, if we are planning for wider usage of timelines, such day granularity would be not enough.

[vikasrohit]

Thanks @maxceem for the updates.

I think day granularity is okay for now until we get more requirements.