Repository navigation
Proposal: Contributor Onboarding Projects #8535
Replies: 4 comments 2 replies
|
In my opinion, this is a worthwhile way of helping new contributors get a understanding of the codebase before they attempt regular issues. The problem I notice is scalability, in particular concerning the "Get feedback" stage. If the number of new members increases, the maintainers could end up with a considerable amount of extra work because of the need to review and mentor each onboarding project, especially since the repository is already receiving a high number of pull requests. It could be worth thinking about making these projects as self-guided as possible for instance, by setting out clear acceptance criteria, tests, the expected behaviour, and examples , so that the maintainers' feedback is mainly directed at the final PR rather than the whole of the learning process. A further difficulty would be ensuring that these projects remain up to date as the codebase changes. It might be more sustainable to have a small number of carefully selected onboarding projects that are regularly reviewed rather than having a large number of projects. |
|
I am tempted to suggest that new contributors complete @stutijain2006 's lesson plans? (It hasn't landed on master yet but will immediately after the next release.) That would expose them to MB w/o the need to review their MB projects. I need to think about it more. |
|
FYI, I have set a limit of 5 open PRs in the MB repo. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Based on what Walter mentioned in today’s meeting, I was thinking about an idea for first-time contributors.
We could have a few small projects that help newcomers get familiar with different parts of Music Blocks before taking on regular contributions.
I’m interested in creating short videos or blogs explaining the relevant concepts and parts of the codebase, along with the projects.
The flow could be:
Learn → Build → Get feedback → Contribute
A contributor could build the project in their fork and get feedback from a maintainer, giving them a chance to understand the codebase and contribution process before working on regular issues.
I also think this could help reduce low-effort or AI-generated PRs, since contributors would first have to engage with the codebase, build something themselves, and respond to feedback.
If this looks useful, I can put together a short doc with some project ideas and examples for the next meeting.
Would love to hear the community’s ideas on this.
@walterbender @vyagh @Ashutoshx7
All reactions