• dgkf@lemmy.ml
    11·
    1 year ago

    I’ve been there, but over the years I’ve gotten better at avoiding being in this situation.

    If you are implementing something for yourself, and merging it back upstream is just a bonus, then by all means jump straight to implementing.

    However, it’s emotionally draining to implement something and arrive at something you’re proud of only to have it ignored. So do that legwork upfront. File a feature request, open a discussion, join their dev chat - whatever it is, make sure what you want to do is valued and will be welcomed into the project before you start on it. They might even nudge you in a direction that you hadn’t considered before you started.

    Be a responsible dev and communicate before you do the work.

  • Omega_Haxors@lemmy.ml
    0·
    1 year ago

    That’s the fucking worst, when you put all this work into a free and open project only for the lead to be like “nah don’t like it”

    Free and Open as in, free to do the work for them and Open for it to be rejected for almost no reason.

    • TheyCallMeHacked@discuss.tchncs.de
      1·
      1 year ago

      A project is in no way, shape, or form obliged to to accept and maintain your code, especially if it’s not a feature they want. If you want your feature so badly, maintain a soft-fork yourself. Don’t want to put in that effort yourself? Then why should the project maintainers?

  • caseyweederman@lemmy.ca
    2·
    1 year ago

    Somebody please fork reprepro, there’s a super useful bugfix in one and a super useful feature in the other but I want both.

    The bugfix is the zstd decompression-cancel race condition bug and the feature is multiple versions per package but they’re both super stale.
    Maybe…
    Maybe I can fork it…

  • Praise Idleness@sh.itjust.worksEnglish
    2·
    1 year ago

    I once made a PR changing a = f(b) from a = "" if b == "" else f(b). About six months later still in pending review. I get that people have their own shit but damn.

    edit) Sorry. Clarified the code.

  • rwhitisissle@lemmy.ml
    1·
    1 year ago

    And this is why I don’t contribute. Or at least I’ll ask a question about whether or not something would be a desired feature and if I don’t get a clear yes or no by someone who can actually approve a PR, I. ain’t. coding. shit.

    • nightm4re@feddit.de
      1·
      1 year ago

      You’re framing this as if it were something unusual. Unsolicited PRs are a no-go in my opinion. It’s just basic communication and collaboration to align with the maintainers whether a change is actually required or not.