They are crucial for open source - documentation, assets, etc.
But they can also mess up a project with giving power to non-developers who focus on changes like redoing the UX every release, to the detriment of stability, functionality, adoption, and so on. They also attract busybodies concerned with "politics", more so than coding does. It's also a great domain for bikeshedding (as anybody feels like they can do it).
The people who do the things that the article talks about do not tend to be busybodies because these are tasks that don't get a lot of attention or recognition, which is why this article was written.
But, what can we do? I like to believe that those anti-social elements are (very vocal) but a small portion of the universe of non code contributors. Project leaders just need to be a little less naive and keep an eye on this possibility to tackle the problem as soon as it appears.
But on the other side, the non-tech infiltration route is also real.
The reality as far as I've seen is that the people injecting politics into the discussion are developers, not "normies". The perception exists because some of us have a stereotype of a developer as someone who's only interested in the technical details of a project, so the people who bring unrelated concerns to the table must be non-technical.
How does that apply here? That applies when people act on their perceptions; here we are talking about what the reality is.
To find petty bickering, look no further than most technical contributors. Accusing non-technical people of this sort of thing isn't borne out.
[1]: https://invisible-island.net/ncurses/ncurses-license.html
Of course all the bickering was between technical people — those were the only people around!
I'm still waiting for anyone to give an example of an open source project meltdown that was triggered by non-technical contributors.
Do you think people are looking to attack and want a vector? A much simpler, less paranoid explanation is that they get involved and then perceive problems. Some of those problems might even be real!
Have you found that a new developer is meaningfully less likely to recommend redoing the UX compared to a new non-developer? Personally my sense is that desire to update the UX is more closely correlated with the "newness" than development ability.
Kind of. New developers tend to do some bug fixing here and there, or implementing some small feature, not dictate major changes. And if they do, they're ignored or debated, and that's it.
I don't believe that to be the case, but am open to examples that provide evidence in favor of the claim.
This reminds me of the codes of conduct hell from a few years ago.
[1] https://github.com/opal/opal/issues/941
[2] https://github.com/nixxquality/WebMConverter/commit/c1ac0baa...
I see cultural change as analogous to steering a large ship. You won't be doing any sharp turns but you can gradually move it in a different direction.
https://news.ycombinator.com/item?id=21386948
The GitHub issue I linked is gone but those archive links are still up.
Never forget the fact they laughed in people's faces when they tried to hold them accountable to their own rules.
This brutal article also came to mind:
https://zedshaw.com/blog/2020-10-07-authoritarianism-of-code...
As for politics and bikeshedding, I have seen plenty of that amongst developers so I'm not convinced non-developers would be more likely to engage in it.
Or they could just give mockups, like in Gnome, Mozilla, and elsewhere, and have enough traction within the project to push for them.
The fact that Gnome was able to choose a direction they wanted to go and then go in that direction even over the extremely vocal protests of a large portion of the community is if anything proof that you absolutely can reject mockups from community members if you don't want to implement them. Ultimately, the project decides what interface it wants to have. And community members can protest that direction, they can complain that project's priorities are wrong, they can fork things (and Gnome has forks), they can do whatever -- but they lack the ability to force the project to abandon a design that its owners like. That's a good thing about Open Source.
The idea that UI designers are somehow hijacking Gnome because they advocated for designs that the org voluntarily implemented... it makes no sense to me at all. Does the org own the project or not, it's their choice. Unless the idea here is that Gnome should have been obligated to accept design critiques from people outside of the project and change their internal designs just because the people proposing changes from outside the project knew a programming language; but that would be a silly thing to say.
Well, here's the problem: these people proposing the changes are not outside the project. They are within the project. And their vote is as good as a dev's (and it's easier to gather dozens of them, as it doesn't require skills for doing the much harder and more prolonged dev work).
And in orgs with a non-dev bureucracy and management (like Mozilla and Gnome) they can get buy-in from those "higher ups" too. And they can also create enough friction and bikeshedding on regular FOSS projects too, as long as those don't have a BDFL and everybody has a voice.
So what, your issue is that project owners get to decide who they work with? If the people working on UI in Gnome are part of the Gnome project that is not in any way randos coming in and bikeshedding over the UI -- it's a project self-determining what it wants to do. I'm sorry they're organized in a way that you (an outsider to the project) find offensive.
Yeah, of course the vote of project members is as good if not better than the votes of people outside of the project because these projects get to set up their own orgs and governance structures and they don't have to justify or prove to anyone outside the project why the people they work with deserve to be there. And that is one of the things that is amazing about Open Source. You can just go do stuff and when somebody else shows up on your Github repo and says, "the UI designers are ruining your software" you can tell them to take a hike because they don't get to decide how your project is run. They're not required to consult with you.
----
I don't see what any of this has to do with no-code contributions. Encouraging non-coders to write documentation and tutorials and help with feature suggestions is bad because you have a problem with project management?
By the "higher ups" I guess you mean the literal orgs behind the projects? You don't need quotation marks for that, those are just called higher-ups, that's how organizations work. It's still the case that the people who build and control Open Source projects can take them in any direction they want regardless of what people outside of the projects want them to do.
Of course, Open Source has lots of mechanisms to avoid problems with bad project direction -- notably, forking, which should be hecking easy since all of the people complaining are apparently such excellent programmers.
In an ideal world, developers write documentation as they're developing. This seems to work really well for OpenBSD and its various project, all of which have some of the best man pages out there.
a lot of documentation is put together as part of some KT handoff, and is written by technical folks in that domain, for folks in that domain.
Also since you seem to be familiar with both project, is Ansel compatible with Darktable sidecar files? If an existing Darktable user were to move to Ansel what can they expect to carry over and what might be lost?
I am only familiar with his YouTube, and then this topic. https://github.com/aurelienpierreeng/ansel Here are his examples.
It seems 1:1 compatible when I switched.
It just so happens that everyone can have an opinion on it. So you have a problem with a thousand possible voices, and that many of them might be drive-through busibodies. But that’s still not bikeshedding.
True bikeshedding would be haggling over the styling of the Who Are We page of your promotional website.
[1] Like many, many nouns based on programming blogs from the last twenty years.