Brickwiki talk:Conventions

Here is where we discuss any long term conventions for BrickWiki. It is intended as a page for debates about the merits/not merits of certain conventions, addition of new conventions etc.

• All debates, once closed, are moved to Brickwiki:Conventions/Closed_Debates.
• In the 2012 Rebirth of Brickwiki all content remaining on this page was archived at Brickwiki:Conventions/2012 cleanup.
• Some older material from the Closed Debates section of this article was moved in 2006 to BrickWiki talk:Conventions/extraPage1.

FAQ

What do we mean by conventions?

Well, with any project involving contributions from multiple people, some standard ways of doing thing may be required. These range from the simple (how do we spell capitalise) through to the complicated (how should I make my uploaded images look). These are conventions.

Why do we need them?

Conventionalising (standardising) things means that all users can know what to do in a certain circumstance. The means that, for example, an article can link correctly and doesn't look like it was written by five people, each with their own spellings etc.

What do I do when I don't know what I should do under X circumstance?

Look through the Open Debates section here. If your question is in an ongoing debate here (meaning a solution hasn't been agreed upon), add your opinion as to what should happen. You might just push the consensus one way and finally get a solution. If your question is not being debated, start a new subsection under the Open Debates section (with two equal signs either side of the title) and write your opinion.

I don't like convention X, what do I do?

What you should not do is go to the Conventions page and just change it. Anything there should have been debated and decided upon before going there and has probably been used already by a number of users. If you really don't like an existing convention, you should move its debate section from Closed to Open and add your reason for doing so in as clear a manner as possible.

Theme Categorisation

Further to the discussion on Category_talk:Trains I would like to propose that we change the convention on theme categorization to the following:

All themes and their associated subthemes should be categorized using the [[Category:Themes]] tag to aid in navigation. If an article is an extension of the theme article (ie: about characters associated with that theme) please consider using a subpage or providing external links to appropriate resources.

I understand this is a big change but I think it is best for logical navigation rather than having two different and incompatible paths. Tedward 17:17, 1 June 2012 (CDT)

Can you elaborate on what the different and incompatible paths are? Navigation is aided if there is a web of categories. Category:Trains should contain subcategories to give better structure, but using subpages to hold related material is not a proper use of subpages in my view. The convention should NOT be changed this way in my view. (Can you give a specific diff of the discussion you're referring to?) Because of the complexity of the train subhobby and the layouts done, Trains is a very big category. It can't be crammed into one article. ++Lar: t/c 00:42, 3 June 2012 (CDT)

Good questions and comments. I am certainly not interested in deleting willy-nilly nor in losing valuable resources and certainly many (if not all) articles related to trains should stay. But I do think we need to address a couple of issues:

• NAVIGATION VIA CATEGORIES: the incompatible paths result because we have two distinct and branching paths to themes. Some themes have their own subcategory and some do not. This results in two separate areas on the category:themes page such that clicking on a sub-theme link takes you to a different list. There is no single page where all themes are listed. If we are to accept this schema then every single theme should be a sub-category and we can start arguing about which subtheme goes where. This is problematical at best as the three main sources I use (Brickset, Bricklink and Peeron) do not agree. If we simply list all themes on one page and then make cross-references in the articles it will be much easier to navigate and less arguing.
• ARTICLES ABOUT BUILDING ARE NOT ARTICLES ABOUT A THEME: I think articles on building within the train theme are not about the theme per se and thus are not really appropriate in the theme section. They should link to the train theme page obviously and they might even deserve a sub category in Category:Building with bricks but they are not articles about the theme itself. This means most, if not all the articles like Fallen Flag and BNSF which are not really about the LEGO theme could be grouped more effectively in a [[:Category:Building trains]]. Tedward 12:01, 3 June 2012 (CDT)

I don't follow what you mean about categories. An article can be in as many categories as needed. On The Big Wiki people don't necessarily use categories as the main way to get around. As for BNSF and ATSF, the story of how LEGO and BNSF decided to work together surely is a fascinating one and highly on topic. I think deleting content because you think it's tangential is a bad idea. ++Lar: t/c 22:36, 3 June 2012 (CDT)

The logical ordering of categories and the ability to navigate through a descending list is integral to an encyclopedia. This is broken here and all because the Category is wrongly labelled and categorized. What is currently labelled Category:Trains should actually be Category:Building Trains as these article are not about the theme but about building in that theme. This would allow all the articles to stay and be expanded logically and would also fix the issue with navigation/categorization. It would mean we would create other categories like Category:Building Pirates which could easily and without objection contain articles like the Pirate glossary. Tedward 10:30, 4 June 2012 (CDT)

I'm following this discussion, but likely won't have a cohesive response until after Brickworld Chicago because I'm madly working on my MOCs. Here's the gist of where I am currently: a) I sympathize with the reason for it, but I don't yet endorse the proposal. Subpages intuitively does not seem like the solution. b) in the aformentioned sites, the term theme specifically refers to the LEGO product line. However, one should be able to navigate from a theme page to an article about fans do with that theme (e.g. building with a theme). Also, BW is about more about fan-created content than TLC-created content, so a different usage may be justified. c) I don't like have a category called "building xx" for every theme xx. d) Themes are not created within a strict hierarchy, so trying to create one is problematic. However, a loose hierachy does exist. e) encylopedias are hierarchical. Wiki's are webbed *and* hierarchical. Why not let themes be both? f) the current categorization of themes is broken. g) if peeron, brickset and bricklink already document the themes, then if we also do it, aren't we venturing into What BrickWiki is not? --ALittleSlow 11:42, 4 June 2012 (CDT)

We can leave it like it is but then we will have de facto endorsed the creation of a category for any and all themes. Of course BW is about "fan-created content" including the entirely fan-created hierarchical ordering of LEGO themes. The company doesn't do it and as I have been pointing out, none of the theme hierarchies out there agree. As for your point d above, my proposal addresses the hierarchy question by removing it altogether and making all themes and subthemes equal in the BW structure. Linking and the "network" approach comes organically from the articles and each and every "Building:X" would obviously start with a link to the theme and vice versa. Tedward 12:07, 4 June 2012 (CDT)

I think having a "Building_mumble" for each theme is overkill. Instead if an article is about an official model (say someone writes an article about Airport Shuttle for a good and valid reason) then put it in the theme ("Monorail") category and in the "Official Model" category, but if it is about Joe Meno's monorail models then put it in "Monorail" and also in "Building".. Use category intersection to get more precise, not categories that are effectively sub cats by using Building as a tack on prefix. As for what the hierarchy of themes is, I'm not too sussed, any hierarchy of themes is fine with me. ++Lar: t/c 21:21, 12 June 2012 (CDT)

Heading Levels

As Lar recently pointed out, it is common practice on this wiki (on Mediawikis in general?) to avoid using the top level heading,

= xxx =

because it just looks too big Level 1 is rendered in HTML essentially as

<h1 class="mw-headline">xxx</h1>

Which means the large size could be fixed with a modicum of CSS editing. I recommend making it the same size as the 2nd-level heading, but still making it visually stronger than level 2 (perhaps using boldface or wider character spacing, and/or a heavier underline). Making level 1 available to editors gives them a bit more flexibility. More importantly (to me), if we fix the CSS to make level 1 render pleasantly, then we won't have to fix articles that use level 1, and we won't have to write a convention telling editors not to use it. --ALittleSlow 22:58, 12 June 2012 (CDT)

Interesting, I have never seen =XXX= used on BW and simply never thought to try. At this point is it feasible to change? Would someone like to right and run a script through the database that moves all instances one heading up? I think it is simply easier to include the current structure in the guidelines if needed. Has someone been using the top level heading format? Tedward 00:25, 13 June 2012 (CDT)

I see it a lot, especially on older pages. When I see it, I fix it, if I'm not too busy. I think just agreeing not to use it going forward will suffice. (and fixing it when you see it... note that it does NOT always require that everything else be shifted down one as well... sometimes it's fine for the current =x= to be at ==x==) A script is possible, but it's low priority. Let's just codify it as a standard. I'm not sure tweaking the CSS is a good idea. ++Lar: t/c 09:36, 13 June 2012 (CDT)

Agree. Tedward 11:05, 13 June 2012 (CDT)

Ok, let's just codify it, then. --ALittleSlow 12:31, 13 June 2012 (CDT)

I did happen across some discussion on this later, either on Wikipedia or MediaWiki or WikiMedia. =xxx= *is* intended to look like a title heading, and is to be used judiciously. In that spirit, modifying the CSS would have been the wrong call, and continuing in our current practice was the right one. --ALITTLESlow: t/c 10:14, 10 August 2012 (CDT)

It is always awesome when "doing nothing" turns out to be the right thing!!! ++Lar: t/c 13:34, 12 August 2012 (CDT) PS, see you in Fort Wayne?

Red links considered harmful?? NOT.

I think we should discontinue the practice of converting red links into redirects, especially ones that lead to exactly the same place as where the red link was before. This is confusing to newbies. And redlinks are an invitation to write content. Which I think we should foster. I'd rather see our energy put into getting ready to formally relaunch... ++Lar: t/c 09:36, 13 June 2012 (CDT)

That particular issue was just me jumping the gun on an effort to consolidate a bunch of stubby articles into a single article and not changing the links to headings in the main article. That has been rendered moot by another discussion so feel free to fix it. As for the title of this section, I do NOT consider redlinks harmful but I have created many pages and made edits to many that were incorrect spellings or insignificant. Using Wanted Pages as a guide to improving BW seems appropriate to me. Tedward 11:04, 13 June 2012 (CDT)

Fans, AFOLs and ALEs

Which is appropriate? Articles seem to use fan, AFOL and (to a lesser extent) ALE interchangeable. Should we standardise? Is it okay to switch? It seems that individuals are generally identified as 'AFOL', but groups are 'fans'. (I haven't done the research, though, that is just what seems to be the case to me).

I would very much like a convention, or at least a preference.... what do others think? Claude Bombarde 02:35, 10 August 2012 (CDT)

The explanatory text at Template:Fans implies fan and AFOL are intended to be interchangeable. Adult fan of LEGO gives ALE as an alternative to AFOL. I don't see a driving need to standardize. I just use "fans" where possible, thus pushing any decision off into the future.

I created the fans template to make it easier and to try to avoid the whole debate over AFOL vs ALE. The original term was AFOL. At some point an attempt was made to introduce the alternate ALE which was created, as far as I can tell, out of whole cloth based on personal preferences of some online LEGO fans rather than the natural emergence of a new term. Fans is a generic descriptor and I think that while we don't really need to impose a standard for this, If we did I would prefer to simply use the template as it stands. Tedward 12:44, 11 August 2012 (CDT)