Improve existing skills

Meet people who are interested in similar things

People coming back for years. Many people form lifelong friendships through their participation, running into each other at conferences or late night online chats.

Find mentors and teach others

Working with others means you’ll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity.

Build public artifacts that help you grow a reputation and a career

By definition, all of our work is public, which means you get free examples to take anywhere as a demonstration of what you can do.

Learn people skills

There are many opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work.

It’s empowering to be able to make changes, even small ones

You don’t have to become a lifelong contributor to enjoy participating. Have you ever seen a typo and wished someone would fix it? Here, you just do that.

What it means to contribute?

If you’re a new contributor, the process can be intimidating. What if you don’t know how to code? What if something goes wrong? Not to worry! There are all sorts of ways to get involved, and a few tips will help you get the most out of your experience.

You don’t have to contribute code!

A common misconception about contributing to open source is that you need to contribute code. In fact, it’s often the other parts of a project that are most neglected or overlooked. Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project.

Do you like to design?

Restructure layouts to improve UX

Conduct user research to reorganize and refine the look of desktop, build engine, armbian-config

Do you like helping people?

Orienting yourself

For anything more than a typo fix, contributing to Armbian is like walking up to a group of strangers at a party. Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard.

Communicating rules

Whether you’re a one-time contributor or trying to join a community, working with others is one of the most important skills you’ll develop. Before you open an issue or pull request, or ask a question, keep these points in mind to help your ideas come across effectively.

Give context.

Help others get quickly up to speed. If you’re running into an error, explain what you’re trying to do and how to reproduce it. If you’re suggesting a new idea, explain why you think it’d be useful to the project (not just to you!).

“X doesn’t happen when I do Y”“X is broken! Please fix it.”

Do your homework beforehand.

It’s OK not to know things, but show that you tried. Before asking for help, be sure to check a project’s README, documentation, issues (open or closed), mailing list, and search the project for an answer. People will appreciate when you demonstrate that you’re trying to learn.

“I’m not sure how to implement X. I checked the help docs and didn’t find any mentions.”“How do I X?”

Keep requests short and direct.

Much like sending an email, every contribution, no matter how simple or helpful, requires someone else’s review. We have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you.

“I’d like to write an boot from SPI tutorial.”“I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you…“

Keep all communication public.

Although it’s tempting, don’t reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions.

(as a comment) “@-maintainer Hi there! How should we proceed on this PR?”(as an email) “Hey there, sorry to bother you over email, but I was wondering if you’ve had a chance to review my PR”

It’s okay to ask questions (but be patient!).

Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you’d want them to show to you.

“Thanks for looking into this error. I followed your suggestions. Here’s the output.”“Why can’t you fix my problem? Isn’t this your project?”

Respect community decisions.

Your ideas may differ from the community’s priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project.

“I’m disappointed you can’t support my use case, but as you’ve explained it only affects a minor portion of users, I understand why. Thanks for listening.”“Why won’t you support my use case? This is unacceptable!”

Above all, keep it classy.

Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It’s fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it.

How to submit a contribution?

Gathering context

Before doing anything, do a quick check to make sure your idea hasn’t been discussed elsewhere. Skim the project’s README, issues (open and closed), and forums. You don’t have to spend hours going through everything, but a quick search for a few key terms goes a long way.

If you can’t find your idea elsewhere, you’re ready to make a move. If the project is on GitHub, you’ll likely communicate by opening an issue or pull request:

Issues are like starting a conversation or discussion

Pull requests are for starting work on a solution

For lightweight communication, such as a clarifying or how-to question, use forums

Before you open an issue or pull request, make sure to READ its template.

If you want to make a substantial contribution, open an issue to ask before working on it. It’s helpful to watch the project for a while (on GitHub, you can click “Watch” to be notified of all conversations), and get to know community members, before doing work that might not get accepted.

Opening a pull request

Start work on a contribution that was already asked for, or that you’ve already discussed, in an issue

A pull request doesn’t have to represent finished work. It’s usually better to open a pull request early on, so others can watch or give feedback on your progress. Just mark it as a “WIP” (Work in Progress) in the subject line. You can always add more commits later.

Here’s how to submit a pull request:

Fork the repository and clone it locally. Connect your local to the original “upstream” repository by adding it as a remote. Pull in changes from “upstream” often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. (See more detailed instructions here.)

Include screenshots of the before and after if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request.

Test your changes! Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don’t break the existing project.

Contribute in the style of the project to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.

What happens after you submit a contribution?

After you submit a contribution, one of the following will happen:

You don’t get a response.

If you haven’t gotten a response in over a week, it’s fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread.

Don’t reach out to that person privately; remember that public communication is vital to open source projects.

If you make a polite bump and still nobody responds, it’s possible that nobody will respond, ever. It’s not a great feeling, but don’t let that discourage you. It’s happened to everyone! There are many possible reasons why you didn’t get a response, including personal circumstances that may be out of your control.

Someone requests changes to your contribution.

It’s common that you’ll be asked to make changes to your contribution, whether that’s feedback on the scope of your idea, or changes to your code. When someone requests changes, be responsive. They’ve taken the time to review your contribution. Opening a PR and walking away is bad form. If you don’t know how to make changes, research the problem, then ask for help if you need it.

If you don’t have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they’re not expecting a response. Someone else may be happy to take over.

Your contribution doesn’t get accepted.

Your contribution may or may not be accepted in the end. Hopefully you didn’t put too much work into it already. If you’re not sure why it wasn’t accepted, it’s perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you’ll need to respect that this is their decision. Don’t argue or get hostile. You’re always welcome to fork and work on your own version if you disagree!