Cleaning task Object.

• Removing the assignee and other keys regarding a task assignment will significantly clean the task object. This will help us to store the data in the task which is only related to the task, most notably our application logic will not reside in our task object.
• What we can do instead is to create a different model like Assignee Ticket, which can store which task is assigned to which user as well as their progress for the same and the submission date for the task.

Pros

• We would not have to run APIs to unassign a user of a task.
• We would be doing fewer I/O operations on the task object.
• Better entity relationships, as well as we can track the past assignee of a particular task as well their progress for the same. Like in the Assignee Ticket we will hold the PR link that way even if they leave the task their progress can be carried forward with a different user.
• Clean task object

Cons

• The biggest con would be as the whole system is already built on this including the frontend applications, therefore making such a drastic change will break the majority of the codebase.
• Will force us to write our tests again.
• Will consume a lot of time debugging after the changes.

Proposed Solution.

Versioning

• Only at the backend but we can do versioning of our APIs and then later on push this to frontend sites one by one.
• Everything will have to get tracked first to the minute detail for this to happen properly.
• We should have already versioned APIs by now as that is really going to help us to release beta features without breaking the major codebase.

No files, tests, or entry points are named. Start by inventorying the task assignment fields and their backend and frontend consumers, then assess the proposed Assignee Ticket model and API versioning approach. Done would require an agreed migration scope, updated consumers, and passing tests across the affected system.