Housekeeping: Removing bottlenecks in the review process. #13441
Description
This issue is created as a result of the conversation in the recent #core-editor meeting about the need to have more Pull Requests reviewers in the repository.
Currently, in Gutenberg, there is a bit of a bottleneck in that there are a relatively small group of people reviewing and approving pull requests compared to the number of code (and otherwise) contributions made. While this is not a new problem for any project of this size, it is something that is worthwhile tackling to help keep momentum.
This issue is created to track an initial approach to solving this problem which has the following action steps:
- Identify various areas in the project that issues/pulls can be classified as.
- Create Github teams for reviewers and approvers over each of those components. It's okay for people to be in more than one team.
- Use the Github code owners feature to assign the various teams to the different project areas.
- Put out a call for people to self-identify with the identified project areas so they can be assigned to the teams.
Gutenberg Areas
Gutenberg is a large application, composed of different packages. A given group of people might only be interested in a given area of the project. From that perspective, there should be reviewers and approvers assigned to each area. The below headings are just a starter. Let's iterate on them. If more granularity is needed depending on interests, we could create smaller areas.
| Project Area | Description | paths |
|---|---|---|
| data | comprised of all code interacting with or persisting data | data, redux-routine, api-fetch, core-data |
| blocks | everything to do with block implementation | block-library,format-library |
| editor | everything to do with the editor implementation | editor, edit-post,list-reusable-blocks,blocks,rich-text,shortcode,annotations,autop,block-serialization-spec-parser,block-serialization-default-parser |
| tooling | babel-plugin-import-jsx-pragma, babel-preset-default, browserslist-config, custom-templated-path-webpack-plugin,eslint-plugin,e2e-test-utils,e2e-tests,jest-console,jest-preset-default,jest-puppeteer-axe,library-export-default-webpack-plugin,npm-package-json-lint-config,postcss-themes,scripts | |
| UI components | Reusable React components | components,compose,notices,viewport,nux,element |
| Utilities | Small JS libraries | blob,deprecated,dom-ready,dom,escape-html,html-entities,is-shallow-equal,keycodes,priority-queue,token-list,url,wordcount,a11y,date,i18n |
| Extensibility | hooks,plugins | |
| Rest API and persistence | Most of the PHP code of the plugin is about REST API endpoints | |
| Docs |
Additional Ideas
There were a number of other ideas that came up in the #core-editor meeting for increasing participation for code reviews. In future meetings these additional ideas could be brought up for future iterations on the goal of increasing code review participation.
How can you become a reviewer / approver?
If you’re interested in helping in one of the areas above (or a smaller set), please comment on this issue and we’ll make sure to add you to the corresponding group.