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