[fluffything]

I only interacted with them on Github issues in the sway repo.

The interaction was of the form: "I'm having this problem, I've looked at this, what would be the best way for me to improve this". Reply from Drew "No [issue closed]".

Then using sway, I ran into a lot of problems, and many of them were already reported, but closed issues, which closed with a similar exchange.

At some point, every time I had a sway problem, I would search for my issue on Github with the closed filter first. Finding those issues, with no rationale, workarounds, path forward, discussion of any kind....

Yeah, I just stopped using sway a while after and went back to i3. It at least worked, so I never had to interact with their community.

[ddevault]

I'm sorry you had a bad experience with Sway. If you can be more specific, with links to issues, it would be helpful for me to learn to deal with those cases better.

It's worth keeping in mind that maintainers see a lot more issues than you do. It's likely that I've heard and declined your feature a dozen times already, or that it's part of a broader class of problems which has been heard a hundred times. Sometimes, it tests my patience. And sometimes we do just have to say "no" - not every feature or change is desirable, and if we said "yes" to everything, then sway would quickly become a Cronenbergian mess.

[fluffything]

Being more specific would give away my identity, but this is one issue I ran into while moving from i3 to sway:

https://github.com/swaywm/sway/issues/1005#issuecomment-3315...

where the comment that closes the issue just says "we'll never implement this, issue closed".

I sympathize with you in that, if you had little time and other things to attend to, then just closing an issue is an instant reward of having something less to do.

But I think it would have been better to, first, don't do anything about that issue if you didn't had the time to do it properly (even if you were the one that filled the issue!), which would have been to write down the rationale why you think that feature is not worth its tradeoffs, and also, to have let other users speak up their mind, and see what others think, before making a decision.

For me, that difference in "project culture" is the difference between an open source project that's worth contributing to, and one that is not.

I've grown a couple of very large open source projects, and some of them I look at once a year, and they keep growing with dozens of PRs per week or day! The main reason I am able to just move on to other things is because I've grown and mentor the new maintainers and leaders of these projects , and I know they both carefully listen to the projects users, and are able to grow new contributors, just like I did.

[ddevault]

This was 3 years ago. I usually treat these issues a bit better these days.

However... I disagree with your suggestions about how to go about this better. You're still coming from a place where all paths lead to the implementation and inclusion of the feature. We will say "no" sometimes, and there's no amount of discussion which is going to change that. We're volunteers with a limited amount of time, why should we lead everyone on by entertaining a fruitless discussion in on a feature for which we have no interest in supporting?

There's a lot of discussion you don't see, too. Discussion on the IRC channel, private discussions between maintainers, snippets here and there on patch reviews and other issues... just because you didn't get your say, doesn't mean that the issue wasn't sufficiently discussed. At some point I just don't want to discuss it any more. I could redirect you to /dev/null and let you say your fill, but I don't think that's fair to you, either. You can't always get what you want, and if I don't always give you what you want, that doesn't make me a bad maintainer IMO.

[fluffything]

> You're still coming from a place where all paths lead to the implementation and inclusion of the feature.

Not really. Ideally, I'd have read a comment saying: "We discussed this on IRC, and for this and that reason, we decided that this is probably never going to be worth doing. If you have any new information or argument that was not considered above, please do raise it with us, but we are closing this issue for now."

> There's a lot of discussion you don't see, too. Discussion on the IRC channel, private discussions between maintainers, snippets here and there on patch reviews and other issues... just because you didn't get your say, doesn't mean that the issue wasn't sufficiently discussed.

If your discussions don't happen in the open, how open is your open source project really?

You can discuss things on IRC, or whatsapp, or wherever you want, but if a synchronous and/or private communication channel is used to decide on technical issues that impact the project, then you are essentially excluding everyone that doesn't live in your same time-zone, wasn't there on IRC at that time, can't search those IRC logs, wasn't invited in the room, etc. from impacting your project.

That's just not open enough for me, so I don't contribute to projects that work like that.

Rust or th linux kernel discuss everything in the open, so that everyone can see it and participate, whenever they have time to, and make their case. Whether that's a mailing list, a forum, or a github issue doesn't matter.

But closing an issue with "no" isn't very helpful for all those users that weren't in the room where that was decided, and they will all wonder "why".

> that doesn't make me a bad maintainer IMO.

There are dozens of different ways of maintaining open source projects. Just because sway's way doesn't fit me doesn't mean it's bad. It just means that it doesn't fit me. If you'd like to change something so that it fits people like me, the above hopefully explains what the issues for me were. But I don't expect you to do that, and you don't have to do that, and its perfectly fine for you to disagree and don't want to do that.

[ddevault]

Our IRC channel is open, and many people watch and participate in discussions there. Many of our contributors and maintainers are also friends, people we ping for advice on unrelated things, and so on, and sometimes discussions happen incidentally. We don't go out of our way to conduct discussions in private, and we make our primary communication mediums available to the public. Just because you don't like IRC doesn't make it less open. If you ask for more details, we will also often entertain your question, especially in the context of "I want to know so I can write a patch". But if you're just another grumpy user bringing their bat up for a swing at the dead horse, then no, we're not going to entertain you.

We're human beings, and we acknowledge that. I don't go out of my way to try and build a community which avoids that fact. Treat us like human beings, people with feelings and knowledge and a limited amount of time. You didn't pay for it, so you're not entitled to support, features, or yes, even explanations of why decisions were made. It's a collaborative effort, run by volunteers, who can stop volunteering whenever they want. Some users get burned by this, but contributors don't, and contributors are more important than users.

Sway is not some abstract concept of a project - it's made out of people.

I know this doesn't directly address many of your comments, but I feel that it hits on a deeper and more important difference in our beliefs. User entitlement is a huge problem in open source, and it burns out maintainers faster than anything else. I don't stand for it.

[Dayshine]

> Just because you don't like IRC doesn't make it less open

No, but having discussions somewhere completely unlinked to your open source repository without a searchable archive and no way to link to discussions does.

Hell, even gitter, which is a pretty clumsy tool lets you link directly to discussion, e.g. https://gitter.im/SublimeLSP/Lobby?at=5dce95d835889012b111a0... (although the fact that this project immediately moved to discord, a less open discussion tool without easy searching isn't amazing).

Do you prefer having to answer the same questions over and over in IRC rather than link to the discussion from a single authoritative issue?

For context: I'm 27 and in the last 10 years, I've used IRC maybe twice. To me, and many others, IRC is an opaque, closed, system. I have absolutely no idea how I would start to search your IRC channel. Hell, I thought IRC logs were only for conversations you were present for. If you can't just give somebody a link to a conversation (which you can in Slack, Gitter, Discord, Teams, mailing lists, Jira, bug trackers, etc) then I'm not sure it counts as open.

> so you're not entitled to support, features, or yes, even explanations of why decisions were made

I was initially going to respond by saying "then you shouldn't ask for contributions". However, the sway repo is actually much better than most and the CONTRIBUTING.md makes it pretty clear you should discuss things with the maintainers first.

Perhaps I'll update my projects with clearer guidance as to whether I'm interested in contributions...

[fluffything]

> Just because you don't like IRC doesn't make it less open.

IRC isn't the problem, the problem is synchrnonous communication channels in general (IRC, whatsapp, telephone, Matrix, ....). If somebody is not available when the discussion is ongoing, they can't participate. That does make your communication channel much less open than, e.g., a mailing list, where somebody from a different timezone can read the discussion 8 hours later and participate in it.

> User entitlement is a huge problem in open source, and it burns out maintainers faster than anything else. I don't stand for it.

What burns maintainers is having too much to do, and the root cause of that is failing to grow other maintainers to help you with your projects, which is impossible to do if you act as a burned maintainer, because open source is something most people do on their free time for fun, and stressed / burned / overworked maintainers aren't fun to deal with.

Sustainable projects have a high-ratio of contributors relative to users. When this ratio is high, it doesn't matter that some users act entitled, because there are enough maintainers to deal with that load. If you have a lot of users, but a relatively small contributor base, that's when things become problematic.

Attracting contributors is probably the hardest part of open source, and like it or not, every project is competing against all other projects for contributors. Projects that are super nice to every user that interacts with them, no matter how "wrong"/"entitled" the user is, or tired its maintainers are, attract the most contributors, because people like working there.

Being tired while dealing with an entitled user and trying to be super nice with them is super tough, but all other alternatives I know are much worse.

[tsukurimashou]

you cannot be that emotionally involved, what you take as aggressive is simply someone not giving you enough attention.

and I'm sorry but a project being 'open source' doesn't mean that everyone can or should contribute, not all contributions are good or helpful and if you have a certain standard in mind for your software you have to filter contributions.

[Dayshine]

The problem of course is that if you have

- an open source project which you advertise as collaborative open source

- a personal vision for what you want in your project

- and hence, a secret list of requests you will turn down

Then frequently people might spend 10, 20, 30, 60 minutes trying to do something with your project then writing up an issue. You then immediately shoot it down, because it doesn't match your vision, and that person gets burned.

If you have MIT license and no guidance on contribution, that's user error. But if your project has a PR workflow or has that "Imposter syndrome" line about contributions, well, maybe it's partly your fault.

I'm not saying all open source projects should have guidance. But perhaps all projects with a CONTRIBUTING.md and ISSUE_TEMPLATE.md really should have a clear list of features they will outright reject.

[pushedx]

One thing that I’ve learned from the Kubernetes community is to have a list of “Non-Goals” right next to every list of “Goals” in documentation, and of course to have a list of “Goals” at all.

[fluffything]

> and I'm sorry but a project being 'open source' doesn't mean that everyone can or should contribute, not all contributions are good or helpful and if you have a certain standard in mind for your software you have to filter contributions.

So if someone sends you a contribution that isn't good enough, you reject them with a "no", and that's it?

Sure, you can do that. A different project might expend some time teaching that contributor and being nice to them, until their PR can be merged. And then the contributor submits another one that's better, and then another one, and then before you realize it you have another full time maintainer that you can trust.

So when you say that if a contribution isn't good enough you reject it I say "Thank you", because that person will move on to a different open source project, which might be one of mine, and I'll be getting another contributor instead.

You might not think that the work required to attract a new full-time contributor is worth it. To me it is.