[Connect 2.5] Workstreams - Basic Features

[maxceem]

For the first step of implementing Workstreams we can start with the basic features and common structure:

• list workstreams
• display work details with 4 tabs (mostly empty for the beginning)
• edit work info

[maxceem]

Questions regarding workstreams list:

1. Currently, workstreams can be only created by admins manually. So all the new project wouldn't have workstreams. Should we implement some logic server-side, so for some new projects Workstreams would be created automatically? And what kind of logic would control it?

2. Every Work card has a short description under the name

   

   1. At which moment we would define this short description? For now, when are adding a new phase (work) we select a ProductTemplate which has a brief field. Should this short description of work be populated from the selected ProductTemplate.brief?
   2. The ProjectPhase model doesn't have the appropriate field for this short description. There are two ways to go:
      1. Add a new brief field to the ProjectPhase model
      2. Keep short description inside ProjectPhase.details JSON, though this field is controlled by the Specification form editor for phases so not sure if it would be a good place.

3. Two last works don't show the status. Is it intentional? Or should we just show status for all the works?

   

4. Last work card has the title not bold, which goes to 2 lines without short descriptiong. I think it's just an issue with the design and we should always show the title in bold only in one line with ... at the end for long titles.

   

5. As I understand, in the design, we are showing the number of messages inside Work. And if there are any unread messages we are showing the number of total messages in red. We don't show the number of unread messages.

   

   1. Is my understanding correct?
   2. So far for phases, we are loading all the messages from the beginning. Though as we are going to introduce more places with messages in new works: "details comments", "requirements comments", "review comments", "comments per each milestone". I think it would be better to avoid loading all the messages for Works from the beginning and load them only when we need them. IMHO it's ok not to see the total number of messages inside Work. And we still can show the number of unread messages using our notifications system.
   3. If we still want to show the total number of messages for Works there are two ways to go:
      1. Just load all the messages for all the works as we do now for phases.
      2. Create a special endpoint in Message Service, which would return only the messages quantity. Such endpoint should support some complex query to count a different kind of messages which we may have inside the work.

6. I see some Work Cards have special buttons, like Create requirements, Accept delivery and Review designs. As I understand these are special button which would be shown depend on currently active WorkItems/Milestones. Pressing them would open the UI to perform that action.

   

7. Clicking Add work buttons, will open the same UI as we have now for adding phases. And it would add a phase to the relative Workstream.

   • Customers cannot add Works In pre-packaged solutions, only copilots and above.
   • Customers also can add Works in prepaid budget/TaaS solutions together with copilots and above.

   

[maxceem]

8. On the work Requirements tab we are showing the requirement text editor. You've suggested to add a new field to the ProjectPhase model.
   I'd like to confirm that we should add a new field to the model, rather then reusing details field of ProjectPhase. Though it may have drawbacks, as details field is currently controlled by the Specification form editor for phases.
   So we can agree on the best way to store requirements and description (which has been mentioned in question 2). Create new fields for them or store them inside details.

   

9. We have some logic for the status of the phases. Should we keep the same logic for works?

   

   1. We cannot choose Delivered status and show a Tooltip that it's controlled by milestones.

      

   2. When we choose In Progress we show a confirmation dialog, that once phase is In Progress status cannot be changed manually.

      

   • Once the status has been changed to In Progress, it cannot be changed manually after and is shown in a read-only way.

     

10. I see that we have edit button for works similar like we have for phases. But there is no new design for the edit form.

    

    1. Should we show the same form as we are showing now for phases when we click edit?

       

    2. We have an UI for editing milestones, I guess we can combine these two UIs to implement UI for editing works, right?

       

[vikasrohit]

1. We need to create work streams at the time of project creation just like we are creating phases as of now. However, going forward with v5 standards, I guess we should create phases/workstreams (or any other related entities) via bus event consumption. In any case, the creation of phase or workstream would depend on the way we decide for determining the way as we are discussing in 10 point of [Connect 2.5] Workstreams #3170 (comment)

2. Lets add a description field in the phase model

3. For now show the status for all work cards. It should not be difficult if we want to get rid of status for some particular status.

4. Yes, assume all cards to be the same. I don't see any reason of having different style for this card.

5. I am not sure what was the intent of the designer here. But for now, just show the total number of unread messages as we are doing as of now. No need to show that grey icon with count. We just need red icon with the count of unread messages.

6. Yes, your understanding is correct. I would like to think for having some kind of generic logic for handling such action items. We might create a first class object in backend or if that is just overkill, we might create action item as component in front end and have a generic logic which can identify the list of action items from the current state of the Work and its milestones. It was just an idea, it might not be needed at all. 😬

7. We don't need to show the template selection UI for work now. We show the product templates in this catalog UI which is essentially mapped to the first product of the phase as of now. However, as with new work management, we are going to use products for work items, we would need product templates when adding work items. I think we need a screen where we ask for basic properties of a work card OR for now we can just give some default name and description to a new work card.

[vikasrohit]

8. I think adding a new field to the model for requirements is better for now. It should not be difficult to move this field to details JSON if required. I am trying to avoid using details until we have complete picture of new work and old phases.

Though it may have drawbacks, as details field is currently controlled by the Specification form editor for phases.

I don't think we are storing any thing in the phase's details JSON, or are we? I am under impression that we are storing the answers of Specification tab of a phase, in phaseProduct's details JSON.

9. Lets not put any of the validations for status of a work. Keep them as is for Phase components though. So, old projects should have same behaviour while new projects with work cards, should not have any validation of status changes for now. We need to clarify the status automation for work card with product team.

10. We have an UI for editing milestones, I guess we can combine these two UIs to implement UI for editing works, right?

Yes. Just to be consistent, don't apply the new styles of the form components. I mean I can see the field label overlapping with the actual field which I think is tricky and I don't want to introduce yet another UI for the form elements.

[maxceem]

Thanks, @vikasrohit.

1. Regarding creating worksreams during project creation and versioning.

   1. I like the idea of having some flag in details property to define whether we should use phases or workstreams. Maybe for such project "features" we may have some reserved place inside details, like details.featuresSupported = { workstreams: true } or details.settings = { workstreams: true }.

      

      Keeping this thing in ProjectSettings feels more complicated. Also, we would have wait for project settings loading before render the project. And in general ProjectSettings feels like something users would control and change manually. While such things like whether to use phases or workstreams should be defined automatically and not changed manually.

   2. The second question is. Should we create all new projects with support of workstreams instead of phases?

   3. How we would determine:

      1. What kind of worksteams to create?
      2. Would be there any default works in workstreams?

[vikasrohit]

1. i) Keeping it in project settings might be better because if we keep these settings in details we have to make sure that no one, except admins, is able to update those fields by making simple PATCH requests which I think might be coupling the JSON structure tightly with project's behavior which is not that problematic, though. And if we keep it in project settings, we would keep such settings as admin controllable only and I think we have to any way write logic for having admin only settings for markup settings, so it might be just reusing that logic for controlling the access to settings which can control the projects' behavior for all users.
   Having said that, I am still open for any of the approaches, we just need to find more positives in one of them. 😬

ii) Yes

iii ) a) Workstream types would be determined by the deliverables of the project. I guess, we can keep a field in the template's planConfig which can keep mapping of the template's question and its options which determines the workstream types. For old templates or even for new templates which does not have such mapping available, we can keep the project plan empty i.e. no workstream OR may be we can have a generic workstream type which we can created for such templates.
b) No. By default it would be empty.

[maxceem]

@vikasrohit as we don't yet have ProjectSetting model implemented, to not depend on the backend I propose to use details.settings = { workstreams: true } for now. At the server-side and client-side. And meanwhile, we could think more which way is preferred. And change it after if needed.

[maxceem]

@vikasrohit that's a good catch regarding planConfig. Our current planConfig in the template is referring PlanConfig with config.

And config for now contains the list of phases like this:

{
  "phase-id-name-1": {
     "product": {
        "id": 1
     }
   },
}

[vikasrohit]

to not depend on the backend I propose to use details.settings = { workstreams: true } for now.

Agreed.

for planConfig, I think we are no longer need to specify the phases in the config for new project templates, we just need that to support old projects templates. So, we might use that config variable as per our needs for new templates.

[maxceem]

@vikasrohit that's a good idea regarding planConfig.

I would propose to add a property workstream inside planConfig.config:

{
   "workstreams": {
      // which field name to use 
      "formQuestionFieldName": "details.appDefinition.deliverables",
      "workstreamTypesToFormQuestionValues": {
          // keys are types of Workstreams
          // values are arrays of possible values of question which would trigger including such a Workstream
          "development": ["dev", "dev-qa"],
          "design": ["design"],
          "deployment": ["deployment"],
          "qa": ["dev-qa"],
      }
   }
}

What do you think?

[vikasrohit]

Looks good to me.

[maxceem]

11. @vikasrohit previously we've discussed that we should be able to complete any milestone manually. Where to put such a button to complete the current milestone in work?

    As per my understanding, we can put them in two places:

    1. Each Work in Workstreams list on the dashboard should have Complete milestone button if it doesn't have some special button like Start review and so on. So the default button here can be Complete milestone. When we click on it, we can show confirmation popp and ask user if he is sure. If sure, then we mark as complete. The disadvantage of putting such a button here - is such a common button doesn't have any information of what kind of milestone we are completing, so probably it shouldn't be here.

       

    2. The second place on the Details tab of Work.

       

       We can always show here the current milestone name, activeText and button to complete it if doesn't have another special button.

    Should we show in both places or only one of them? Or you have another idea where to show it.

[vikasrohit]

I think we do need the special buttons as shown in designs for a work card (collapsed form) depending on the type of active milestone and role of the user.
We don't need the default button to mark current milestone as complete on the work card (collapsed form) itself.
For the details tab, I think we should have designs for every possible milestone type when it is active and we should show that design by default below the timeline along with the name, activeText etc. We don't need another button here to open the UI for actionable item. For example, when a design work milestone is active, we can show the Input Design Works on the collapsed work card as a quick action and on the details page, we can the UI to add the design work directly below the milestone activeText (in your suggested UI). And it would be visible only for the users who has permissions to upload the designs. Customer would see only the milestone name and text.