From dd519f9e72a98b72ef999809df11f0c8086d7867 Mon Sep 17 00:00:00 2001 From: heitorlessa Date: Tue, 17 May 2022 17:07:47 +0200 Subject: [PATCH 01/18] docs(maintainers): initial skeleton --- MAINTAINERS.md | 107 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 MAINTAINERS.md diff --git a/MAINTAINERS.md b/MAINTAINERS.md new file mode 100644 index 00000000000..37a2eb938cf --- /dev/null +++ b/MAINTAINERS.md @@ -0,0 +1,107 @@ + +## Table of contents + +- [Overview](#overview) +- [Current Maintainers](#current-maintainers) +- [Emeritus](#emeritus) +- [Maintainer Responsibilities](#maintainer-responsibilities) + - [Uphold Code of Conduct](#uphold-code-of-conduct) + - [Prioritize Security](#prioritize-security) + - [Review Pull Requests](#review-pull-requests) + - [Triage Open Issues](#triage-open-issues) + - [Triage Bug Reports](#triage-bug-reports) + - [Releasing a new version](#releasing-a-new-version) + - [Releasing a documentation hotfix](#releasing-a-documentation-hotfix) + - [Maintain Overall Health of the Repo](#maintain-overall-health-of-the-repo) + - [Manage Roadmap](#manage-roadmap) + - [Add Continuous Integration Checks](#add-continuous-integration-checks) + - [Negative Impact on the Project](#negative-impact-on-the-project) + - [Becoming a maintainer](#becoming-a-maintainer) + +## Overview + +This is document explains who the maintainers are (see below), what they do in this repo, and how they should be doing it. If you're interested in contributing, see [CONTRIBUTING](CONTRIBUTING.md). + +## Current Maintainers + +| Maintainer | GitHub ID | Affiliation | +| ---------------- | --------------------------------------------- | ----------- | +| Heitor Lessa | [heitorlessa](https://github.com/heitorlessa) | Amazon | +| Alexander Melnyk | [am29d](https://github.com/am29d) | Amazon | +| Michal Ploski | [mploski](https://github.com/mploski) | Amazon | +| Simon Thulbourn | [sthulb](https://github.com/sthulb) | Amazon | + +## Emeritus + +Previous active maintainers who contributed to this project. + +| Maintainer | GitHub ID | Affiliation | +| ----------------- | ----------------------------------------------- | ----------- | +| Tom McCarthy | [cakepietoast](https://github.com/cakepietoast) | MongoDB | +| Nicolas Moutschen | [nmoutschen](https://github.com/nmoutschen) | Amazon | + +## Maintainer Responsibilities + +Maintainers are active and visible members of the community, and have [maintain-level permissions on a repository](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization). Use those privileges to serve the community and evolve code as follows. + +### Uphold Code of Conduct + +Model the behavior set forward by the [Code of Conduct](CODE_OF_CONDUCT.md) and raise any violations to other maintainers and admins. There could be unusual circumstances where inappropriate behavior does not immediately fall within the [Code of Conduct](CODE_OF_CONDUCT.md). These might be nuanced and should be handled with extra care - do not engage, whenever in doubt reach out to other maintainers and admins. + +### Prioritize Security + +Security is your number one priority. Maintainer's Github keys must be password protected securely and any reported security vulnerabilities are addressed before features or bugs. + +Note that this repository is monitored and supported 24/7 by Amazon Security, see [Reporting a Vulnerability](SECURITY.md) for details. + +### Review Pull Requests + +> WORK-IN-PROGRESS +> TODO: cover labels, CI automation, the right to close, and a reference to FAQ on common issues. + +Review pull requests regularly, comment, suggest, reject, merge and close. Accept only high quality pull-requests. Provide code reviews and guidance on incoming pull requests. + +Use and enforce [semantic versioning](https://semver.org/) pull request titles, as these will be used for [CHANGELOG](CHANGELOG.md) and Release notes - make sure they communicate their intent at human level. + +### Triage Open Issues + +> WORK-IN-PROGRESS +> TODO: cover labels, reference to Roadmap Project Status definition, sensitive labels to defer or prioritize work + +### Triage Bug Reports + +> WORK-IN-PROGRESS +> TODO: cover different types of bugs (internal, customer-facing, upstream), reference to releasing section + +### Releasing a new version + +> WORK-IN-PROGRESS +> convert what's written in [publish.yml](.github/workflows/publish.yml) + +### Releasing a documentation hotfix + +> WORK-IN-PROGRESS +> convert what's written in [publish.yml](.github/workflows/publish.yml) + +### Maintain Overall Health of the Repo + +Keep the `develop` branch at production quality at all times. Backport features as needed. Cut release branches and tags to enable future patches. + +### Manage Roadmap + +See [Roadmap section](https://awslabs.github.io/aws-lambda-powertools-python/latest/roadmap/) + +Ensure the repo highlights features that should be elevated to the project roadmap. Be clear about the feature’s status, priority, target version, and whether or not it should be elevated to the roadmap. + +### Add Continuous Integration Checks + +Add integration checks that validate pull requests and pushes to ease the burden on Pull Request reviewers. Continuously revisit areas of improvement to reduce operational burden in all parties involved. + +### Negative Impact on the Project + +Actions that negatively impact the project will be handled by the admins, in coordination with other maintainers, in balance with the urgency of the issue. Examples would be [Code of Conduct](CODE_OF_CONDUCT.md) violations, deliberate harmful or malicious actions, and security risks. + +### Becoming a maintainer + +> WORK-IN-PROGRESS +> TODO: cover ideas of what a future process might look like for when we're ready to do it fairly and securely. From f3a22c8c208d6f3f544ffa1bcf68167aef35d342 Mon Sep 17 00:00:00 2001 From: heitorlessa Date: Fri, 20 May 2022 09:48:11 +0200 Subject: [PATCH 02/18] docs(maintainers): initial structure --- MAINTAINERS.md | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 37a2eb938cf..500733c2c1b 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -8,8 +8,9 @@ - [Uphold Code of Conduct](#uphold-code-of-conduct) - [Prioritize Security](#prioritize-security) - [Review Pull Requests](#review-pull-requests) - - [Triage Open Issues](#triage-open-issues) + - [Triage New Issues](#triage-new-issues) - [Triage Bug Reports](#triage-bug-reports) + - [Triage RFCs](#triage-rfcs) - [Releasing a new version](#releasing-a-new-version) - [Releasing a documentation hotfix](#releasing-a-documentation-hotfix) - [Maintain Overall Health of the Repo](#maintain-overall-health-of-the-repo) @@ -20,6 +21,8 @@ ## Overview +> **This document is currently a WORK-IN-PROGRESS** + This is document explains who the maintainers are (see below), what they do in this repo, and how they should be doing it. If you're interested in contributing, see [CONTRIBUTING](CONTRIBUTING.md). ## Current Maintainers @@ -46,7 +49,7 @@ Maintainers are active and visible members of the community, and have [maintain- ### Uphold Code of Conduct -Model the behavior set forward by the [Code of Conduct](CODE_OF_CONDUCT.md) and raise any violations to other maintainers and admins. There could be unusual circumstances where inappropriate behavior does not immediately fall within the [Code of Conduct](CODE_OF_CONDUCT.md). These might be nuanced and should be handled with extra care - do not engage, whenever in doubt reach out to other maintainers and admins. +Model the behavior set forward by the [Code of Conduct](CODE_OF_CONDUCT.md) and raise any violations to other maintainers and admins. There could be unusual circumstances where inappropriate behavior does not immediately fall within the [Code of Conduct](CODE_OF_CONDUCT.md). These might be nuanced and should be handled with extra care - when in doubt, do not engage and reach out to other maintainers and admins. ### Prioritize Security @@ -61,18 +64,23 @@ Note that this repository is monitored and supported 24/7 by Amazon Security, se Review pull requests regularly, comment, suggest, reject, merge and close. Accept only high quality pull-requests. Provide code reviews and guidance on incoming pull requests. -Use and enforce [semantic versioning](https://semver.org/) pull request titles, as these will be used for [CHANGELOG](CHANGELOG.md) and Release notes - make sure they communicate their intent at human level. +Use and enforce [semantic versioning](https://semver.org/) pull request titles, as these will be used for [CHANGELOG](CHANGELOG.md) and [Release notes](https://github.com/awslabs/aws-lambda-powertools-python/releases) - make sure they communicate their intent at human level. -### Triage Open Issues +### Triage New Issues > WORK-IN-PROGRESS -> TODO: cover labels, reference to Roadmap Project Status definition, sensitive labels to defer or prioritize work +> TODO: cover labels, reference to Roadmap Project Status definition, sensitive labels to defer or prioritize work, and give first priority to original authors on implementation ### Triage Bug Reports > WORK-IN-PROGRESS > TODO: cover different types of bugs (internal, customer-facing, upstream), reference to releasing section +### Triage RFCs + +> WORK-IN-PROGRESS +> TODO: cover design proposal quality, mentoring sessions, etc. + ### Releasing a new version > WORK-IN-PROGRESS @@ -85,6 +93,8 @@ Use and enforce [semantic versioning](https://semver.org/) pull request titles, ### Maintain Overall Health of the Repo +> TODO: Coordinate in removing `master` and renaming `develop` to `main` + Keep the `develop` branch at production quality at all times. Backport features as needed. Cut release branches and tags to enable future patches. ### Manage Roadmap @@ -99,7 +109,7 @@ Add integration checks that validate pull requests and pushes to ease the burden ### Negative Impact on the Project -Actions that negatively impact the project will be handled by the admins, in coordination with other maintainers, in balance with the urgency of the issue. Examples would be [Code of Conduct](CODE_OF_CONDUCT.md) violations, deliberate harmful or malicious actions, and security risks. +Actions that negatively impact the project will be handled by the admins, in coordination with other maintainers, in balance with the urgency of the issue. Examples would be [Code of Conduct](CODE_OF_CONDUCT.md) violations, deliberate harmful or malicious actions, spam, monopolization, and security risks. ### Becoming a maintainer From ce5b163027de5c78d8dc0e130d8c24a8f2ddedf2 Mon Sep 17 00:00:00 2001 From: heitorlessa Date: Tue, 31 May 2022 14:59:41 +0200 Subject: [PATCH 03/18] docs(maintainers): initial rfc triage --- MAINTAINERS.md | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 500733c2c1b..c07e8f84f9d 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -78,8 +78,21 @@ Use and enforce [semantic versioning](https://semver.org/) pull request titles, ### Triage RFCs -> WORK-IN-PROGRESS -> TODO: cover design proposal quality, mentoring sessions, etc. +RFCs are meant to be a collaborative process to help us get to the most optimal solution given the context. Their purpose is to ensure everyone understand what this context is, their trade-offs, and alternative solutions that were considered as part of the research before implementation begins. + +When reviewing newly submitted RFCs, make sure you have the following questions but not limited in mind: + +* Does it use our [RFC template](https://github.com/awslabs/aws-lambda-powertools-python/issues/new?assignees=&labels=RFC%2Ctriage&template=rfc.yml&title=RFC%3A+TITLE)? +* Does the match our [Tenets](https://awslabs.github.io/aws-lambda-powertools-python/latest/#tenets)? +* Does it focus on the mechanics to solve the use case over fine-grained implementation details? +* Can anyone sufficiently familiar with the code base implement that RFC? +* If approved, does the RFC author want to proceed in implementing with maintainer's guidance? + +If necessary, be upfront that the time it takes to review, approve, and implement a RFC can vary. Some RFCs will likely be updated as soon as the implementation PR begins, as certain areas become clearer. If you find a RFC or its implementation would benefit from a call or mentoring, don't hesitate in offering it - this often can unblock language barriers. + +As a maintainer, make sure you set the authors to success while keeping maintenance in mind. When in doubt, use `need-more-information` or `need-customer-feedback` labels to signal more context and feedback are necessary before proceeding. + +Some examples using our initial and new RFC templates: #92, #94, #95, #991, #1226 ### Releasing a new version From 3b5a1519fffad858e1e04698cbebdb76a6052127 Mon Sep 17 00:00:00 2001 From: heitorlessa Date: Tue, 31 May 2022 16:53:31 +0200 Subject: [PATCH 04/18] docs(maintainers): line-editing; add common scenarios --- MAINTAINERS.md | 36 +++++++++++++++++++++++++++++------- 1 file changed, 29 insertions(+), 7 deletions(-) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index c07e8f84f9d..b99a165c0f8 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -18,6 +18,10 @@ - [Add Continuous Integration Checks](#add-continuous-integration-checks) - [Negative Impact on the Project](#negative-impact-on-the-project) - [Becoming a maintainer](#becoming-a-maintainer) +- [Common scenarios](#common-scenarios) + - [Contribution is stuck](#contribution-is-stuck) + - [Insufficient feedback or information](#insufficient-feedback-or-information) + - [Crediting contributions](#crediting-contributions) ## Overview @@ -78,19 +82,19 @@ Use and enforce [semantic versioning](https://semver.org/) pull request titles, ### Triage RFCs -RFCs are meant to be a collaborative process to help us get to the most optimal solution given the context. Their purpose is to ensure everyone understand what this context is, their trade-offs, and alternative solutions that were considered as part of the research before implementation begins. +RFCs are meant to be a collaborative process to help us get to the most optimal solution given the context. Their purpose is to ensure everyone understands what this context is, their trade-offs, and alternative solutions that were part of the research before implementation begins. -When reviewing newly submitted RFCs, make sure you have the following questions but not limited in mind: +Make sure you ask these questions in mind when reviewing: * Does it use our [RFC template](https://github.com/awslabs/aws-lambda-powertools-python/issues/new?assignees=&labels=RFC%2Ctriage&template=rfc.yml&title=RFC%3A+TITLE)? * Does the match our [Tenets](https://awslabs.github.io/aws-lambda-powertools-python/latest/#tenets)? * Does it focus on the mechanics to solve the use case over fine-grained implementation details? -* Can anyone sufficiently familiar with the code base implement that RFC? -* If approved, does the RFC author want to proceed in implementing with maintainer's guidance? +* Can anyone familiar with the code base implement it? +* If approved, are they interested in contributing? Do they need any guidance? +* Does this significantly increase the overall project maintenance? e.g., lacks expertise in the team, fast moving target, etc. +* If we can't take this use case, are there alternative projects we could recommend? Or does it call for a new project altogether? -If necessary, be upfront that the time it takes to review, approve, and implement a RFC can vary. Some RFCs will likely be updated as soon as the implementation PR begins, as certain areas become clearer. If you find a RFC or its implementation would benefit from a call or mentoring, don't hesitate in offering it - this often can unblock language barriers. - -As a maintainer, make sure you set the authors to success while keeping maintenance in mind. When in doubt, use `need-more-information` or `need-customer-feedback` labels to signal more context and feedback are necessary before proceeding. +When necessary, be upfront that the time it takes to review, approve, and implement a RFC can vary - see [Contribution is stuck](#contribution-is-stuck). Some RFCs may be further updated after implementation, as certain areas become clearer. Some examples using our initial and new RFC templates: #92, #94, #95, #991, #1226 @@ -128,3 +132,21 @@ Actions that negatively impact the project will be handled by the admins, in coo > WORK-IN-PROGRESS > TODO: cover ideas of what a future process might look like for when we're ready to do it fairly and securely. + +## Common scenarios + +### Contribution is stuck + +A contribution can get stuck often due to lack of bandwidth and language barrier. For bandwidth issues, check whether the author needs help. Make sure you get their permission before pushing code into their existing PR - do not create a new PR unless strictly necessary. + +For language barrier and others, don't hesitate to offer a 1:1 chat to get them unblocked. Often times, English might not be their primary language, and writing in public might put them off, or come across not the way they intended to be. + +In other cases, you may have constrained capacity. Use `help wanted` label when you want to signal additional maintainers and external contributors that you could use a hand to move it forward. + +### Insufficient feedback or information + +When in doubt, use `need-more-information` or `need-customer-feedback` labels to signal more context and feedback are necessary before proceeding. You can also use `revisit-in-3-months` label when you anticipate it might take a while to gather enough information before you can make a decision. + +### Crediting contributions + +> TODO: mention release notes and provide an example. From f56959c0fa5662ca4b90ab2435ed54ce2f26f70d Mon Sep 17 00:00:00 2001 From: heitorlessa Date: Tue, 31 May 2022 18:20:09 +0200 Subject: [PATCH 05/18] docs(maintainers): add doc hotfix --- MAINTAINERS.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index b99a165c0f8..c55f389ba99 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -105,8 +105,9 @@ Some examples using our initial and new RFC templates: #92, #94, #95, #991, #122 ### Releasing a documentation hotfix -> WORK-IN-PROGRESS -> convert what's written in [publish.yml](.github/workflows/publish.yml) +You can rebuild the latest documentation without a full release via this [GitHub Actions Workflow](https://github.com/awslabs/aws-lambda-powertools-python/actions/workflows/rebuild_latest_docs.yml). Choose `Run workflow`, keep `develop` as the branch, and input the latest Powertools version available. + +This workflow will update both user guide and API documentation. ### Maintain Overall Health of the Repo From df1460390a9b2c44acb4d837bfa7dbdc370810ac Mon Sep 17 00:00:00 2001 From: heitorlessa Date: Wed, 1 Jun 2022 10:01:02 +0200 Subject: [PATCH 06/18] docs(maintainers): add labels section --- .github/ISSUE_TEMPLATE/static_typing.yml | 2 +- .github/boring-cyborg.yml | 31 ++--- .github/release-drafter.yml | 36 +++--- .github/workflows/publish.yml | 155 +++++++++++------------ MAINTAINERS.md | 36 ++++++ 5 files changed, 144 insertions(+), 116 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/static_typing.yml b/.github/ISSUE_TEMPLATE/static_typing.yml index c197fba4967..863dde7d33f 100644 --- a/.github/ISSUE_TEMPLATE/static_typing.yml +++ b/.github/ISSUE_TEMPLATE/static_typing.yml @@ -1,7 +1,7 @@ name: Static typing mismatch report description: Report a static type mismatch caught by a static type checker title: "Static typing: TITLE" -labels: ["static_typing", "triage"] +labels: ["typing", "triage"] body: - type: markdown attributes: diff --git a/.github/boring-cyborg.yml b/.github/boring-cyborg.yml index 31aa24bc94f..57d840d34dd 100644 --- a/.github/boring-cyborg.yml +++ b/.github/boring-cyborg.yml @@ -1,49 +1,47 @@ ##### Labeler ########################################################################################################## labelPRBasedOnFilePath: - area/logger: + logger: - aws_lambda_powertools/logging/* - aws_lambda_powertools/logging/**/* - aws_lambda_powertools/package_logger.py - area/tracer: + tracer: - aws_lambda_powertools/tracing/* - aws_lambda_powertools/tracing/**/* - area/metrics: + metrics: - aws_lambda_powertools/metrics/* - aws_lambda_powertools/metrics/**/* - area/event_handlers: + event_handlers: - aws_lambda_powertools/event_handler/* - aws_lambda_powertools/event_handler/**/* - area/middleware_factory: + middleware_factory: - aws_lambda_powertools/middleware_factory/* - aws_lambda_powertools/middleware_factory/**/* - area/parameters: + parameters: - aws_lambda_powertools/parameters/* - aws_lambda_powertools/parameters/**/* - area/batch: + batch: - aws_lambda_powertools/batch/* - aws_lambda_powertools/batch/**/* - area/validator: + validator: - aws_lambda_powertools/validation/* - aws_lambda_powertools/validation/**/* - area/event_sources: + event_sources: - aws_lambda_powertools/data_classes/* - aws_lambda_powertools/data_classes/**/* - area/parser: + parser: - aws_lambda_powertools/parser/* - aws_lambda_powertools/parser/**/* - area/idempotency: + idempotency: - aws_lambda_powertools/idempotency/* - aws_lambda_powertools/idempotency/**/* - area/feature_flags: + feature_flags: - aws_lambda_powertools/feature_flags/* - aws_lambda_powertools/feature_flags/**/* - area/jmespath_util: + jmespath_util: - aws_lambda_powertools/utilities/jmespath_utils/* - area/utilities: + utilities: - aws_lambda_powertools/utilities/* - aws_lambda_powertools/utilities/**/* - - aws_lambda_powertools/middleware_factory/* - - aws_lambda_powertools/middleware_factory/**/* documentation: - docs/* @@ -86,7 +84,6 @@ firstPRMergeComment: > firstIssueWelcomeComment: > Thanks for opening your first issue here! We'll come back to you as soon as we can. - ###### IssueLink Adder ################################################################################################# # Insert Issue (Jira/Github etc) link in PR description based on the Issue ID in PR title. #insertIssueLinkInPrDescription: diff --git a/.github/release-drafter.yml b/.github/release-drafter.yml index 44ad5a61779..b590898b517 100644 --- a/.github/release-drafter.yml +++ b/.github/release-drafter.yml @@ -1,32 +1,28 @@ change-template: "* $TITLE (#$NUMBER) by @$AUTHOR" categories: - - title: '⚑ Breaking Changes' + - title: "⚑ Breaking Changes" labels: - - 'breaking-change' - - title: '🌟New features and non-breaking changes' + - "breaking-change" + - title: "🌟New features and non-breaking changes" labels: - - 'major' - - 'feature' - - title: '🌟 Minor Changes' + - "feature" + - title: "πŸ“œ Documentation updates" labels: - - 'enhancement' - - title: 'πŸ“œ Documentation updates' + - "documentation" + - title: "πŸ› Bug and hot fixes" labels: - - 'documentation' - - title: 'πŸ› Bug and hot fixes' + - "bug" + - "fix" + - title: "πŸš’ Deprecations" labels: - - 'bug' - - 'fix' - - title: 'πŸš’ Deprecations' + - "deprecated" + - title: "πŸ”§ Maintenance" labels: - - 'deprecated' - - title: 'πŸ”§ Maintenance' - labels: - - 'internal' - - 'dependencies' + - "internal" + - "dependencies" exclude-labels: - - 'skip-changelog' -tag-template: 'v$NEXT_PATCH_VERSION' + - "skip-changelog" +tag-template: "v$NEXT_PATCH_VERSION" template: | ## Summary diff --git a/.github/workflows/publish.yml b/.github/workflows/publish.yml index f72c6bb4f20..6a4bb3b3cf5 100644 --- a/.github/workflows/publish.yml +++ b/.github/workflows/publish.yml @@ -22,7 +22,7 @@ name: Publish to PyPi # 8. Builds a fresh version of docs including Changelog updates # 9. Push latest release source code to master using release title as the commit message # 10. Builds latest documentation for new release, and update latest alias pointing to the new release tag -# 11. Close and notify all issues labeled "status/staged-next-release" about the release details +# 11. Close and notify all issues labeled "pending-release" about the release details # # === Fallback mechanism due to external failures === @@ -36,7 +36,6 @@ name: Publish to PyPi # # Look for rebuild latest docs workflow - on: release: types: [published] @@ -45,84 +44,84 @@ jobs: release: runs-on: ubuntu-latest steps: - - uses: actions/checkout@v3 - with: - fetch-depth: 0 - - name: Set up Python - uses: actions/setup-python@v3 - with: - python-version: "3.8" - - name: Set release notes tag - run: | - RELEASE_TAG_VERSION=${{ github.event.release.tag_name }} - echo "RELEASE_TAG_VERSION=${RELEASE_TAG_VERSION:1}" >> $GITHUB_ENV - - name: Ensure new version is also set in pyproject and CHANGELOG - run: | - grep --regexp "${RELEASE_TAG_VERSION}" CHANGELOG.md - grep --regexp "version \= \"${RELEASE_TAG_VERSION}\"" pyproject.toml - - name: Install dependencies - run: make dev - - name: Run all tests, linting and baselines - run: make pr - - name: Build python package and wheel - run: poetry build - - name: Upload to PyPi test - run: make release-test - env: - PYPI_USERNAME: __token__ - PYPI_TEST_TOKEN: ${{ secrets.PYPI_TEST_TOKEN }} - - name: Upload to PyPi prod - run: make release-prod - env: - PYPI_USERNAME: __token__ - PYPI_TOKEN: ${{ secrets.PYPI_TOKEN }} - - name: publish lambda layer in SAR by triggering the internal codepipeline - run: | - aws ssm put-parameter --name "powertools-python-release-version" --value $RELEASE_TAG_VERSION --overwrite - aws codepipeline start-pipeline-execution --name ${{ secrets.CODEPIPELINE_NAME }} - env: - # Maintenance: Migrate to new OAuth mechanism - AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} - AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} - AWS_DEFAULT_REGION: eu-west-1 - AWS_DEFAULT_OUTPUT: json - - name: Setup doc deploy - run: | - git config --global user.name Docs deploy - git config --global user.email aws-devax-open-source@amazon.com - - name: Build docs website and API reference - run: | - make release-docs VERSION=${RELEASE_TAG_VERSION} ALIAS="latest" - poetry run mike set-default --push latest - - name: Release API docs to release version - uses: peaceiris/actions-gh-pages@v3 - with: - github_token: ${{ secrets.GITHUB_TOKEN }} - publish_dir: ./api - keep_files: true - destination_dir: ${{ env.RELEASE_TAG_VERSION }}/api - - name: Release API docs to latest - uses: peaceiris/actions-gh-pages@v3 - with: - github_token: ${{ secrets.GITHUB_TOKEN }} - publish_dir: ./api - keep_files: true - destination_dir: latest/api - - name: Close issues related to this release - uses: actions/github-script@v6 - with: - script: | - const post_release = require('.github/workflows/post_release.js') - await post_release({github, context, core}) + - uses: actions/checkout@v3 + with: + fetch-depth: 0 + - name: Set up Python + uses: actions/setup-python@v3 + with: + python-version: "3.8" + - name: Set release notes tag + run: | + RELEASE_TAG_VERSION=${{ github.event.release.tag_name }} + echo "RELEASE_TAG_VERSION=${RELEASE_TAG_VERSION:1}" >> $GITHUB_ENV + - name: Ensure new version is also set in pyproject and CHANGELOG + run: | + grep --regexp "${RELEASE_TAG_VERSION}" CHANGELOG.md + grep --regexp "version \= \"${RELEASE_TAG_VERSION}\"" pyproject.toml + - name: Install dependencies + run: make dev + - name: Run all tests, linting and baselines + run: make pr + - name: Build python package and wheel + run: poetry build + - name: Upload to PyPi test + run: make release-test + env: + PYPI_USERNAME: __token__ + PYPI_TEST_TOKEN: ${{ secrets.PYPI_TEST_TOKEN }} + - name: Upload to PyPi prod + run: make release-prod + env: + PYPI_USERNAME: __token__ + PYPI_TOKEN: ${{ secrets.PYPI_TOKEN }} + - name: publish lambda layer in SAR by triggering the internal codepipeline + run: | + aws ssm put-parameter --name "powertools-python-release-version" --value $RELEASE_TAG_VERSION --overwrite + aws codepipeline start-pipeline-execution --name ${{ secrets.CODEPIPELINE_NAME }} + env: + # Maintenance: Migrate to new OAuth mechanism + AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} + AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} + AWS_DEFAULT_REGION: eu-west-1 + AWS_DEFAULT_OUTPUT: json + - name: Setup doc deploy + run: | + git config --global user.name Docs deploy + git config --global user.email aws-devax-open-source@amazon.com + - name: Build docs website and API reference + run: | + make release-docs VERSION=${RELEASE_TAG_VERSION} ALIAS="latest" + poetry run mike set-default --push latest + - name: Release API docs to release version + uses: peaceiris/actions-gh-pages@v3 + with: + github_token: ${{ secrets.GITHUB_TOKEN }} + publish_dir: ./api + keep_files: true + destination_dir: ${{ env.RELEASE_TAG_VERSION }}/api + - name: Release API docs to latest + uses: peaceiris/actions-gh-pages@v3 + with: + github_token: ${{ secrets.GITHUB_TOKEN }} + publish_dir: ./api + keep_files: true + destination_dir: latest/api + - name: Close issues related to this release + uses: actions/github-script@v6 + with: + script: | + const post_release = require('.github/workflows/post_release.js') + await post_release({github, context, core}) sync_master: needs: release runs-on: ubuntu-latest steps: - - uses: actions/checkout@v3 - - name: Sync master from detached head - # If version matches CHANGELOG and pyproject.toml - # If it passes all checks, successfully releases to test and prod - # Then sync up master with latest source code release - # where commit message will be Release notes title - run: git push origin HEAD:refs/heads/master --force + - uses: actions/checkout@v3 + - name: Sync master from detached head + # If version matches CHANGELOG and pyproject.toml + # If it passes all checks, successfully releases to test and prod + # Then sync up master with latest source code release + # where commit message will be Release notes title + run: git push origin HEAD:refs/heads/master --force diff --git a/MAINTAINERS.md b/MAINTAINERS.md index c55f389ba99..db9830fa10e 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -4,6 +4,7 @@ - [Overview](#overview) - [Current Maintainers](#current-maintainers) - [Emeritus](#emeritus) +- [Labels](#labels) - [Maintainer Responsibilities](#maintainer-responsibilities) - [Uphold Code of Conduct](#uphold-code-of-conduct) - [Prioritize Security](#prioritize-security) @@ -47,6 +48,41 @@ Previous active maintainers who contributed to this project. | Tom McCarthy | [cakepietoast](https://github.com/cakepietoast) | MongoDB | | Nicolas Moutschen | [nmoutschen](https://github.com/nmoutschen) | Amazon | +## Labels + +These are the most common labels used by maintainers to triage issues, pull requests (PR), and for project management: + +| Label | Usage | Notes | +| ---------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------- | +| triage | New issues that require maintainers review | Issue template | +| bug | Unexpected, reproducible and unintended software behavior | PR/Release automation; Doc snippets are excluded; | +| documentation | Documentation improvements | PR/Release automation; Doc additions, fixes, etc.; | +| feature-request | New or enhancements to existing features | Issue template | +| typing | New or enhancements to static typing | Issue template | +| RFC | Technical design documents related to a feature request | Issue template | +| bug-upstream | Bug caused by upstream dependency | | +| help wanted | Tasks you want help from anyone to move forward | Bandwidth, complex topics, etc. | +| need-customer-feedback | Tasks that require additional feedback before proceeding | 80/20% rule, uncertain, etc. | +| need-more-information | Missing information before making any call | | +| need-documentation | PR is missing or has incomplete documentation | | +| need-issue | PR is missing a related issue for tracking change | Needs to be automated | +| need-rfc | Feature request requires a RFC to improve discussion | | +| pending-release | Merged changes that will be available soon | Release automation auto-closes/notifies it | +| revisit-in-3-months | Blocked issues/PRs that needs to be revisited | Often related to `need-customer-feedback`, prioritization, etc. | +| breaking-change | Changes that will cause customer impact and needs careful triage | | +| do-not-merge | PRs that are blocked for varying reasons | Might not have a timeline in sight | +| size/XS | PRs between 0-9 LOC | PR automation | +| size/S | PRs between 10-29 LOC | PR automation | +| size/M | PRs between 30-99 LOC | PR automation | +| size/L | PRs between 100-499 LOC | PR automation | +| size/XL | PRs between 500-999 LOC, typically PRs that evolved with feedback | PR automation | +| size/XXL | PRs with 1K+ LOC, largely documentation related | PR automation | +| tests | PRs that add or change tests | PR automation | +| `` | PRs related to a Powertools utility, e.g. `parameters`, `tracer` | PR automation | +| feature | New features or minor changes | PR/Release automation | +| dependencies | Changes that touch dependencies, e.g. Dependabot, etc. | PR/ automation | +| github-actions | Changes in GitHub workflows | PR automation | + ## Maintainer Responsibilities Maintainers are active and visible members of the community, and have [maintain-level permissions on a repository](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization). Use those privileges to serve the community and evolve code as follows. From 4e78d677b45a8e77f9f56d6542cd5997009523a9 Mon Sep 17 00:00:00 2001 From: heitorlessa Date: Wed, 1 Jun 2022 10:38:56 +0200 Subject: [PATCH 07/18] docs(maintainers): adjust labels and respective automation --- .github/auto_assign-issues.yml | 8 -------- .github/boring-cyborg.yml | 26 +++++++++++++++++++++++--- .github/workflows/post_release.js | 2 +- MAINTAINERS.md | 2 ++ 4 files changed, 26 insertions(+), 12 deletions(-) delete mode 100644 .github/auto_assign-issues.yml diff --git a/.github/auto_assign-issues.yml b/.github/auto_assign-issues.yml deleted file mode 100644 index 1b7aa13da77..00000000000 --- a/.github/auto_assign-issues.yml +++ /dev/null @@ -1,8 +0,0 @@ -addAssignees: true - -# The list of users to assign to new issues. -# If empty or not provided, the repository owner is assigned -assignees: - - heitorlessa - - nmoutschen - - cakepietoast diff --git a/.github/boring-cyborg.yml b/.github/boring-cyborg.yml index 57d840d34dd..9f6554fc784 100644 --- a/.github/boring-cyborg.yml +++ b/.github/boring-cyborg.yml @@ -39,6 +39,9 @@ labelPRBasedOnFilePath: - aws_lambda_powertools/feature_flags/**/* jmespath_util: - aws_lambda_powertools/utilities/jmespath_utils/* + typing: + - aws_lambda_powertools/utilities/typing/* + - mypy.ini utilities: - aws_lambda_powertools/utilities/* - aws_lambda_powertools/utilities/**/* @@ -48,17 +51,34 @@ labelPRBasedOnFilePath: - docs/**/* - mkdocs.yml + github-actions: + - .github/workflows/* + - .github/workflows/**/* + - .github/dependabot.yml + - .github/boring-cyborg.yml + - .github/release-drafter.yml + - .github/semantic.yml + - .github/stale.yml + - .github/mergify.yml + + github-templates: + - .github/ISSUE_TEMPLATE/* + - .github/PULL_REQUEST_TEMPLATE.md + - .github/.chglog/* + - .github/.chglog/**/* + internal: - - .github/* - - .github/**/* - - .chglog/* - .flake8 + - .bandit.baseline - .gitignore - .pre-commit-config.yaml + - MANIFEST.in - Makefile - CONTRIBUTING.md + - MAINTAINERS.md - CODE_OF_CONDUCT.md - LICENSE + - THIRD-PARTY-LICENSES - aws_lambda_powertools_python/shared/* - aws_lambda_powertools_python/shared/** diff --git a/.github/workflows/post_release.js b/.github/workflows/post_release.js index 4b67a6965ec..70474740e2e 100644 --- a/.github/workflows/post_release.js +++ b/.github/workflows/post_release.js @@ -1,4 +1,4 @@ -const STAGED_LABEL = "status/staged-next-release"; +const STAGED_LABEL = "pending-release"; /** * Fetch issues using GitHub REST API diff --git a/MAINTAINERS.md b/MAINTAINERS.md index db9830fa10e..f96f6d00aba 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -82,6 +82,8 @@ These are the most common labels used by maintainers to triage issues, pull requ | feature | New features or minor changes | PR/Release automation | | dependencies | Changes that touch dependencies, e.g. Dependabot, etc. | PR/ automation | | github-actions | Changes in GitHub workflows | PR automation | +| github-templates | Changes in GitHub issue/PR templates | PR automation | +| internal | Changes in governance and chores (linting setup, baseline, etc.) | PR automation | ## Maintainer Responsibilities From f2050080f57bcf59a16253faaa5619f463a3e4ce Mon Sep 17 00:00:00 2001 From: heitorlessa Date: Wed, 1 Jun 2022 11:57:24 +0200 Subject: [PATCH 08/18] docs(maintainers): add PR and issue triage --- MAINTAINERS.md | 36 +++++++++++++++++++++++++++++++----- 1 file changed, 31 insertions(+), 5 deletions(-) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index f96f6d00aba..3d8309159a4 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -23,6 +23,8 @@ - [Contribution is stuck](#contribution-is-stuck) - [Insufficient feedback or information](#insufficient-feedback-or-information) - [Crediting contributions](#crediting-contributions) + - [Inviting contributions](#inviting-contributions) + - [Long running issues or PRs](#long-running-issues-or-prs) ## Overview @@ -101,23 +103,39 @@ Note that this repository is monitored and supported 24/7 by Amazon Security, se ### Review Pull Requests -> WORK-IN-PROGRESS -> TODO: cover labels, CI automation, the right to close, and a reference to FAQ on common issues. - Review pull requests regularly, comment, suggest, reject, merge and close. Accept only high quality pull-requests. Provide code reviews and guidance on incoming pull requests. +PRs are automatically [labelled](#labels) based on file changes and semantic title. Pay attention to whether labels reflect the current state of the PR and correct accordingly. + Use and enforce [semantic versioning](https://semver.org/) pull request titles, as these will be used for [CHANGELOG](CHANGELOG.md) and [Release notes](https://github.com/awslabs/aws-lambda-powertools-python/releases) - make sure they communicate their intent at human level. +> TODO: This is an area we want to automate using the new GitHub GraphQL API. + +For issues linked to a PR, make sure `pending release` label is applied to them when merging. Upon release, all issues with that label will be notified which version contains that change. + +See [Common scenarios](#common-scenarios) section for additional guidance. + ### Triage New Issues -> WORK-IN-PROGRESS -> TODO: cover labels, reference to Roadmap Project Status definition, sensitive labels to defer or prioritize work, and give first priority to original authors on implementation +Manage [labels](#labels), review issues regularly, and create new labels as needed by the project. Remove `triage` label when you're able to confirm the validity of a request, a bug can be reproduced, etc. Give priority to the original author for implementation, unless it is a sensitive task that is best handled by maintainers. + +> TODO: This is an area we want to automate using the new GitHub GraphQL API. + +Make sure issues are assigned to our [board of activities](https://github.com/orgs/awslabs/projects/51/) and have the appropriate [status](https://awslabs.github.io/aws-lambda-powertools-python/latest/roadmap/#roadmap-status-definition). + +Use our [labels](#labels) to signal good first issues to new community members, and to set expectation that this might require additional feedback from the author, other customers, experienced community members and/or maintainers. + +Be aware of [casual contributors](https://opensource.com/article/17/10/managing-casual-contributors) and recurring contributors. Provide the experience and attention you wish you had if you were starting in open source. + +See [Common scenarios](#common-scenarios) section for additional guidance. ### Triage Bug Reports > WORK-IN-PROGRESS > TODO: cover different types of bugs (internal, customer-facing, upstream), reference to releasing section +See [Common scenarios](#common-scenarios) section for additional guidance. + ### Triage RFCs RFCs are meant to be a collaborative process to help us get to the most optimal solution given the context. Their purpose is to ensure everyone understands what this context is, their trade-offs, and alternative solutions that were part of the research before implementation begins. @@ -189,3 +207,11 @@ When in doubt, use `need-more-information` or `need-customer-feedback` labels to ### Crediting contributions > TODO: mention release notes and provide an example. + +### Inviting contributions + +> TODO: sensitive labels to defer or prioritize work + +### Long running issues or PRs + +> TODO: Suggesting 1:1 or group calls, break XXL PRs in smaller chunks and different priorities, etc. From f1443f9ab6661fec69d0aac67b3370fa4774ad83 Mon Sep 17 00:00:00 2001 From: heitorlessa Date: Wed, 1 Jun 2022 14:19:53 +0200 Subject: [PATCH 09/18] docs(maintainers): add bug triaging section --- MAINTAINERS.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 3d8309159a4..f973e4136bb 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -23,6 +23,7 @@ - [Contribution is stuck](#contribution-is-stuck) - [Insufficient feedback or information](#insufficient-feedback-or-information) - [Crediting contributions](#crediting-contributions) + - [Is that a bug?](#is-that-a-bug) - [Inviting contributions](#inviting-contributions) - [Long running issues or PRs](#long-running-issues-or-prs) @@ -131,8 +132,11 @@ See [Common scenarios](#common-scenarios) section for additional guidance. ### Triage Bug Reports -> WORK-IN-PROGRESS -> TODO: cover different types of bugs (internal, customer-facing, upstream), reference to releasing section +Be familiar with [our definition of bug](#is-that-a-bug). If it's not a bug, you can close it or adjust its title and labels - always communicate the reason accordingly. + +For bugs caused by upstream dependencies, replace `bug` with `bug-upstream` label. Ask the author whether they'd like to raise the issue upstream or if they prefer us to do so. + +Assess the impact and make the call on whether we need an emergency release. Contact other [maintainers](#current-maintainers) when in doubt. See [Common scenarios](#common-scenarios) section for additional guidance. @@ -147,7 +151,7 @@ Make sure you ask these questions in mind when reviewing: * Does it focus on the mechanics to solve the use case over fine-grained implementation details? * Can anyone familiar with the code base implement it? * If approved, are they interested in contributing? Do they need any guidance? -* Does this significantly increase the overall project maintenance? e.g., lacks expertise in the team, fast moving target, etc. +* Does this significantly increase the overall project maintenance? Do we have the necessary skills to maintain? * If we can't take this use case, are there alternative projects we could recommend? Or does it call for a new project altogether? When necessary, be upfront that the time it takes to review, approve, and implement a RFC can vary - see [Contribution is stuck](#contribution-is-stuck). Some RFCs may be further updated after implementation, as certain areas become clearer. @@ -208,6 +212,12 @@ When in doubt, use `need-more-information` or `need-customer-feedback` labels to > TODO: mention release notes and provide an example. +### Is that a bug? + +A bug produces incorrect or unexpected results at runtime that differs from its intended behavior. Bugs must be reproducible. They directly affect customers experience at runtime despite following its recommended usage. + +Documentation snippets, use of internal components or unadvertised functionalities are not considered bugs. + ### Inviting contributions > TODO: sensitive labels to defer or prioritize work From 03fb522806838210efbd4fadb5eabeec87069075 Mon Sep 17 00:00:00 2001 From: heitorlessa Date: Wed, 1 Jun 2022 15:02:01 +0200 Subject: [PATCH 10/18] docs(maintainers): link bug report template --- .github/ISSUE_TEMPLATE/bug_report.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.github/ISSUE_TEMPLATE/bug_report.yml b/.github/ISSUE_TEMPLATE/bug_report.yml index 8c557bdbed0..23ffd564a74 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.yml +++ b/.github/ISSUE_TEMPLATE/bug_report.yml @@ -7,6 +7,8 @@ body: attributes: value: | Thank you for submitting a bug report. Please add as much information as possible to help us reproduce, and remove any potential sensitive data. + + Please become familiar with [our definition of bug](MAINTAINERS.md#is-that-a-bug). - type: textarea id: expected_behaviour attributes: From 0bab6cc68f0129375f82dd531731181e7b1a83db Mon Sep 17 00:00:00 2001 From: heitorlessa Date: Wed, 1 Jun 2022 15:05:18 +0200 Subject: [PATCH 11/18] docs(maintainers): fix link bug report template --- .github/ISSUE_TEMPLATE/bug_report.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/ISSUE_TEMPLATE/bug_report.yml b/.github/ISSUE_TEMPLATE/bug_report.yml index 23ffd564a74..6d441bf0c64 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.yml +++ b/.github/ISSUE_TEMPLATE/bug_report.yml @@ -8,7 +8,7 @@ body: value: | Thank you for submitting a bug report. Please add as much information as possible to help us reproduce, and remove any potential sensitive data. - Please become familiar with [our definition of bug](MAINTAINERS.md#is-that-a-bug). + Please become familiar with [our definition of bug](https://github.com/awslabs/aws-lambda-powertools-python/blob/develop/MAINTAINERS.md#is-that-a-bug). - type: textarea id: expected_behaviour attributes: From 8e30376486ed0ab43970346ce8cec94dabe37a7f Mon Sep 17 00:00:00 2001 From: heitorlessa Date: Wed, 1 Jun 2022 16:58:19 +0200 Subject: [PATCH 12/18] docs(maintainers): add releasing section --- .github/workflows/release-drafter.yml | 1 + MAINTAINERS.md | 50 ++++++++++++++++++++++++--- 2 files changed, 47 insertions(+), 4 deletions(-) diff --git a/.github/workflows/release-drafter.yml b/.github/workflows/release-drafter.yml index 59633a634b6..ecc2251ec43 100644 --- a/.github/workflows/release-drafter.yml +++ b/.github/workflows/release-drafter.yml @@ -5,6 +5,7 @@ on: # branches to consider in the event; optional, defaults to all branches: - develop + workflow_dispatch: jobs: update_release_draft: diff --git a/MAINTAINERS.md b/MAINTAINERS.md index f973e4136bb..65b0f88dde7 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -13,6 +13,9 @@ - [Triage Bug Reports](#triage-bug-reports) - [Triage RFCs](#triage-rfcs) - [Releasing a new version](#releasing-a-new-version) + - [Changelog generation](#changelog-generation) + - [Bumping the version](#bumping-the-version) + - [Drafting release notes](#drafting-release-notes) - [Releasing a documentation hotfix](#releasing-a-documentation-hotfix) - [Maintain Overall Health of the Repo](#maintain-overall-health-of-the-repo) - [Manage Roadmap](#manage-roadmap) @@ -112,7 +115,7 @@ Use and enforce [semantic versioning](https://semver.org/) pull request titles, > TODO: This is an area we want to automate using the new GitHub GraphQL API. -For issues linked to a PR, make sure `pending release` label is applied to them when merging. Upon release, all issues with that label will be notified which version contains that change. +For issues linked to a PR, make sure `pending release` label is applied to them when merging. [Upon release](#releasing-a-new-version), all issues with that label will be notified which version contains that change. See [Common scenarios](#common-scenarios) section for additional guidance. @@ -160,8 +163,47 @@ Some examples using our initial and new RFC templates: #92, #94, #95, #991, #122 ### Releasing a new version -> WORK-IN-PROGRESS -> convert what's written in [publish.yml](.github/workflows/publish.yml) +> TODO: This is an area we want to increase automation while keeping communication at human level. + +Firstly, make sure you are using the `develop` branch and it is up to date with the origin. + +There are three main steps to release a new version: Changelog generation, version bumping, and drafting release notes. + +#### Changelog generation + +You can pre-generate a temporary CHANGELOG using `make changelog`. This will generate a `TMP_CHANGELOG.md` with all staged changes under the `unreleased` section. + +Each unreleased line item is a commit. You can adjust them if you find the commit titles are insufficient to describe their intent. Once you're comfortable, bring these changes to the `CHANGELOG.md` with a new version heading like in previous versions. + +#### Bumping the version + +Use `poetry version ` to bump the version. For example, you can use `poetry version minor` when releasing a minor version. + +NOTE. Make sure both `CHANGELOG` and `pyproject.toml` are committed and pushed to the remote `develop` branch before proceeding. + +#### Drafting release notes + +Visit the [Releases page](https://github.com/awslabs/aws-lambda-powertools-python/releases) and choose the edit pencil button. + +Make sure the `tag` field reflects the new version you're releasing, target branch field is set to `develop`, and `release title` matches your tag e.g., `v1.26.0`. + +You'll notice that all changes are grouped based on their [labels](#labels) like `feature`, `bug`, `documentation`, etc. + +> **Q: What if there's an incorrect title or grouping?** + +Edit the respective PR title and update their [labels](#labels). Then run the [Release Drafter workflow](https://github.com/awslabs/aws-lambda-powertools-python/actions/workflows/release-drafter.yml) to update the Draft release. + +The best part comes now. Replace the placeholder `[Human readable summary of changes]` with what you'd like to communicate to customers what this release is all about. Always put yourself in the customers shoes. For that, these are some questions to keep in mind when drafting your first or future release notes: + +* Can customers understand at a high level what changed in this release? +* Is there a link to the documentation where they can read more about each main change? +* Are there any graphics or code snippets that can enhance readability? +* Are we calling out any key contributor(s) to this release? + - All contributors are automatically credited, use this as an exceptional case to feature them + +Once you're happy, hit `Publish release`. This will kick off the [Publishing workflow](https://github.com/awslabs/aws-lambda-powertools-python/actions/workflows/publish.yml) and within a few minutes you should see the latest version in PyPi, and all issues labelled as `pending-release` will be notified. + +> TODO: Wait for @am29d new Lambda Layers pipeline work to complete, then add how Lambda Layers are published ### Releasing a documentation hotfix @@ -210,7 +252,7 @@ When in doubt, use `need-more-information` or `need-customer-feedback` labels to ### Crediting contributions -> TODO: mention release notes and provide an example. +We credit all contributions as part of each [release note](https://github.com/awslabs/aws-lambda-powertools-python/releases) as an automated process. If you find that contributors are missing from the release note you're producing, please add them manually. ### Is that a bug? From 384fda96976133eb3138ca279854d2e46db845e5 Mon Sep 17 00:00:00 2001 From: heitorlessa Date: Wed, 1 Jun 2022 17:13:01 +0200 Subject: [PATCH 13/18] docs(maintainers): add long running issues/prs scenario --- MAINTAINERS.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 65b0f88dde7..cdc098110b5 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -266,4 +266,6 @@ Documentation snippets, use of internal components or unadvertised functionaliti ### Long running issues or PRs -> TODO: Suggesting 1:1 or group calls, break XXL PRs in smaller chunks and different priorities, etc. +Try offering a 1:1 call in the attempt to get to a mutual understanding, and clarify areas that maintainers could help. + +In the rare cases where both parties don't have the bandwidth or expertise to continue, it's best to use the `revisit-in-3-months` label. By then, see if it's possible to break the PR or issue in smaller chunks, and eventually close if there is no progress. From 21ba6c5ca5a9d9239d6db56ca56857465502bb73 Mon Sep 17 00:00:00 2001 From: heitorlessa Date: Wed, 1 Jun 2022 17:39:23 +0200 Subject: [PATCH 14/18] docs(maintainers): add remaining areas --- MAINTAINERS.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index cdc098110b5..a7048f346d2 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -27,7 +27,7 @@ - [Insufficient feedback or information](#insufficient-feedback-or-information) - [Crediting contributions](#crediting-contributions) - [Is that a bug?](#is-that-a-bug) - - [Inviting contributions](#inviting-contributions) + - [Mentoring contributions](#mentoring-contributions) - [Long running issues or PRs](#long-running-issues-or-prs) ## Overview @@ -213,7 +213,7 @@ This workflow will update both user guide and API documentation. ### Maintain Overall Health of the Repo -> TODO: Coordinate in removing `master` and renaming `develop` to `main` +> TODO: Coordinate removing `master` and renaming `develop` to `main` Keep the `develop` branch at production quality at all times. Backport features as needed. Cut release branches and tags to enable future patches. @@ -233,9 +233,9 @@ Actions that negatively impact the project will be handled by the admins, in coo ### Becoming a maintainer -> WORK-IN-PROGRESS -> TODO: cover ideas of what a future process might look like for when we're ready to do it fairly and securely. +We will revisit this in 2023. We need to improve our understanding of how other projects are doing, their mechanisms to promote key contributors, and how they interact on a daily basis. +We suspect this process might look similar to the [OpenSearch project](https://github.com/opensearch-project/.github/blob/main/MAINTAINERS.md#becoming-a-maintainer). ## Common scenarios ### Contribution is stuck @@ -260,9 +260,11 @@ A bug produces incorrect or unexpected results at runtime that differs from its Documentation snippets, use of internal components or unadvertised functionalities are not considered bugs. -### Inviting contributions +### Mentoring contributions -> TODO: sensitive labels to defer or prioritize work +Always favor mentoring issue authors to contribute, unless they're not interested or the implementation is sensitive (_e.g., complexity, time to release, etc._). + +Make use of `help wanted` and `good first issue` to signal additional contributions the community can help. ### Long running issues or PRs From 17545fa7bc12eca67b0ba68f652a4efd73d653fe Mon Sep 17 00:00:00 2001 From: heitorlessa Date: Wed, 1 Jun 2022 18:08:12 +0200 Subject: [PATCH 15/18] docs(maintainers): line editing --- MAINTAINERS.md | 102 ++++++++++++++++++++++++------------------------- 1 file changed, 51 insertions(+), 51 deletions(-) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index a7048f346d2..c983d9a4a1e 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -58,38 +58,38 @@ Previous active maintainers who contributed to this project. These are the most common labels used by maintainers to triage issues, pull requests (PR), and for project management: -| Label | Usage | Notes | -| ---------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------- | -| triage | New issues that require maintainers review | Issue template | -| bug | Unexpected, reproducible and unintended software behavior | PR/Release automation; Doc snippets are excluded; | -| documentation | Documentation improvements | PR/Release automation; Doc additions, fixes, etc.; | -| feature-request | New or enhancements to existing features | Issue template | -| typing | New or enhancements to static typing | Issue template | -| RFC | Technical design documents related to a feature request | Issue template | -| bug-upstream | Bug caused by upstream dependency | | -| help wanted | Tasks you want help from anyone to move forward | Bandwidth, complex topics, etc. | -| need-customer-feedback | Tasks that require additional feedback before proceeding | 80/20% rule, uncertain, etc. | -| need-more-information | Missing information before making any call | | -| need-documentation | PR is missing or has incomplete documentation | | -| need-issue | PR is missing a related issue for tracking change | Needs to be automated | -| need-rfc | Feature request requires a RFC to improve discussion | | -| pending-release | Merged changes that will be available soon | Release automation auto-closes/notifies it | -| revisit-in-3-months | Blocked issues/PRs that needs to be revisited | Often related to `need-customer-feedback`, prioritization, etc. | -| breaking-change | Changes that will cause customer impact and needs careful triage | | -| do-not-merge | PRs that are blocked for varying reasons | Might not have a timeline in sight | -| size/XS | PRs between 0-9 LOC | PR automation | -| size/S | PRs between 10-29 LOC | PR automation | -| size/M | PRs between 30-99 LOC | PR automation | -| size/L | PRs between 100-499 LOC | PR automation | -| size/XL | PRs between 500-999 LOC, typically PRs that evolved with feedback | PR automation | -| size/XXL | PRs with 1K+ LOC, largely documentation related | PR automation | -| tests | PRs that add or change tests | PR automation | -| `` | PRs related to a Powertools utility, e.g. `parameters`, `tracer` | PR automation | -| feature | New features or minor changes | PR/Release automation | -| dependencies | Changes that touch dependencies, e.g. Dependabot, etc. | PR/ automation | -| github-actions | Changes in GitHub workflows | PR automation | -| github-templates | Changes in GitHub issue/PR templates | PR automation | -| internal | Changes in governance and chores (linting setup, baseline, etc.) | PR automation | +| Label | Usage | Notes | +| ---------------------- | ---------------------------------------------------------------- | --------------------------------------------------------------- | +| triage | New issues that require maintainers review | Issue template | +| bug | Unexpected, reproducible and unintended software behavior | PR/Release automation; Doc snippets are excluded; | +| documentation | Documentation improvements | PR/Release automation; Doc additions, fixes, etc.; | +| feature-request | New or enhancements to existing features | Issue template | +| typing | New or enhancements to static typing | Issue template | +| RFC | Technical design documents related to a feature request | Issue template | +| bug-upstream | Bug caused by upstream dependency | | +| help wanted | Tasks you want help from anyone to move forward | Bandwidth, complex topics, etc. | +| need-customer-feedback | Tasks that need more feedback before proceeding | 80/20% rule, uncertain, etc. | +| need-more-information | Missing information before making any calls | | +| need-documentation | PR is missing or has incomplete documentation | | +| need-issue | PR is missing a related issue for tracking change | Needs to be automated | +| need-rfc | Feature request requires a RFC to improve discussion | | +| pending-release | Merged changes that will be available soon | Release automation auto-closes/notifies it | +| revisit-in-3-months | Blocked issues/PRs that need to be revisited | Often related to `need-customer-feedback`, prioritization, etc. | +| breaking-change | Changes that will cause customer impact and need careful triage | | +| do-not-merge | PRs that are blocked for varying reasons | Timeline is uncertain | +| size/XS | PRs between 0-9 LOC | PR automation | +| size/S | PRs between 10-29 LOC | PR automation | +| size/M | PRs between 30-99 LOC | PR automation | +| size/L | PRs between 100-499 LOC | PR automation | +| size/XL | PRs between 500-999 LOC, often PRs that grown with feedback | PR automation | +| size/XXL | PRs with 1K+ LOC, largely documentation related | PR automation | +| tests | PRs that add or change tests | PR automation | +| `` | PRs related to a Powertools utility, e.g. `parameters`, `tracer` | PR automation | +| feature | New features or minor changes | PR/Release automation | +| dependencies | Changes that touch dependencies, e.g. Dependabot, etc. | PR/ automation | +| github-actions | Changes in GitHub workflows | PR automation | +| github-templates | Changes in GitHub issue/PR templates | PR automation | +| internal | Changes in governance and chores (linting setup, baseline, etc.) | PR automation | ## Maintainer Responsibilities @@ -109,13 +109,13 @@ Note that this repository is monitored and supported 24/7 by Amazon Security, se Review pull requests regularly, comment, suggest, reject, merge and close. Accept only high quality pull-requests. Provide code reviews and guidance on incoming pull requests. -PRs are automatically [labelled](#labels) based on file changes and semantic title. Pay attention to whether labels reflect the current state of the PR and correct accordingly. +PRs are [labeled](#labels) based on file changes and semantic title. Pay attention to whether labels reflect the current state of the PR and correct accordingly. -Use and enforce [semantic versioning](https://semver.org/) pull request titles, as these will be used for [CHANGELOG](CHANGELOG.md) and [Release notes](https://github.com/awslabs/aws-lambda-powertools-python/releases) - make sure they communicate their intent at human level. +Use and enforce [semantic versioning](https://semver.org/) pull request titles, as these will be used for [CHANGELOG](CHANGELOG.md) and [Release notes](https://github.com/awslabs/aws-lambda-powertools-python/releases) - make sure they communicate their intent at the human level. > TODO: This is an area we want to automate using the new GitHub GraphQL API. -For issues linked to a PR, make sure `pending release` label is applied to them when merging. [Upon release](#releasing-a-new-version), all issues with that label will be notified which version contains that change. +For issues linked to a PR, make sure `pending release` label is applied to them when merging. [Upon release](#releasing-a-new-version), these issues will be notified which release version contains their change. See [Common scenarios](#common-scenarios) section for additional guidance. @@ -125,9 +125,9 @@ Manage [labels](#labels), review issues regularly, and create new labels as need > TODO: This is an area we want to automate using the new GitHub GraphQL API. -Make sure issues are assigned to our [board of activities](https://github.com/orgs/awslabs/projects/51/) and have the appropriate [status](https://awslabs.github.io/aws-lambda-powertools-python/latest/roadmap/#roadmap-status-definition). +Make sure issues are assigned to our [board of activities](https://github.com/orgs/awslabs/projects/51/) and have the right [status](https://awslabs.github.io/aws-lambda-powertools-python/latest/roadmap/#roadmap-status-definition). -Use our [labels](#labels) to signal good first issues to new community members, and to set expectation that this might require additional feedback from the author, other customers, experienced community members and/or maintainers. +Use our [labels](#labels) to signal good first issues to new community members, and to set expectation that this might need additional feedback from the author, other customers, experienced community members and/or maintainers. Be aware of [casual contributors](https://opensource.com/article/17/10/managing-casual-contributors) and recurring contributors. Provide the experience and attention you wish you had if you were starting in open source. @@ -145,7 +145,7 @@ See [Common scenarios](#common-scenarios) section for additional guidance. ### Triage RFCs -RFCs are meant to be a collaborative process to help us get to the most optimal solution given the context. Their purpose is to ensure everyone understands what this context is, their trade-offs, and alternative solutions that were part of the research before implementation begins. +RFC is a collaborative process to help us get to the most optimal solution given the context. Their purpose is to ensure everyone understands what this context is, their trade-offs, and alternative solutions that were part of the research before implementation begins. Make sure you ask these questions in mind when reviewing: @@ -154,10 +154,10 @@ Make sure you ask these questions in mind when reviewing: * Does it focus on the mechanics to solve the use case over fine-grained implementation details? * Can anyone familiar with the code base implement it? * If approved, are they interested in contributing? Do they need any guidance? -* Does this significantly increase the overall project maintenance? Do we have the necessary skills to maintain? +* Does this significantly increase the overall project maintenance? Do we have the skills to maintain it? * If we can't take this use case, are there alternative projects we could recommend? Or does it call for a new project altogether? -When necessary, be upfront that the time it takes to review, approve, and implement a RFC can vary - see [Contribution is stuck](#contribution-is-stuck). Some RFCs may be further updated after implementation, as certain areas become clearer. +When necessary, be upfront that the time to review, approve, and implement a RFC can vary - see [Contribution is stuck](#contribution-is-stuck). Some RFCs may be further updated after implementation, as certain areas become clearer. Some examples using our initial and new RFC templates: #92, #94, #95, #991, #1226 @@ -185,9 +185,9 @@ NOTE. Make sure both `CHANGELOG` and `pyproject.toml` are committed and pushed t Visit the [Releases page](https://github.com/awslabs/aws-lambda-powertools-python/releases) and choose the edit pencil button. -Make sure the `tag` field reflects the new version you're releasing, target branch field is set to `develop`, and `release title` matches your tag e.g., `v1.26.0`. +Make sure the `tag` field reflects the new version you're releasing, the target branch field is set to `develop`, and `release title` matches your tag e.g., `v1.26.0`. -You'll notice that all changes are grouped based on their [labels](#labels) like `feature`, `bug`, `documentation`, etc. +You'll notice we group all changes based on their [labels](#labels) like `feature`, `bug`, `documentation`, etc. > **Q: What if there's an incorrect title or grouping?** @@ -201,7 +201,7 @@ The best part comes now. Replace the placeholder `[Human readable summary of cha * Are we calling out any key contributor(s) to this release? - All contributors are automatically credited, use this as an exceptional case to feature them -Once you're happy, hit `Publish release`. This will kick off the [Publishing workflow](https://github.com/awslabs/aws-lambda-powertools-python/actions/workflows/publish.yml) and within a few minutes you should see the latest version in PyPi, and all issues labelled as `pending-release` will be notified. +Once you're happy, hit `Publish release`. This will kick off the [Publishing workflow](https://github.com/awslabs/aws-lambda-powertools-python/actions/workflows/publish.yml) and within a few minutes you should see the latest version in PyPi, and all issues labeled as `pending-release` will be notified. > TODO: Wait for @am29d new Lambda Layers pipeline work to complete, then add how Lambda Layers are published @@ -233,7 +233,7 @@ Actions that negatively impact the project will be handled by the admins, in coo ### Becoming a maintainer -We will revisit this in 2023. We need to improve our understanding of how other projects are doing, their mechanisms to promote key contributors, and how they interact on a daily basis. +In 2023, we will revisit this. We need to improve our understanding of how other projects are doing, their mechanisms to promote key contributors, and how they interact daily. We suspect this process might look similar to the [OpenSearch project](https://github.com/opensearch-project/.github/blob/main/MAINTAINERS.md#becoming-a-maintainer). ## Common scenarios @@ -242,23 +242,23 @@ We suspect this process might look similar to the [OpenSearch project](https://g A contribution can get stuck often due to lack of bandwidth and language barrier. For bandwidth issues, check whether the author needs help. Make sure you get their permission before pushing code into their existing PR - do not create a new PR unless strictly necessary. -For language barrier and others, don't hesitate to offer a 1:1 chat to get them unblocked. Often times, English might not be their primary language, and writing in public might put them off, or come across not the way they intended to be. +For language barrier and others, offer a 1:1 chat to get them unblocked. Often times, English might not be their primary language, and writing in public might put them off, or come across not the way they intended to be. -In other cases, you may have constrained capacity. Use `help wanted` label when you want to signal additional maintainers and external contributors that you could use a hand to move it forward. +In other cases, you may have constrained capacity. Use `help wanted` label when you want to signal other maintainers and external contributors that you could use a hand to move it forward. ### Insufficient feedback or information -When in doubt, use `need-more-information` or `need-customer-feedback` labels to signal more context and feedback are necessary before proceeding. You can also use `revisit-in-3-months` label when you anticipate it might take a while to gather enough information before you can make a decision. +When in doubt, use `need-more-information` or `need-customer-feedback` labels to signal more context and feedback are necessary before proceeding. You can also use `revisit-in-3-months` label when you expect it might take a while to gather enough information before you can decide. ### Crediting contributions -We credit all contributions as part of each [release note](https://github.com/awslabs/aws-lambda-powertools-python/releases) as an automated process. If you find that contributors are missing from the release note you're producing, please add them manually. +We credit all contributions as part of each [release note](https://github.com/awslabs/aws-lambda-powertools-python/releases) as an automated process. If you find contributors are missing from the release note you're producing, please add them manually. ### Is that a bug? -A bug produces incorrect or unexpected results at runtime that differs from its intended behavior. Bugs must be reproducible. They directly affect customers experience at runtime despite following its recommended usage. +A bug produces incorrect or unexpected results at runtime that differ from its intended behavior. Bugs must be reproducible. They directly affect customers experience at runtime despite following its recommended usage. -Documentation snippets, use of internal components or unadvertised functionalities are not considered bugs. +Documentation snippets, use of internal components, or unadvertised functionalities are not considered bugs. ### Mentoring contributions @@ -268,6 +268,6 @@ Make use of `help wanted` and `good first issue` to signal additional contributi ### Long running issues or PRs -Try offering a 1:1 call in the attempt to get to a mutual understanding, and clarify areas that maintainers could help. +Try offering a 1:1 call in the attempt to get to a mutual understanding and clarify areas that maintainers could help. In the rare cases where both parties don't have the bandwidth or expertise to continue, it's best to use the `revisit-in-3-months` label. By then, see if it's possible to break the PR or issue in smaller chunks, and eventually close if there is no progress. From 1ef9b178f1f5770c62cb96614fd7cdd023c4d516 Mon Sep 17 00:00:00 2001 From: heitorlessa Date: Wed, 1 Jun 2022 18:13:57 +0200 Subject: [PATCH 16/18] docs(maintainers): missing label --- MAINTAINERS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index c983d9a4a1e..248088b83b6 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -62,6 +62,7 @@ These are the most common labels used by maintainers to triage issues, pull requ | ---------------------- | ---------------------------------------------------------------- | --------------------------------------------------------------- | | triage | New issues that require maintainers review | Issue template | | bug | Unexpected, reproducible and unintended software behavior | PR/Release automation; Doc snippets are excluded; | +| not-a-bug | New and existing bug reports incorrectly submitted as bug | Analytics | | documentation | Documentation improvements | PR/Release automation; Doc additions, fixes, etc.; | | feature-request | New or enhancements to existing features | Issue template | | typing | New or enhancements to static typing | Issue template | From 850c13bed9394ea3a809364635721adcf6a3d70c Mon Sep 17 00:00:00 2001 From: heitorlessa Date: Thu, 2 Jun 2022 10:15:53 +0200 Subject: [PATCH 17/18] docs(maintainers): extra rfc question on michal's feedback --- MAINTAINERS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 248088b83b6..4fdb4e3292f 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -152,6 +152,7 @@ Make sure you ask these questions in mind when reviewing: * Does it use our [RFC template](https://github.com/awslabs/aws-lambda-powertools-python/issues/new?assignees=&labels=RFC%2Ctriage&template=rfc.yml&title=RFC%3A+TITLE)? * Does the match our [Tenets](https://awslabs.github.io/aws-lambda-powertools-python/latest/#tenets)? +* Does the proposal address the use case? If so, is the recommended usage explicit? * Does it focus on the mechanics to solve the use case over fine-grained implementation details? * Can anyone familiar with the code base implement it? * If approved, are they interested in contributing? Do they need any guidance? From a062051e64cc4bfe749a0ae8a5b3c1b391e49883 Mon Sep 17 00:00:00 2001 From: heitorlessa Date: Thu, 2 Jun 2022 10:27:18 +0200 Subject: [PATCH 18/18] docs(maintainers): note on common scenarios on michal's feedback --- MAINTAINERS.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 4fdb4e3292f..8db5f42fd59 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -96,6 +96,8 @@ These are the most common labels used by maintainers to triage issues, pull requ Maintainers are active and visible members of the community, and have [maintain-level permissions on a repository](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization). Use those privileges to serve the community and evolve code as follows. +Be aware of recurring ambiguous situations and [document them](#common-scenarios) to help your fellow maintainers. + ### Uphold Code of Conduct Model the behavior set forward by the [Code of Conduct](CODE_OF_CONDUCT.md) and raise any violations to other maintainers and admins. There could be unusual circumstances where inappropriate behavior does not immediately fall within the [Code of Conduct](CODE_OF_CONDUCT.md). These might be nuanced and should be handled with extra care - when in doubt, do not engage and reach out to other maintainers and admins. @@ -240,6 +242,8 @@ In 2023, we will revisit this. We need to improve our understanding of how other We suspect this process might look similar to the [OpenSearch project](https://github.com/opensearch-project/.github/blob/main/MAINTAINERS.md#becoming-a-maintainer). ## Common scenarios +These are recurring ambiguous situations that new and existing maintainers may encounter. They serve as guidance. It is up to each maintainer to follow, adjust, or handle in a different manner as long as [our conduct is consistent](#uphold-code-of-conduct) + ### Contribution is stuck A contribution can get stuck often due to lack of bandwidth and language barrier. For bandwidth issues, check whether the author needs help. Make sure you get their permission before pushing code into their existing PR - do not create a new PR unless strictly necessary.