I think blueocean should always be treated as the exception not the rule. I tried to do the codeowners for it and didn't realize the privacy thing. https://github.com/jenkinsci/blueocean-plugin/blob/master/CODEOWNERS
Codeowners would be opt in, and maybe even defaulted. But not mandatory. I think if the code owners with teams worked, more people would update their teams instead of individuals. And if they don't. Then the plugins are no worse off than if we did nothing. On Mon., Jan. 13, 2020, 5:37 a.m. Daniel Beck, <db...@cloudbees.com> 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 <o.v.nenas...@gmail.com> > 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 jenkinsci-dev+unsubscr...@googlegroups.com. >> 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 jenkinsci-dev+unsubscr...@googlegroups.com. > 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DusX7BtbSDd-UTqZrCu5kc2js%2BkF51jMAs5LTZ7PFtF82w%40mail.gmail.com.
