Boilerplates

Guideline	Where available, boilerplates are suggested for the creation of new content.
Add'l info	A boilerplate is like a template that suggests what a certain category of resource/page should look like.
Examples	Here is an example of a working boilerplate this page explains that site's use of them here is a list of the different boilerplates that site utilises

Discussion

I'm a huuuuuge advocate of boilerplates. They help make the wiki look really professional as a whole, and in each individual article. Potential boilerplate categories are lesson plans, tutorials, course outlines... can anyone think of types of content that would have similar parts in each article? I don't think it's necessary to have existing boilerplates when we make this guideline. They can be created later; we'll just make a note that none currently exist, would you like to create one? And we could set up a workgroup for creating boilerplates. Actually, we already have one existing boilerplate, and that's Workgroup:WikiEducator Workgroups/Team_Charter, though it doesn't appear to be ready for official use. I'm guessing it would eventually be relocated to a title that's easier to type like "Help:Workgroup charter" Wording could include something like "Where available, boilerplates are suggested for the creation of new content." and "Use {{subst:Help:BoilerplateName}} to start your project" --Jesse Groppi 01:27, 15 July 2009 (UTC)

Great idea, and I am also a huge fan of the use of boilerplates. I think this guideline should include the versioning of boilerplates. One of my frustrations has been boilerplates being "upgraded" during the lifecycle of a project... I invested a lot of development using a certain version of a boilerplate only finding it changed after a brief time away and having to make changes to already completed work so the overall design of the module(s) remain consistent. Should we include a policy for setting a boilerplate version and changes have to go through an approval process. Or the person changing the biolerplate has to make changes to ALL the content already dependent on the boilerplate???? -- Peter Rawsthorne 15:03, 24 July 2009 (UTC)

Hi Peter, Changing the pages due to a boilerplate change during a lifecycle sounds like a job for a Bot -- it should contain a link to bot accounts on the wiki. You might want to add your comments in Administrators discussion as well to help define the role of the specific WE accounts. --Kruhly 03:23, 28 July 2009 (UTC)

Peter, my thoughts on this are similar to Rob's. A well made boilerplate isn't going to change often, and should always be given due consideration over a length of time so that can be prevented. That said, if a boilerplate does change, proper categorisation makes changes via bot easy to do. We can always create a "no bot edits" category, should an author not want them made, and bot edits like boilerplate changes should always be human checked. --Jesse Groppi 18:56, 29 July 2009 (UTC)

I just created Category:Boilerplates. I had moved the Workgroup charter boilerplate to the Help: namespace (Jesse, based on your example above) and thought I should take care of categorizing it as a boilerplate while I was thinking about it.

Also, I ended up including a few sections on the charter boilerplate that might be useful to have on all boilerplates:

• Resources (or maybe this should be called "External links") for finding additional info about this kind of content
• Examples of this boilerplate in use
• About this boilerplate

--Alison Snieckus 13:00, 2 August 2009 (UTC)

Alison, great thinking on the boilerplate category; that will be very useful! In regards to other sections in the boilerplate, my specific thoughts I placed at the charter boilerplate talk page, but I'll try to recap them here, and address your specific ideas for the benefit of the guideline discussion.

The first major point is that if the boilerplate is going to be used as an inputbox preload it cannot have anything but the content you want on the page. That means no navigation, no boilerplate categories, and no documentation. This is because inclusion tags do not work with the inputbox extension. It's very sad! If you want the boilerplate linked to a category, it needs to go in the header of the talk page. That includes navigation between documents. Documentation can go in the category content, or if the boilerplate involves a policy, it can go on the policy page such as with the workgroup charter.

Resources for similar content, or facts about the boilerplate can just as easily be put into a content page about that sort of content, or in the category content. In fact, content like that may have other reasons to exist, and putting it in the boilerplate might be redundant.

Every boilerplate should include a category for its specific type of content. In this way, the list of documents using that boilerplate should match the list of articles with that type of content. If it's an issue that folks aren't using the boilerplate, another category could be created that is basically "pages utilising this boilerplate". In fact, we may want to start off that way, whilst we adapt to the new guidelines.

The information you're talking about could definitely be useful, but because of inputbox issues, it just isn't feasible now to keep it in the boilerplate page.

--Jesse Groppi 22:36, 3 August 2009 (UTC)