Martijn,
First, *thank you* for drafting this -- I believe this is a fundamental architectural and maintenance issue we need to resolve. It is also a long term innovation issue -- as it is one of the ways individuals can participate in extending our user experience.
This would be a great case to plan and work on together, starting with gathering all of the different use cases currently covered, goals, problems, catalogue of current templates with usage data and desired improvements via a requirement document on-wiki.
We (WMF engineering) should provide support for this (so this complements any refactoring in Media Wikis and features under development), which means we would need to prioritize and schedule on our side as well. But requirement gathering can start now.
Martijn -- thank you for this, Lila
On Tue, Sep 2, 2014 at 2:40 AM, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
tl;dr: We've been collectively whining about templates for long enough. Who wants to help with fixing them?
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.
- The mobile skin special-cases some templates (notably issue templates and
infoboxes) because they would render horribly.
- Media-viewer has a tough time doing to correct thing with attribution and
license information because parsing template-madness is hard.
- 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.
- 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
All this together is sufficient to assert we have a template problem. The main editing community has a problem with how templates are and must be used, the readers have a problem with display issues on mobile as well as style inconsistencies, the technical editing community has a problem with writing and maintaining templates, and the development community has a problem with the difficulty in correctly parsing and interpreting templates and there contents.
It would be great if this problem were tackled; it would be even greater if the WMF could work together with the community to identify the pain points, and jointly take steps to tackle them. Templates are currently extraordinarily powerful, and most if not all of this power is finding use in the projects, possibly in ways nobody ever foresaw. As we all know from Uncle Ben, with great power comes great responsibility, and it's about time we all took our share of that responsibility, tough up, and fix it.
We should keep in mind that current use is paramount, and any fixing of templates that breaks the wiki is frankly unacceptable, which probably means we can't go from insane to sane overnight, even if we could define sane and insane with regards to templates overnight. At the same time we shouldn't shy away from fixes that would break some exotic use of templates, if as part of the process of making things better, before implementation, we can fix those templates.
I hope we can, for the coming period, accomplish the following:
- Catalog the problems with templates. Make a comprehensive list that
enumerates the problems with templates we have now, categories 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.
- Brain storm 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 templates.
Personally, I'm all talk and no action, so to get this of the ground we would need a lot of help. First, we need to know if I'm on to something, or if this is just the raving of a lunatic (please tell me if it is!). If the idea is sound, we need to set up the infrastructure. We probably need a Meta page set up to organise things and set up initial reconnaissance. We need a lot of grunt work categorising issues and problems from all perspectives: reader (this is difficult, but many groups that don't directly represent the readers care deeply about their needs, so that's something), template users, template maintainers, and template infrastructure maintainers (developers). For that we need to reach out to those different communities; this email is posted to wikimedia-l only (because I couldn't think of a better one, but I acknowledge this doesn't fit like a glove), but there are bound to be other interested parties out there who want to help that this email isn't reaching.
What do you all think? Should we make this happen?
--Martijn _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe