4 ms·

> The maintainer is expecting attention and users Do they? The projects I maintain I do so for myself and work. > By alerting the maintainer to issues, I woul

by mmmrk 6y ago

> The maintainer is expecting attention and users Do they? The projects I maintain I do so for myself and work. > By alerting the maintainer to issues, I would be helping them Do you? I need to weight the time and effort to understand your issue against my potential gain from it. > The nuclear option for a maintainer is to completely ignore the user base whose attention they need Odd, I don't need attention for my projects. > as if owing was any part of any of it You explicitly spell out that maintainers owe user listening to them and helping them for their "free labor". > But wouldn’t we hope the social contract in FOSS has a higher standard and people try to both give and receive reasonable feedback, and people try, at least, to consider users’ needs after users have invested attention, word of mouth review, effort on bug reports If said users indeed invest quality time and I as a maintainer feel like their presence enhances my project, sure, giving and receiving is a good idea! Now, we both know how often that happens :)

mlthoughts2018 6y ago
> Do they? Overwhelmingly yes. > Do you? Yes, only users of a library or package really have sufficient context to articulate the pain points, bugs, and missing features. Users have to weigh up their own time and priorities too, so for users to give up their free time to put work into documenting issues / feature needs, that is a bunch of free labor given to the project maintainer. Any maintainer who sees bug reports or feature requests as a time drain instead of free product research is completely wrong. > Odd, I don't need attention for my projects. Then why are they open source? > You explicitly spell out that maintainers owe user listening to them and helping them for their "free labor". No, I never said anything like that, in fact I said the opposite. Maintainers are perfectly free to ignore users if they want. It would just mean it’s reasonable for users to see that as a shitty owner and express frustration about it. Maintainers don’t owe anyone anything, and I never said otherwise. But it’s perfectly legitimate for users to express frustration over badly managed FOSS projects, neglected feature requests, etc. In other words, “if you don’t like it, leave” is unjustified, and users should express frustration. It doesn’t mean a maintainer is going to listen, but that’s beside the point. The original comment I replied to proposed that users are ingrates or should possibly be banned if they “complain” - that if they have a problem, it’s not the maintainer’s problem. These are just wrong attitudes. Maintainers aren’t obliged to do anything. Irrelevant. Users should still complain and lobby maintainers to fix things, as that’s far more helpful and reasonable than “take it or leave it.” > If said users indeed invest quality time and I as a maintainer feel like their presence enhances my project, sure, giving and receiving is a good idea! Now, we both know how often that happens :) No, this is up to the users to decide, as they actually use the project. Users decide if filing a bug report, asking for a feature, or pushing back on a roadmap is needed, because it stems from the problems they experience as users. Of course the maintainer doesn’t have to care or even read it, but that would be horrendously undiplomatic of the maintainer, and users would have every justification to express frustration about it.
- TheDong 6y ago
  > Yes, only users of a library or package really have sufficient context to articulate the pain points, bugs, and missing features This is a bizarre viewpoint. The creator/developers of an open source project usually has a far better understanding of the bugs, missing features, etc of their project. They've spent months to years thinking about it. They understand the technical restrictions that result in various tradeoffs. Users making feature requests rarely have the full picture or understand the technical tradeoffs at play, unless they implement or fix their issue themselves. Maybe there's a 1/3000 issue where a user gives thoughtful and meaningful insight into a new feature the project could have which the maintainer hasn't thought of, but the vast majority of issues are not that. The vast majority are users who don't understand the technical tradeoffs of the project, don't understand the maintainer's goals, etc. Again, if a user has a good idea for the project, the user should fork it and implement it. If the user can't, then they shouldn't be asking the maintainer to. In addition, if a user feels like they're spending enough time to "put work into documenting issues/features" that they're net losing time after the savings of being able to use the project (vs implement it all themselves), then they should neither file issues nor use the project at all. > Then why are they open source? Projects don't have to be open source because someone wants bug reports from users who have no clue what they're talking about. In fact, if you listen to maintainers, the vast majority don't want that crap. Projects can be open source because "information wants to be free", or "I want my users to be able to fork it, they have rights", or "I hope someone learns from this", or "I want people to contribute code (but not dumb issues)". For the most part, an open source project wants attention from a group of people - people who find the project useful already, and who are willing to not incur a maintenance burden. Just because the author of the project does want people who find the project useful as-is to use it doesn't mean that they're inviting people who have issues with it to use it and complain. > Users should still complain and lobby maintainers to fix things, as that’s far more helpful and reasonable than “take it or leave it.” No, it's not more reasonable for users to complain unless the maintainer asks users to complain. If the maintainer has a contributing.md or a page on their site that says something like "please send me poorly thought out feature requests, hate mail, and entitled bullshit", then yes, users can do that. Otherwise, the user should indeed take it or leave it. If the maintainer has a contributing.md saying "I might accept PRs", the user can absolutely discuss implementing a feature with the maintainer. The default, if there's no documentation about expectations, is that it is 100% take it or leave it. You seem to think that all open source projects are like RHEL, where a huge company runs it and all users pay thousands of dollars for support. In that specific case, yes it's totally fine for users to send support emails describing issues they ran into. The majority of oss projects are not that. The majority are some dude who hacked something out and hopes other people like it too. If other people like it, cool. That does not give other people a reasonable right to expect that person to actually do any serious maintainership of it. That seems to be your big disconnect. Users are entitled to nothing more than the existing code given to them in an OSS project unless the author explicitly adds additional expectations (such as having a contributing.md asking for issues or having a bug report button in the project or something). I have to ask, have you maintained many open source projects? Have you seen things from both sides of the fence? What interactions have led you to have this viewpoint? Your viewpoint seems quite foreign to the maintainers I've met, and I'm curious what has shaped it. My perspective has largely been shaped by maintaining OSS projects, talking to other maintainers, and reading secondary sources on the free software ethos.

by mmmrk 6y ago

mlthoughts2018 6y ago

> Do they? Overwhelmingly yes. > Do you? Yes, only users of a library or package really have sufficient context to articulate the pain points, bugs, and missing features. Users have to weigh up their own time and priorities too, so for users to give up their free time to put work into documenting issues / feature needs, that is a bunch of free labor given to the project maintainer. Any maintainer who sees bug reports or feature requests as a time drain instead of free product research is completely wrong. > Odd, I don't need attention for my projects. Then why are they open source? > You explicitly spell out that maintainers owe user listening to them and helping them for their "free labor". No, I never said anything like that, in fact I said the opposite. Maintainers are perfectly free to ignore users if they want. It would just mean it’s reasonable for users to see that as a shitty owner and express frustration about it. Maintainers don’t owe anyone anything, and I never said otherwise. But it’s perfectly legitimate for users to express frustration over badly managed FOSS projects, neglected feature requests, etc. In other words, “if you don’t like it, leave” is unjustified, and users should express frustration. It doesn’t mean a maintainer is going to listen, but that’s beside the point. The original comment I replied to proposed that users are ingrates or should possibly be banned if they “complain” - that if they have a problem, it’s not the maintainer’s problem. These are just wrong attitudes. Maintainers aren’t obliged to do anything. Irrelevant. Users should still complain and lobby maintainers to fix things, as that’s far more helpful and reasonable than “take it or leave it.” > If said users indeed invest quality time and I as a maintainer feel like their presence enhances my project, sure, giving and receiving is a good idea! Now, we both know how often that happens :) No, this is up to the users to decide, as they actually use the project. Users decide if filing a bug report, asking for a feature, or pushing back on a roadmap is needed, because it stems from the problems they experience as users. Of course the maintainer doesn’t have to care or even read it, but that would be horrendously undiplomatic of the maintainer, and users would have every justification to express frustration about it.

TheDong 6y ago
> Yes, only users of a library or package really have sufficient context to articulate the pain points, bugs, and missing features This is a bizarre viewpoint. The creator/developers of an open source project usually has a far better understanding of the bugs, missing features, etc of their project. They've spent months to years thinking about it. They understand the technical restrictions that result in various tradeoffs. Users making feature requests rarely have the full picture or understand the technical tradeoffs at play, unless they implement or fix their issue themselves. Maybe there's a 1/3000 issue where a user gives thoughtful and meaningful insight into a new feature the project could have which the maintainer hasn't thought of, but the vast majority of issues are not that. The vast majority are users who don't understand the technical tradeoffs of the project, don't understand the maintainer's goals, etc. Again, if a user has a good idea for the project, the user should fork it and implement it. If the user can't, then they shouldn't be asking the maintainer to. In addition, if a user feels like they're spending enough time to "put work into documenting issues/features" that they're net losing time after the savings of being able to use the project (vs implement it all themselves), then they should neither file issues nor use the project at all. > Then why are they open source? Projects don't have to be open source because someone wants bug reports from users who have no clue what they're talking about. In fact, if you listen to maintainers, the vast majority don't want that crap. Projects can be open source because "information wants to be free", or "I want my users to be able to fork it, they have rights", or "I hope someone learns from this", or "I want people to contribute code (but not dumb issues)". For the most part, an open source project wants attention from a group of people - people who find the project useful already, and who are willing to not incur a maintenance burden. Just because the author of the project does want people who find the project useful as-is to use it doesn't mean that they're inviting people who have issues with it to use it and complain. > Users should still complain and lobby maintainers to fix things, as that’s far more helpful and reasonable than “take it or leave it.” No, it's not more reasonable for users to complain unless the maintainer asks users to complain. If the maintainer has a contributing.md or a page on their site that says something like "please send me poorly thought out feature requests, hate mail, and entitled bullshit", then yes, users can do that. Otherwise, the user should indeed take it or leave it. If the maintainer has a contributing.md saying "I might accept PRs", the user can absolutely discuss implementing a feature with the maintainer. The default, if there's no documentation about expectations, is that it is 100% take it or leave it. You seem to think that all open source projects are like RHEL, where a huge company runs it and all users pay thousands of dollars for support. In that specific case, yes it's totally fine for users to send support emails describing issues they ran into. The majority of oss projects are not that. The majority are some dude who hacked something out and hopes other people like it too. If other people like it, cool. That does not give other people a reasonable right to expect that person to actually do any serious maintainership of it. That seems to be your big disconnect. Users are entitled to nothing more than the existing code given to them in an OSS project unless the author explicitly adds additional expectations (such as having a contributing.md asking for issues or having a bug report button in the project or something). I have to ask, have you maintained many open source projects? Have you seen things from both sides of the fence? What interactions have led you to have this viewpoint? Your viewpoint seems quite foreign to the maintainers I've met, and I'm curious what has shaped it. My perspective has largely been shaped by maintaining OSS projects, talking to other maintainers, and reading secondary sources on the free software ethos.