3 ms·

This is an extraordinary and unsubstantiated claim, and in no way resembles anything I said, nor anything I want. Development to improve software should be a c

This is an extraordinary and unsubstantiated claim, and in no way resembles anything I said, nor anything I want. Development to improve software should be a conversation between skilled and knowledgeable workers across many domains. Without that, you don't get improvement, you get feature creep. "Patches welcome" is a conversation killer.

account42 2mo ago
There is nothing wrong with a "conversation killer" in this instance. The original authors do not consider your desired changes important enough to spend their limited time on them. They owe you neither to implement it themselves nor a "conversation" to guide you through implementing and merging the changes. If you disagree you can either spend the time to get the necessary technical knowledge yourself or find (and possibly pay) a third party willing to do it for you. Giving clear answers about what the existing project members are willing or not willing to spend their time on is the opposite of feature creep. The idea that open source projects should somehow be obliged to humor anyone with "insight" is absurd, especially when it comes to topics like UX that are 99% subjective. That expectation is something you can have in a corporate structure where you (or someone you represent) employ those developers but not outside of that.
- MrVandemar 2mo ago
  There's a lot of projection there. Among other misapprehensions, I never proposed the idea that open source projects should be "obliged" to "humour anyone with 'insight'". That said, if you have any kind of project (open source or not), and someone with significant experience in a domain outside your own makes a suggestion of something that could be improved, then the progressive and constructive response is "tell me why I should think that. What value is there in making this change? How will it be better" which opens up a dialogue, instead of "Hey man, RTFM and start coding" which is alienating (but your position is that there's actually nothing wrong with this. It is wrong if your goal is to create quality software). I do design work sometimes, and when someone tells me "it doesn't look right", whether it's technically perfect or not, it means it's wrong. They might not be able to explain, but I know it's wrong somehow, and it's my responsibility to fix it. I don't sit them down in front of the keyboard and say "Ok, wiseguy, you fix it. You might need to take some classes at art school though". And sometimes that person is a designer and they say "Well, this composition is unbalanced, but you could try shifting that element a little to the right" and I'd be dumber than Trump if I didn't try that. The subjectivity thing is interesting though. UX is not 99% subjective, and I don't know how you arrived at that figure. Start with Fitts Law, which is a thing, and not subjective and is measurable. Lots of people have spent a lot of time quantifying this stuff. There's science to it, and, yes, there's an irrational "feelings" component to it, but you ignore either or both at your peril.

account42 2mo ago

There is nothing wrong with a "conversation killer" in this instance. The original authors do not consider your desired changes important enough to spend their limited time on them. They owe you neither to implement it themselves nor a "conversation" to guide you through implementing and merging the changes. If you disagree you can either spend the time to get the necessary technical knowledge yourself or find (and possibly pay) a third party willing to do it for you. Giving clear answers about what the existing project members are willing or not willing to spend their time on is the opposite of feature creep. The idea that open source projects should somehow be obliged to humor anyone with "insight" is absurd, especially when it comes to topics like UX that are 99% subjective. That expectation is something you can have in a corporate structure where you (or someone you represent) employ those developers but not outside of that.

MrVandemar 2mo ago
There's a lot of projection there. Among other misapprehensions, I never proposed the idea that open source projects should be "obliged" to "humour anyone with 'insight'". That said, if you have any kind of project (open source or not), and someone with significant experience in a domain outside your own makes a suggestion of something that could be improved, then the progressive and constructive response is "tell me why I should think that. What value is there in making this change? How will it be better" which opens up a dialogue, instead of "Hey man, RTFM and start coding" which is alienating (but your position is that there's actually nothing wrong with this. It is wrong if your goal is to create quality software). I do design work sometimes, and when someone tells me "it doesn't look right", whether it's technically perfect or not, it means it's wrong. They might not be able to explain, but I know it's wrong somehow, and it's my responsibility to fix it. I don't sit them down in front of the keyboard and say "Ok, wiseguy, you fix it. You might need to take some classes at art school though". And sometimes that person is a designer and they say "Well, this composition is unbalanced, but you could try shifting that element a little to the right" and I'd be dumber than Trump if I didn't try that. The subjectivity thing is interesting though. UX is not 99% subjective, and I don't know how you arrived at that figure. Start with Fitts Law, which is a thing, and not subjective and is measurable. Lots of people have spent a lot of time quantifying this stuff. There's science to it, and, yes, there's an irrational "feelings" component to it, but you ignore either or both at your peril.