-
Notifications
You must be signed in to change notification settings - Fork 4k
CDK Community PR Reviews
The CDK Team is introducing Community PR Reviews to improve the contributor experience. We've heard from a group of community members that they would be interested in additional responsibility to help scale our open-source project. Historically, reviewing PRs has always been a bottleneck for the team. Now, with the help of a pool of trusted reviewers, we will be expanding our reviewing power beyond just the team of CDK maintainers.
We review Pull Requests in the following order:
- p1 PRs with passing checks (denoted by
pr/needs-maintainer-review) - p2 PRs that are community reviewed (also gets
pr/needs-maintainer-review) - p1 PRs with a failing automated review to see if we can unblock you
- p2 PRs with passing checks (denoted by
pr/needs-community-review)
Essentially, getting a community review lets you jump the line slightly. The CDK Maintainers still aim to get to all community PRs that come in but recognize that we are a finite resource and don't manage to get to everyone in a timely manner.
Please do not ping our community members directly, either on GitHub or on cdk.dev!
If your PR is eligible for a community review, the pr/needs-community-review label
will be automatically added to the PR. Trusted community members will be able to search
for that label and find these PRs organically. If you feel like your PR needs an extra
bump, consider posting it on the #contributing channel in cdk.dev. Community members
will be on the lookout there as well for possible reviews.
A guide for reviewers when evaluating CDK PRs. It is not a strict checklist but a living document that may evolve. There will be exceptions and specific cases not covered here.
- PR titles should follow conventional commits, using "feat" or "fix" if we want the change to appear in the CHANGELOG.
- Contributors should avoid using "chore" or "refactor."
- The PR description must clearly explain the change being made, the rationale for it, and any design decisions taken.
- Avoid including permalinks in the description, as they can corrupt the CHANGELOG. Instead, place them in a comment.
- In alpha modules, highlight any breaking changes by using the
BREAKING CHANGE:text in the PR description.
PR reviewers should always consider the perspective of the end-user writing CDK code. Key user-visible changes to evaluate, in decreasing order of priority, include:
- Public API Surface
- Property Names and Function Names
-
Error Messages
- Do the error messages make sense and assist users in debugging their code?
- Doc Strings
-
README Content
- Ensure the README is user-focused, coherently describing use cases and integrating well with surrounding sections, rather than merely satisfying the linter.
- Do the defaults make sense?
- Does the public API expose as little as possible?
- Are there backward compatibility considerations or feature flags in place?
| Github | cdk.dev | Specialization |
|---|---|---|
| pahud | Pahud Hsieh | |
| jogold | Jonathan Goldwasser | |
| hoegertn | Thorsten Höger | |
| robertd | Robert Djurasaj | |
| watany-dev | yohei watanabe | |
| jumic | Julian Michel | |
| daschaa | Joshua Weber | |
| yamatatsu | yamatatsu | |
| lpizzinidev | Luca Pizzini | |
| iRoachie | Kyle Roach | |
| laurelmay | Laurel May | |
| WinterYukky | WinterYukky | |
| tmokmss | tmokmss | |
| humanzz | Ahmed Kamel | |
| msambol | Michael Sambol | |
| go-to-k | k.goto | |
| nmussy | nmussy | |
| badmintoncryer | Kazuho Cryer-Shinozuka | |
| mazyu36 | mazyu36 |