"UI is honestly what a lot of open source projects need work on."
I agree, but I would assume many maintainers themself would not agree. So the sensitive approach atoav took, (asking first) is probably the right thing to do.
I think UI can be hard because it is hard to be objective about it. It is critical work, but at the same time if someone came out of nowhere, totally re-arranged all the UI elements, and was just, "trust me bro, this is better", i would be extremely doubtful.
I was working as a freelance designer both for print and web before and went through what was essentially a graphics design bootcamp by an old grumpy typographer. Then I worked as a camera operator/DoP for films, so my intuition for composition, how to communicate things visually etc. is pretty good.
Contrary to what many people think about design, good design is mostly about structuring the importance and grouping of information, clear typography, good color choices, etc. with the goal of making that information apparent on first glance for most people, while still retaining some sense of character (where/if needed). So this wasn't about them having to trust me, but about me having to explain my rationale behind each design decision in a way that convinces them it is worth the work. Design in open source projects often has the problem that it is made by "someone who knows how to use inkscape" and not by people who necessarily have the eyes/experience to reason these changes on a grand overarching level, hence the often very mixed up non-uniform UI look of open source projects.
As a former freelancer I learned to detach myself somewhat from my work – not in the sense that I make things I dislike, but in the sense that I find the rational reasons behind a design more important than the fact that it was me who did it, so if someone has a better idea I'd happily go for it and if priorities are not shared, that helps adjust that reasoning etc.
Many graphical contributers in open source projects don't have that humility. They want their taste to be represented, not necessarily to put their skill into the service of the project. And that runs into the danger of becoming bike-shedding, where totally subjective aspects of a design (e.g. matters of taste when it comes to color choices) take a lot of energy – because these changes are so devoid of real meanign it is safe for everybody to have an opinion here – this is where you should just add theming and let them do it themselves..
So I tried to do the opposite of bike-shedding, because every "help" I offer produces a cost on the other side.
At work for company product problem is that everyone has an opinion on UI/UX.
It is just super hard to get people agree on one way or the other.
No one has opinions on my database design or architecture.
I can see how OSS project leaders that are developers not really wanting to deal wit UI/UX drama where everyone can make up something and you have to fight for every small detail.
Does everyone have reasonable opinion? Like do they present an objective reasons for their opinion? If all they can say "I don't like it", this opinion means nothing. Rarely people can meaningfully argue about UI changes.
Even if their “I don’t like it” doesn’t add value it still that they are business people or other devs or QA that we work together on daily basis.
I still have to manage emotions and validate their feelings and I can’t just say “fuck off, we do it my way”. Which of course is taxing emotionally especially when I have to deal with my own emotions not to feel attacked when presenting something and gettin people “on the spot, ideas”.
> No one has opinions on my database design or architecture.
As a DBRE, I have many opinions about schema design. Unfortunately, they are often not well-received, because Some Grifting Blog told them their way was fine, and who am I to argue?