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:"
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 are a bunch of other benefits to these bugs, including:
- 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.
Rust has E-easy and E-mentor
I am getting desperate to contribute (too much post-work free time, don't ask). I have been spamming my favorite python libraries on github with feature requests (so I can pick them up myself later ; ) ), but it's _really_ hard for a n00b contributor to get grounded and started.
I'll hijack this thread: would you have Python projects for first-time contributors? Can we turn downthread from here to "Post open-for-beginners python projects"?
https://wiki.mozilla.org/Mobile/Get_Involved#Mentor_Bugs and Ctrl+F for "python" :)
> Use npm scripts so people don’t have to understand or globally install any build tools
I do this on every project I work on. In fact, where possible, I completely skip globals entirely (for instance in my msngr.js library it uses Grunt but it executes grunt locally without it being installed globally on the machine).
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.
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.
I left a similar response on Medium before I noticed your comment: https://medium.com/@peterjmag/great-tip-d6fcdec36e13
I've been thinking about a very similar issue for a while now, and I'm still trying to organize my thoughts into a blog post or something, but here's the basic idea:
Hire more juniors. Or cross-train people from other departments. Doesn't really matter who. But they should be pretty darn close to beginners.
Assign a relatively small issue to them. The kind of thing that would only take about an hour for a more senior dev to look in to. Plan more than an hour for the junior. Probably a lot more. Also plan some time for one of those more senior devs. Sit them down next to each other.
Point the junior to the readme. Ask the junior to ping / poke / bother the senior every time they hit a roadblock. Every single time. Ask them to be relentlessly persistent. (Not everyone's good at being relentlessly persistent. So encourage them. Create an environment where they feel like they can be relentlessly persistent.) Then leave them alone.
Give it a day or two. Watch as interesting things start to happen.
Watch as the junior dev learns how to be a better communicator. Watch as they learn how to make problems visible. How to get help. And as an added bonus: how to program.
Watch as the senior dev goes insane at first from all the questions. Watch them start to wonder how they can avoid going through this every time somebody needs to touch their code. Watch them remove obstacles. Or at least reduce their number. Watch them automate things. Or speed up things that are already automated. Or improve processes in ways they had never even considered before sitting with the junior. Also watch them learn how to be a better communicator.
Do this a few times. Watch for magical things. Code quality improves. Onboarding times plummet. Hiring friction melts away. Teamwork starts... working. Productivity skyrockets. Job satisfaction goes up. Happiness prevails.
 See also https://twitter.com/patio11/status/657902663686754304
You really do "commit a fix" but you commit it to your own git repository, then you make a "pull request" to the owner of the main repository, asking them to pull in your fix.
GitLab calles it a "Merge request", which is more fitting IMO.
EDIT: Admittedly if you are talking specifically of the request part, then you are correct. However the name comes directly from git's pull command which is a feature of git.
Merge-request makes more sense in Gitlab because they're main use-case is as a self-hosted internal tool where developers most-likely are pushing all of their feature branches to a central repository and asking for the branch to be merged into the mainline branch.
The command may exist within git, but it's not a part of most people's git workflows. "Pull Request" is a term that's far more commonly attributed-to and associated with tools like GitHub, Gitlab, Bitbucket etc.
Did you know that git has the ability to send patches via email, built in ? Git has a lot of functions that the majority of people don't use.
As another piece of evidence, see this page https://www.kernel.org/doc/Documentation/SubmittingPatches
It says Linus (and other kernel maintainer) will want a pull request from you if you want to contribute code, yet he thinks GitHubs version of pull request is, well, lacking (http://www.wired.com/2012/05/torvalds_github/)
Acronyms and abbreviations with well defined / well known alternative meanings really bug me.
Actually Acronyms and abbreviations bug me full stop.
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.
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).
I mean, it's very well possible that the long-term investment in expanding the "base" of willing coders is worth the short-term loss in productivity. But even long-term investments in human capital need better planning than just "hey, I bet a high-schooler could deal with this simple accounting spreadsheet; that would train him even if it takes him a day to fix what I can fix in ten minutes". It's fine investing in high-schoolers, sure, but that's not the point.
The OP's initiative may come at an excellent cost-benefit price, but it's questionable whether they even considered the tradeoff. And if they have, it's still important to discuss it if it comes to an internet forum.
Now, could I have finished it quicker and moved on my way if I’d just done it myself? Of course. But that’s not what it’s all about as an open source contributor. It’s fun delivering good software that helps other people, but also realize that there are tons of people out there who just don’t know where to get started.
Some of you may be asking yourself, “what if I (and other lib users) don’t want to wait days for the feature?” From my experience, people are eager to try it out. At least one PR (sometimes several) is submitted, iterated on, and merged within a matter of a few hours.
Clearly, productivity was not a priority.
edit: A proverb: If you want to go fast, go alone. If you want to go far, go together.
(Or a vagrant file)
If the image is set up so it "just works" and has all tools preinstalled, you can be up and running locally in seconds.
With NPM scripts, its often possible to run I to problems with node-gyp... Or any other number of cross platform incompatiblities.
The docker/vagrant route is a really novel solution I've seen used effectively in other projects.
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.
If you're in the Salt Lake area, also please consider joining us next Saturday  or Tuesday, Dec. 15  as we give a little back to the Open Source community!
 SLC JS Learners - monthly meetup - http://www.meetup.com/SLC-JS-Learners/events/226862778/
Edit: Changed "spamming" to "filling" That was meant as a positive thing but I guess I shouldn't have used the word spamming.
Why is CONTRIBUTING.md important? Its just another file for someone to read alongside COPYING, INSTALL, README, TODO, and perhaps what's in the doc/ directory. And why markdown?
Organising and comments are good but people have been trying to get devs to do that for decades and we're still mentioning it.
"Add an up-for-grabs label" to what? Where? How will people see this?
Adding a githook might be useful on a remote repository but I don't want to run a full test suite every time I commit, ammend a commit, rebase, or otherwise trigger it.
What's NPM? Why would anyone use it over a makefile?
The up-for-grabs label goes in your bug tracker. Then anyone can see it by browsing open bugs.
NPM is the package management tool used by Node, not a build tool. I think that Node having its own package manager is ridiculous, but since Node development already requires it, there's no reason for this project to not make full use of it.
Outside of using NPM, I don't see anything web-specific, and outside of Githook I don't see anything git-specific. Even Sourceforge gives you a bug tracker!