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.
People forget that there are more items to maintaining a product than writing code.
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.)
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.
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.
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”.
The less meaningful a change is the more people dare to voice strong preferences.
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.
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?
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.