| 1 |
Alan Mackenzie <acm@×××.de> writes: |
| 2 |
|
| 3 |
> Hello, Lee. |
| 4 |
> |
| 5 |
> On Tue, Sep 29, 2015 at 08:45:10PM +0200, lee wrote: |
| 6 |
>> Neil Bothwick <neil@××××××××××.uk> writes: |
| 7 |
> |
| 8 |
>> > Patches are always more welcome than suggestions. "Fix it!" is never as |
| 9 |
>> > welcome as "here's how". I think it was Canek who said "code talks". |
| 10 |
> |
| 11 |
>> Do you have an example for such a case? |
| 12 |
> |
| 13 |
> Yes, many. I'm a contributor to Emacs, and relatively frequently (perhaps |
| 14 |
> 10 - 30 times a yeaar) somebody reports a bug and simultaneously submits |
| 15 |
> a patch for it. This is always well received, |
| 16 |
|
| 17 |
I sent in a contribution to emacs, too, and never even heard anything |
| 18 |
back. |
| 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 |
That apparently means that nobody is allowed to suggest something and/or |
| 26 |
to discuss a suggestion, and that everyone must have an "I don't care" |
| 27 |
attitude. |
| 28 |
|
| 29 |
>> My experience has disproved this claim, and I've even seen people |
| 30 |
>> fixing stuff multiple times after I told them it's broken and provided |
| 31 |
>> a perfectly working version before telling them, much better coded, |
| 32 |
>> which they could have used instead of insisting on their crappy code |
| 33 |
>> and trying to fix it several times. |
| 34 |
> |
| 35 |
> That's not very friendly, |
| 36 |
|
| 37 |
How is it not friendly to point out a bug when you find one, at the same |
| 38 |
time pointing to what fixes it? |
| 39 |
|
| 40 |
> and hardly inclined to gain extra contributors |
| 41 |
> for your project. A gentle guiding hand, helping these other people to |
| 42 |
> reach a satisfactory fix themselves, would work much better. |
| 43 |
|
| 44 |
It wasn't my project but software I'm using and had made a fork of. So |
| 45 |
I noticed what upstream changed, found it to be broken, fixed it and |
| 46 |
notified them that it's broken and how, and that there's a fix they can |
| 47 |
use. They didn't use the fix, made a couple attempts to fix their own |
| 48 |
code until it finally worked, and though it now works, their code still |
| 49 |
sucks. |
| 50 |
|
| 51 |
So the most logical conclusion is not to report bugs and not to provide |
| 52 |
any fixes or contributions, and not dare to suggest anything because at |
| 53 |
best, it leads to nothing, and most of the time, you're being told that |
| 54 |
you're a clueless idiot and to shut up. OTOH, you often times get to |
| 55 |
hear and/or see that peoples' contributions and help are wanted and that |
| 56 |
there are always not enough contributers. But why ask for more |
| 57 |
contributers when contributions aren't wanted anyway? |
| 58 |
|
| 59 |
>> > On the contrary, it serves to illustrate that you do not grasp the |
| 60 |
>> > complexity of the situation. |
| 61 |
> |
| 62 |
>> Perhaps you can enlighten me how it is so difficult to change a message |
| 63 |
>> from "slot conflict" to "slot conflict (can probably be ignored while |
| 64 |
>> there are other problems)" and what the complexity is which makes it |
| 65 |
>> impossible to do so. |
| 66 |
> |
| 67 |
> It's not difficult, it's just tedious. Something like that which is |
| 68 |
> user facing needs to be agreed by the core of the project, and getting |
| 69 |
> that agreement tends to involve lots of bike shedding on the project |
| 70 |
> mailing lists - there's always a few people who'll prefer the message to |
| 71 |
> stay the same. |
| 72 |
|
| 73 |
That is a bad situation which might help to explain why projects neither |
| 74 |
want contributions, nor contributers. Yet it doesn't mean that those |
| 75 |
who would like to contribute shall receive the blame for the bad |
| 76 |
situation the project is in, nor that it is wise to put them off. |
| 77 |
|
| 78 |
It also indicates that the argument "go ahead and supply a patch" is |
| 79 |
entirely inappropriate beyond being merely condescending, and that |
| 80 |
arguing along the lines that the contributers aren't being payed and |
| 81 |
that /you/ aren't contributing anyway is even worse. None of them are |
| 82 |
acceptable under these conditions. They are irrelevant. |
| 83 |
|
| 84 |
> Then there's all the stuff about writing change logs for the change |
| 85 |
> and commiting it. |
| 86 |
|
| 87 |
How is that being too tedious? If it really is too tedious, is there a |
| 88 |
way to make it less tedious? |
| 89 |
|
| 90 |
> Such a tiny change is scarcely achievable in less than an hour. To |
| 91 |
> the core developers, it barely seems worth it. |
| 92 |
|
| 93 |
So nobody do anything because it isn't worth it. That's a great |
| 94 |
attitude. |
| 95 |
|
| 96 |
|
| 97 |
-- |
| 98 |
Again we must be afraid of speaking of daemons for fear that daemons |
| 99 |
might swallow us. Finally, this fear has become reasonable. |
Archives