Lua's Development Style (2008)
lua-users.org
lua-users.org
Note that I eventually convinced Roberto that it was worth having a public github repository even just to show the history and evolution. https://github.com/lua/lua
It has been immensely valuable when porting code from Lua 5.1 -> 5.3, to see the changes in the repo over time.
I don’t agree with all the design decisions made by the Lua team, but I deeply respect this philosophy.
It’s clear that Lua has certain guiding principles and that its design team sticks to them, leading to a cohesive and predictable language. Compare this to Python, JavaScript etc, whose designers just seem to add as many features as possible, with no regard to how well they mesh with the rest of the language.
https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
GCC and Emacs famously followed similar models (the Cathedral model): developed behind closed doors, to be released as open-source when it's ready. Both eventually went full "Bazaar" model. I guess it depends on the personality and goals of the projects' maintainers. (I'm certainly not faulting Lua's creators for anything!)
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.
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.
"[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/1228...
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.