"So I did the next best thing and made an effort to collect a list of UI/UX papercuts and logical inconsistencies, each with a list of proposed options to fix it, sometimes including mock ups how I imagined it could look like."

I love that so much!

It's very hard to judge the usability of your own software because you know it better than anyone else in the world.

Pointing out sharp edges like this is just incredibly useful. Attaching research into options that can help is huge too - much more valuable than proposing a single fix without acknowledging that there might be multiple ways this could go.

UI is honestly what a lot of open source projects need work on. The fact you took the time, made mocks and contributed to the documentation is amazing!

People forget that there are more items to maintaining a product than writing code.

I agree. I have lots of projects that work very well but definitely need some UX work. Often times even features that are implemented but not exposed because I don't know how to make the UX work. Designs or a frontend developer would be amazing.

But it always feels easier to a slide into a project with a bug fix or a small feature as opposed to redoing some UI that the owner did. It isn't always obvious if the owner things their design is great and is protective about it or if they would love someone to come in with some ideas. (And even then it may be a lost cause of you both have different tastes.)

"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.

> No one has opinions on my database design or architecture.

Oh dear, if you only knew ...

I have personally seen both those things gridlock entire teams, to the point where people would rather quit than continue working.

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.

The relationship between the perceived importance of the thing and the amount of people who have strong opinions it is inversely proportional.

The less meaningful a change is the more people dare to voice strong preferences.

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?

The contributions appear to be to Horizon EDA: https://github.com/horizon-eda/horizon.

True : ) Still working with that software, although lately i didn't contribute much, partly because of day-job reasons (not enough time), partly because the software is already pretty darn good.