Hi everyone, I’m a recent grad from the HackBright Software Engineering Fellowship and I’m really interested in applying to roles at OpenCraft, but I’m new to open source contributions. I had a great chat today with some of the OpenCraft folks at the HackBright career fair and was encouraged to make a post on this forum to get some tips and links on contributions that a recent grad like me could get started with. Thank you for your time and attention in advance, I’m looking forward to it!
Hi @lucianact, and welcome to the forum!
I’m glad to see you’re interested in contributing to open source - it’s arguably the most important thing we do, and correspondigly, the thing we most look for in candidates. It’s not all - because of the way the company is structured we also look for seniority - but we’ve made (successful!) exceptions in cases where there was a clear desire to work like we do, even if lacking experience.
Since you’re completely new to it, you should probably do a read of this opensource.com article. It’s a quick rundown of the advantages to you as a developer, without getting into the philosophy of it. (If you are interested in a bit of history, what gets me excited to this day is a 2001 documentary called “Revolution OS” - I hear you can find it on everybody’s favorite video site.)
On the How: while we don’t complete our community’s contribution course, you can get a taste of what the process is like by making an artificial contribution here. It doesn’t count as a real one, of course, as it sidesteps the meat of it - communicating well and handling a review - but it should give you a rough understanding of the mechanics.
If at this point you’re still interested in working with open source and joining us, the pro-tip is to read our handbook. It lays out in the open how the company works - including how the recruitment process itself works! (Talk about making it easy, huh? ) You’ll see that one of the only hard requirements is for you to have one merged contribution.
Still with me? Great! The good news is that any contribution counts, as long as it’s a “real” one: sent to a project you don’t maintain, and merged by the maintainer (hopefully after a little back-and-forth, demonstrating that you can handle a review process).
For extra credit, I suggest taking a shot at contributing to Open edX, the platform we work on the most here at OpenCraft. I’ll be the first to tell you: it’s a complex project (hence, why we get paid to make changes to it!). But if you manage to get through the initial hurdles on your own, even to get a simple one-liner merged, it would go a long way in convincing us you’re right for the job.
Finding low-hanging Open edX fruit to work on isn’t very straightforward, either, but there is an official forum where people commonly report issues such as this one. In this case it’s not a confirmed bug, but it would be a starting point: if you can reproduce the issue, confirming it is half the work. Plus, it’ll get you all set up to work on the Open edX code.
There is also an official Jira board for community reported Open edX issues, but it’s not very actively curated. A better alternative for confirmed issues is the Build-Test-Release board on Github, but the ones currently unassigned cannot be reasonably classified as “newcomer friendly”.
On setting up Open edX for development: we have a page on our open onboarding course dedicated to it. I suggest you sign up and take a peek. (The course itself will give you a further glimpse as to what it’s like to work with us.)
Phew… Forgive the wall of text - just honestly trying to maximize your chances. Hope it’s enough to get you started!
Good luck, and welcome to the Light Side of the Source! ;)
PS: Having just combed the forum, I found two low-hanging fruit that would make great first contributions, in addition to earning some community karma:
A good place to start is with software you currently use. Is there open source software you use where there’s a certain missing feature you would love to have? Or something annoying or buggy that you want to fix? A typo in the user manual? Find the source code, build the software from source, and start hacking away!
- Start small! I’m serious about addressing typos and such. If you haven’t done it before, the process for forking/branching, writing pull requests, communicating with maintainers, etc. can be daunting. So if the actual code change is simple, you can focus on the other parts.
- Don’t be disheartened if your contribution is ignored or rejected. Many maintainers work on projects in their spare time and may be taking a break from a project, or have a long backlog of contributions and reports to go through. Or the change you propose may not fit with the project’s vision or short term goals.
- Search through issues and pull requests for a project before opening a new issue or working on a PR. Often there will be existing issues, discussions, or PRs, which will help inform you about what sort of features, etc. may be welcomed. If they have an developer chat channel (irc, discord, gitter, etc.), consider joining it to have a chance to discuss your plans directly with maintainers and the community.
- Respect the maintainers. Some projects have contributing guides, pull request templates, or other guidelines. Making an effort to follow these will help make a good impression to begin with. Sometimes it may be difficult to follow exactly, but making an effort, and clearly communicating your motivations and what your contribution is addressing will go a long way.