Mozilla "Mentor Bugs If you are looking for a bug with guidance, we maintain a set of bugs that are marked with an assigned mentor (see "Whiteboard" field). The mentor will help you get the necessary information to understand the issue, point out relevant parts of the code to look at, etc. You can browse these bugs on Bugs Ahoy!, but here's a list of unassigned mentor bugs to get you started:"
We also try to have good starter bugs on Servo (and its myriad dependencies):
One of the biggest challenges we have is keeping some around and available! The good ones almost always have an opened PR within 24 hours:
- There's a lively stream of people setting up the dev environment for the first time, both keeping our instructions up to date and making sure we handle scenarios like slow internet connections, really old versions of Ubuntu or Linux graphics drivers, etc.
- Reviewing these bugs is also a good way to help grow contributors from committers into reviewers/maintainers.
Most of our challenges with these kinds of bugs are related to GitHub. e.g., you can't "assign" an issue to somebody outside of the project organization, so somebody has to manually label it "Assigned" for our filters to work. Also, you don't get notifications when somebody pushes a new commit to their work branch or rebases, so there's a lot of manual watching of these PRs during the review cycle that sometimes gets dropped (though our myriad GH bots could probably fix this!).
Even with the challenges, we love having this kind of bug as a way to bring in more contributors and keep development on the project accessible, and like the author, I'd highly recommend it to other projects.
I think it's really important that anyone can go up to a library, pull it down, and start it with little to no further effort. The less friction you can provide a developer the better.
100% agree.. and just as important as ease of starting: ease of finishing. make all of your tests / linters / etc. runnable via a simple npm run.
there's overhead in setting this up, but i can remember several times where i have pulled the code down, made my changes, and gave up when trying to figure out how the maintainer wants my code formatted / tested.
We've a curated set of Pioneer Projects for MirageOS , where more established contributors have agreed to act as mentors for newcomers. It's worked really well for us!
One of the unexpected benefits was that we could quickly take part in things like Outreachy and GSoC, as we already had a curated list. Reviewing this list every few months has become part of the normal process now.
In addition, asking people to act as mentors also gives them a different perspective on the existing code base, especially where things are particularly thorny.
Jenkins has been filling my twitter feed with information for new contributors lately under the hashtag #hacksgiving I think.
A related effort: https://twitter.com/yourfirstpr
This is really great. I've contributed to lots of projects and it would be nice if maintainers were all this thoughtful. If not actively encouraging people to get involved, it would be nice of maintainers to simply acknowledge or appreciate someone's effort.
I've contributed a lot of code and have had vastly different experiences. Sometimes people are excited and accept a PR without question. Some people just ignore PRs. Some people make you feel as though you've just spit in their face. I had one pull request that I thought was reasonable which was met with a ridicule from the maintainer at how useless my idea was (to him). I'm a seasoned programmer with my own projects and a lot of code under my belt but, even knowing how these things work, that one really soured me on his project. I can't imagine if a novice who was excited at their first PR was treated so poorly.
If I could suggest anything to maintainers, it would be to simply appreciate that somebody was trying to contribute. If their code doesn't meet your goals or standards, try to still respect that they spent some time on your project.
edit: A proverb: If you want to go fast, go alone. If you want to go far, go together.
I would add: if someone tries to do contribute something, but maybe they have a git issue, don't step in and push it yourself. This happened to me on one project, and it bothered me so much that I stopped contributing entirely (which was the right move, it turned out).
>>> why sour? because of who gets credit issue? interesting