this post was submitted on 06 Jan 2024
380 points (93.0% liked)

Memes

45674 readers
882 users here now

Rules:

  1. Be civil and nice.
  2. Try not to excessively repost, as a rule of thumb, wait at least 2 months to do it if you have to.

founded 5 years ago
MODERATORS
 
all 34 comments
sorted by: hot top controversial new old
[–] dgkf@lemmy.ml 89 points 10 months 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.

[–] killeronthecorner@lemmy.world 81 points 10 months ago (1 children)

You made this?

Fork

I made this

[–] RedWeasel@lemmy.world 41 points 10 months ago* (last edited 10 months ago) (2 children)

Now everone expects you to be the maintainer. You get a lot of bug reports.

[–] redcalcium@lemmy.institute 42 points 10 months ago (1 children)

Then you ghost them and wait for the next sucker to fork your fork.

[–] Steve@startrek.website 5 points 10 months ago (1 children)
[–] _dev_null@lemmy.zxcvn.xyz 3 points 10 months ago
[–] vzq@lemmy.blahaj.zone 20 points 10 months ago

LOOK AT ME. I’M THE MAINTAINER NOW.

[–] ILikeBoobies@lemmy.ca 45 points 10 months ago
[–] RedditWanderer@lemmy.world 35 points 10 months ago (2 children)

The last 2 frames should be the same text

[–] Thekingoflorda@lemmy.world 49 points 10 months ago

You should edit it and post a pull request.

[–] qaz@lemmy.world 16 points 10 months ago

You’re right. Oops

[–] Bipta@kbin.social 24 points 10 months ago (1 children)

This is why I always ask if the maintainers are open to a PR first.

[–] CosmicTurtle@lemmy.world 11 points 10 months ago

Yeah...but even then they may not get to you.

Over the holidays, I had a good back and forth with the maintainer of a project that I started using. The documentation needed updating and created a PR.

Then I went almost 10 comment rounds on why it was necessary, why I wrote it the way I did, and all this bullshit.

I just left it saying "merge it or whatever. I'm moving on."

It's still open.

[–] caseyweederman@lemmy.ca 23 points 10 months ago (1 children)

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...

[–] djtech@lemmy.world 13 points 10 months ago (1 children)

Fork the feature one, get the diff of the commit that patches the bug and apply the diff to your fork.

Now compile and test.

[–] caseyweederman@lemmy.ca 9 points 10 months ago

I don't have a lot of experience with merging but then again, this is a great opportunity to learn.

[–] rwhitisissle@lemmy.ml 17 points 10 months ago (3 children)

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.

[–] driveway@lemmy.zip 14 points 10 months ago

This is how its supposed to be done anyway.

[–] JDubbleu@programming.dev 2 points 10 months ago

Fair enough, but as someone who has worked closely with the Decky Loader maintainers and contributed my own stand alone plugin I get it. We basically all have day jobs as devs and it can be mentally taxing to do more PRs at home. Not to mention sometimes there's just not enough time in the day, and I don't even have kids.

Maintainers are ultimately volunteers doing work with hundreds of dollars an hour for free. I've had some PRs take 20+ days to be looked at, it's just how it goes.

[–] nightm4re@feddit.de 1 points 10 months 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.

[–] Moonrise2473@lemmy.ml 10 points 10 months ago

Or worse, ban you from their GitHub repository without any reply or explanation

[–] famfo@social.dn42.us 9 points 10 months ago

Even better when someone makes the exact same PR and it gets merged a few days after being opened and yours left unreviewed.

[–] mumblerfish@lemmy.world 9 points 10 months ago

It is a bit sad that reviewing takes a long time. I have had the same thing for a project, someone on the team pings someone to do a review, 2 years later you get a review saying you should rebase because the PR is too old. I get why; it takes people and time to review. It is sad though.

[–] 2xsaiko@discuss.tchncs.de 9 points 10 months ago

"closed by stalebot"

[–] spaphy@lemmy.ml 4 points 10 months ago

If that's happening to you that's crazy. GitHub is way too noisy though. I get 30 notifications on that apps notification widget though for just bullshit I didn't even know I signed up for or snyk or some other garbage.

[–] DeaDvey@lemmy.ml 4 points 10 months ago

I did this, then it too so long that it broke. Still hasn't been pulled.

[–] Omega_Haxors@lemmy.ml 1 points 10 months ago* (last edited 10 months ago) (1 children)

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 points 10 months 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?