Post #169055
2026-01-22 18:20 UTC
Replies (10)
-
@Treczoks@lemmy.world 2026-01-22 18:25
Sorry for meeting such an asshole maintainer. I'd never do this, especially for someone who actually did the preparatory work to find the location of the bug.
-
@edinbruh@feddit.it 2026-01-22 18:35
What project is this? I have never seen a reaction like that, if anything I've had the opposite, where I said it was a minor inconvenience and the maintainer said "what do you mean 'minor'? This is terrible!"
-
@nightlily@leminal.space 2026-01-23 00:03
The big red flag here that should warn away anyone from interacting with the project is that the maintainer clearly wasn’t using a standard library for time functions. Arrogant stupidity is a given in that situation.
-
@Neptr@lemmy.blahaj.zone 2026-01-22 18:46
My experience was the opposite. I asked the maintainer if I could specify environment variable directly in the sandbox profile config and they said "uh you can do that with the cli [reference to documentation], but sure I will think about adding it" and they had a version by the evening that I could test.
-
@kali_fornication@lemmy.world 2026-01-22 19:17
.cpp is the funniest file extension, .see PP lmaooooooo
-
@Pika@sh.itjust.works 2026-01-22 23:15
I don't contribute to projects most of the time strictly due to the hurdles in place for contributions. if I see an issue with something, I would like to be able to properly fix it, not have to follow a multi month process to actually get it in The last project I wanted to contribute to had the following system: 1) make an account (makes sense, its a self hosted tracker) 1) verify my identity and specify what I wanted to do in a whole different project in order to get validated to be able to open issues in the tracker 1) open an issue stating that I found a problem 1) state in the issue that I was willing to fix said problem 1) agree to sign the code away if done 1) wait for response confirming that it was ok 1) fork the project 1) fix the issue on your fork 1) create test units for the project 1) submit a merge on the main project 1) wait weeks to months for the actual maintainer teams to review the fix and make suggestions/alterations 1) fix any merge conflicts that was created during the time that it took to review 1) rinse and repeat the last 2 steps until it's finally merged Luckily I had noticed that the timeframe of existing requests prior to doing it, and decided to pass on it. Don't get me wrong, a lot of those steps are necessary for proper development cycles but, it's the extra steps that are annoying. I'm looking to quickly contribute and move on. Too many steps or if the process seems like it will be a major pain in the butt = You can find and fix it yourself. Most projects if they have that I will at least open an issue for it so it's known as a problem... but some projects don't seem to want them reported, let alone fixed.
-
@infinitesunrise@slrpnk.net 2026-01-23 17:15
I always read the project's issue tracker *before* I decide to contribute anything. Has spared me from a lot of contact with people like this.
-
@CreateProblems@corndog.social 2026-01-24 00:04
Okay but like, there's a right and wrong way to count time and they're doing it wrong. This is 100% valid to report as a bug, and imo, incredibly helpful - especially compared to most of the bug reports I see! Idk what the context is here, but for the software I QA for work, this kind of mistake would break *everything*, and I'd report it as a bug. Their comment isn't a reply in a professional situation, but still, that reaction is extremely over the top. What an asshole
-
@mkwt@lemmy.world 2026-01-22 23:54
PR rejected: Unnecessary bloat.
-
@ExLisper@lemmy.curiana.net 2026-01-23 22:55
Maybe I was lucky but I never had an experience like that. I contributed to couple of projects and it was mostly fun. Like find a missing feature -> implement -> PR -> accepted with a thank you. Or report a bug -> get a fix in a matter of days.