Your first contribution
Thank you for your interest in contributing to our project - we couldn't be more excited!
Learn["Learn about contributions"] --> Find["Find areas to work / get mentoring"] --> Work["Prepare pull request"] --> Closing["Take learnings with you"]
Types of contributions¶
Whether you're new contributor or a pro, we compiled a list of the common contributions to help you choose your first:
Each type link goes to their respective template, or Discord invite.
|Ideas to make user guide or API guide clearer. This includes typos, diagrams, tutorials, the lack of documentation, etc.
|New functionalities or enhancements that could help you, your team, or existing and future customers. Check out our process to understand how we prioritize it.
|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.
|A runtime error that is reproducible whether you have an idea how to solve it or not.
|Share what you did with Powertools for AWS Lambda. Blog posts, workshops, presentation, sample applications, podcasts, etc.
|Become a public reference to share how you're using Powertools for AWS Lambda at your organization.
|Kick off a discussion on Discord, introduce yourself, and help respond to existing questions from the community.
|Suggest areas to address technical debt, governance, and anything internal. Generally used by maintainers and 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:
|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.
|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 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.
|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, 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 main branch, unless instructed otherwise.
- You check existing open, and recently merged pull requests to make sure someone else hasn't addressed the problem already.
- You discuss and agree your proposed changes under an existing issue or a new 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.
These are the steps to send a pull request:
- Make sure that all formatting, linting, and tests tasks run as git pre-commit & pre-push hooks are passing.
- Commit to your fork using clear commit messages. Don't worry about typos or format, we squash all commits during merge.
- Send us a pull request with a conventional semantic title - see full list of scopes and actions here.
- Fill in the areas pre-defined in the pull request body to help expedite reviewing your work.
- 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
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.