Getting started with an organization and project
Now that you have shortlisted a few organizations and their project ideas, doing your homework (coming prepared) is important because Bitcoin, as most technology open-source communities, is very talent driven.
Here are some ways to come prepared when getting started with an organization and project:
Join the community and make connections All of the open-source organizations have an open place where members of the community hang out. For each of the participating organizations, you'll find links to their discord, slack or telegram groups on the project ideas page on our website. Join their groups, lurk around the different channels and introduce yourself. Your goal should be to connect with the community members and make a good first impression.
Communicate clearly and respectfully Avoid making your sentence so long, dense and complicated that your readers will get lost trying to follow its meandering, splitting logic such that they will have to read it three times just to make sense of what you’re trying to say and then respond to you asking for clarification even though you could have used small, short sentences to make the point that you wanted to make without confusing the reader and wasting their time. In short, use brief, complete sentences. Not like the above sentence. Avoid SMS abbreviations. Be friendly, polite and a joy to work with. People want to work with other people whose company they enjoy. Your goal is to help create and maintain an atmosphere around your contribution that is enjoyable.
Try not to make a bad first impression, have extremely poor English or be rude and hostile. Bad first impression will seriously damage your chances of selection, even if you are a great programmer or a designer. Don’t address your mentors as sir or ma’am. Address each other by their first name or nick. Most open source communities have their own Code of Conduct (formally or informally). Be sure you are aware of the Code of Conduct and are treating everyone with respect.
Before you begin reaching out to a mentor regarding a project idea, here is what we expect you to do:
Read the project’s website and documentation entirely. You should be able to answer what it does, what problem it is solving, why it’s an important problem to solve, how it works, who are the developers behind it. You must cover the project’s documentation at least to the point where you feel like you can ask questions that are not already extensively covered in the docs.
Use the project’s software. If it’s an app, install it and run it. If it’s a website, visit it and play with it. If it’s a library, build it and try writing a sample app using its APIs. If you are not a user of the project, how can you help develop it?
Study the developer guide or contribution guidelines. Visit the project’s codebase on GitHub. Build it from source in your local environment, run it, use it. If you're in the design track, see https://bitcoin.design/contribute/ for tips on how to contribute.
If you found a bug while using the software or reading the project documentation, don’t just point us to it. Create an issue explaining the bug, and a pull request fixing the issue. Always follow the contributor guidelines and best practices of the project when discussing in GitHub issues or creating pull requests in GitHub.
Browse through all the open GitHub issues of the project. There are always easy issues that you can help with. Re-read the issue if you don’t get it the first time. Reproduce the bug. Investigate the part of code that is causing it. Participate in the discussion on how to fix it. Create a pull request with your fix clearly documenting your code and explaining your approach in the PR. Patiently wait for the project maintainers to review it. When they comment, be steadfast with addressing their comments and feedback. Never abandon a PR. Ensure to see it through a merge or a closure.
Fixing issues is not only about learning the code base, it’s also about making friends within the community, and demonstrating how professional you are.
Ideally, we require all applicants to submit a patch. This does not need to be accepted and merged, but it does need to be online and available for potential mentors to inspect. Contact your mentors if you are unsure what would be an appropriate patch to submit. If you’re completely new to open-source contribution, refer to how to contribute a patch to a GitHub hosted Open Source project.
Doing all of the above means you have convinced us that you can accomplish your project independently. It means you have experience contributing to open-source projects, you have done your homework and research and you are one of the best people to become a project contributor.
Once you’re through all of the above steps, we really welcome your questions, but they should not invade anyone's privacy. We recommend not to approach any mentor on their personal accounts (i.e: Facebook, Instagram, Linkedin, Twitter etc...) Open Source does not only mean the source code is public but it also means public communication. So we suggest keeping discussions on the Discord channel in our server. In some cases, the project may have their own Discord/Slack/IRC, ask us so we can point you to it. Once again, private email conversations or messages on personal accounts are strongly discouraged, unless something is really personal.
If you’re unsure about your English skills, use Hemingway Editor to check the grammar and readability of your writing.
Last updated