Add table teams and FK in table users

[apiraino]

This is in preparation of more upcoming work discussed with compiler leads (David and Boxy). They would like a triagebot command to record meetings with team members, so there will be the need to filter users based on team membership.

We don't yet a teams table, I thought to create one as a first step instead of hard-coding this information in other tables. I am not sure how far that would take us.

The SQL statements should be completely idempotent.

Let me know if more context is needed, I've kept the description short here :)

r? @Urgau (but anyone else is ok)

thanks!

[Urgau]

What does it mean to "to record meetings with team members"?

r? Kobzol (as you probably know more than me about your DB)

[apiraino]

What does it mean to "to record meetings with team members"?

right, sorry that was really not enough context: the final goal is keeping a register of when 1:1 meetings with team members happened for bookkeeping purposes and build a querying tool to find out f.e. who are the team members with whom team leads had a 1:1 meeting long ago, therefore reschedule another one. Since team members wear many shoes, it could be useful to split them by team.

(That opens the question about how to keep this table updated: I thought about a cronjob with the info the triagebot already has from team_data).

Hope this helps!

cc @davidtwco (if you want to add anything)

[Kobzol]

Hi, I'd like to learn more about this. I'm planning to upstream my student's CI dashboard work to triagebot eventually, which also models team relationships and users. So we have some experience what does and doesn't work 😁

Some notes:

• Having a FK in the users table is not the right model, because the mapping between users and teams is M:N.
• The team DB is the source of truth, so our tables have to only act as proxies for the team data. In other words, whenever we receive new data from the team API, we have to update the team tables. Either incrementally, or simply by nuking the table and rebuilding it from scratch (which is what is done in the CI dashboard).
• We should think whether we want both a team table and then another team_user M:N table, or just the latter one. Depends on what is the uce-case.

In the dashboard, we chose to put the team (and git) data into the DB in order to have a unified layer where we could write queries that work with team, git and GitHub data together, which is quite powerful. But if for the use-case of t-compiler that is not needed, then we can start with simply combining data from the team API, and then store some custom state in our DB, without necessarily having a team table.

So I would first start with examining the whole design first, rather than landing a separate table before the actual use-case, so that we won't have to rework it later (DB migrations are always a bit annoying to deal with).

[apiraino]

@Kobzol do you have a concrete plan (i.e. a timeline) for the DB changes? I may wait on your dashboard to be merged but before anything my first thought is what do you mean by "eventually".

I'll bring the discussion about the design I mention on Zulip (works better).