5

How do I contribute to open source?

Comments
  • 4
    I recommend starting with documentation, since it’s the easiest and it’s very helpful. Or, if you can, translating the documentation to your local language.

    If you want to write code, you should first be very familiar with the library. Go to the GitHub repo, check out if there’s any issues that nobody has taken, and go for it.

    Python 3.10 had an update on more descriptive error codes. It’s a simple tweak, but very useful.
  • 2
    Open a pull request and phone home.
  • 1
    @eo2875

    > it’s the easiest

    | = | ~ | = |

    That depends, markdown on GitHub is quite extensive and still code that can be written

    badly ..
  • 2
    I started with libreoffice i18n [translations]. But you can start anywhere. Like docs, lots and lots of projects lack instructions in their readmes [e.G. Installation instructions, compilation, project setup, etc.], examples and samples [like sample config files, example launch commands]. I think this might be the easiest and most beneficial way into oss contribution
  • 2
    You can use a crowbar to pry open some code. Doesn't matter which. Can be your apartment door code.
  • -1
    well you could start by tracking down anyone named john zimmerman.

    eviscerating him, and leaving his chest cavity open as the source of his entrails.

    meanwhile for communal purposes you could slap and or utilize the mouth of ANY FEMALE named Tori.

    They're literally all evil bitches.
  • 0
    also this time.

    i want a pretty sleek affectionate kitty with soft fur that wants to cuddle and be petted and trill at me !
  • 0
    @ostream pr ?
  • 0
    @ostream no. female Tori.

    not the party

    the name :P
  • 0
    @ostream what about puerto rico ? :P
  • 1
    Whatever you do - don't start with documentation. You need intricate knowledge of the system in quastion to write good documentation and bad documentation is often worse than no documentation.

    And don't contribute to open source just to contribute to open source. Find something you actually use and fix bugs in it.

    Btw, did you know, that if you write a game mod that is open source, you technically contributed to the open source community...
  • 0
    @Oktokolo depends. It usually takes a looot of trial and error to write examples and samples in docs. Time consuming, tedious, but useful as hell. Imo it's not a bad place to start
  • 0
    @netikras If you already know the system, you should be able to cut down on the trial and error part significantly. And examples have to be written by people who actually know their shit. Bad examples that just barely worked on the writer's machine but don't do so anywhere else are also worse than no examples.

    Anyone can fix typos and refactor the text flow and wording. Adding more info to an already good documentation is fine for noobs too.

    But the initial writer has to be someone who knows exactly, what is going on in the system to document - not some random noob who found some random way by trial and error their way to a sortof working use case. The sad truth is, that technical documentation has to be written by the actual devs. No one likes that (mostly the devs themselves including me). But in the end, you either have documentation significantly worked on by the devs or you have crappy documentation.
  • 1
    @Oktokolo so in the end you either share the usage examples it took you 2 days to figure out, or you don't and hope devs will share the same examples within an upcoming century?

    Naah, I don't agree. If I'm using an oss project and it takes me >2hrs to figure out, I update its readme with usage examples and prerequisites for it to launch. I'm not waiting for what's not gonna happen. It's oss for a reason - so that the COMMUNITY contributes however they can. THEN and only then it's up to devs/maibtainers to either close or merge the pr
  • 0
    I would suggest starting with a small and simple 1 man repo that you've used yourself and have some issues with.
    Ask the maintainer first.

    It can be quite a chore for maintainers to get PR:s for features they don't want or plan to solve a different way.
  • 1
    @netikras Yes, you are right. It was wishful thinking from my side.

    It sadly is likely that the devs will never add documentation even when they see that the lack of it really hinders adoption by the community.
Add Comment