Hello, Lee. On Tue, Sep 29, 2015 at 08:45:10PM +0200, lee wrote: > Neil Bothwick <n...@digimed.co.uk> writes:
> > Patches are always more welcome than suggestions. "Fix it!" is never as > > welcome as "here's how". I think it was Canek who said "code talks". > Do you have an example for such a case? Yes, many. I'm a contributor to Emacs, and relatively frequently (perhaps 10 - 30 times a yeaar) somebody reports a bug and simultaneously submits a patch for it. This is always well received, and the patch is usually applied, sometimes with a bit of to and fro and negotiation, sometimes after waiting for the tedious paperwork to be completed. One of my own first contributions was a request for an enhancement (to enable scrolling during an incremental search) together with a rough, but working patch. After some amendments, this was applied. On the other hand, "wouldn't X be a good idea"s which reach the mailing list only rarely get taken up by regular contributors - there's only so much time in the day, and such hackers usually have plenty of Xs of their own to fill their time with. > My experience has disproved this claim, and I've even seen people > fixing stuff multiple times after I told them it's broken and provided > a perfectly working version before telling them, much better coded, > which they could have used instead of insisting on their crappy code > and trying to fix it several times. That's not very friendly, and hardly inclined to gain extra contributors for your project. A gentle guiding hand, helping these other people to reach a satisfactory fix themselves, would work much better. [ .... ] > > On the contrary, it serves to illustrate that you do not grasp the > > complexity of the situation. > Perhaps you can enlighten me how it is so difficult to change a message > from "slot conflict" to "slot conflict (can probably be ignored while > there are other problems)" and what the complexity is which makes it > impossible to do so. It's not difficult, it's just tedious. Something like that which is user facing needs to be agreed by the core of the project, and getting that agreement tends to involve lots of bike shedding on the project mailing lists - there's always a few people who'll prefer the message to stay the same. Then there's all the stuff about writing change logs for the change and commiting it. Such a tiny change is scarcely achievable in less than an hour. To the core developers, it barely seems worth it. -- Alan Mackenzie (Nuremberg, Germany).
