---
title: Clickup-Github Automation Discussion
tags: daohaus
---
# Discussion: Clickup - Github Automation

# 1. Objective
This document aims to list and discuss the different approaches towards task management in DAOhaus to support further community contributions of dev work.

This should help decide on the process and platforms for task management that works well internally within Magesmiths, as well as external contributors

# 2. Where are we now?
Currently, CU works well as the main hub for task management within magesmiths.

However, as we start to get community contributions, task management becomes not just for internal magesmiths, but external contributors.

In view of this, a good task workflow should do the following:
(A) Task management: track status, assignees and progress of tasks (currently done on CU)
(B) Task display: Surface tasks to **anyone outside of DH** (currently done on GH)

The current CU / GU combination is great for a MVP process, as we see tasks being taken up and completed by external contributors. However, moving forward, the current set up might create some issues:
1. Additional project management steps to manage 2 task boards & synchronise information
2. Information inconsistencies and miscommunication between 2 task boards.

# 3. How to move ahead?
To move ahead, we should reach a process / workflow that
1. Works well internally for magesmiths and new contributors
2. Minimises project management steps to manage task boards
3. Minimises information inconsistencies among parties

Drawing on previous discussions, there are 2 approaches to this:

## 3.1 Continue CU/GH hybrid, but improve synchronisation with automation

The recommendation here would be to

| | Action Point | Rationale |
| --- | ----------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| 1 | Continue CU as the hub to manage tasks within magesmiths | It works well now and we want to minimise unnecessary changes |
| 2 | Continue GH as the “task/bounty board” for everyone outside of magesmiths | It kind of works now and is how most other OSS / Web3 projects create and solve issues with external contributors |
| 3 | **Create automation to synchronise information and status updates** between CU & GH when issues are created or closed | Automation serves as the glue to minimise manual work and information inconsistencies |

Ideally, 80% of the tasks which are created and fixed internally would be unaffected (i.e. still running through current CU process). The remaining 20% of issues created and/or fixed externally will be solved via automation.

**This achieves all 3 objectives and has the flexibility to move to a full CU model (option 2) since CU is still the hub for task management with GH as the display component.**

## 3.2 Do everything on CU
Another model explored was to **do everything on ClickUp** (i.e. today's task management, but layer on the display of tasks as well). Based on previous discussions, we will create a **publicly viewable list of tasks** for contributors to claim and complete. When external bug-reporters want to open issue, we will use **CU's form functionality to collect inputs**.

| | Action Point | Rationale |
| --- | ----------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| 1 | Continue CU as the hub to manage tasks within magesmiths | It works well now and we want to minimise unnecessary changes |
| 2 | **Use CU as the “task/bounty board” to surface tasks** for everyone outside of magesmiths | House everything within 1 platform (CU) |
| 3 | **Create a CU form to create new issues** | Close the loop of reporting issues on GitHub |

This approach would also achieve all 3 objectives stated. The upside here is definitely in having **all the processes and information within 1 platform, making it easy for the magesmiths to manage and have visiblity**. Also, without the automation efforts, **less engineering time and effort is dedicated here.**

**However, we would have to create some user education / edit to docs on Github Repos to get bug-reporters and contributors to use the new CU flow, instead of the Github Issues -> PR flow they are used to.**

# 3. Discussion / Recommendation

==Up for Discussion==