Maintainer stance is understandable. They are the ones taking on the risks and who will be left dealing with consequences.
Flyby contributors don’t know how much effort there is to keep things going even at good enough level. It’s up to the newcomer to convince that the new opinion matters and new risk is worth taking.
Maintainers can’t distinguish between troll and flyby-contributor-never-to-be-seen-again and genius-that-will-sacrifice-everything-for-the project.
I get that you can’t convince of anything if they don’t discuss, but that means one must earn the right to discuss, by becoming part of current organisation.
Illustrative analogy from open source project (not mine).
Project had top level directories like “ext” and “external” and “vendor” (which is confusing at the first glance). Potential contributor made PR to rectify it (memory slips on how; but seemed reasonable at first glance). Owner/Maintainer rejected this help. The would be contributor got frustrated, later complained here that the project did not care about code quality and best practices and is hostile to new contributors. I see Chesterton’s fence here and a bit of entitlement on the would-be-contributor’s side.
Editing Wikipedia is not the same as developing software, and they're different enough for the distinction to matter. Wikipedia is not Nupedia, and the comparison in this comment between Wikipedia and open source software maintenance is simply flawed from the start.
The statement that "one must earn the right to discuss" alone has the minor problem that it is totally antithetical to the actual policies and guidelines that Wikipedia aims to adhere to.
> Wiki, open source projects, stackoverflow and democratic country, all are different, but they definitely have similarities.
A unicycle and a hula hoop have similarities.
As I said, the distinction matters. The argument by metaphor in your previous comment is off-base.
Feel free to address concretely what I wrote in my previous comment.
(Though I have doubts about the quality of any insights that might be offered; no one referring to Wikipedia as "Wiki" is informed enough about Wikipedia to be informative about it.)
I think you want me to address the policy, that you linked to.
Well, the wiki’s policy is irrelevant. Or only 50% relevant.
I see that the policy tries to provide some “spirit of the law” and/or hints to avoid edit wars and such, but evidently many follow the policy only in letter and just know what not to mention, i.e. to not trigger the policy. (instead of rejecting edits with “I own this” or “I know this better”, edits get rejected with “citation needed”)
> As I said, the distinction matters.
I see you sincerely believe that it does, but I’m of different opinion.
People in any group form a hierarchy, and have (frequently unwritten) “traditions”. And those are features, not bugs.
Hierarchy is not necessarily strict or formal, but it helps with coordination.
“Tradition” is the actual way how things are done. “Tradition” can be changed by policies, it may even implement the policy to the letter, but it always encompasses more than the policy contains. Because it’s almost impossible and most undesirable to have policies for each breath we take.
> Feel free to address concretely what I wrote in my previous comment.
Somebody has older account then me here and is feeling authoritative I see. Thanks for good practical illustration.
If you dismiss peoples opinion ("quality of any insights") on the basis of their choice of words or abbreviations instead of the content, it becomes really hard to assume you're arguing in good faith.
Flyby contributors don’t know how much effort there is to keep things going even at good enough level. It’s up to the newcomer to convince that the new opinion matters and new risk is worth taking.
Maintainers can’t distinguish between troll and flyby-contributor-never-to-be-seen-again and genius-that-will-sacrifice-everything-for-the project.
I get that you can’t convince of anything if they don’t discuss, but that means one must earn the right to discuss, by becoming part of current organisation.
Illustrative analogy from open source project (not mine).
Project had top level directories like “ext” and “external” and “vendor” (which is confusing at the first glance). Potential contributor made PR to rectify it (memory slips on how; but seemed reasonable at first glance). Owner/Maintainer rejected this help. The would be contributor got frustrated, later complained here that the project did not care about code quality and best practices and is hostile to new contributors. I see Chesterton’s fence here and a bit of entitlement on the would-be-contributor’s side.