Skip to content
This repository has been archived by the owner on Mar 14, 2023. It is now read-only.

Assigning T-team labels when highfive assigns a reviewer #146

Open
pietroalbini opened this issue May 3, 2018 · 3 comments
Open

Assigning T-team labels when highfive assigns a reviewer #146

pietroalbini opened this issue May 3, 2018 · 3 comments

Comments

@pietroalbini
Copy link
Member

It would be awesome if highfive, after choosing a reviewer from a team, assigned the T-team label of that team. This will allow scripts to easily see the assigned team, for example to build graphs.

@davidalber
Copy link
Collaborator

Is there a way to query which team a user is on or are you imagining that we would encode that in the repo config file? The rust config has several groups (compiler, syntax, libs). Do those align with teams? If yes, are there situations where you wouldn't want them to align with teams? If that is no, we could talk about changing the config format to optionally specify labels for each group.

@pietroalbini
Copy link
Member Author

Is there a way to query which team a user is on or are you imagining that we would encode that in the repo config file?

Some people are in more than one team, so the config file would be better.

The rust config has several groups (compiler, syntax, libs). Do those align with teams?

Both compiler and syntax are T-compiler, and libs is T-libs. From _global.json doc is T-doc.

If yes, are there situations where you wouldn't want them to align with teams?

Technically yes, if someone only changes the docstring of a stdlib method the PR is assigned to the libs team, but that's not a new problem, the reviewer is also wrongly assigned, so I wouldn't worry about it.

If that is no, we could talk about changing the config format to optionally specify labels for each group.

That would be awesome :)

@nrc
Copy link
Member

nrc commented May 3, 2018

I don't think you can choose a team based on the reviewer because of people belonging to multiple teams (for which team.html on r-l.o is the source of truth). But putting a label based on the config sounds good.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants