Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Open Source Programming

Avoiding Common Pitfalls When First Contributing To Open Source (hashnode.dev) 20

Posted by msmash from the PSA dept.
Angie Byron, a long-time member of the Drupal community, offers guidance on avoiding common mistakes and general good-practices for those new to contributing to open-source projects: [...] You might not know it yet, but as a newcomer to an open source project, you have this AMAZING superpower: you are often-times the only one in that whole project capable of reading the documentation through new eyes. Because I can guarantee, the people who wrote that documentation are not new. :-)

So take time to read the docs and file issues (or better yet, pull requests) for anything that was unclear. This lets you get a "feel" for contributing in a project/community without needing to go way down the deep end of learning coding standards and unit tests and commit signing and whatever other bananas things they're about to make you do. :) Also, people are more likely to take time to help you, if you've helped them first!
This discussion has been archived. No new comments can be posted.

Avoiding Common Pitfalls When First Contributing To Open Source More

Avoiding Common Pitfalls When First Contributing To Open Source

Comments Filter:

  • subject says it all.

    • Yeah. Just last night I was looking at the source code for an open-source project that I thought I might like to add a feature to, and I must be spoiled by years (decades, really) of coding at my current company. While the code was somewhat understandable, seemed to be pretty well written, and appeared to follow some coding conventions, the one thing that really struck me was the complete lack of comments. None. I'm a long time Linux and now FreeBSD user, and I really appreciate the open source communit

      • Open a PR that comments the code. Don't refactor it, *just comment*. Note that in the bug title. I'll bet it is much appreciated and merged, although of course YMMV. Everybody wants to hack in some feature that scratches their itch, few are willing to do the other 90% of the work to actually deliver robust code. If you do some of that work, you are in some non-binding way called "goodwill" buying a little of the maintainer's time to evaluate your eventual feature PR.

        • The community needs to build a model to predict when an open source project could get end of lifed. There are hundreds of thousands of open source projects, picking one that will be alive with more than zombie version number updates for 5 years is a critical problem for developers.

          It's one of our main efforts to identify and remove dependencies of near dead, not quite dead yet pipers and truly dead open source packages.

  • This sounds like a pitch some cult like Christianity or Scientology would come with.

  • Bad Headline (Score:3)

    by firewrought ( 36952 ) on Thursday February 29, 2024 @01:52PM (#64279392)
    The article fails to identify any first-timer mistake. It's just suggestions for cautiously finding and approaching a project/community.

  • I've made only furtive attempts to contribute to open-source projects in my life. In my limited experience, as a first-time contributor, you will be shat upon, unless your pull request fits on two lines, in which case you will be dismissed, unless your two-line change fixes an unambiguous bug, in which case you will be ignored for about twelve years.

    And so it seems to me that, unless you're the kind of person who can bang their skull against a wall over and over again for years without even visibly looseni

  • coding standards and unit tests and commit signing and whatever other bananas things they're about to make you do

    They wrote it, nowadays coding standards made contributing utterly uncool.

    • The problem is that if the proposed contribution needs additional work, the pull request is now a tradeoff between the maintainer's time and the contributor's time. And worse, there's typically a competence/task inversion. The person who is likely the most competent to implement changes is reduced to the manual labor of fixing formatting, adding comments and docs, and writing tests. This is why contributing by fixing a very clear and obvious bug in just a LOC or two is much appreciated. In contrast, reo

      • This is an *excellent* summary of the tension between being welcoming to new contributors and staving off maintainer burnout. Because if there was a bug / deliberate nefarious thing hidden in that "innocent" 300-line refactoring patch, the maintainer's the one who's gonna be on the hook for it, not the contributor who may be long gone. :\

        Whereas, if you take work *off* a maintainer's plate by doing a "thankless" task like improving docs or writing test cases, it's good things all around.

  • I'd ive any project with a code of conduct w wide pass. I'm off the clock, doing it on my own time. I want to have fun, not feeling like I'm being controlled by another lot of leftist corporate dic... tators.

    • Yep. That is exactly the point of Codes of Conduct, so that **everyone** can just have fun and not worry about being harassed, berated, singled out for some immutable trait, and so on.

      If having fun for you necessitates having the freedom to do this to other people, maybe carefully sit down and consider your life choices. ;)

  • The gist of the article is simply that the author focuses on the community. That's fine, but the article has very little actual, practical advice to offer beside how to be accepted into the community.

  • Just fork it. It's open source after all. You will have full control of the project.

Slashdot Top Deals

A committee takes root and grows, it flowers, wilts and dies, scattering the seed from which other committees will bloom. -- Parkinson

Close