4 ms·

Firstly, a developer emotionally attached to a bad UI is not likely to propose significant enough of a change in your interface for this to concern you. Second

Firstly, a developer emotionally attached to a bad UI is not likely to propose significant enough of a change in your interface for this to concern you. Secondly, how would you, as a maintainer, vet a code change outside your best-known languages or paradigms? For that matter, how do you choose a mechanic if you're not a mechanic? How do you choose a caterer if you're not a chef? Solicit outside evaluation assistance by asking for experienced design input on your repo page, newsletter, or other community gathering place. Look at previous work. Ask for portfolio links if you wish. Ask well-thought-out questions about: paths to accomplish tasks in the new vs the current setup; why specific changes are beneficial, to whom, and if it's deleterious to others; larger user goals or user groups seemingly left behind; important assumptions you think they made, fundamental implementation concerns without getting bogged down in inertia, etc. Experienced designers are used to having their work challenged and critiqued— that's true even for fresh college grads if they came from a design school. Bikeshedding, overt dismissiveness, unnecessary defensiveness, tangentially-related gotcha questions to make the asker feel less insecure about not being the expert, and other defensive/ avoidant behaviors look the same without code involved. If you see your community engaging in them, politely ask them to change their tune or butt out. You'd do the same if a designer on your team started an ill-informed group dart-throwing session at someone sharing a technical proof-of-concept. If the person challenging the designer can't justify their assertion as well or better, you should consider if they're someone you should trust with that decision. Thirdly, if you have to ask then it's probably never been a concern. Design is a communication field. Their proposal should be in plain language, logical, entirely justifiable, and almost certainly conceptual rather than in code. If they submit a cold PR out of nowhere with a significant interface modification and little to no justification, I wouldn't consider them a domain specialist regardless of what their portfolio looked like. If you've got some detailed interface modification proposals you're just not sure about, a good

jancsika 5y ago
> Firstly, a developer emotionally attached to a bad UI is not likely to propose significant enough of a change in your interface for this to concern you. a) They have, b) it's definitely not rare, and c) it is an enormous time-drain and source of frustration for maintainers in the FOSS community. Such devs will simply feign expertise at every turn and choose to die on the hill of their submission. In fact my previous run-in with such a dev nearly burned me out on FOSS development altogether. > Their proposal should be in plain language, logical, entirely justifiable, and almost certainly conceptual rather than in code. It's difficult to exaggerate how much I'd welcome such a submission! In fact I have never read such a proposal in any issue tracker, including my own. Do you have a link to an extant example, preferably one that got implemented? I honestly don't care if it's FOSS or not, I just want to read the communication back and forth.
- chefandy 5y ago
  You've never seen a thorough design proposal? Typical commercial pre-wireframe research and proposal: https://web.stanford.edu/~eadolfo/cis-redesign/attachments/proposal-newsignature.pdf https://web.stanford.edu/~eadolfo/cis-redesign/attachments/p... More common in FOSS: https://github.com/openstreetmap/iD/issues/759 https://github.com/openstreetmap/iD/issues/759 https://github.com/stashapp/stash/issues/1549 https://github.com/stashapp/stash/issues/1549 https://github.com/newrelic/nr1-groundskeeper/issues/3 https://github.com/newrelic/nr1-groundskeeper/issues/3 https://github.com/creativecommons/creativecommons.github.io-source/issues/189 https://github.com/creativecommons/creativecommons.github.io... https://github.com/godotengine/godot-proposals/issues/1823 https://github.com/godotengine/godot-proposals/issues/1823 (from google searching for things like site:github.com "wireframes" "design" "proposal") > a) They have, b) it's definitely not rare, and c) it is an enormous time-drain and source of frustration for maintainers in the FOSS community. I can't claim to be omniscient but I've been a constant open source contributor for 10 odd years and heavy user for nearly 25 and I've never seen that, or even heard people complain about it, let alone enough to be an enormous problem. I've seen ill-conceived gripe lists, superficial 'lets make this look cool,' and 'this font sucks' type issues periodically. None of those are serious design proposals any more than "make everything faster" or "I hate when your program does x" or "I think we should get rid of this and make it in react" are serious development proposals. I'll happily put together a guide on cutting through bullshit UI change proposals if I could evaluate some issues/PRs for open source repos that constantly experience this problem.

jancsika 5y ago

> Firstly, a developer emotionally attached to a bad UI is not likely to propose significant enough of a change in your interface for this to concern you. a) They have, b) it's definitely not rare, and c) it is an enormous time-drain and source of frustration for maintainers in the FOSS community. Such devs will simply feign expertise at every turn and choose to die on the hill of their submission. In fact my previous run-in with such a dev nearly burned me out on FOSS development altogether. > Their proposal should be in plain language, logical, entirely justifiable, and almost certainly conceptual rather than in code. It's difficult to exaggerate how much I'd welcome such a submission! In fact I have never read such a proposal in any issue tracker, including my own. Do you have a link to an extant example, preferably one that got implemented? I honestly don't care if it's FOSS or not, I just want to read the communication back and forth.

chefandy 5y ago
You've never seen a thorough design proposal? Typical commercial pre-wireframe research and proposal: https://web.stanford.edu/~eadolfo/cis-redesign/attachments/proposal-newsignature.pdf https://web.stanford.edu/~eadolfo/cis-redesign/attachments/p... More common in FOSS: https://github.com/openstreetmap/iD/issues/759 https://github.com/openstreetmap/iD/issues/759 https://github.com/stashapp/stash/issues/1549 https://github.com/stashapp/stash/issues/1549 https://github.com/newrelic/nr1-groundskeeper/issues/3 https://github.com/newrelic/nr1-groundskeeper/issues/3 https://github.com/creativecommons/creativecommons.github.io-source/issues/189 https://github.com/creativecommons/creativecommons.github.io... https://github.com/godotengine/godot-proposals/issues/1823 https://github.com/godotengine/godot-proposals/issues/1823 (from google searching for things like site:github.com "wireframes" "design" "proposal") > a) They have, b) it's definitely not rare, and c) it is an enormous time-drain and source of frustration for maintainers in the FOSS community. I can't claim to be omniscient but I've been a constant open source contributor for 10 odd years and heavy user for nearly 25 and I've never seen that, or even heard people complain about it, let alone enough to be an enormous problem. I've seen ill-conceived gripe lists, superficial 'lets make this look cool,' and 'this font sucks' type issues periodically. None of those are serious design proposals any more than "make everything faster" or "I hate when your program does x" or "I think we should get rid of this and make it in react" are serious development proposals. I'll happily put together a guide on cutting through bullshit UI change proposals if I could evaluate some issues/PRs for open source repos that constantly experience this problem.