Skip to content

Instantly share code, notes, and snippets.

@tomaskrcka

tomaskrcka/Opensource_sharing.md

Last active February 13, 2020 15:16
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save tomaskrcka/ce48cf17ee8b375bdf0fbc199bde7e5a to your computer and use it in GitHub Desktop.
Save tomaskrcka/ce48cf17ee8b375bdf0fbc199bde7e5a to your computer and use it in GitHub Desktop.
Download ZIP
Raw
Opensource_sharing.md

Topics

Motivation

What it means to contribute

If you’re a new open source contributor, the process can be intimidating. How do you find the right project? What if you don’t know how to code? What if something goes wrong?

A common misconception about contributing to open source is that you need to contribute code.

You don’t have to contribute just code

General

Before to write an issue or a new functionality

  • check the FAQ first to see if your issue is addressed in a well-known question
  • if you have a general question about the app (library etc.) usage, please ask it at Stack Overflow
  • check the open issues to see if the issue has already been reported. If it has, don’t dismiss the report, but check the ticket history and comments. If you have additional useful information, please leave a comment, or consider sending a pull request with a fix.
  • write complete, reproducible, specific bug reports. The smaller the test case, the better. Remember that other developers won’t have your project to reproduce the bug, so please include all relevant files required to reproduce it. See for example StackOverflow’s guide on creating a Minimal, Complete, and Verifiable example exhibiting the issue.
  • provide falling testcase
  • provide exact version

Github

  • fork the repo
  • read the contribution guideline
  • make your changes
  • open PR (if it's a complex task, better open earlier to get a feedback)
  • wait for the responses
  • if the change is not accepted, don't complain about that

Linux kernel contribution

  • There is exactly one person who can merge patches into the mainline kernel repository: Linus Torvalds.
  • The kernel code base is logically broken down into a set of subsystems: networking, specific architecture support, memory management, video devices, etc. Most subsystems have a designated maintainer, a developer who has overall responsibility for the code within that subsystem.
  • email conference: http://vger.kernel.org/vger-lists.html
  • first search in the maillists
  • dont ask userspace questions (it's not the overflow)
  • Examples

https://lists.gnu.org/archive/html/coreutils/2016-01/msg00007.html https://opensource.com/article/18/8/first-linux-kernel-patch

https://github.com/torvalds/linux/commits/master/drivers/net/can/spi/mcp251x.c https://lists.freedesktop.org/archives/dri-devel/2015-July/087006.html

https://github.com/MunGell/awesome-for-beginners

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment