@dotstdy I haven't said that maintainers should close issues on a whim because they don't like somebody. Though in this case I absolutely agree that maintainers are free and should close such issues.

It's their project. They aren't obligated to resolve any specific issues, nor to accept contributions of any sort to address certain needs.

Of course if it's a bandwidth limitation they wouldn't close it on a whim and is simple a pessimistic interpretation of what I haven't even said here.

@karolherbst maintainers are not some kind of magical being, able to trivially determine the right course of action at a glance. i don't think encouraging people to think in such adversarial ways really helps anyone. by all means close issues that nobody's going to work on, but you gotta accept that maintainers are not the only humans in the story. this is why projects have governance mechanisms, to avoid the kinds of failures that arbitrary one-guy decision making leads to.

@dotstdy "artists are not some kind of magical being, able to trivially determine the right course of action at a glance"

but somehow trying to chime on on artists work _is_ considered a rude thing to do, but not when it's a FOSS project?

Like if I have a personal project and get random people telling me what to do, I can just ignore them in any other circumstances, but with FOSS people are feeling entitled of having that duty, which is just wrong.

@karolherbst in most large projects where this is even a problem, it is not in fact "their project", it's a project built over many years through the contributions of many people. I think that's the core tricky part.

@dotstdy yeah and you'll have a core community around a project that's doing that.

But again, you just have the worst possible interpretation of what I've said here. And might just want to vent about your own experiences here.

Project internal issues are an entirely different topic. Replace "maintainer" with "project" if you like that better. But the core message stays the same: they can just decide things if they want to and nobody has any say in it.

@karolherbst I mean project is a lot better than maintainer, but my core thing here is that it's just unnecessary to be us-vs-them here. by all means close tickets that are not actionable, or nonsense. but i think any time you close something without a reason, or just because you don't like it, as a project, that's a bad outcome for your community.

@dotstdy well the project also needs to consider the community when making such decisions clearly...

Like sure there are bad project leaders, but what are others going to do about it?

People often and generally use this felt entitlement as an excuse for their horrible behavior (starting harassment, trash-talking, etc...).

If a project says "no", it means "no", not "but you are bad and you should consider my technical reasons, because I'm smart and know better".

@karolherbst Framing it as entitlement is really weird and I don't think it's helpful. Again, there's humans on both side of the fence here. A project is ideally a collaboration of people writing and maintaining and using software. The majority of people are pretty receptive to "yeah we just don't have time for that", but nobody likes an issue they spent time researching and writing to be closed without even a reason given. It often creates further issues, rather than shutting them down.

@karolherbst this isn't 100% true for artists either. If they art needs to be part of a larger project involving other artists (Eg. Think of a game) then it makes sense that the artist needs to be given some direction to make sure things fit tougher in some measure. It's not rude at all it's a consequence of cooperation. Whether something is art or not frankly has very little to do with this. Also tbh issues and such are social interactions and the rules there are that of any other social interactions: unwarranted hostility is never justified imho.

@pac85 well the artist also gets payed in this case to do something specific often.

Of course there are also collective of artists doing things together, but then it's a project and the project is still deciding even if individuals are having different opinions.

The mistake here is to assume users are part of the project, which they aren't. Just because they are allowed to participate doesn't grant them any further privileges like decision making rights.

@pac85 Also I heavily disagree with the "hostility" claim.

That's one-sided. The maintainers were never asked if they want a relationship with their users, but somehow if the users gets told "no" it's hostile.

That's kinda absurd, isn't it? Like it's a para-social construct. There is no relationship, but somehow we accept that fake relationships should drive how FOSS is operating which sounds very sick tbh.

@karolherbst well no, the moment you accept to be a maintainer you accept a number of responsibilities. The social aspects are just as important as the technical parts for maintainer. But more generally whenever there's a channel of communication I think the rules for decency apply and ignoring those leads to a perception of hostility. There's many ways of addressing the "I don't have the resources to fix this" problem and deciding to completely ignore the bug seems the worst to me even on a technical level (Eg. You might have the resources in the future).

@pac85 > well no, the moment you accept to be a maintainer you accept a number of responsibilities.

Nope, you don't. You accept nothing. You are free to participate in a community, but you are not obligated of doing so.

The only exception where one can demand things of you is if there is a contract you signed nd get paid for it.

@karolherbst I don't get where you are going with this. Are you gonna justify assholish behaviour just because someone is volunteering?

@pac85 Like if I go to a random manufacturer of something and "open issues" and they show me the door, I have to accept it. But if it's FOSS you claim it's hostile to show me the door.

@karolherbst this isn't true though? Customer services is a thing and big companies tend to lose money over a small number of individuals for the sake of pr.

@pac85 customer services has the right to throw out any customer for any reason unless it's like because of racism or so.

@pac85 But what you are arguing here for is, to not accept boundaries that maintainers/project set up.

And mostly "because it's FOSS and it has to be the way I think it needs to be".

And all I'm saying here is, that we all have to respect maintainers boundaries first. Then we can figure out the rest later.

dotstdy@mastodon.social hey, sorry to interject, but my uninvited thoughts on "happy to accept PRs" is that it's also problematic because it means you continue to assume the maintenance burden of any new functionality.

Being a project maintainer doesn't mean you are obligated to spend bandwidth on every pull request, either.

karolherbst@chaos.social