Possibly could give maintainers team maintainer permission to help with that if the person they want to add is a member of the org
On Mon, 13 Jan 2020 at 13:37, Daniel Beck <[email protected]> wrote: > How do you plan to address issues in plugins whose maintainers are largely > (or even completely) managed outside the repo-specific team, or with custom > teams that are largely maintained manually? > > Since we grant repo admin permissions, it's easiest for maintainers to > just add new people as external collaborators, rather than go through Jira > to get someone to tell the IRC bot to add a new team member. Nobody is a > team maintainer by default. > > As an example of the kind of mess we're in, see jenkinsci/blueocean-plugin > which has more than a dozen external collaborators, and its > blueocean-plugin Developers team governs write access to four separate > repositories (which also have external collaborators, and possibly their > own "$pluginId-plugin Developers" teams). > > On Thu, Jan 9, 2020 at 2:05 PM Oleg Nenashev <[email protected]> > wrote: > >> Hi all, >> >> I propose to improve the code review process across the Jenkins GitHub >> organization. TL;DR: Let's introduce CODEOWNERS in repositories and >> automatically request reviews from maintainer teams. >> >> *Motivation:* In a number of plugins we have issues with pull requests >> which do not get timely reviews from the maintainers. It slows down >> delivery of fixes and impacts contributor experience, especially for >> newcomers who have to wait and to ping maintainers. Finally it impacts our >> ability to attract and retain contributors, and also causes frustration >> among maintainers and Jenkins users who see the desired PRs unmerged. >> >> *Why does it happen?* We have well known issues with abandoned plugins, >> and there we cannot do much except promoting the adoption process >> <https://jenkins.io/doc/developer/plugin-governance/adopt-a-plugin/>. >> But lack of reviews also happens in other plugins. In many cases it is just >> caused by maintainers missing GitHub notifications (I am guilty of that >> too) and/or forgetting to follow-up. It is normal, because many plugins are >> maintained by volunteers. Life happens, work happens, etc. But we could >> help maintainers to keep track of review requests. >> >> *Current state:* >> >> - In recent years GitHub introduced support of code review requests. >> GitHub offers built-in dashboards so that every user can see the pending >> reviews (link <https://github.com/pulls/review-requested>). There are >> also tools like In recent years GitHub introduced support of code review >> requests. Pull reminders <https://pullreminders.com/> which can >> integrate with corporate environments. For example, it allows to notify >> about new PRs and to periodically remind about stale review requests in >> Slack. >> - How do we use GitHub? For each plugin we already have a GitHub team >> ( ${reponame}-developers) which could be used to request reviews (see >> GitHub >> permissions management >> >> <https://jenkins.io/doc/developer/plugin-governance/managing-permissions/#github-permissions>). >> jenkinsci organization members can request reviews inside the organization >> - External contributors cannot request reviews if they are not a part >> of the organization or repository collaborators. They can only CC >> maintainers in comments, and they won/t be able to see developer teams and >> request reviews from them >> >> *Proposed solution:* GitHub now offers Code Owners metadata file >> <https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners> >> for >> repos. It allows to specify owners of particular sections of code and to >> automatically request reviews from them in pull requests. Such reviews will >> be requested even if the submitter is not a member of the GitHub >> organization. It would also help organization members, because they will >> not need to manually request reviews and spend time on it. In order to >> implement that for a repo, we just need to add a string like "* >> @jenkinsci/pluginId-plugin-developers " in to .github/CODEOWNERS (example >> <https://github.com/jenkinsci/role-strategy-plugin/blob/master/.github/CODEOWNERS> >> ). >> >> *Scope of changes: *Plugin repositories inside the jenkinsci GitHub >> organizations. Other organizations (e.g. jenkins-infra) or non-plugin >> repositories are out of the scope. >> >> *Risks:* >> >> - "${reponame}-developers" team is a common practice, put it is not a >> case for all plugin repositories. >> - Solution: We skip repositories with a different permission model >> - Not every maintainer may want to be requested in such way. Some >> people do not like to receive too many notifications, and prefer to look >> at >> the repository periodically. >> - Solution: the process should be opt-in >> - Ownership changes in plugin? How they will impact the process >> - Solution: we use a "${reponame}-developers" team, so that the >> process is not bounded to individuals. Once a new contributor added to >> the >> list of plugin maintainers, he/she will receive review requests for >> newly >> created PRs and review re-requests >> >> *Rollout plan:* >> >> - Jenkins project recommends setting CODEOWNERS in the repositories >> - We add CODEOWNERS template to plugin archetypes >> <https://github.com/jenkinsci/archetypes> >> - We submit pull requests to plugin repositories which have >> associated "${reponame}-developers" teams. Due to the number of >> repositories it will likely require a bot, similar to how Daniel Beck >> handled the Plugin POM HTTP/HTTPs mess cleanup >> >> <https://groups.google.com/forum/#!msg/jenkinsci-dev/fc8xSQXift4/GlZZQR5lDAAJ> >> - Each plugin maintainer or maintainer team will decide on their own >> whether they accept the process or not. Merging or closing the pull >> request >> will indicate the decision >> >> I think that such change could greatly improve contributor experience >> across the in the project. What do you think? >> >> Thanks in advance, >> Oleg Nenashev >> >> >> >> >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDCPCEb3oE_4uynf%2BE8KcFcSaY5pxy3MR6wveR%2BdtijBw%40mail.gmail.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDCPCEb3oE_4uynf%2BE8KcFcSaY5pxy3MR6wveR%2BdtijBw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtLEk5Sg6nKBZ%3Dp5Ghg0SqYhx6C7uuNiT7dCrtTcKvBZoA%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtLEk5Sg6nKBZ%3Dp5Ghg0SqYhx6C7uuNiT7dCrtTcKvBZoA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bie%2BUvLNhTrA72As4PUih-NDQdtRnVs3ZTjUEoC2pg05pQ%40mail.gmail.com.
