Hi Martijn. Thanks for starting this thread.
Martijn Hoekstra [roughly] wrote:
- Catalog the problems with [dev issue]. Make a comprehensive list that
enumerates the problems with [dev issue] we have now, categorise the problems (right now I'm roughly thinking in style, wikitext parsing rules and generated HTML, creation and writing issues (let's hope there is little of this one left after Scribunto), and usability by editors).
- Note which quirks that lead to technical difficulties are used in the
wild as features rather than bugs.
- Brainstorm possible (partial) solutions.
- Find candidates that have high bang-for-buck possible solutions
without impeding future improvements much.
- Refine those solutions so we know quite exactly what it will fix, what
it won't fix, and what it would possibly break.
- Define sane fallback procedures for when things break; this should
mainly come from the editing communities, but could probably use some guidance of what is possible/easy/logical/feasible from a technical POV from the development community.
- Fix [dev issue].
I don't disagree with what you're saying, but I don't think it's really specific to templates. We should roughly be following these steps for most development issues, no?
There won't be a "one size fits all" approach to templates.
In the recent discussions/debacles about technical and stylistic advances, a recurring theme is that the use of some templates causes major headaches, and a commonly heard complaint from the developers and designers is that their products exhibit problems and shortcoming because of that. Anecdotal evidence I've lately encountered includes:
- The mobile skin obfuscates talk page access because the templates
commonly found on talk pages makes them render horribly.
Talk page templates are dumb. We should integrate their functionality into a MediaWiki extension. We currently have people going around assessing articles on talk pages and adding talk page banners using iterator tools such as AutoWikiBrowser. These are fine people and they're doing fine work, but the mechanism by which they're doing it is sorely lacking. We can easily store and manage page properties such as an article's quality assessment or which WikiProjects are interested in the article in a structured database. We already track (and can query!) by many page properties. Let's leverage the software platform we've built.
Regardless of whether we use a built-in tool or we continue to use templates, you're talking about trashing templates because of CSS issues. That doesn't make much sense to me. Templates make life vastly easier. We can likely update most talk page templates on large wikis with a single edit to a meta-template or perhaps even just a CSS edit. That's great!
- The mobile skin special-cases some templates (notably issue templates
and infoboxes) because they would render horribly.
Second mention of the mobile skin. Perhaps it's the mobile skin that needs work. I think the mobile experience is horribly and painfully deficient and flawed. Any help you can provide in trying to make it better would surely be welcome. I've tried a few times and it only results in sadness.
- Media-viewer has a tough time doing to correct thing with attribution
and license information because parsing template-madness is hard.
Structured data, a.k.a. Wikidata, as Brad noted.
- VE development has spent a large amount of time around templates, and
it's still one of its weakest suits. Template substitution is still a problem, as well as templates that produce wikitext that in itself doesn't map cleanly to HTML tokens.
VisualEditor actually doesn't deal with wikitext, as I understand it, it deals only with HTML. The Parsoid team deals with wikitext and they knew what they were getting into long before this project started. There was a commitment made to support most wikitext. And so it goes.
And as Brad notes, both VisualEditor and Parsoid will have to deal with annoying use-cases. (Of all the features, I think {{hidden top}}-type functionality will probably be one of the easier features to implement.)
- Scribunto has been developed specifically because writing and
maintaining templates with more complicated logic is horrible, both from a writers/maintainers perspective as well as from a performance perspective
This isn't really an argument against templates. Scribunto is part of the solution, not part of the problem. In theory, anyway.
All this together is sufficient to assert we have a template problem.
I think there's a reasonable case to be made against specific uses of templates (talk page templates are an easy target, as discussed above).
The steps you laid out here make sense and seem reasonable, but you'll have to do a new pass-through of these steps for each general template use-case you discover and wish to address. And each pass-through takes close to a year in my experience, if not longer. And that's with dedicated development resources.
One point that you didn't hit on which is an even easier target for criticism is that there's currently no easy way of sharing templates between wikis (no interwiki templates). We need to shrink the overall number of templates by finding common patterns between wikis and smartly sharing code _and_ man-power. If you want to make a substantive impact on the number of templates, I'd strongly suggest figuring out a way to revive interwiki transclusion or an equivalent sharing mechanism.
MZMcBride