Hiya! Sloan, DEV Moderator and resident mascot, back with another question submitted by a DEV community member. 🦥
For those unfamiliar with the series, this is another installment of Sloan's Inbox. You all send in your questions, I ask them on your behalf anonymously, and the community leaves comments to offer advice. Whether it's career development, office politics, industry trends, or improving technical skills, we cover all sorts of topics here. If you want to send in a question or talking point to be shared anonymously via Sloan, that'd be great; just scroll down to the bottom of the post for details on how.
Let's see what we got...
Today's question is:
I would like to start with open source and create more connections with people, but I can't ever decide how to approach people online. Do I just DM them and say, "Hey, hello, want to connect with you and collaborate on your project/know your opinion on this and that.."? It feels pretty strange and difficult to me; how do you approach this?
Share your thoughts and let's help a fellow DEV member out! Remember to keep kind and stay classy. 💚
Want to submit a question for discussion or ask for advice? Visit Sloan's Inbox! You can choose to remain anonymous.
Top comments (6)
Everyone has different levels of comfort wether it's approaching others or being approached.
For me, I started making contributions to option source projects that I use.
I started with updates to documentaion, fixing typos, improving wording.
Depending on your skill level, submit PRs to fix issues or add features. If they are accepted, great! If not, its all learning and you can always use the code locally.
Some open source projects have online support communities on Slack, Discord or others. Drop in, say hi, and help out where you can.
Hacktober is a great time to see what open-source projects welcome contributions. And how their communities offer and give help. Not every community will be a good fit for everyone and that's OK. It's about finding something that works for both sides.
Different people expect different things... But as a general rule of thumb, there isn't an expectation to "connect with a person/people" before contributing - it is more usual to contribute first, and discover connections through your involvement.
The most usual way of first contributing to a project is by finding something to improve, and doing so.
You can contribute in many ways by making improvements to the project
For code contributions, the only rule really is : follow the guidance in
Contributing.mdyou find inside the project, and adhere to the project's Code of Conduct.yes awesome post .Me too!!!
I just do not know the rules either!!
I have been all over github and i see old and outdated posts. people crying to be assigned etc...
Ad another thing is When im looking to edit files or to just look at the files. I can ever get to find your conventional old .html and .css and or .js files.
I wanna provide solutions but i find myself getting lost in the myriad .md or someother form of jsx etc ocean of type of files. this is not at all like the tutorials.
What is the big deal.
Please help us.
It's easier to contribute to a project you actively use, than coming into a new project without having experienced it a lot as a user.
Think of the parts you do already use - perhaps your first contributions can be via the forums, answering questions you know the answer to, or testing the scenarios in people's questions and raising well-described bugs if you find any - or even checking for known bugs to link to forum questions.
Then, some projects just aren't very well documented (how to build this? what are the requirements? how to test this?), and have no clear starting point. They would clearly benefit from a contribution documenting the basics - maybe you can provide this :-)
The more you go through this, the more you get to see of the project, and the files start to make sense .
I recently had my first (big) exposure to contributing to open source when I got accepted to Google's Summer of Code (GSoC) this year.
While applying to GSoC is one way to do it, there are some general things that I noticed to keep in mind.
Usually the maintainers of an open-source project are very passionate about their work since it's typically unpaid. In that light, if you submit pull requests and get a whole bunch of critiques, don't let it discourage you. It's not personal, and this is the way they show care to the quality of the project. The fact that they went out of their way to critique you, instead of just ignoring or deleting your work means that you have a chance to work on it.
It definitely helps if you actively use the project as well as make an effort to try to talk to the maintainer before diving head-first into the issues. Sometimes, no matter how good you are, if people don't like working with you, then they simply won't.
If you're going to open issues in a repo, be as detailed as possible. Provide screenshots, steps to reproduce your problem, etc. It goes a very long way to create quality issues, and these ones are much more likely to get addressed quickly. Maintainers tend to be especially appreciative and open-minded if you can propose a solution to your issue in a high quality PR :).