why does EVERYTHING have to have muh use case?

context would be nice
where is this from?

what's the use case for this thread?

its linux philosophy

>>106002788 (OP)
Because there should be a good reason to change something

>>106002857
Only for changes that will certainly have considerable impact on current and future iterations of whatever it is that is being changed. Otherwise its just faggotry.

>>106003078
so tell them that in those exact words

>>106002788 (OP)
If you want the change then make it yourself. If you want somebody else to do it then justify it. You are not entitled to the time and effort of others.

>>106002854
it's gnome philosophy. the rest of linux works the opposite way.

>>106002788 (OP)
it's another way of asking "out of the six million other bugs/feature requests/defects we could be fixing, why should your request jump even into the middle of the pile instead of at the end of the backlog?"

>>106002788 (OP)
it's because of spaghetti. they cant implement any simple feature and copes by asking this

>>106002788 (OP)
>Can you change your thing for me for free?
>Why do you need it?
>STOP ASKING QUESTIONS AND JUST DO IT!

>>106005078
>>106006756
>>106006781
you're incorrectly assuming this only happens on issues/feature requests, i've seen this happen on pull requests where the contributor has provided the code for the feature, tests included, perfect PR stalled by "what's the use case"

>>106006794
that cuts down on the maintainer load required but it doesn't reduce it to zero
plus what if the drive-by contributor never shows up again, and nobody who's permanent understands wtf the code does?

>>106006794
>forgets maintenance costs
What's the use case for me having to understand how this affects the rest of the project or just code around it for the rest of the product's lifecycle?

You are incorrectly assuming your "perfect PR" solves all future problems related to it. If you have already done everything, then it should literally werks on your machine, what's the use case for pushing it back to me?

>>106006830
>>106006832
>nobody who's permanent understands wtf the code does
>What's the use case for me having to understand how this affects the rest of the project or just code around it for the rest of the product's lifecycle?
that's literally your job, to understand the code you are maintaining
>what's the use case for pushing it back to me?
so that others can use it
>your "perfect PR"
not mine, i've seen it many time as a maintainer, other maintainers say "what's the use case" for something that there is indeed a valid use case for, then the contributor is gone, they don't bother any more

>>106006965
>that's literally your job, to understand the code you are maintaining
EX-fucking-ACTLY

So you're literally admitting that you are adding to my job, regardless of how perfect your PR is (I don't mean yours as you made it, retard, I mean as in your examplary fictional perfect PR). It will add some code for me to maintain. You admitted it already wrerks on your machine and you want others to have it.

All I'm asking is WHY do you think others might need it, and WHY do you think I should have to work on it. You don't think I'm allowed to even ask that? I'm supposed to just gobble up more UNPAID work like I'm some fucking jannie? And without having a say so, just shut up and take it, stop asking questions, like some fucking wagie? You think less of me than both of them?

FUCK KIKES, FUCK JANNIES!
BUT MOST OF ALL, FUCK YOU, FAGGOT!

>>106006997
if it's some no-name no stars toy project then sure go ahead, you probably don't maintain it anyway, i'm talking about large repos with paid maintainers and the use case for the PR is already spelled out in the PR itself
>FUCK KIKES
cool it with the anti-semitism guy

>>106007015
>the use case is already spelled out in the PR
Then the maintainer is not fucking asking the use case, retard.

>>106007034
as i said, yes they are, i've seen it many times

>>106007041
>Maintainer asks for use case info already present on the PR
Then it's not a problem of needing to have muh usecase for everything, as spelled out in OP (as there is already a use case and it's explained on the PR), it's a case of communication problem. So your question now is why there are communication problems where the maintainer doesn't understand the use case provided by the PR guy?

>>106007055
i don't see it as a communication issue, it's about exerting control and making people jump through hoops to justify their own existence

>>106007075
But it IS more work for the maintainer. The work HAS to justify its existence to the maintainer. I don't understand how you expect the maintainer to just take up more work and doesn't need to understand why he needs to do it. Is it not a valid question?

>>106007075
Suppose you work idk, breaking rocks. Someone walks up to you and points at another pile of rocks and says "Dude, you have to break those too. Not instead of the ones you're breaking, you gotta break these and also those. Two piles of rocks." and you're not supposed to ask why? You just take it with a smile?

>>106007098
you're assuming they need to work on that area of code again, there are many areas in the codebase i'm talking about that haven't been touched for years, there is no extra work for the maintainer, the extra work has been done by the contributor
>>106007110
that's not realistic and you know it. it's more like someone rocks up and says "if you do this it will be more efficient" and you screech what's the use case for being more efficient

>>106007114
These are my rocks and I've been breaking these rocks before you came, you walk up to me from your high and might authority and declares:
>"if you do this it will be more efficient"
I can't ask why you think that is more efficient? Why you know more about breaking my rocks than I do?

>>106007114
>you're assuming they need to work on that area of code again
It's new code. They don't know whether or not they'll need to work on it again. They don't know which subtle bugs it could bring elsewhere. Or how it affects the larger design.

And yet, you're attacking their ability to ask and make an informed decision about it instead of just taking the gamble and trusting your word. You are a nobody. They don't know you. You're at best an anime avatar with a PR. They shouldn't even devote precious minutes to read your code or hours to try to understand it without knowing WHY they'd need to. And you're saying they shouldn't ask why.

>>106007130
>They don't know which subtle bugs it could bring elsewhere. Or how it affects the larger design.
this is what tests are for lol

>>106007151
If your code is so perfect and flawless, then why don't you keep your repo up and maintain your fork? Why do I have to do it?

The problem is not the commit, not the PR, not the code. The problem is you fail to see the agency of another human being. For you, the maintainer is nota person who can chose what he wants to do. For you, the maintainer is a tool for you to dump your code on and he maintains it. A cog that should be a good cog and keep spining to the beat of the machine. He's a person, maybe he's having a bad day and wants to power trip. Maybe he's having a good day and just curious about the use case his software is having that he didn't anticipate. Maybe he's just used to asking and did it without thinking. And you are defending the position that he doesn't have a right to ask it. He should just take your pr AND the extra work you admitted it's going to give him and just be the tool you want him to be instead of the person he is.

This isn't about technolo/g/y. This is about you being a horrible person. And if I couldn't get it thru to you in however many posts I wasted, God knows I fucking tried. I hope you learn some empathy and that not everybody else exists to serve you, despite the fact that I just spend some hours doing just that.

Good night, anon. Have a good life. I hope your PRs get accepted when you decide to provide the use case to the maintainer.

>>106007178
as i said, this is something i've seen as a maintainer from fellow maintainers, where the PR clearly outlines the use case, yet they still power trip, making the contributor jump through hoops reiterating what's already been said, and inevitably put the contributor off from contributing again
there's one in particular that made several excellent PRs with high impact, i worked with him to ensure the quality was excellent, he literally asked what they could work on next, suggested a few things that were needed, then other maintainers pulled the "what's the use case" out on him, and he never contributed again

use case for posting github screenshots without context?

>>106002788 (OP)
>why does EVERYTHING have to have muh use case?

>>106007198
So it's not about the need for things to have use cases. It's about your particular situation where some specific people were being mean jerks. You should have asked on OP "Why are some meanies mean?", and you would have been called out as a faggot, which you are, since you are OP, but it would have saved mine and other anons a lot of time discussing the benefits of the maintainer understanding the use case before accepting more work.

Classic XY problem.

In your specific problem, if your coworkers are making you uncomfortable, talk to HR. That's why they are there, not to power trip and make hiring a tinder shit. If HR is shit, take it up the command chain. If the higher up is also shit, then quit that shitty job.

/thread

>>106007222
i'm not the op, take your meds

>>106007230
>OP asks about the need for use cases
>anons start discussing the merits of having use case explained to maintainer
>(you) highjack the thread to counter every argument about the legitimate need for use cases because you are butthurt about your coworkers

Well, I'd like to restate my earlier FUCK YOU!
And have a nice day.

>>106007241
read the op screenshot, if you follow the context it is more than likely from a PR, not an issue where someone has requested a change, they have made the change, explained the use case, then the maintainer says "what's the use case"
>FUCK YOU!
meds

>>106002788 (OP)
It wastes developer time and more complexity equals less polish.

>>106002788 (OP)
because increased complexity raises maintenance cost.

>>106007276
Use case for meds?

>>106002788 (OP)
Ask any experienced software engineer and she will tell you that almost every feature, every option, every change...
>makes the project more complex
>creates more scenarios to test
>increases the likelihood of some obscure bugs only reproducible with very specific configurations
>will lead to more support requests from users
so you need to make a good argument that it's worth it.

>>106002838
time wasting