Thanks for the great discussion!
Renaming the topic as it deviated a bit from Lucas' original announcement, and was questioning whether we should do Wikilambda at all. So, this is mostly to answer Gilles' comment as to why a collection of functions and tests needs to be editable on a wiki - that's the premise of the first part of the project.
So yes, we could maybe create the whole code for the renderers in a classical way, as an Open Source project, going through git and gerrit, and assume that we will have hundreds of new coders working on this, neatly covering all supported languages, to keep up with the creation of renderers when the community creates new constructors, etc. I have doubts. I want to drastically reduce the barrier to participate in this task, and I think that this is, in fact, necessary. And this is why we are going for Wikilambda, a wiki of functions first, as said in my first email to the list.
There is a closely related discussion on Meta about this:
If I try to reconstruct the history of how so many templates, user scripts, gadgets, and modules, ended up being stored as wiki pages in the first place, it's something like this:
Templates started in 2003 or 2004, and were very simple initially. Plain wikitext, very basic parameters support, no parser functions, no documentation pages, and no TemplateData. No one treated templates as code that should be managed with proper design and software engineering practices.
User scripts started in 2006 or so, when there was almost no JavaScript on Wikipedia, and much less JavaScript on the web in general. Storing stuff on wiki pages was easy and natural. Their versioning was pretty much as good as CVS and SVN; Git was very young and ultra-nerdy.
Gadgets started in 2007 as a way to package user scripts *very slightly* better.
Modules started in 2012 as a way to make something similar to templates, but with better performance and more maintainable syntax. So their programming language was different from how templates are written, but their packaging was almost the same.
PLEASE CORRECT ME IF I'M WRONG ABOUT ANYTHING ABOVE.
Basically, the reason they are stored and versioned the way they are is that we are essentially preserving the way things were in 2006. It may sound like I'm saying that it's bad, but it's really not so simple.
The advantages of storing code as wiki pages are, at least for the editors:
1. They are familiar to all wiki editors, at least as a concept. Not everyone knows the *syntax* of JS, Lua, or template parameters and parser functions, but, without exception, everyone who edits wikis is familiar with the general editing and versioning interface.
2. There are three easy steps to deploy code changes: Step one: Edit. Step two: Publish. Step three: There's no step three.[1]
3. They are controlled directly by the editors community and not by people on some other website (Gerrit, Phabricator, GitHub), or organization (WMF, WMDE).
The disadvantages of wiki pages are:
1. Templates, modules, and gadgets are code, even though they very often aren't treated as code. And code, these days, is *expected* to have proper versioning, review, and deployment practices. "Proper versioning" usually means Git. Not in 2006, and not even in 2012, but definitely in 2020.
2. It's easy to break things without proper review.
Disadvantage #1 sounds relevant to pretty much all other people on Earth who write code, but... not so much to editors of Wikimedia wikis. Git is now much more common and much less nerdy than it was in 2006, but that's not necessarily what wiki editors think. So this disadvantage is outweighed by the three advantages.
Disadvantage #2 is easily outweighed by the general wiki principle: what is easy to break is also easy to fix. In fact, with our current deployment tools (Gerrit and zuul and scap and all that), undeploying a Gerrit change takes much more time than reverting a wiki page.
Nevertheless, times did change since 2006, so *considering* a modern versioning system is a valid idea. But it would have to be a versioning system that doesn't give up on the advantages. Otherwise, the community won't use it.
* * * * * * *