ClickUp: Task management system
Task management systems
The main place where we manage tasks and their current statuses is on ClickUp. We use the following systems to manage and hold information about tasks and support tickets:
- ClickUp (main task management system)
- Fluent Support
- WordPress Support Forums
- Github issues and pull requests
All tasks related to the Fluid Checkout plugins are managed in the ClickUp Workspace “Fluid Checkout”.
ClickUp tasks lists
The Fluid Checkout workspace is separated into tasks lists which are described below. Depending on your role in the team, you might or might not have access to all the tasks lists.
How tasks are organized
Tasks on ClickUp are organized in lists, which are by default broken down into groups of tags added to the tasks.
Other views are also available and you are welcome to explore and create new views if it helps to keep yourself organized.
Explaining what each view type of ClickUp can be used for and what is possible to do with them is not part of this article. If you want more information please search in the ClickUp documentation directly (link).
The Fluid Checkout workspace is separated into the following tasks lists:
| List | Description |
|---|---|
| Support tickets | This is the list where all support tickets, support topics, github issues and pull requests are concentrated. Any task that was originated by a customer will be on this list. New tasks are automatically added to this list whenever a ticket, topic, issue or pull request is created on the other systems. |
| Sprint MM/YYYY | There are usually two of these lists available, the current sprint and the next spring. Sprint lists are used to organize which tasks will executed during the 4-week period of that sprint. Tasks in this list might be related to new features, compatibility with other plugins and themes, or other tasks that were originated by the team members. It might also contain some tasks from the Support tickets list when appropriately scheduled. |
| Backlog | This list contains all tasks, usually originated by the team members, which will be considered in future sprints. |
| Marketing | This list contains all marketing related tasks. These tasks might also be added to Sprint lists when appropriately scheduled. |
Automation of task creation from other systems
Whenever a ticket, topic, issue or pull request is created on the other systems, a new task will be automatically added to the Support Tickets list on Clickup.
Tasks created automatically from other systems have the following prefixes:
| System | Task name prefix |
|---|---|
| Fluent Support | [fc-support] |
| WordPress Support Forums | [wp-support] |
| Github | [github] |
The automations work by forwarding or sending emails directly to the ClickUp list email address.
| System | Automation details |
|---|---|
| Fluent Support (web) | Sends emails directly to ClickUp when the new task is not yet assigned to any support team member. |
| Fluent Support (email) | Whenever a customer sends an email to [email protected], the email message is forwarded to the email parsing service from the creators of Fluent Support which in turn calls the website API and creates a new ticket, which triggers the email messages as explained in the item above. |
| WordPress Support Forums | Emails notifications of new topic of responses to topic sent from WordPress Support Forums to Diego’s personal email associated with his account on that platform are forwarded to ClickUp according to the filter settings. The email filter will compose the ClickUp task title and set the assignee to the support team members. |
| Github | Tasks are created on Clickup when a new issue or pull request is created on Github by an automation task via Zapier. |
ClickUp task status
The main place to check and keep the status for a specific task or ticket is ClickUp. Every task on other systems must have a corresponding tasks on ClickUp.
What each status mean and the corresponding status on other systems are mapped below:
ClickUp task status: what each status is used for
As our main system to manage tasks, keeping the status and priority of tasks on ClickUp update is of utmost importance.
Although new tasks will be created automatically, it is not currently possible to automatically update the status of tasks on ClickUp when the status of those tasks change on other systems.
ClickUp tasks in all lists can have the following statuses:
| Status | Description |
|---|---|
| To do | New task added to the list, whether manually or automatically created with automations. No work has been done yet and the task most likely do not have someone responsible for it. |
| In progress | Work on the task has been started by it’s assignee. The task should be completed before the assignee starts working a new task. |
| Pending | Work on the task has been started, but the assignee had to stop working on it for some reason. After finishing the task currently “In progress”, the assignee should get back to this task and complete it. |
| Oh hold | Work on task has been stopped because the assignee cannot proceed with it. Usually the task would be set as “On hold” if we are awaiting for a customer to send more information. |
| Need changes | The task has been analyzed and changes are needed (usually in code), however, it has been postponed to another sprint or time. The “Need changes” status takes precedence over “On hold” for the cases where we have already identified changes that needs to be done but we still need information from the customers. Tasks on this status should have a priority, a time estimate, more details about what is expected to be done in this task and the relevant tags added. |
| For review | Work on this task has probably been completed, but a review from another team member is needed before completing the task. When setting a tasks as “For review”, you should also remove yourself from the task and assign the task to the team or team member that needs to review the work. After completing the review of the work related to the task, you should either close it as completed or remove yourself from the task and assign the task to the original assignee. |
| Done, awaiting release | The task has been completed and the code has been merged to the next version branch. After releasing a new version, the support team will contact the relevant customers telling them the new version is available and then complete the task. |
| Complete | All work on the task has been done and no more work is needed. The task is then archived for future reference. |
Task statuses in relation to other systems
Fluent Support
Fluent Support is the support tickets system we used on our website. Customers of the Lite or PRO versions of our plugins can use this support channel.
Support ticket statuses on Fluent Support can only have the following task statuses:
| Status | Description |
|---|---|
| New | New support ticket received. We have not yet replied to the customer with an initial response. |
| Active | We have already replied to the customer at least once. The ticket will stay at this status until work on it is completed and the ticket is closed. |
| Open | This status serves as a grouping of tickets that has not been closed yet. This is more useful as a filter than a status in itself. |
| Closed | All work on the ticket has been completed and no more work is needed. The ticket is then archived for future reference. |
ClickUp status translate into the following on the Fluent Support system:
| Status | Corresponding statuses on Fluent Support |
|---|---|
| To do | New, Open |
| In progress | Active, New, Open |
| Oh hold | Active, Open |
| Need changes | Active, Open |
| Pending | Active, Open |
| For review | Active, Open |
| Done, awaiting release | Active, Open |
| Complete | Closed |
Tasks created from support tickets on the Fluent Support system have the prefix [fc-support].
WordPress Support Forums
The WordPress.org Support Forums do not support different topic statuses. The support topics can only have the following statuses:
| Status | Description |
|---|---|
| Open | The support topic was created and might even have been replied to by our team. Topics will remain at this status for as long as it is not resolved in one way or another. There is no indication of the status of support topics that are still open. If they are not marked as “Resolved” then they are still open. |
| Resolved | All work on the support topic has been completed and no more work is needed. The topic then remains available in the WordPress Support Forums for an indefite amount of time. |
ClickUp status translate into the following on the WordPress Support Forums:
| Status | Corresponding statuses on WordPress Support Forums |
|---|---|
| Complete | Resolved |
| All other ClickUp statuses | Open |
Tasks created from support topics on the WordPress Support Forums have the prefix [wp-support].
Github Issues and Pull Requests
Github is used as the code repository for our plugins and other code libraries.
Any user and other developers can create issues or send Pull Requests with changes to the code for the Lite plugins. For our PRO plugins, only authorized developers have access to it and can send Pull Requests when changes are done to code which need to be merged into the main branch.
Github issues
Github issues tracking system can only have the following statuses for issues:
| Status | Description |
|---|---|
| Open | The issue was created by a user of the plugin and work and replies to it might have already been done. Issues will stay at this status for as long as it is not closed in one way or another. |
| Closed (as resolved) | All work on the issue has been completed and the problem was resolved in one way or another. This could be when the changes to the code has already been merged and an update is available, or when a question has been answered satisfactorily. |
| Closed (as not resolved) | No more work will be done on this issue because we cannot reproduce the issue or won’t make the requested changes. |
ClickUp status translate into the following for Github issues:
| Status | Corresponding statuses on Github |
|---|---|
| Complete | Closed (as resolved), Closed (as not resolved) |
| All other ClickUp statuses | Open |
Github Pull Requests
Github also has a separate section for code Pull Requests, which will also have a correspondent task in ClickUp.
Pull Requests can have the following statuses:
| Status | Description |
|---|---|
| Open | The pull request was created by a developer and work and replies to it might have already been done. Pull requests will stay at this status for as long as it is not closed in one way or another. After creating the pull request on Github, you should change the status of the task on ClickUp to “For review” and assign it to the team member that will review if for you. |
| Merged | The code changes related to this pull request has already been integrated into the main branch and no more work is need on this pull request. This status can also be considered as “closed” with the different that in this case the code was merged. |
| Closed | The code changes are rejected and will not be merged or integrated into the main branch. No more work will be done for this pull request, and in case a subset or the totality of the code changes are to be considered again, another pull request with a different number will have to be created. |
ClickUp status translate into the following for Github Pull Requests:
| Status | Corresponding statuses on Github |
|---|---|
| Complete | Merged, Closed |
| All other ClickUp statuses | Open |
Tasks created from issues or pull requests on Github code repositories have the prefix [github].
ClickUp task priority
The main place to check and keep the priority for a specific task or ticket is ClickUp. Every task on other systems must have a corresponding tasks on ClickUp. Because of that, we need to keep the correct task status and priority for each task updated on ClickUp while working on it.
ClickUp tasks in all lists can have the following priorities:
| Status | Description |
|---|---|
| Urgent | For support tickets, it means the issue reported prevents customers from completing the checkout process on our client’s websites. It can also be used for tasks which are impactful and might cause serious usability problems. In any case, task with this priority needs to be worked on as soon as possible. |
| High | The issue reported might cause usability issues on our client’s websites for main features or integrations our plugin already provides. It can also be used for compatibility issues that prevents our clients from using Fluid Checkout or other plugins. |
| Normal | The default status. The new feature or issue reported have low to medium impact on the checkout process. |
| Low | Tasks with low impact on usability of the checkout process and do not prevent our clients from using Fluid Checkout or other plugins. Tasks with this priority will be postponed and only worked on while also making changes on the same components of the plugin. |
| (not set) | (same as “Normal”) |