Portions of this page come from comments made by User:Jamesday and myself on Template talk:Sisterproject. -- Netoholic @ 19:05, 2005 Feb 4 (UTC)

Doesn't most of this apply to any popular template? In other words, if Wikipedia:WikiProject Stub sorting had not begun, or were to be called off, wouldn't this apply to the original {{stub}} template as well? — Itai (f&t) 14:41, 7 Feb 2005 (UTC)

Certainly, the potential for vandalism exists, and the template could be protected for those reasons. The server load problem still partially exists because of the use of the category in that template. Meta-templates are worse though. -- Netoholic @ 16:00, 2005 Feb 7 (UTC)

Could be. Basically, what I'm saying is this: are we sure this is not part of a greater problem? Seems that the problem is not meta-templates per se, but rather any template that is used on more than n pages. — Itai (f&t) 16:55, 7 Feb 2005 (UTC)

It seems to me that a large part of the problem stems from the different treatment given to anonymous users, who are served by massive caches which must be invalidated every time an edit is made. Registered users do not reap the benefit of these caches, because of the way the software implements the "logged-in-ness" of a given user.

Maybe some effort should be applied to making the software more efficient for registered users, if necessary at the expense of worse performance for anonymous users, which would encourage more people to log in.

I'm not expert enough in the whys and wherefores of XHTML/CSS to understand quite why anonymous users should be able to use caching—and logged-in users cannot—when I thought the real difference is in the CSS "wrapper" which should be independent of the "real content".

Enlighten me, someone, please!

--Phil | Talk 11:35, Feb 8, 2005 (UTC)

Happy to.:) When a page has been removed from caches, the first view of the page causes several steps significant to this discussion:

• Each item in the base page portion is requested from the database (images and CSS aren't in the main part). The page you edit, each templage, each template included in the template and so on. Two templates, to database records to be retrived. One template on its own, one read, one template including another, two. Plus the one for the base page.
• Once that and the rest of what is called the parsing is done, the page is saved in the parser cache. That's kept in RAM in memcached, subject to a capacity limit, currently 12 memcached programs running, ach holding 280MB for a total of 3.3GB of cache (a bit is used for other things but this is most of it). I see that 8 more are currently disabled - probably a temporary problem. In a few weeks I expect it to be about 12-15GB for this.
• Finally the skin is applied and the page is passed on to the Squids, which cache it for all who aren't logged in (will only be useful if it's the normal skin) and send it on to the person who originally requested it.
• Whenever any part of a page is changed, be it the page itself or a template or image used in it, the page is marked as changed and will be regenerated next time it is requested. Both the Squid and parser caches have it removed. Necessary so people see the correct version.

The Squids, because of the limitations in the way they can work, with much less work per page, are inherently the fastest way of serving the pages and just 4 machines can serve some 75% of all hits to the site. But they are restricted in what they can serve. Next step is using the parser cache via the apache web servers. That allows all of the user settings for logged in people but uses more web server CPU so it's less efficient. But can't yet be avoided (we're working on it - we want to serve as much as possible from cache).

We could switch everyone to using the apaches but that would be far less efficient and would require something like 4-5 times as many apaches as we have today, far more than the 4 machines gained by not using them as squids.

So, logged in people aren't being discriminated against. They also get caching. But the need to support user preferences does mean that they can't be served as efficiently as those who aren't logged in. Jamesday 08:09, 13 Feb 2005 (UTC)

I don't understand why you need to reparse the page in order to support user preferences. There are only two preferences that affect layout (3 options for dates and 6 options for math). So why not include all 9 options in the document, using CSS and JavaScript to select which one gets presented in the browser? Then the same cached page would work for all users, logged in or not. Gdr 16:07, 2005 Mar 22 (UTC)

What does

Two templates, to database records to be retrived.
One template on its own, one read, one template including another, two.
Plus the one for the base page.

mean? MarSch 16:36, 26 Mar 2005 (UTC)

Just in case anybody was not clear on the subject - this policy is, at the moment, being considered. It has not been endorsed by the Wikipedia community. No decisions should be based on it. — Itai (f&t) 22:29, 8 Feb 2005 (UTC)

This is not intended to be "policy". The Be bold guideline isn't "policy" either, but that doesn't mean we should ignore its wise guidance. -- Netoholic @ 17:25, 2005 Feb 9 (UTC)

The wiseness of this non-policy is being debated as well. In other words: don't point people, through edits summaries or directly, to this page as an explanation for actions without pointing out that this is not an official policy, merely the opinion of some Wikipedians. — Itai (f&t) 17:38, 9 Feb 2005 (UTC)

I see no debate refuting the points made in this page. Your argument on other talk pages seems to be about templates in general, but that doesn't mean the assertions of this page are incorrect. Beyond simple vandalism, meta-templates have other technical problems, which are documented here. -- Netoholic @ 18:22, 2005 Feb 9 (UTC)

Not policy but Netoholic is right in suggesting that templates in general and more so, templates within templates, increase server load . Better not to use meta templates if relatively few templates are involved and there's much concern for efficiency and page loading times. Jamesday 08:09, 13 Feb 2005 (UTC)

Can you explain a little more on why templates in general are a problem, and how much of a problem they are? BlankVerse ∅ 13:08, 13 Feb 2005 (UTC)

As I mentioned above, I'm not sure most of the content of this page is directly related to meta-templates. How about moving everything that is not directly related to, for instance, Wikipedia:Problems with frequently used templates (along with a note saying that meta-templates often fall under this criterion), and keep on this page (which I would rather have moved to Wikipedia:Problems with meta-templates, but this really isn't important) only what relates to meta-templates (along with a note pointing out that meta-templates are often frequently used). — Itai (f&t) 19:18, 10 Feb 2005 (UTC)

I've tried to assist by highlighting some of the general "big template" issues and the ones whcih are specific to templates wihtin templates. Basically, templates within templates because they are likely to affect more pages, do have a larger effect than is initially apparent, mostly because of that lag issue, but also because of the extra base load for the database servers. Base load we can buy more machines for, that lag is a far tougher problem. You cna probably extract the generic template bits for a page on that. Jamesday 08:09, 13 Feb 2005 (UTC)

Whatever is true of regular templates is twice as true for meta-templates. Please don't split out sections of this page, and don't rename it. -- Netoholic @ 20:55, 2005 Feb 10 (UTC)

I've had no intention of taking any such actions unilaterally. However, I still maintain that this page is misleadingly named. This is like a Ford advertisement saying: "you shouldn't buy Hondas because Hondas can't fly." True, but the same can be said of all other automobiles. Wouldn't it be better to have a site-wide policy regarding all frequently used templates (say, those having over 10,000 occurrences), and keep this page for problems restricted to meta-templates? (Along with a note saying that some meta-templates also have the misfortune of being frequently used, and thus pose the problems mentioned on the newly created page.) — Itai (f&t) 21:58, 10 Feb 2005 (UTC)

If you like, I'm sure that when template parameters were first considered, there was a lot of discussion regarding what's wrong with parameters. You can add the arguments against allowing parameters to this page. (Meta-templates generally use parameters.) In fact, if you wish to make this page longer still, you can even include bits about what's wrong with wikis in general - which applies, admittedly, to meta-templates as well. — Itai (f&t) 21:20, 11 Feb 2005 (UTC)

I've no significant load concerns about parameters in templates. The parsing cost is minimal compared to the extra database reads of templates or templates within templates. People may have stylistic and taste objections but that's a different thing. Jamesday 08:09, 13 Feb 2005 (UTC)

Itai, stop trolling. This page presents many of the major issues of meta-templates. Vandalism is only one, but it's impact is felt even harder than when using one template. For example, if I have meta-template that governs 20 other templates used on 100 pages each (2000 pages affected), it is more damaging to vandalise the one meta-template than it would be to vandalize a single template used on those 2000 pages. -- Netoholic @ 21:48, 2005 Feb 11 (UTC)

Netoholic, stop murdering infants. (You're not, but neither am I trolling.) If using a meta-template-generated templates for these 2000 pages is indeed worse than using a single template, list the reasons for this on this page. You've still to provide one good reason why it wouldn't make more sense to list the problems with all frequently used templates on one page, and keep this page, which has "meta-templates" in its title, for problems specific to meta-templates. (Including, for instance, the reasons for your above statement.) — Itai (f&t) 02:08, 12 Feb 2005 (UTC)

Each meta-template doubles the number of template records which must be retrieved from the database when the page is being built, slowing down the page view and adding database server load. That's true regardless of caching questions. If a meta-template is used in 5,000 other templates it may be worth having anyway because of the amount of work it saves (though it's probably debatable whether it is really wanted by all 5,000). If it's used in 10, twice the number of template retrievals seems like a high cost to pay compared to the human work saved. We can solicit donations to buy more hardware to do that work, but it's nice to try to be efficient as well. For this reason, meta-templates are a special, more costly, case of the general big template situation and do merit some extra consideration. Jamesday 08:09, 13 Feb 2005 (UTC)

What if we quit using those templates that are currently being used as meta-templates as meta-templates, but just use them only as a common template design, and then create the "daughter" templates using {{subst:meta-template}}? That should get rid of the double read.

From your description, it also sounds like we should be trying to keep down the number of templates per page. I've seen a few pages that have been plastered with an attention template, a dispute template, and a stub template. Should there be a policy that in general there should only be one (or two?) templates/page?

Although I haven't seen you address the issue, I am guessing that there may also a problem with some of the very large templates that are sometimes being created (compared to small templates)? Also: How easy would it be to get a list of the most commonly used templates with an estimate of the number of pages they are being used on? BlankVerse ∅ 09:47, 13 Feb 2005 (UTC)

As I discussed at Wikipedia:Templates for deletion#Template:us-geo-stub, using lists, because of the large number of entries, and the large amount of human maintenance that would be required, is an unworkable alternative for trying to deal with stub articles. The topic stubs were created because the Category:stub had grown so huge that it had to be disabled because of the hit on system performance. The Category:substubs was also growing to an unmanageable size. Regrouping the stubs into smaller stub categories allows individuals who are interesting in those topics, plus the Regional notice boards and Wikiprojects, to find and expand those stubs into larger articles. As far as I can see, the best solution for handling the topic stubs may be to quit use the metastubs except that the text for the metastubs is saved somewhere so that they can be used as text templates for creating topic stubs with a standardized format. BlankVerse 09:37, 11 Feb 2005 (UTC)

Can I ask this... why are unsorted stubs such a problem? Take us-geo-stub, for example - I can guarantee there is noone sitting around saying "Gee, I think I'll see what random U.S. locations are stubs, and improve one". Let's leave them to be happy little stubs, sitting out there doing no harm and not being referenced, until someone actually interested in that subject comes along and improves it. Sorting stubs is busywork. For any specific topic area, wouldn't it make more sense to just make a list of the needed articles, and prioritize them for work? I'm not saying you must maintain a list of every related stub, but why go out searching for them just to categorize them? The problem is, the stub message should never have had the Category:Stub added to it. We only needed a simple text to encourage people to come in and edit. -- Netoholic @ 15:43, 2005 Feb 11 (UTC)

1) I have already explained to you in the Wikipedia:Templates for deletion#Template:us-geo-stub discussion that I have used the Template:Japan-stub/Category:Japan-related stubs combination to look for articles on Japanese topics to un-stub. I've heard of other Wikipedians doing similiar things for other subject areas. So yes, there are people who are using the topic stubs to help un-stub articles.

2) Leaving the articles as just stubs will guarantee that many of them will NEVER be upgraded unless someone comes along interested in that specific article rather than that subject area.

3) Having a huge number of articles with template:stub has been a problem because category:stub because so huge that it was big performance hit and so the stub category had to be removed from that template. That means that the only way to find those Wikipedia articles with the stub template but are not in the stub category is to do a Google site search.

4) Lists would be a HUGE amount of busy work if there were to be used to keeping track of stubs. BlankVerse ∅ 13:04, 13 Feb 2005 (UTC)

I can guarantee there is noone sitting around saying "Gee, I think I'll see what random U.S. locations are stubs, and improve one". Can you now? I don't spend a whole lot of time looking at the geo-stubs, but I do check in occasionally to see if there are any that I recognize and can help out. However, while I find the geo-stubs marginally useful, I'm really not convinced about the entire elaborate new stub sorting apparatus. Seems unnecessarily complex to me, but then there may be others who, like me, check for stubs in their areas of interest from time to time. So count me as decidedly ambivalent. I can see how a *simple* stub sorting method is superior to making lists (it is trivially easy for a random editor to add a stub tag to an article, while adding the article to an appropriate list is considerably more involved). older≠wiser]] 16:03, Feb 11, 2005 (UTC)

I agree with you. That guarantee was pretty much a blatant assumption; all editors don't (and shouldn't) edit the same way. That is exactly what people are doing. I often pick a stub topic and go through it, copyedit, google it, get out a book I have on the subject. It's pretty difficult to find articles that really need development otherwise. Randomly clicking hoping to find an article in the subject I'm interested that really needs it is a waste of my limited time. --Sketchee 16:05, Feb 28, 2005 (UTC)

Personally, not speaking as the developer most responsible for database issues for this comment, I'd like to see stubs in both alphabetic and subject categories (with alphabetic grouped by the first 3 letters of the page name). There are people who like to work on specific topic areas and also are people who like to just work on random stubs. (shrug) Easy enough to help both groups. There's no extra cost for this in the individual page views. Alphabetic grouping for the full stub list to keep the category sizes manageable. Jamesday 08:09, 13 Feb 2005 (UTC)

Now as a developer: large categories were a significant load problem. They are still an issue but less so and may be a smaller factor with MediaWiki 1.5, whenever that arrives. For load reasons it's nice to keep the total number of items in a category in the few thousand range. For general guidance, we use 500 for the all pages lists and such because 500 is currently about the maximum normal comfort level. More than that starts to become an issue and in the thousands I start to notice them showing up as unusually slow queries which are delaying others. Try to think how big the category will eventually be and segment it in some way with a target in the 500 or fewer members range if you're trying to avoid load issues. In November or December 2004 I requested an emergency change in how categories were handled (hard limit to 500 members). I also acted as a developer to temporarily protect one template at a version without a category or image in it for load reasons. Another change made it possible to remove that limit and protection, though it's an imperfect solution at present - just good enough to dodge a hard limit. There's a change coming in MediaWiki 1.5 which may raise the 500 number by reducing the cost a bit. Jamesday 08:09, 13 Feb 2005 (UTC)

Can you tell us how many Wikipedia articles currently have the stub and substub templates? Also: which categories on the Wikipedia currently have the most number of articles? Finally: Are images in templates a performance issue? BlankVerse ∅ 13:04, 13 Feb 2005 (UTC)

Netoholic: Your description was overblown as well as incorrect. I still left your basic points intact. Without the exaggerations that were in your original version, people will actually probably believe your position more. BlankVerse ∅ 17:36, 12 Feb 2005 (UTC)

There are no exaggerations. The wording may be "dramatic", but this page serves to describe a strong position against the use of these meta-templates. -- Netoholic @ 01:00, 2005 Feb 13 (UTC)

From your description in the Scope creep section:

• " literally hundreds": with roughly 250 stub templates in Category:Stub categories, it should have said a few hundred.

• Baring mind, if we have 250 stub templates for roughly 475k articles, how many do you think we'll have when the Wikipedia reaches 1 million articles? Certainly not 250 stub templates. Maybe 500, maybe more. We might have as many stub templates and stub categories as we do have categories now. -- AllyUnion (talk) 06:31, 16 Feb 2005 (UTC)

• "many of which have been created on the spur of the moment": False. If you had check the various pages for the Wikipedia:WikiProject Stub sorting, you would have seen that the new topic stubs were being created with specific needs in mind. For example, many of them are being created to be associated with different WikiProjects or Regional notice boards.

• It was spur of the moment when it started, by the way. Certainly not completely the case now, as project members are trying to keep in mind not to create any stub without asking first. -- AllyUnion (talk) 06:31, 16 Feb 2005 (UTC)

• "... for use on only a few articles": False: The stubs that are being created by the people in the Stub-sorting WikiProject are only being created when it can be shown that there are enough stubs to populate the stub category. Although things were a little too haphazard to begin with, especially before the creation of the Stub-sorting WikiProject, there is now a Wikipedia:Stub sorting policy, which says there should be a minimum of 100 articles.

  Baring in mind, that was Netoholic's idea. -- AllyUnion (talk) 06:24, 16 Feb 2005 (UTC)

  It use to be 10, by the way. -- AllyUnion (talk) 06:24, 16 Feb 2005 (UTC)

  And oh, that stub sorting policy has not been made official, and still in the draft stages. -- AllyUnion (talk) 06:31, 16 Feb 2005 (UTC)

• "many of these new "child" templates have come up for deletion": False. There have been a few "joke" templates at WP:TFD (such as Template:Cowstub and Template:Stub-sorting-stub), there have been a few accidental template creations that duplicated the scope of existing stub templates (such as Template:us-geo-stub and Template: Car-stub), and there have been a few that were created where the Stub-sorting WikiProject later decided that there were better ways to categorize things (such as Template: City-stub). Finally, there was also Template:Bush-stub, which was created by someone not involved with the Stub-sorting WikiProject. You've made it sound like there were dozens of stub templates that were inundating the WP:TFD process.

In my opinion, your descriptions went beyond just exaggerations in some cases. They were inaccurate descriptions of the stub template creation process, which it appears you have not investigated before you created your descriptions. BlankVerse ∅ 12:27, 13 Feb 2005 (UTC)

AllyUnion's responses are spot-on. Leave this section alone. Feel free to write Wikipedia:Meta-templates are teh best or somesuch. This page is to describe the negatives of using them, and no watering down of the scope creep section is welcome. -- Netoholic @ 04:26, 2005 Feb 18 (UTC)

I believe that meta-templates are considered harmful if and only if they are not used with the subst: included. Netoholic's example of the stub sorting is valid simply because it's one of the best examples he could find. I doubt that Netoholic would object if every stub template used {{subst:metastub}} instead of {{metastub}}. -- AllyUnion (talk) 22:17, 19 Feb 2005 (UTC)

If -all- that a template is used for is to "subst:", then I don't think the template should exist. In general it is much better to document the wikicode for the template "genre" on a project page for easy copy and pasting. -- Netoholic @ 03:29, 2005 Feb 20 (UTC)

Then we should delete {{vt}}, {{vb}}, {{vfd top}}, {{vfd bottom}}, {{vfd}} under your logic. -- AllyUnion (talk) 07:07, 4 Mar 2005 (UTC)

As the stub messages are being turned from readable semantically-marked-up code to less-readable stuff with DIVs flyign to and fro, I gotta as this.

As Jamesday pointed out, when a page's entry in the cache is empty, a database query is made to fetch that page. Then another one for each template it contains, and so forth. Why on earth aren't we caching the templates as well?

From what Jamesday said, this is the current process: Say page1 contains template, which contains meta-template. page2 also contains template. Then, if meta-template is changed, loading the two pages causes this to happen:

• page1(template(meta-template)) is dirty, needs to be refreshed. Fetch page1 from db.
  • Fetch template from db.
    • Fetch meta-template from db.
  • Assemble template(meta-template).
• Assemble page1(template(meta-template)).
• Serve (and cache) page1(template(meta-template)).
• Fetch page2 from db.
  • Fetch template from db.
    • Fetch meta-template from db.
  • Assemble template(meta-template).
• Assemble page2(template(meta-template)).
• Serve (and cache) page2(template(meta-template)).

This can't possibly be right, but it looks like this is what Jamesday is saying is happening. If so, no wonder meta-templates are such a performance hit. What's wrong with caching a version of the page with references to the templates, so they can be substituted into an already in-cache page without dirtying it? So we'd avoid dirtying zillions of pages and requiring them to be fetched all the way from the database again when, really, nothing's actually changed in them.

Am I way off base here? Someone set me straight. grendel|khan 02:07, 2005 Mar 4 (UTC)

1. It seems like we can change the way pages are cached instead of inconveniencing everyone by removing meta-templates. True?
2. If "glorified stylesheets" are converted into css classes, the classes have to be as visible and easy to use as the templates and also editable. - Omegatron 23:41, Mar 21, 2005 (UTC)

Stub templates aren't the only meta-templates in use. See Template:Message box. -- AllyUnion (talk) 07:08, 4 Mar 2005 (UTC)

No one's made any major changes to this in a while, nor refuted the basic conclusions. We already have some areas (like stubs) which are moving away from meta-template schemes now that the technical reasons have been described. One of the main reasons cited for other areas which are not yet adopting this principle is that it is not "policy". Well, let's start moving that way.

I'd like to move this from an "opinion" piece to a guideline. Namely, I propose renaming this to something like "Avoid using meta-templates", and replace the "proposed" line with one specifying this as an active guideline. I'd like to also link to it from the relevant template-related pages. -- Netoholic @ 22:31, 2005 Mar 21 (UTC)

The discussion has become moribund here not because there has been any consensus reached, but instead, it is because you have taken ownership of the article and not allowed any changes that you do not agree with. For example, your censorship of any mention of the use of "subst:". I do agree that Meta-templates should not be directly used, but without the use of such templates as the metastub template, you had the problem that existed before it was created where the newly created topic stubs had different wordings and formattings. Since the participants in the Stub-sorting Wikiproject have quit using the metastub template, that problem has returned.

I think that this is close to being ready to be Wikipedia:Semi-policy, but I think that it still needs some work and some rewording. Without those changes, I do not support changing its status. It certainly isn't ready to be official Wikipedia policy yet, which is what it sounds like you want to do. (Just a suggestion: I think that you need to become more familiar with Wikipedia:How to create policy, including "Do not rush" and "Consult widely - make a special effort to engage potential critics of the new policy".) BlankVerse ∅ 13:02, 22 Mar 2005 (UTC)

I am well aware of how to create policy, and don't see this as rushing. Please propose what you'd like to add. -- Netoholic @ 14:59, 2005 Mar 22 (UTC)

Except for mention of ":subst", it is mostly deletions that I think need to be done to the proposal. For example, since User:Jamesday has said that creating topic stubs is a good thing™, then the entire "Scope creep" section (or at least any mention of the topic stubs) weakens your arguments. "Use lists" under "Alternatives" should be removed because it is an unworkable proposal. There also needs to be some discussion of using ":subst" as a way to use a template as a standard format (e.g. Metastub), but still avoid the double database call. I'll think about it some more, and then do some editing in a day or two.

I do agree that the article name should be changed to either "Avoid using meta-templates" or just "Avoid meta-templates". BlankVerse ∅ 03:03, 23 Mar 2005 (UTC)

I don't even understand why this is necessary. Have you asked for opinions in places where people are likely to see it? - Omegatron 16:17, Mar 22, 2005 (UTC)

Well, because I think its important that we have something to back up the contention that "meta-templates" should in fact not be used. In its current state, people consider more of an opinion and optional. Moving to guideline makes for a stronger stance. -- Netoholic @ 16:53, 2005 Mar 22 (UTC)

Turning it into a guideline doesn't justify it. I'm asking if you've convinced a large number of people that meta-templates are inherently bad and can't be fixed in software. I'm not convinced that this is necessary in the first place. I don't see any kind of consensus from this talk page. - Omegatron 17:41, Mar 22, 2005 (UTC)

I've linked to this page and discussion from quite a few relevant pages. Most people either don't work with templates, can't follow the technical aspects, or probably don't care. When Jamesday, the main database guy, says these are a problem, one has to be convinced. In fact, the stub sorting project is convinced and is moving away from using a meta-template. -- Netoholic @ 18:18, 2005 Mar 22 (UTC)

Although this page was mentioned on some of the pages where the people most likely to work on templates usually go, there probably should be another round of publicity before it moves from proposal to guideline (it certainly didn't receive as much publicity as Wikipedia:Requests for de-adminship). All the usual places, such as Wikipedia:Templates for deletion should get a new notice, plus the stub-sorting Wikiproject, plus some of the general Wikipedia info pages such as the Village Pump and maybe even the mailing list. You also should probably put a note on the Talk page of Users who have participated in this discussion so far (such as User:AllyUnion) in case they don't have this page on their Watchlist. BlankVerse ∅ 03:03, 23 Mar 2005 (UTC)

I for one oppose moving this to a guideline. It's a good page to have, but these things should be decided on a case-by-case basis. — Itai (f&t) 17:31, 23 Mar 2005 (UTC)

I think that grendel|khan has a very good question above under #Question about caching. which should be answered first. If there really is a problem, then what could be done when a template is changed is not mark any pages that use it as dirty and just wait for them to get an edit and be rebuild using the newest version of the template. MarSch 17:11, 26 Mar 2005 (UTC)

I agree that technical fixes should be tried before enforcing rules like this.

If we did that, MarSch, we would then have to go and edit every article that used that template by hand to update them to the latest version, using up a LOT more time and bandwidth than having it update automatically. - Omegatron 19:31, Mar 26, 2005 (UTC)

For a fair representation, perhaps all the templates which are considered as meta-templates should be listed here first? -- AllyUnion (talk) 06:07, 30 Mar 2005 (UTC)

Good idea. - Omegatron 06:18, Mar 30, 2005 (UTC)

Is anyone seriously interested in a list of meta-templates? One I've created is template:Prefecture navobox which is now used by roughly 800 articles on cities, and districts in Japan. Other high runner templates I've created or that I'm aware of include:

• Template:Japan-geo-stub, used in essentially all the articles on cities, towns, and villages in Japan
• Template:birthyr (not "meta" in the sense used here), used in essentially all (2000?) of the "birth by year" categories
• Template:deathyr, ditto
• Template:birthdecade, used in essentially all (200?) "birth by decade" categories
• Template:deathdecade, ditto

-- Rick Block 04:58, 5 Apr 2005 (UTC)

Have all technical fixes been tried? One possibility I don't see mentioned here (which might be a lot of work, but if the problem is actually severe it might be worthwhile) would be to automatically convert template references and template content to javascript allowing templates to be cached independently of the page that references them. If it's not clear, the idea is to convert a reference to a template T to HTML somewhat like:

 <script language="javascript" src="T.js"></script>

and translate the contents of the template to the appropriate javascript code stored at the T.js URL. The net result of this is that a change to the template does NOT need to set the dirty bit for any referencing article since the browser would fetch the javascript independently of fetching the article text. This would tend to increase the number of URL fetches, but a change to a widely used template would have very little performance impact. I don't think mediawiki currently requires javascript to be enabled when browsing - this would require javascript. I'm not as familiar with stylesheets, but I suspect something similar could be done with stylesheets (without requiring javascript). In either case, this might be limited to templates that have no parameters. Another possibility would be to augment squid with the ability to understand a server-side include mechanism. -- Rick Block 23:34, 4 Apr 2005 (UTC)

Perhaps I'm biased; I just finished creating a set of metatemplates myself. But I think it might be just as honest to say that the template work I did and my position on this article stem from the same deeply-held conviction:

Human time is more valuable than computer time.

This is the main current of thought among programmers and developers since the first great box full of vacuum tubes was brought to life: Let George do it. The first computers were programmed by connecting components, one to the next, with dozens of patch cords. Then, somebody decided that the computer could store instructions, and execute them -- one after another. The machine could be wired *once*, and once only; thereafter, all the programming would be done in "software".

Early computers were programmed in machine language: raw numbers. This was, and is, both extremely difficult and prone to error. In the right hands, it was blindingly efficient, too. In time, special programs allowed programmers to write in assembly language, using mnemonics -- short, vaguely readable "words" -- mixed in with the numbers. This was less efficient for the machine to execute, but any loss was quickly made up by advances in hardware -- bigger, faster, cheaper. Meanwhile, programmer productivity went way up.

Assembly language gave way to higher-level languages; perhaps the most powerful common language in use today is C++. This is an extremely sophisticated language, in which programmers write in something very like a highly-stylized English. They do not even always say what the machine will do next; instead, they merely describe objects, which interact with each other as they are defined. This makes far more complex programs possible -- that is, it makes it possible for humans to write them. Once written, a C++ program is compiled into a rather inefficient machine language, which is all any computer can actually execute directly.

Fortunately, we now have computers powerful enough both to compile C++ and execute the resulting inefficient code pretty quickly. Our resources have grown to permit us to do more advanced work.

HTML and similar markup is another development of the same idea. If you want a computer to display text on the screen with a box around it, there are far more efficient ways to do this than rendering some HTML markup in a browser. But the advantage of HTML is that relatively inexperienced users can master it, while even the most basic C++ skills are a bit difficult for some to grasp.

Wikimarkup is still another step in the same direction: Let George do it. Before Wikimarkup can be rendered in a browser, the wiki server must parse it into HTML. The HTML is interpreted by your browser, which was probably written in C++; converted into machine-readable data by inefficient (and buggy) code, and finally displayed on screen. From a technical POV, this sucks. But Wikimarkup means your grandma can program a computer, even if chocolate chips are all she thinks about when someone says "cookies".

Templates are a very clever, flexible way to standardize Wikimarkup, so pages all over a wiki have a consistent look-and-feel. They aren't the only way to do this; but they're accessible to everyone. They do incur all kinds of overhead -- servers must work hard to render lots of pages with lots of templates and lots of templates that use other templates. But the payoff is the same as it has always been: More users are able to do more powerful things better, faster, more easily. Let George do it.

There has always been a countercurrent of industry insiders who, by virtue of their superior competency, are able to do more with less, and loudly demand that others do the same. We must resist this anti-trend. We need to keep moving in the right direction. We can always go back to wiring the computer up for each job; we will get very fast execution on small, slow machines. Or we can continue building larger, faster, better machines that allow us to use them more easily. This is Good.

Specific points:

Yes, bigger-better-faster servers cost more Cash Money. More efficient, capable, reliable servers demand that humans maintain them and their code.

I keep hearing people say that Wikimedia Foundation is swimming in money (which I don't believe). I put forth a small effort to enhance donations and it fell on deaf ears. ("It ain't broke, don't fix it.") Well, it can't be both ways. Either there is a shortage of money, and suggestions for getting more merit attention -- OR -- there is a surplus of money, and we can go out and buy more and better machines and hire wonks to work them. I gather that every scrap of MediaWiki code has, up til now, been written by volunteers. I agree with the ideology -- and, yes, the code should remain free-speech-free -- but I see no harm in paying some kids to do actual work-for-hire. Everyone involved in this project (I have to think) has a Real Job and can only do so much for free.

Yes, much template stuff could be done in CSS style sheets. In fact, a lot of it uses CSS locally, and might be overridden by users.

But I do not see any way to edit the Monobook style sheet, let alone the Cologne Blue style sheet. I can edit my copy, but the WP-wide default is read-only. And, quite frankly, I'm not 100% sure I want those pages open to user edits. And it is anti-wiki to suggest that we get together and beg Somebody to make the changes for us. Things do not really get done around here by forming consensus first, then making the change. It's more like change-talk-change-talk-change-talk-change=consensus.

Yes, widely-used templates are vectors for all sorts of attacks. Yes, we could slam this door shut on all users, thus keeping evildoers out as well. While we're at it, we should restrict all editing to logged-in users, and perhaps demand email addresses too, so we can check up on returning, banned vandals and their sock puppets. If we didn't have so many ignorant, pimply pre-teens editing articles way above their heads, we'd surely have higher-quality content -- so perhaps we should verify users' credentials before allowing them to edit related content. We'll call the project NuNupedia.

Or maybe we can continue to deal with all sorts of attacks, case by case.

Yes, we can draw up detailed guidelines and formats for everything under the sun. We can even hope editors will read these guidelines before editing. We might even require editors to read and obey them all. In fact, we could impose a strict hierarchy of punishments to be levied on those who create non-standard edits. Example: User creates new article with pluralized title. Penalty: Ten lashes in public square.

Yes, {{subst:sometemplate}} answers a lot of performance and security problems. But it does so by gutting the power of the template technique in the first place. Since a template included using subst: is "frozen" at the moment of edit, nobody can automatically change it on all pages where it's used -- not for evil, nor for good. I believe that Good is more powerful than Evil. Good thrives on Freedom; Evil thrives on Secrecy and Control.

There are times when it is absolutely correct to use subst: and I agree it is underused; I even admit I've failed to use it properly at times. I especially support the use of subst: when choosing a licensing template for uploaded images -- after all, what does it mean if someone later (quite properly) changes the text of the license?

Templates that help to support a standard look, feel, and work across a large project are just Good Ideas. This proposal to suppress them does not move us along the Wiki Way.

— Xiong (talk) 07:15, 2005 Mar 31 (UTC)

• Template:31DayCalendarStartingOnMonday
• Template:31DayCalendarStartingOnTuesday
• Template:31DayCalendarStartingOnWednesday
• Template:31DayCalendarStartingOnThursday
• Template:31DayCalendarStartingOnFriday
• Template:31DayCalendarStartingOnSaturday
• Template:31DayCalendarStartingOnSunday

Used on the calender sources then used on the calendar themselves! Triple include! -- AllyUnion (talk) 06:48, 30 Mar 2005 (UTC)

• Template:30DayCalendarStartingOnMonday
• Template:30DayCalendarStartingOnTuesday
• Template:30DayCalendarStartingOnWednesday
• Template:30DayCalendarStartingOnThursday
• Template:30DayCalendarStartingOnFriday
• Template:30DayCalendarStartingOnSaturday
• Template:30DayCalendarStartingOnSunday

Don't forget the 30 day ones too. -- AllyUnion (talk) 06:48, 30 Mar 2005 (UTC)

Add Template:2005Calendar. -- AllyUnion (talk) 06:53, 30 Mar 2005 (UTC)

• I feel a little ill now that I've seen those. The approach I sstarted working on at simple:Wikipedia:Calendars is, well, simpler. -- Netoholic @ 07:26, 2005 Mar 30 (UTC)
  • Template:Calendar is somewhat worse. It includes Template:CalendarSource which includes 12 months as something like: Template:JanuaryCalendar2005Source which in turns uses one of those above day calendar things. -- AllyUnion (talk) 10:51, 30 Mar 2005 (UTC)

Template:Message box - glorified stylesheet. -- Netoholic @ 07:24, 2005 Mar 30 (UTC)

• This is a personal opinion piece by one user, and should be acknowledged as such.

I am suggesting that it goes into user space as User:Netoholic/Avoid using meta-templates, or into Meta as m:Avoid using meta-templates. Susvolans (pigs can fly) 12:31, 31 Mar 2005 (UTC)

• Give me a break and stop with the controversy. This isn't an "opinion piece", it is a description of how meta-templates work from a system side. The vast majority of the text of this page was verbatim from User:Jamesday - THE database admin. Other people have edited this page, and its been cited often. -- Netoholic @ 17:27, 2005 Mar 31 (UTC)

• Agree -- I support the requested move. This is an opinion piece. — Xiong (talk) 17:31, 2005 Apr 1 (UTC)

• Disagree. Every policy or guideline starts off as an opinion piece, albeit one you notice more than one Wikipedian shares. Instead of exiling this to user space ASAP to avoid having to discuss it any further, I suggest convincing Netoholic, Jamesday and any others who agree that they're wrong instead. This may sound shocking, but I think it's part of building consensus. :-)
  While this is still clearly marked a proposal, it's not harming anyone now, is it? I would obviously oppose any promotion to semi-guideline or true policy as well, but I see no reason to kill it.
  In fact, why am I still arguing? The mere fact that I still want to discuss it should be enough to prevent any move from happening. Hahaa, I too have the power of veto! (I'm kidding, people. Really. :-) JRM 00:57, 2005 Apr 2 (UTC)
• Also disagree. Dan100 10:29, Apr 3, 2005 (UTC)

• I'm changing my vote; I overreacted. This opinion might mature into viable policy Someday. But it is opinion, not a mere, bald statement of technical fact. Netoholic should be restrained from shoving his opinion through without that necessary maturation, and must allow other editors to contribute to its development. Someone who does not have a dog in this fight should refactor both article and its talk to remove inflammatory statements that appear to give this opinion more weight than it has in fact acquired. — Xiong (talk) 05:42, 2005 Apr 2 (UTC)

• I disagree that this should be moved; just rebutted. - Omegatron 20:20, Apr 3, 2005 (UTC)

Template:Notmoved violet/riga (t) 09:03, 4 Apr 2005 (UTC)

A nice polemic section to get the edits flowing.

Let's separate fact from opinion, first. I think we can give Jamesday his credit and take his description of the page building process for granted. Not that I'm truly interested in all the details, mind you; those are fine for the talk page but the blurb as a whole is quite overwhelming. If James had just said "meta-templates are really bad for performance because every inclusion in X articles adds Y computrons to a retrieval" I would have simply taken it on faith as well. In that vein, the "vandalism would be really bad because they're so performance-intensive" argument is really not a separate argument, just a strengthening of the performance argument. We will deal with that shortly.

The "vandalism would be really bad because the changes would appear in a lot of articles" is a separate argument, but this is a case of "no good without the bad". This is exactly why many meta-templates exist in the first place, and as with anything for which vandalism is really bad (page moves, the Main Page) we have ways of limiting the damage (restrict to logged-in users, protect and obscure through templates). The keyword here is restrict, not disable. I'm sure that if vandalism of meta-templates becomes such a big problem (and I'm not aware it's one already) we will deal with that as we see fit, and I hardly think completely avoiding them is a relevant alternative in that case, unless very satisfactory replacements can be found. We will deal with those shortly as well.

Now, the opinions in this proposal, as I see them, are:

• The performance burden is significant, and we cannot expect it to reduce even in the long term.

  Rebuttal. As people have suggested above, are we already out of technical solutions? Isn't there any way to speed up the process if you take the existence of meta-templates into account in the first place? Obviously a trade-off is involved: developers would like it a lot if users just stopped using them; users would like it a lot if developers sped up the processing. But users will only stop using meta-templates if developers can convince them that it's really very expensive, and there's no way to improve that: the software is there to support us, not the other way around.

• The existence of meta-templates encourages the creation of poorly conceived child templates based on them. Avoiding them will diminish their numbers, which is good.

  Rebuttal. Encouraging people to be smart by making things harder doesn't work. "Make something foolproof and nature will invent a better fool." Yes, people can create silly templates. They always could, and always will. We're talking a template—on-the-fly substitution. This is not so complicated that avoiding it will stump users with a bad idea so much that it has a noticeable impact on the number of ill-conceived templates. But even if it did, ill-conceived templates can simply be removed. As far as I'm aware, we are not suffering an acute problem of being overwhelmed by bad templates proliferating on pages—no more so than WP:TFD is handling, that is. This smells strongly of personal revulsion to the phenomenon, which, while understandable, is not an argument for anything—not unless it can be converted in objective criticism.

• The alternatives offered are adequate.

  Rebuttal. What others have already said: they're not.

  Design, document, and implement

  A way of doing meta-templates without using meta-templates: instead of editing the proposed template, you edit a regular page. Instead of using the talk page of that template for central discussion and Wikipedia:Template messages for documentation, you use a regular page. Instead of using "what links here", you maintain this list manually on a regular page. Administrator note In short: separating the actual template from its implementation. This is make-belief neatness, as it's equivalent to an integrated approach but without actual integration.

  Make use of CSS

  Avoid globals. It's unworkable to propose that any attempt at a uniform appearance should involve a change to the global stylesheet. The threshold for innovation would be unreasonably high. Replacing well-established meta-templates only used for appearance with a CSS class may be an attractive optimization and is certainly something to think about, but suggesting the global stylesheet as the only way of going for uniform appearance is iffy at best.

  Use lists, not templates and categories

  This idea has already been discredited by others. Lists are high overhead work, and most of it is automatable. So let it be automated. The argument that you could combine other tasks with lists is like saying that sorting different-sized ball bearings by hand is preferable to doing it by machine because it gives you the opportunity to check them for defects while you're at it. There's no reason to assume there are so many naturally combinable tasks that you're really no worse off without machine assistance—and even if this were so, this just forces you to combine those tasks even if you don't want to, because the overhead is prohibitive otherwise.

  Fix the problem, don't mark it with a template

  Good advice. It just doesn't have anything to do with meta-templates in particular. This is something to consider before using any template. Proposing that only fixing is allowed, and not identifying the problem, however, is distinctly counterproductive—and in some cases impossible. If I see a POV article, can I just "fix it" so it's NPOV? Most probably not, because my "fixes" will draw disagreement from others. Fixing problems is a good thing; the ability to clearly identify them for others is also a positive good, one that should not be lightly discarded.

  Use {{subst: }} when creating the daughter templates.

  From the argument itself: "...which probably defeats the point of using a meta-template in the first place". Exactly. Obviously, in places where we don't need updatable meta-templates, we shouldn't use updated meta-templates. Unfortunately this will rarely be so, and suggesting it should be is not really an alternative.

1. Template:Anb I am aware of the problem "what links here" is suffering for meta-templates, as outlined above: instead of listing only its direct children, it lists all articles indirectly using it. This could be called a feature, but then we also need the feature that lists only direct children. This is an implementation issue, though, not an argument against meta-templates.

JRM 00:57, 2005 Apr 2 (UTC)

When I first put this page together, and each time I quote it, it is so that I can refer people to it without having to re-explain each and every time about the technical problems with meta-templates. I don't do it to imply this is already policy, just that it presents the reasoning behind my actions.

Frankly, I'm shocked that people are ignoring the one voice on this issue which cannot be dismissed. This page describes the very real technical concerns about using meta-templates. That description didn't come from me, it came from User:Jamesday who is the project database administrator. I really don't care if thirty editors come on to this page to disagree... when someone so close to the technical issues has spoken out, there is hardly room for dispute. This guy knows how the system works, has done his best to make things work better, and can still see and describe the very real impact of wide-spread meta-template usage. I am sorry if I take his words and elevate them above fellow editors, but I just cannot bring myself to ignore him. I myself have surely created meta-templates in the past, but upon looking into this and reading his description, I have stopped, reversed what I could, and have worked to get this out to as many people as I can. -- Netoholic @ 18:27, 2005 Apr 5 (UTC)

Why isn't he here fighting for it, then? - Omegatron 18:30, Apr 5, 2005 (UTC)

First of all, he took the time and wrote for a us a very nice, long technical description - what more do you want or need? He does have a talk page after all, if youwant to ask questions. Second, he's probably a bit busy lately keeping this site online with rapidly-growing traffic. -- Netoholic @ 18:35, 2005 Apr 5 (UTC)

This is silly. If Jamesday's concerns are really so pressing, why doesn't he just announce on the mailinglist or the Village Pump that we are in serious trouble, and if we would be so kind to restrict use of (meta-)templates to an absolute minimum? Indeed, why build guidelines or policy like this at all? Last time I checked, the developers' word was still law. If we don't have a choice, then don't make it appear like one.

Jamesday said, quote, "better not to use meta templates if relatively few templates are involved and there's much concern for efficiency and page loading times". Thanks for the safety tip! Now can someone please explain to me why reasons that have nothing to do with efficiency and loading times are included, like "scope creep"? Where is the restriction to "relatively few" templates only? As it stands the proposal doesn't just say "think carefully before using meta-templates", it says "avoid them", period. So all this "shock" about "ignoring" the voice of wisdom seems out of proportion, and firmly stating that "I really don't care if thirty editors come on to this page to disagree" is likewise nonsense. I advise making the developers simply speak out on this once and for all, instead of having us act as their proxies to interpret the hints. Jamesday's technical description gives no indication of how badly the server load is affected in terms of how big a load we can handle. If we have no way of estimating the effects of a feature, it's silly to argue for its complete abolishment.

Again: if Jamesday had said: "I'd like you to stop using meta-templates altogether from now on, and look for other ways to do things" than that would have been that. But that's not what happened: Jamesday gave a detailed technical description of why meta-templates are a significant burden to the server. That shows they should not be used frivolously, which is good to know. This was subsequently built on to read "step away from that meta-template with your hands in the air—here are some poor alternatives". I think we're being a bit overzealous. JRM 19:44, 2005 Apr 5 (UTC)

Update: I've sent Jamesday a mail to ask him to clear up this matter in more decisive terms. We're close to starting religious wars over interpreting "divine revelation" here. Better ask the source directly. (Of course, Jamesday is quite busy, so it may take a while before we have an answer.) JRM 19:58, 2005 Apr 5 (UTC)

Of course, when putting together this page, I removed a lot of the non-descriptive text from his posts. If you want to read where he has asked us not to use meta-templates (or any template on a large number of pages), see Template talk:Sisterproject#Technical impact of templates like this and his other posts on that page. I found them quite clear on the direction he's asking us to go - away from using templates on more than a small percentage of pages and away from meta-templates specifically since they exacerbate the problem. -- Netoholic @ 20:06, 2005 Apr 5 (UTC)

We're going to use templates on more than "a small percentage of pages". That's a fact. If we shouldn't use them then they should be removed from the software. They are convenient and obvious solutions to the problem of wanting a similar set of information on more than one page. Are we sure that:

1. The alternative, individual sets of text that are independent from each other and need to be edited all by hand separately would really use less server resources? (Are templates really making the wiki more efficient, and making it easier to add info, which is the actual cause of increased workload?)
2. There is NO way to increase the efficiency of templates and meta-templates by altering the software? I haven't seen an answer to this question yet. - Omegatron 21:03, Apr 5, 2005 (UTC)

I've been looking into this a bit, and edge side includes (see http://www.esi.org/ to start with) looks quite promising (to me). I've posted a comment on User:Jamesday's talk page about this. -- Rick Block 23:53, 5 Apr 2005 (UTC)

I have gone a step further and created a new proposal that I would like to move to guideline status. See Wikipedia:Avoid using wikilinks. - Omegatron 20:21, Apr 3, 2005 (UTC)

Netoholic does not agree with the explicit stipulation on the page that there is no consensus for the proposal, describing the previous notice ("this is proposed policy") as "this notice clearly show it is not policy, while not "shutting it down" completely. There is still much support for this."

People have hammered on a more prominent notice that this is not merely proposed, but quite explicitly not policy. First of all, if there is "much support" for it, I haven't seen much evidence for that. I've counted plenty of opposers, but the supporters are remarkably unwilling to come here and talk about their objections. To top that, Netoholic has been referring to this article in justifying edits to meta-templates (this is my understanding, I haven't been involved in it), without making it clear to others that this is the situation. It all looks very authoritative when its decisive power is exactly zero.

It is disingenuous to say the least of continuously referring people to a "proposed policy" that is widely seen as problematic, without making any attempt at building consensus for it. This just gives a convenient excuse for not ever having to discuss changes on other pages, after all, you only have to refer them to this one to explain where you're coming from, right?

Stop pushing us, Neto. We know your opinion. You're entitled to it. Just don't go over our backs to promote it. The Wikipedia namespace is not a launching pad for your actions.

And everyone please stop this childish reverting. This is not getting us anywhere. JRM 17:21, 2005 Apr 5 (UTC)

I object only to the assertion that the request for guideline status "failed" after less than two weeks, and more strongly object that it can never work. Before a couple people came to this talk page and voiced pages-long diatribes on this subject, we were making progress incorporating some good feedback. I actually wish the objectors who have not will to make this into a good guideline would take a break for a while. Why do people have to live in the WikiNow by trying to cut this off at the knees? I have seen many people agree with the reasoning on this page, and apply it, though they are not as vocal as I'd hoped. -- Netoholic @ 17:35, 2005 Apr 5 (UTC)

Turning this around, why do people have to live in the WikiNow by trying this to justify decisions others soundly disagree with? Your point is well-taken, however. Let's not be overly pessimistic. I've weakened the note to meet both goals: express clearly that this is not a guideline or policy, but don't imply it will never be. Would that be more acceptable?

There's no point in continuing a discussion if you feel that those who are not providing "good feedback" are giving you "pages-long diatribes" you simply cannot have any answer to. Take a break? From what? Discrediting the fundamental assumptions on the talk page? I've said all I can say on that, really, so there's nothing to take a break from.

I have seen many people agree with the reasoning on this page, and apply it, though they are not as vocal as I'd hoped.

You are under no obligation to answer those "diatribes" by "objectors who have not the will", but anecdotal evidence of many people agreeing with you doesn't exactly sway me either. They don't have to be outspoken, but can we just get a few people here to come and say, "I basically agree with this" and leave it at that? Or take a straw poll, for that matter? Put it up for RFC? Anything? Lots of people who agree but can't seem to care about making this an official guideline are not convicing.

I cannot speak for others, but I "have not the will to make this into a good guideline" because I basically disagree with it, top to bottom. I happen to think constructive criticism, as opposed to tweaking, is a contribution too, but even if it's not, I'm not going to apologize for not turning away my head and allowing a proposal to become a guideline I don't agree with—guidelines are supposed to represent best practices. I frankly disagree that avoiding meta-templates is a good practice, as the arguments put forth haven't been convincing. And I've seen lots of "objectors", most quite vocal, but the supporters have fallen uncomfortably silent. Surely, if the objections raised here are all wrong and completely misguided, we'd like to hear so. JRM 18:08, 2005 Apr 5 (UTC)

"To top that, Netoholic has been referring to this article in justifying edits to meta-templates (this is my understanding, I haven't been involved in it), without making it clear to others that this is the situation."

Yes, he has. See Template talk:prettytable. It should be more clear on the proposal page that this is definitely not a consensus viewpoint. He had me convinced that it was, though I didn't understand why, simply by saying it was going to be turned into a guideline. - Omegatron 18:19, Apr 5, 2005 (UTC)

It seems to me that the arguments here don't actually argue against using meta-templates. What they argue against is changing meta-templates. When a meta-template changes, it's expensive. Fine. Changing something that appears on many pages is necessarily expensive for the server.

Consider the following options:

1. Lots of stub templates include the metastub template
2. Lots of stub templates subst the metastub template

Now suppose that I don't like the wording of the metastub template.

Option 1: I change it. The servers work hard for a while because it's included in a zillion pages so their cached versions are invalidated.

Option 2: I go and change each of the stub templates. The servers work hard for a while because I'm editing a whole bunch of pages. Then they work hard for a while because I've invalidated the cached versions of every page I've edited (exactly the same set of pages as above!)

So Option 2 is more work for both me and the server.

Perhaps I have misunderstood, and even without changing metatemplates, they add significantly to the server load? Otherwise I just don't see any performance advantage to taking them out.

This is not to say there aren't some awful metatemplates: the calendar metatemplates were pretty ugly (but I think that's less painful than making all the calendar templates just as ugly!). Problems with individual metatemplates are entirely possible, but when text is supposed to be the same, make it really the same. Metatemplates provide the same advantages as templates, as well as providing the same costs. --Andrew 02:40, Apr 6, 2005 (UTC)

I guess the difference is that on option 1 you are doing all the work on a single transaction while on option 2 you spread it over a number of transactions. The total work is the same, but the atomic parts of the work are smaller. Also, with option 2 you give the servers some time to recover after each change. --cesarb 02:53, 6 Apr 2005 (UTC)

On the other hand, the server needs to spend time handling individual edits, doing previews, and so forth. From the technical description, it sounds like the atomicness of the process is not very important, given the servers' willingness to serve up old pages rather than stall. The human cost, of course, is much greater or option 2; all else being equal, I'd rather the computer do the work. --Andrew 04:11, Apr 6, 2005 (UTC)

Updating isn't the only reason these are bad. As they sit, they use more resources than using separated templates. The solutions given here are to avoid using meta-templates, becuase using them creates avoidable overhead on many levels. -- Netoholic @ 03:01, 2005 Apr 6 (UTC)

What extra resources do they use? What avoidable overhead do they introduce? Not using them also has a significant human overhead; is the avoidable overhead greater? --Andrew 04:09, Apr 6, 2005 (UTC)

RTFP. -- Netoholic @ 05:41, 2005 Apr 6 (UTC)

The total work in Option 2 is almost certainly more (perhaps far, far more work for the editor and likely at least twice as much overall work for the server), however the burst of work on the server given the current implementation of templates creates an acute problem. IMO a policy of "don't use meta-templates" is not a solution, since users can (and seem to want to) create meta-templates. It is fine advice as an expedient work-around ("doctor, it hurts when I do this"), but an actual solution involving some sort of software change should be found. One draconian change might be to disallow including templates within templates. I think we can do better (edge side includes are apparently supported in squid 3). I suspect wikipedia is approaching (or is already at) the point where commercial vendors might be interested in some of its performance issues. Is this an avenue anyone has pursued? -- Rick Block 04:45, 6 Apr 2005 (UTC)