InnerSourceCommons / InnerSourceCommons/InnerSourceLearningPath
Pulling contributors in as reviewers
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 77
- Forks
- 47
- Avg merge
- 11h 11m
- Merged PRs (30d)
- 5
Description
In the learning path for the Trusted Committer (part 2) we explain how it's the trusted committers that are reviewing code. In a first approximation this is correct and matches what I see in many open source projects.
When it comes to recruiting new committers and onboarding them I have seen a different approach:
https://blogs.apache.org/comdev/entry/an-approach-to-community-building (pretty much at the bottom) - contributors at Apache Beam are encouraged to do code reviews as well - in particular if the original patch comes from a committer, the idea is that such a review is enough for merging the code.
Maybe this is something for an InnerSource Pattern instead of the LearningPath though.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read the Trusted Committer part 2 learning path section and the linked Apache Beam community-building article, especially its discussion of contributors reviewing code. Decide whether the material should be updated in the learning path or captured as an InnerSource Pattern; done means the proposed placement and scope are agreed and the relevant learning material is revised.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100