integrate with GitHub

[josh-chamberlain]

We'll use github to communicate about requests. This integration allows us to create issues, and read their status from the app.

• here's a project. We will pare down the potential status options before we migrate.
  • we can use github Projects and Labels to keep things organized in a way that can sync to our db
  • new requests should get a github discussion, but admins might need a way to manage their details and vet them for the time being
    • maybe we use github discussions to prevent new ones from being created except through the app
    • maybe there needs to be a retool middle layer, like data source approvals, for moderating these before they're public
    • discussions are kind of higher level research questions, and issues are tasks within them. discussions don't have project management. if we use discussions, we need an orderly way to extract the requests from them—especially for simple cases where 1 request → 1 discussion → 1 task → response, we want to cut the noise a bit.

[maxachis]

* maybe they go into a private repo at first, and get moved into a public repo when they're ready for volunteers

One option is to utilize GitHub discussions, which would enable us to review and discuss data requests before converting them to an issue (which can be easily done using Discussions functionality). GitHub discussions, as I understand it, is tied to the visibility of the repository it is connected with.

Still, having them exist as discussions allows us to refine and potentially talk more with the request provider before converting it to a distinct issue, and avoids having to maintain two separate repositories. We can set it so that users with read access can be disallowed from creating discussions.

At the very least, I think it's worth playing around with to see whether it can work for our purposes.

[josh-chamberlain]

@maxachis I like this idea. In particular, blocking people from creating a new discussion except through the form, which we can't do with issues. It's set up to encourage community involvement and more appropriate from an abstract terms/functions perspective. Either way, I set up discussions for the repo to give it a fighting chance.

misgivings:

• we don't really need to silo these any more, because they're already in their own repo + project
• the discussion doesn't convert to an issue, it creates one—then there are two conversations to track. we could automate this problem away, maybe.
• it'd be nice to talk to the user before we make an official issue out of it; but a discussion is still not private. I don't like my private repo idea. i think a retool middle layer for processing requests could make sense here the same way it does for approving data source submissions.