Closed tomeach closed 5 years ago
Hi @tommy-meacham , thanks for submitting your issue and pull request.
You don't worry about the PR failing. I understand the problem which occurs when creating a pull request from a fork. I'll fix it.
I have had the experience of working with remote office members, so I understand how you feel. I agree with your idea which selecting reviewers from each group.
However I want to discuss the implementation method. I have a concern that how to manages user group.
By your PR, need to commit the configuration file every time change the members (ex. join the team or leave the team). It is troublesome if you are using the auto-assign app in multiple repositories. I suggest implementation using GitHub Team.
// Creating team in advance
reviewGroups:
- GroupA
- GroupB
// This codes are roughly made
// Get all teams
const teams = await octokit.repos.listTeams({owner, repo})
// Get team IDs included in configuration file
// result: [15, 87]
const teamIds = teams.data.filter(team => reviewGroups.includes(team.name).map(team => team.id);
// Get mebers by team
// result: [{'john', 'taro'}, {'hanako', 'emi'}]
const membersByTeam = teamIds.map(async (teamId) => {
const members = await octokit.teams.listMembers({team_id: teamId})
const membersList = members.data.map(member => member.login)
return membersList
});
// Select reviewers by chooseUsersFromGroups method
Finally, we summarized the pros and cons of the two ideas. Please let me know if you have an opinion on my idea. I'm thinking to incorporate both ideas (although the configuration file gets more complicated).
Your idea:
Pros
Cons
My Idea:
Pros
Cons
Hey @kentaro-m , Thanks so much for getting back to me so quickly! I am excited to see that you like the idea of adding group functionality.
I like your idea of using Github Teams as an option to handle groups. However, for flexibility, there is value in keeping the current way of adding groups into the config (my idea). For example, if some members of the Github "Backend Team" shouldn't have access to, or should shouldn't care about a certain repo, you can only assign relevant groups using the config file.
To sum up, I think it is a good idea to have both implementations of assigning groups. Both through a Github Team or through the config file.
Hi, @tommy-meacham. Thank you for sharing your opinion!
I was made to realize there is value in keeping the current way of adding groups into the config by your comment.
I think my idea do too much for the app's responsibility (Of course, it would be great if the app has a feature that adds reviewers using Github Teams. ).
So I will take your idea and start to review your PR https://github.com/kentaro-m/auto-assign/pull/70.
Hi @kentaro-m, Fantastic! Thanks very much. Don't hesitate to ask questions (ask on the PR). :)
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Hi @tommy-meacham! I created a pull request adding the ability to tag Github teams as reviewers in #120, could you have a look if this is useful for you and leave feedback if you have any? Thank you!
Hi kentaro-m, I have opened a PR for the requested functionality in this ticket. Sadly the CircleCi build is failing with a confusing error:
Bad response: 422 {"message":"Couldn't find a repository matching this job.","error":true}
Is your feature request related to a problem? Please describe. I find myself in the situation where there is a rift in the engineering team I am working in (which I understand is a common problem). The divide in knowledge and practices lies along the separation of our offices.
Describe the solution you'd like I therefore looked for a tool that could help us to share the knowledge between offices. The auto_assign bot was perfect for our needs, except that we specifically want to select people from each office, or "group", to review any given PR. The theory is that selecting reviewers from each group will help us bridge the gap in knowledge and bring the two teams closer together.
Describe alternatives you've considered I have designed the implementation to leave all the current functionality intact, and add review/assignee groups on top of your current code.
Let me know what you think!