Does eeyore need a database?

[carols10cents]

I'm trying to limit dependencies in general, but here are some things I'm sort of leaning towards having a database for:

• Users + oauth tokens -- I'm going to try storing them in cookies first, and we'd have to store something in their session anyway to keep people logged in, have to think about this more
• Repos and whether or not eeyore is currently enabled on them
  • Pros: don't have to ask github for the repo list every time, would know immediately if eeyore is enabled or not (otherwise we'd have to check each repo to see if eeyoretriage is a collaborator and the webhook exists and is enabled, which might take a while)
  • Cons: if we cache the list of repos, we'd need a button to refresh the list of repos

[carols10cents]

• List of github users who are enabled as triagers?

[steveklabnik]

One thing that would be nice is to have a full audit log of the changes made. In theory, we could have it leave a comment in-thread, but that also adds extra noise, since github already shows this stuff:

so like, take this thread:

This could just say "eeyore added enhancement, question" and nothing more, or, it could have that, with a comment saying "changes made by @carols10cents: x, y".

It's early here, and I'm jetlagged, but I would think that you'd need a DB for the former case, but not the latter.

[carols10cents]

This could just say "eeyore added enhancement, question" and nothing more, or, it could have that, with a comment saying "changes made by @carols10cents: x, y".

It's early here, and I'm jetlagged, but I would think that you'd need a DB for the former case, but not the latter.

I think jetlagged steve mixed up the formers and the latters? ;) We'd need the DB for the audit log but not for what github does automatically, which is just showing that eeyore changed the labels? Making sure I understand too :)

[steveklabnik]

We'd need the DB for the audit log but not for what github does automatically, which is just showing that eeyore changed the labels?

If we left a comment, we wouldn't need a DB, because the log would be the comments in the issues. We'd have to leave a comment because github's automatic stuff would say eeyore, not the actual user.

If we didn't leave said comment, then you'd need to check the log to see.

[carols10cents]

OHHHHH I thought you were saying the choice was between not keeping track of the user who initiated the label change at all and making a comment saying "changes made by". I see what you mean now, that the choice is between keeping track of the user who initiated the label change in eeyore's database vs keeping track of the user who initiated the label change in github comments.

Since I was imagining this working as, say, I would leave a comment that says "@eeyoretriage add label E-easy", then you'd see eeyore change the label, having another comment after that saying "changes made by @carols10cents: added label E-easy" seems wordy. But there's currently nothing stopping me from telling eeyore to add a label then deleting my comment (nor is there record in github's interface of me having done so), which is where eeyore's comment would be useful.

So I guess that means I'm leaning towards keeping the audit log in an eeyore database? So that the normal case of non-malicious users isn't as wordy and doesn't cause as many notifications to people subscribed to the issue?

[steveklabnik]

... and I guess I was thinking that you'd be changing it from some kind of UI, rather than in github comments. But with the comments, then you wouldn't need to worry about it.... unless they got deleted, like you say.

Even "simple" projects are complex, I guess...

[carols10cents]

Which do you think is better, having some kind of separate UI or using github comments to talk to eeyore? I was kind of thinking comments because in order to triage you're going to be in the github issue anyway... but that does potentially cause more notifications, if you have to add a comment all the time. There also wouldn't be a way to triage a bunch of issues at once; you'd have to comment on each individually. Idk, tradeoffs :-/

[locks]

I want to argue in favor of using GitHub comments. It's familiar to users of bors/highfive/etc, and it seems like the lower hanging fruit.

[booyaa]

In addition to all the fine examples by @carols10cents on why we should use one. If we use postgres you can also cache any api responses natively as json. Yes you'd need a refresh button, but this is what Travis does. We could even do an overnight process.