3 ms·

> Accordingly, our discussion style may be considered somewhat unusual by some people. We do not argue till exhaustion defending our points of view. We present

> Accordingly, our discussion style may be considered somewhat unusual by some people. We do not argue till exhaustion defending our points of view. We present ours and read others'. This is an important lesson that I hope more communities and maintainers adopt. I didn’t learn it myself until I had been working in open source professionally for a decade and was beginning to burn out.

robbedpeter 5y ago
I like the effects of this type of discussion, and it's excellent when embraced by the community and enforced by moderators. Lua's community is notable for neighborliness and an almost Mr Rogers level of patience with newcomers, and the fact that the culture has persisted for 2 decades should be celebrated.
howenterprisey 5y ago
Highly related: "[N]ot every argument or idea you disagree with has to be shouted down loudly. If a proposal (or a counter-argument to it) demonstrates value to enough people then it will gain support and can be refined into something that can reach consensus. If not, then it won't. Critiques of early-stage proposals in particular should be done with a goal of improving them, better understanding their motivation, or comparing them to alternatives. Comments that are closer to just 'voting no' on a proposal aren't really necessary. In disagreements, responding with new information is great, but try not to get in a mode where you are trying to convince specific people (or all people) that you are right and they are wrong. Focus on presenting your own ideas/needs/etc. as clearly as possible. Then people reading the thread (not just the person you are responding to) can judge competing arguments on their merits. For anyone who wants to [design new features], remember that the bulk of the work is not in coming up with ideas, but in building consensus for them. To succeed, you'll need to spend a lot of time on understanding other people's viewpoints and tweaking your designs and communication based on what you learn. (This includes any concerns from the people who would need to implement and maintain your feature.) This 'listening' is the part of the process you'll need to focus most of your time and energy on. If you don't invest in it, then the rest of your effort is likely to be wasted." From the brilliant mbrubeck at https://internals.rust-lang.org/t/aliasing-other-things/12288/35 https://internals.rust-lang.org/t/aliasing-other-things/1228...
socialdemocrat 5y ago
I think a similar philosophy has worked well team work. I pushed to principle in our team that you should always listen to alternative views. However if there is clear disagreement which cannot easily be resolved then whomever writes the code, has the last word. That is of course just a guiding philosophy and not a hard rule. But it helps avoid endless debates about minor points. It also encourages developers to share ideas they are working on without being afraid that they must spend lots of time defending their choice against relentless attacks. One has to ultimately respect that others might make slightly different technical choices than yourself.

robbedpeter 5y ago

I like the effects of this type of discussion, and it's excellent when embraced by the community and enforced by moderators. Lua's community is notable for neighborliness and an almost Mr Rogers level of patience with newcomers, and the fact that the culture has persisted for 2 decades should be celebrated.

howenterprisey 5y ago

Highly related: "[N]ot every argument or idea you disagree with has to be shouted down loudly. If a proposal (or a counter-argument to it) demonstrates value to enough people then it will gain support and can be refined into something that can reach consensus. If not, then it won't. Critiques of early-stage proposals in particular should be done with a goal of improving them, better understanding their motivation, or comparing them to alternatives. Comments that are closer to just 'voting no' on a proposal aren't really necessary. In disagreements, responding with new information is great, but try not to get in a mode where you are trying to convince specific people (or all people) that you are right and they are wrong. Focus on presenting your own ideas/needs/etc. as clearly as possible. Then people reading the thread (not just the person you are responding to) can judge competing arguments on their merits. For anyone who wants to [design new features], remember that the bulk of the work is not in coming up with ideas, but in building consensus for them. To succeed, you'll need to spend a lot of time on understanding other people's viewpoints and tweaking your designs and communication based on what you learn. (This includes any concerns from the people who would need to implement and maintain your feature.) This 'listening' is the part of the process you'll need to focus most of your time and energy on. If you don't invest in it, then the rest of your effort is likely to be wasted." From the brilliant mbrubeck at https://internals.rust-lang.org/t/aliasing-other-things/12288/35 https://internals.rust-lang.org/t/aliasing-other-things/1228...

socialdemocrat 5y ago

I think a similar philosophy has worked well team work. I pushed to principle in our team that you should always listen to alternative views. However if there is clear disagreement which cannot easily be resolved then whomever writes the code, has the last word. That is of course just a guiding philosophy and not a hard rule. But it helps avoid endless debates about minor points. It also encourages developers to share ideas they are working on without being afraid that they must spend lots of time defending their choice against relentless attacks. One has to ultimately respect that others might make slightly different technical choices than yourself.