+! from me. I like that idea very much. On Thu, Jan 9, 2020 at 6:05 AM 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> > . > -- Thanks! Mark Waite -- 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/CAO49JtEUMKQEi2z4fbmTWqc%2Bny1xrnrE%2Bn6z3q0H2z857-muew%40mail.gmail.com.
