No maintainer is obligated to maintain access to a discussion space for their users.
> One now doesn't even know and cannot even estimate the number of other issues that must have gone unreported. It's not safe or wise to use a package that is so shrouded in mystery. It is in fact foolhardy.
Issues don't get reported for any number of reasons. All open source is use at your own risk.
Do not try to equalize the risk of using an open software where issues are allowed versus one where issues are not allowed. The risks are not the same. In blocking users from commenting, it is obvious that the authors of this software are trying to cover up for gross negligence and bugs.
Do you simultaneously believe "it is a maintainer's prerogative to ignore any public feedback they receive":
If maintainers don't want to address issues, they only have to ignore them.
and that disallowing comments on a temporary basis, starting in the last few days, is gross negligence?
And do you also believe that the offensive part of this scenario is that their users, who may or may not be compensating them but statistically are not, temporarily don't have a public venue in which to chastise them for a problem that was already responsibly solved in a previously released update?
Do not try to equalize a maintainer guarding their time and energy from having to deal with an issue that has already been fixed and users that refuse to search or read with trying to cover up for gross negligence and bugs.
There are better ways of dealing with it. For example, a particular issue can both be locked and pinned. The readme too can be updated to reflect the concerns. There is never a need to disable all user interaction. It is foul-play and it stinks of other major bugs that the authors don't want users to become aware of.
Damn, I was hoping this bridge would stay in its current limbo state where it's open to pedestrians and bikes but closed to vehicles. It's so much nicer not having a five lane stroad that lets cars go 50mph into a park, and instead having a pseudo-community space.
They could do that, but you'd be able to see that nobody/few outside their cluster signed any of their keys.
Let's say they have fake passports and physically appear at key signing parties. Now you're screwed because even your peers (that you thought know how to validate identities using passports) will get fooled.
It looks like accounts can be entirely anonymous. How are you planning on handling moderation of comments? What happens if I post on a neighbor's house "jagoff who lets their dogs poop everywhere lives here, please evict"?
I wish Bluey hadn't introduced the concept of a "bush wee" to my kid, I've had to explain that no, we can't pee in someone's yard in the middle of our busy neighborhood...
This is a culture difference. The U.S. seems peculiarly against this compared to most of the rest of the world. It seems especially acceptable for kids most places. We may have to accept that we're the weird ones on this. It's just pee.
Crates.io has publisher information-- namespacing is not required for that. For example, here are all the crates owned by the `azure` GitHub organization and published by the `azure-sdk-publish-rust` team: https://crates.io/teams/github:azure:azure-sdk-publish-rust
The point is that it's much easier to make a mistake typing "requests" than "
org.kennethreitz:requests" (as a pure hypothetical.)
It also means that more than one project can have a module called "utils" or "common", which once again reduces the risk of people accidentally downloading the wrong thing.
> One now doesn't even know and cannot even estimate the number of other issues that must have gone unreported. It's not safe or wise to use a package that is so shrouded in mystery. It is in fact foolhardy.
Issues don't get reported for any number of reasons. All open source is use at your own risk.