Your first contribution

Thank you for your interest in contributing to our project - we couldn't be more excited!

graph LR
    Learn["Learn about contributions"] --> Find["Find areas to work / get mentoring"] --> Work["Prepare pull request"] --> Closing["Take learnings with you"]

End-to-end process

Types of contributions

We consider any contribution that help this project improve everyone's experience to be valid, as long as you agree with our tenets, licensing, and Code of Conduct.

Whether you're new contributor or a pro, we compiled a list of the common contributions to help you choose your first:

Please check existing open, or recently closed issues before creating a new one.

Each type link goes to their respective template, or Discord invite.

Type	Description
Documentation	Ideas to make user guide or API guide clearer. It generally go from typos, diagrams, tutorials, the lack of documentation, etc.
Feature request	New functionalities or enhancements that could help you, your team, existing and future customers. Check out our process to understand how we prioritize it.
Design proposals	Request for Comments (RFC) including user experience (UX) based on a feature request to gather the community feedback, and demonstrate the art of the possible.
Bug report	A runtime error that is reproducible whether you have an idea how to solve it or not.
Advocacy	Share what you did with Powertools for AWS Lambda. Blog posts, workshops, presentation, sample applications, podcasts, etc.
Public reference	Become a public reference to share how you're using Powertools for AWS Lambda at your organization.
Discussions	Kick off a discussion on Discord, introduce yourself, and help respond to existing questions from the community.
Static typing	Improvements to increase or correct static typing coverage to ease maintenance, autocompletion, etc.
Technical debt	Suggest areas to address technical debt that could make maintenance easier or provide customer value faster. Generally used by maintainers and contributors.
Governance	Ideas to improve to our governance processes, automation, and anything internal. Typically used by maintainers and regular contributors.

Finding contributions to work on

Besides suggesting ideas you think it'll improve everyone's experience, these are the most common places to find work:

Area	Description
Help wanted issues	These are triaged areas that we'd appreciate any level of contribution - from opinions to actual implementation.
Missing customer feedback issues	These are items we'd like to hear from more customers before making any decision. Sharing your thoughts, use case, or asking additional questions are great help.
Pending design proposals	These are feature requests that initially look good but need a RFC to enrich the discussion by validating user-experience, tradeoffs, and highlight use cases.
Backlog items	We use GitHub projects to surface what we're working on, needs triage, etc. This view shows items we already triaged but don't have the bandwidth to tackle them just yet.
Documentation	Documentation can always be improved. Look for areas that a better example, or a diagram, or more context helps everyone - keep in mind a diverse audience and English as a second language folks.
Participate in discussions	There's always a discussion that could benefit others in the form of documentation, blog post, etc.
Roadmap	Some roadmap items need a RFC to discuss design options, or gather customers use case before we can prioritize it.
Build a sample application	Using Powertools for AWS Lambda in different contexts will give you insights on what could be made easier, which documentation could be enriched, and more.

Still couldn't find anything that match your skill set?

Please reach out on [Discord](https://discord.gg/B8zZKbbyET){target="_blank" rel="nofollow"}, specially if you'd like to get mentoring for a task you'd like to take but you don't feel ready yet :)

Contributions are meant to be bi-directional. There's always something we can learn from each other.

Sending a pull request

First time creating a Pull Request? Keep this document handy.

Before sending us a pull request, please ensure that:

• You are working against the latest source on the develop branch.
• You check existing open, and recently merged pull requests to make sure someone else hasn't addressed the problem already.
• You open an issue before you begin any implementation. We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.
• Create a new branch named after the change you are contributing e.g. feat/logger-debug-sampling

Ready?

These are the steps to send a pull request:

1. Run all formatting, linting, tests, documentation and baseline checks: make pr
2. Commit to your fork using clear commit messages. Don't worry about typos or format, we squash all commits during merge.
3. Send us a pull request with a conventional semantic title.
4. Fill in the areas pre-defined in the pull request body to help expedite reviewing your work.
5. Pay attention to any automated CI failures reported in the pull request, and stay involved in the conversation.

Code of Conduct

This project has adopted the Amazon Open Source Code of Conduct

For more information see the Code of Conduct FAQ or contact opensource-codeofconduct@amazon.com with any additional questions or comments.

Security issue notifications

If you discover a potential security issue in this project, we kindly ask you to notify AWS/Amazon Security via our vulnerability reporting page. Please do not create a public github issue.

Troubleshooting

API reference documentation

When you are working on the codebase and you use the local API reference documentation to preview your changes, you might see the following message: Module aws_lambda_powertools not found.

This happens when:

• You did not install the local dev environment yet
  • You can install dev deps with make dev command
• The code in the repository is raising an exception while the pdoc is scanning the codebase
  • Unfortunately, this exception is not shown to you, but if you run, poetry run pdoc --pdf aws_lambda_powertools, the exception is shown and you can prevent the exception from being raised
  • Once resolved the documentation should load correctly again