What information/data do we want about issues?

[Cleop]

From #1:

I need a backup of GitHub issues
so that I can work "offline".

Thought it might be good to start creating a list of fields that we want about the issues. I know that some work has already been done using the github API and issues in https://github.com/dwyl/tudo so maybe thinking about the fields will help us see if what's been done there is of any use.

So far we've discussed the importance of recording:
History of:

• Comment text
• Comment author
• Comment time/date
• Issue title
• Issue description - not sure if this is a different field to comments or if they're considered the same

Are these sufficient for now as an MVP starting point?

Or do we need to record info like commits on an issue, labels, assignment or associated milestones? Or even more github detail?

[nelsonic]

@Cleop this is a great starting point. We can always add to it later. 👍

[Cleop]

@nelsonic - for the first iteration do you think we should include/exclude comments/reviews on PRs?

[nelsonic]

@Cleop yeah, for the first iteration we only want to capture the changes in issues comments.
That is more than enough to get started with the rest of the plan. 👍

[Cleop]

My proposed schema

Users
ID
Github handle (called 'login' on the payload)

Organisations
ID
Organisation name

Repositories
ID
Repo name

Issues
ID
Github-description ID
Issue number (from github)
Author ID
Updated at (time/date)
S3 url for description
Repository ID

Comments
ID
Github-comment ID
Author ID
Updated at (time/date)
S3 url for text
Issue ID

The github-comment ID is the ID which will be unique to that comment but will be kept consistent throughout the different versions of that comment. Whereas the primary key will be unique for each version of the comment.

[nelsonic]

@Cleop this looks good as a starting point. 👍

[SimonLab]

I think we need to save the s3 url of the file in the database for each edit of the issues and comments.
I was thinking a structure like the following:

I think having the "history" tables make it a be easier to track all the edits of the issues and comments. The tables issues/comments only save the main information

[nelsonic]

@SimonLab agree that we need to have a "history" table.
But it's unclear (to me) what the distinction between issue_history and comment_history is.
Also, I think all comments should be in the comment_history table even if there are no edits to it.

[SimonLab]

agree we can create only one "history" table where an entry of this table can refer either to the issue or to the comment table. As soon as a new issue or a new comment is created the history table will have a new entry wich will also contain the url of the s3 file.

[Cleop]

Closing this as we're now recording all of the data in the description of this issue.