[RFC] Task Levelling new flow

[vinayak-trivedi]

Current flow

• currently, the user marks their task as complete from status and they get options to whether they want a new task or not
• if the user clicks on don't assign task button then they are not assigned a new task and their task is marked as complete
• if they click on continue then the tasks/assign/self API is called which checks if the user has a status idle and then assigns them a task based on their skill levels

How is it decided which task should be assigned to the user?

• we take the skills of the user and then give them a task up to +2 level of that user's skill
• if the user doesn't have a skill then we get any task that is less than level 2 and assign them that task
• once the task is assigned we update user status to active

What happens if there is no task available based on user skills or no task that is less than level 2?

• The user has an option of fetching a task in the future for themselves by using a fetch button that is provided to them on my site only if they don't have an ongoing task, otherwise, the button will not be visible to them
• The super also has options of assigning tasks to users from the dashboard site, they also get suggested users based on the category of task that they have selected there

current Flow diagram

New Flow to be done

• we need the flow to be in such a way that the user is not automatically assigned a task, there is a request that they create, which gets shown on the dashboard site and needs to be approved by the super user and then they are assigned that particular task
• one thing that we can add to it is that we can check if the user has added any skill that they want to learn and assign them those tasks
• we will change the API from tasks/assign/self to tasks/request
• a task is fetched for them the process is same as the old flow, except those task will not be directly assigned to them, a request for that will be created which needs to be approved by super user once the super user approves that request then they are going to be assigned that task

Requirement

• create a new collection taskRequests
• give the super-user a dashboard once they approve
• a new status needs to be created for tasks i.e reserved or something else

New flow diagram

[ankushdharkar]

@vinayak-trivedi Great work. Looks good to proceed with.

A couple of things to look at:

• Collection name should be updated to match our conventions.
• Tasks should be fetched based on user's skills and levels.
• Last step of the flow chart seems unclear. There will be a delay between when the task is marked RESERVED, and when superuser approves it on the dashboard. Will this still be part of the same flow?

[vinayak-trivedi]

1. will change the name for the collection
2. got it, that is how we are going to do it, I am suggesting that we are taking some data from the user about what they want to learn, we can use that as well
3. makes sense will update that

[vinayak-trivedi]

@ankushdharkar I thought about the third question I think, this flow should contain flow of all the things which are happening once the user tries to fetch a task for themselves, the approval from super user shouldn't be in this flow, let me know I am wrong

also what convention are you talking about for the collection name

[ankushdharkar]

@vinayak-trivedi For the first iteration (and a long time after), superuser will be involved in task assignment confirmation. So, the flow that provides an approval workflow for superuser needs to exist.

what convention are you talking about for the collection name

We don't camel-case the names for collections (taskRequests ❌). Do we have any other collections with two words in its name?

[vinayak-trivedi]

• added in the flow
• we do have some collection which are camelCased, e.g: usersStatus, itemTags

[ankushdharkar]

we do have some collection which are camelCased, e.g: usersStatus, itemTags

This makes me sad :(

[TanishqSingla]

I want to work on this task

[TanishqSingla]

Updated implementation

Upon various rounds of discussions, following changes were made to the implementation

Task Request Model

{
  approvedTo?: string;
  id: string;
  isNoteworthy: boolean;
  priority: "LOW" | "MEDIUM" | "HIGH";
  purpose: string;
  requestedBy: Array<ProtoUser*>;
  status: "WAITING" | "APPROVED";
  title: string;
  type: "feature" | "bug"
}

Approach

• A single task request will be created which will correspond to the task
• Multiple users can request for a task with a limit
• If a task request already exists then the server will validate if the request is a repeat request or a new user has requested. In case of new user it will update the requestedBy and add the new user to the field
• Superuser can fetch tasks, which will be viewed on a dashboard
• Superuser can approve task request, and while approving superuser also select the user who's being approved. The approvedTo field will get updated with the username of assigned user.

* Proto user is a sub-model of user containing relevant info to display on frontend.