Update BECOMING_A_CORE_CONTRIBUTOR.md (#11337)
Co-authored-by: Justus Schock <12886177+justusschock@users.noreply.github.com> Co-authored-by: ananthsub <ananth.subramaniam@gmail.com>
This commit is contained in:
Carlos Mocholí
GitHub
parent
6107ce8e0d
commit
08f6a079c7
|
|
@ -1,13 +1,14 @@
|
|||
# How to become a core contributor
|
||||
|
||||
Thanks for your interest in joining the Lightning team! We’re a rapidly growing project which is poised to become the go-to framework for DL researchers!
|
||||
We're currently recruiting for a team of 5 core maintainers.
|
||||
|
||||
As a core maintainer you will have a strong say in the direction of the project. Big changes will require a majority of maintainers to agree.
|
||||
As a core maintainer, you will have a strong say in the direction of the project. Big changes will require a majority of maintainers to agree.
|
||||
Our development is fully open, so you can still raise your voice just by commenting on issues and pull requests! Doing so is a big step in becoming part of core.
|
||||
|
||||
## Code of conduct
|
||||
|
||||
First and foremost, you'll be evaluated against [these core values](https://github.com/PyTorchLightning/pytorch-lightning/blob/master/.github/CONTRIBUTING.md). Any code we commit or feature we add needs to align with those core values.
|
||||
First and foremost, you'll be evaluated against [these core values](CONTRIBUTING.md). Any code we commit or feature we add needs to align with those core values.
|
||||
Any collaboration and communication must adhere to our [code of conduct](CODE_OF_CONDUCT.md).
|
||||
|
||||
## The bar for joining the team
|
||||
|
||||
|
|
@ -17,53 +18,48 @@ With that said, the Lightning team will be diverse and a reflection of an inclus
|
|||
|
||||
## Responsibilities:
|
||||
|
||||
The responsibilities mainly revolve around 3 things.
|
||||
Here, we describe general expectations from core contributors:
|
||||
|
||||
### Github issues
|
||||
|
||||
- Here we want to help users have an amazing experience. These range from questions from new people getting into DL to questions from researchers about doing something esoteric with Lightning
|
||||
Often, these issues require some sort of bug fix, document clarification or new functionality to be scoped out.
|
||||
- Our community is the main motivation for our work. Help them have an amazing experience. Issues range from answering questions from new people getting into deep learning to helping researchers doing something esoteric.
|
||||
They often require some sort of bug fix, document clarification, or new functionality to be scoped out. You can help them solve their issues and guide them to completion.
|
||||
|
||||
- To become a core member you must resolve at least 10 Github issues which align with the API design goals for Lightning. By the end of these 10 issues I should feel comfortable in the way you answer user questions
|
||||
Pleasant/helpful tone.
|
||||
- Weigh in on discussions in a timely fashion. Most importantly, on the RFCs (request for comments) that will shape the future of Lightning.
|
||||
There are some big decisions which the project must make. For these, we expect core contributors to have something meaningful to add, especially if it’s their area of expertise.
|
||||
|
||||
- Can abstract from that issue or bug into functionality that might solve other related issues or makes the platform more flexible.
|
||||
- Propose your own RFCs that align with the API design goals for Lightning.
|
||||
|
||||
- Identify opportunities from an issue or bug that can solve other related issues or make the framework more flexible.
|
||||
|
||||
- Don’t make users feel like they don’t know what they’re doing. We’re here to help and to make everyone’s experience delightful.
|
||||
|
||||
### Pull requests
|
||||
- Help out with critical bugs. Nobody likes bugs so you'll be a hero if you fix them!
|
||||
|
||||
- Here we need to ensure the code that enters Lightning is high quality. For each PR we need to:
|
||||
- Make sure code coverage does not decrease
|
||||
- Documents are updated
|
||||
- Code is elegant and simple
|
||||
- Code is NOT overly engineered or hard to read
|
||||
- Ask yourself, could a non-engineer understand what’s happening here?
|
||||
- Make sure new tests are written
|
||||
- Is this NECESSARY for Lightning? There are some PRs which are just purely about adding engineering complexity which have no place in Lightning.
|
||||
Guidance
|
||||
- Some other PRs are for people who are wanting to get involved and add something unnecessary. We do want their help though! So don’t approve the PR, but direct them to a Github issue that they might be interested in helping with instead!
|
||||
- To be considered for core contributor, please review 10 PRs and help the authors land it on master. Once you've finished the review, ping me
|
||||
for a sanity check. At the end of 10 PRs if your PR reviews are inline with expectations described above, then you can merge PRs on your own going forward,
|
||||
otherwise we'll do a few more until we're both comfortable :)
|
||||
### Pull requests (PRs)
|
||||
|
||||
### Project directions
|
||||
- Pull requests are the evolutionary mechanism of Lightning, so quality is extremely important. Make sure contributors adhere to the guidelines described in the [contributing section](CONTRIBUTING.md#Pull-request).
|
||||
|
||||
There are some big decisions which the project must make. For these I expect core contributors to have something meaningful to add if it’s their area of expertise.
|
||||
- Some PRs are from people who want to get involved and try to add something unnecessary. We do want their help though! So don’t approve the PR, but direct them to a Github issue that they might be interested in helping with instead!
|
||||
|
||||
- Provide strong and valuable feedback during reviews. This is expected both when reviewing community PRs as well as PRs from other core contributors.
|
||||
Even if you are not part of core yet, you can still review and approve PRs. This will show us your abilities.
|
||||
|
||||
### Diversity
|
||||
|
||||
Lightning should reflect the broader community it serves. As such we should have scientists/researchers from
|
||||
different fields contributing!
|
||||
Lightning should reflect the broader community it serves. As such we should have scientists/researchers from different fields contributing!
|
||||
|
||||
The first 5 core contributors will fit this profile. Thus if you overlap strongly with experiences and expertise as someone else on the team, you might have to wait until the next set of contributors are added.
|
||||
### Community
|
||||
|
||||
### Summary: Requirements to apply
|
||||
We have an active [Slack](https://join.slack.com/t/pytorch-lightning/shared_invite/zt-pw5v393p-qRaDgEk24~EjiZNBpSQFgQ) community, where questions are asked daily.
|
||||
This is a great way to show off your Lightning and PyTorch knowledge, and help out others.
|
||||
There's also [GitHub discussions](https://github.com/PyTorchLightning/pytorch-lightning/discussions).
|
||||
|
||||
The goal is to be inline with expectations for solving issues by the last one so you can do them on your own. If not, I might ask you to solve a few more specific ones.
|
||||
## Applying
|
||||
|
||||
- Solve 10+ Github issues.
|
||||
- Create 5+ meaningful PRs which solves some reported issue - bug,
|
||||
- Perform 10+ PR reviews from other contributors.
|
||||
There are no precise targets for becoming a core contributor. In the past, community members have become core after fitting the previous expectations consistently.
|
||||
We are on the lookout for new people to join, however, if you feel like you meet the expectations already and we haven't reached out to you yet, feel free to ping us privately on [Slack](https://join.slack.com/t/pytorch-lightning/shared_invite/zt-pw5v393p-qRaDgEk24~EjiZNBpSQFgQ)!.
|
||||
|
||||
If you want to be considered, ping me on [Slack](https://join.slack.com/t/pytorch-lightning/shared_invite/zt-pw5v393p-qRaDgEk24~EjiZNBpSQFgQ).
|
||||
## Employment
|
||||
|
||||
You can also become a [Grid.ai](https://www.grid.ai) employee or intern and work on Lightning. To get started, you can email `careers@grid.ai` with your resume or check out our [open job postings](https://boards.greenhouse.io/gridai).
|
||||
|
|
|
|||
|
|
@ -232,21 +232,41 @@ python -m pytest -v tests/trainer/test_trainer_cli.py::test_default_args
|
|||
|
||||
We welcome any useful contribution! For your convenience here's a recommended workflow:
|
||||
|
||||
0. Think about what you want to do - fix a bug, repair docs, etc. If you want to implement a new feature or enhance an existing one, start by opening a GitHub issue to explain the feature and the motivation. Members from core-lightning will take a look (it might take some time - we are often overloaded with issues!) and discuss it. Once an agreement was reached - start coding.
|
||||
1. Start your work locally (usually until you need our CI testing).
|
||||
0. Think about what you want to do - fix a bug, repair docs, etc. If you want to implement a new feature or enhance an existing one.
|
||||
|
||||
- Start by opening a GitHub issue to explain the feature and the motivation.
|
||||
In the case of features, ask yourself first - Is this NECESSARY for Lightning? There are some PRs that are just
|
||||
purely about adding engineering complexity which has no place in Lightning.
|
||||
- Core contributors will take a look (it might take some time - we are often overloaded with issues!) and discuss it.
|
||||
- Once an agreement was reached - start coding.
|
||||
|
||||
1. Start your work locally.
|
||||
|
||||
- Create a branch and prepare your changes.
|
||||
- Tip: do not work with your master directly, it may become complicated when you need to rebase.
|
||||
- Tip: do not work on your master branch directly, it may become complicated when you need to rebase.
|
||||
- Tip: give your PR a good name! It will be useful later when you may work on multiple tasks/PRs.
|
||||
|
||||
1. Test your code!
|
||||
|
||||
- It is always good practice to start coding by creating a test case, verifying it breaks with current behaviour, and passes with your new changes.
|
||||
- Make sure your new tests cover all different edge cases.
|
||||
- Make sure all exceptions are handled.
|
||||
1. Create a "Draft PR" which is clearly marked, to let us know you don't need feedback yet.
|
||||
- Make sure all exceptions raised are tested.
|
||||
|
||||
1. If your PR is not ready for reviews, but you want to run it on our CI, open a "Draft PR" to let us know you don't need feedback yet.
|
||||
|
||||
1. When you feel ready for integrating your work, mark your PR "Ready for review".
|
||||
|
||||
- Your code should be readable and follow the project's design principles.
|
||||
- Make sure all tests are passing.
|
||||
- Make sure you add a GitHub issue to your PR.
|
||||
1. Use tags in PR name for following cases:
|
||||
- Make sure all tests are passing and any new code is tested for (coverage!).
|
||||
- Make sure you link the GitHub issue to your PR.
|
||||
- Make sure any docs for that piece of code are updated, or added.
|
||||
- The code should be elegant and simple. No over-engineering or hard-to-read code.
|
||||
|
||||
Do your best but don't sweat about perfection! We do code-review to find any missed items.
|
||||
If you need help, don't hesitate to ping the core team on the PR.
|
||||
|
||||
1. Use tags in PR name for the following cases:
|
||||
|
||||
- **\[blocked by #<number>\]** if your work is dependent on other PRs.
|
||||
- **\[wip\]** when you start to re-edit your work, mark it so no one will accidentally merge it in meantime.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue