connect kanban to a GitHub

[aayu5hgit]

@JapneetRajput @Drew-Macgibbon Here, we have thought of a following approach, let us know if this is the right path

• Step 1: Store the user feedback in the supabase table
• Step 2: Fetch the feedback data from supabase and display it on the kanban

@Drew-Macgibbon after these steps, we need you to provide us some clarity on how can we connect the kanban to GitHub (Clarity as in terms of what and how the data should be passed to GitHub and the process that we will be following thereafter)

[Drew-Macgibbon]

@aayu5hgit @JapneetRajput

In the spirit of minimizing complexity we should focus on updating data from a single side. Because we HAVE to allow users to create feedback without requiring a GH account (in our app) that decision is made for us.

So all our interactions with this GH project board will be done programatically. It should be fairly simple actually, we just need to listen for these events then create/upsert with the GH API.

Feedback Events:

• Approved: New GH issue created in backlog
• Updated: Update changed data on GH (status, category, title, body)
• Completed: Close issue on GH
• Commented: Add comment to GH issue, Future Task
• Anything to add?

This does not mean we cannot interact with the GH issue directly, just that they will not be tracked in app; so we would need to think about acceptable actions. This can also be considered a benefit, as we know every action in the app is public, whereas comments created directly on the issue would be more for private/internal discussion.

We may include two way data binding in the future (if we turn this into a paid application), but it does introduce many challenges.

Two-Way Data Binding Challenges:

1. Conflict Resolution: One of the biggest challenges with two-way data binding is handling conflicts. If changes are made to data on both sides (GH and your app) before synchronization happens, how do you decide which version to keep? You'll need to have some logic or manual intervention to address this.
2. Data Integrity: Consistency between GH and your app is crucial. If there's a failure in communication (e.g., the GH API is down or your app encounters an error), you might end up with discrepancies in data.
3. Rate Limiting: The GH API has rate limits. If your application has many users or frequent data changes, you may hit these limits, causing some operations to fail or be delayed.
4. Event Sequencing: You'd need to ensure that events are processed in the correct order. Imagine if a comment was added before an issue was created due to some lag – it would result in an error.
5. Data Mapping: Your application's data structure and GH's might differ. This means you need robust mapping logic to ensure that the data syncs correctly between the two.
6. Redundancy and Duplication: If not handled properly, you could end up creating duplicate issues or comments.
7. Security: The more connections and interactions between systems, the more potential vulnerabilities. Ensuring that the data flow is secure and encrypted, and that only authorized entities can access and modify data is crucial.
8. Additional Complexity: The more features you add (like listening to GH events), the more intricate your system becomes. This might make debugging harder and potentially introduce more points of failure.