I think I am qualified to answer on this sub-thread. I can talk for a long time on this, but I need not. And as a contributor who started 3 years ago on this very thread, I have first hand knowledge of this process.Walter wrote: ↑Sat Oct 15, 2022 3:46 pmBe sure your arguments are being read - though sometimes not all of them, if the first is so far off (IMO) that I feel challenged to respond to the first already. I can't guarantee I comprehend always what you meant, however (1st theorem of communication: A message is not what the sender sends but what the receiver gets). So if it seems I didn't get what you meant (or didn't read your message properly), please check and rephrase and try once more. And if you refer to older posts, please include links to them (or it may well be I don't remember).redglyph wrote: ↑Sat Oct 15, 2022 12:04 pmMy gripe is not with a solution being accepted or refused. My problem is a solution that is discarded (or accepted, though it's very unlikely) without even reading any of the arguments.ben.titmus wrote: ↑Wed Oct 12, 2022 1:08 amSo I'd say: continue suggesting new ideas, but not all of them will be taken.
It will suffice to say that if you try hard enough with facts and not emotions (in fact ignore those for a while), that you can get through to change the spec. It is not easy. But the result is satisfying. The process makes you continue to do it only if you really feel it is needed. Sometimes that is not pleasant. And be warned that if you do succeed to have the spec changed, the spec is just that - it is not automatically implemented to be blunt, and it will help if you add your own resources to the open source project to implement the bit you got agreement to change.
I found that if you have a vision, sometimes you need to be pro-active and make a demo in code or in a graphic or in a series of graphics, because as usual, a picture is worth a lot more. My opinion is that (a software) spec can still change even after a final product is out the door, whenever that may be. If you saw something the team did not see or understand at the time, I will bet my bottom dollar if you get them to understand the problem they will change if it is valid and worth it. But do understand for every apparent small change you want, there may be countless repercussions in the program that you will only know once you study the code. Also understand some you won't win even if you think you understand everything, it may simply not fit into the now or future project plan.
In that case, if you are not happy, roll you own. I was sure that I used this expression before and a quick search gives this: My 2019 post, where the two main co-contributors to the other project both are batting ideas back and forth. See "roll your own" used here: viewtopic.php?f=2&t=2216&p=11348&hilit= ... own#p11348
Either way, do not dismiss the quoted post from Walter above. It contains many truths.