Documentation is not an Obituary
Developed and presented based on an original class by Master Dafydd ap Gwystl
|Drachenwald Crown Tournament||Master Terafan Greydragon|
|19 March AS XXXIXfirstname.lastname@example.org|
This class isn't really intended as a documentation class, although it will help you develop clear, concise, intelligent documentation. It's really a philosophy class. We will discuss options and alternatives for ways of making medieval objects. Furniture, illumination, armouring, embroidery, making garb, whatever.
Why do we write documentation? Most people seem to only write documentation when they want to submit some project in an Arts & Sciences competition. This is where most people head off in the wrong direction.
Documentation as Obituary
Many people often write their documentation as an obituary. This seems to be the standard SCA method. People get an idea. They start and finish a project, and then after the project is done, they attempt to "find documentation" and write it up.
This method sucks and is a really lousy way of doing documentation. It seems that the focus is on "justification" for some judge in an A&S competition. All the writing is done only after the project is dead, and it winds up being pretty cursory. Any accumulation of skills and knowledge has little or no relation to the Middle Ages (most of the research is done after the project is dead, connected to 'documentation'). If anything is found that describes a better way things could have been done, the focus often becomes glossing over the 'error' and ignoring it, rather than using it and learning from it. People often only do the research that will provide "documentation" for whatever it was they made. Additionally, projects rarely benefit from the effort put into research and documentation, and the documentation rarely gives an objective view of the project.
Documentation as a Project Diary
A better method of project creation is to decide upon a project and then find out how such things were done in the Middle Ages. Once you have looked around, done some researching, reading, and studying, you can start recording things you learned and things you do as a sort of project diary. You will probably make conscious compromises (more about this later), but you can record those compromises and why you made those decisions. You then finish the project and record any insights you come to while making the project. Very often, while in the midst of doing something or just after finishing, you realize some very important thing that you should have done or a better way to have done it. You want to write that down as well. There are a couple of reasons for that. You either might want to make another one of those items and want to do it better, or you may wish to help someone else or teach a class on creating those items. Your notes about improvements and better ways will be a big help. Now, IF you wish to have documentation for whatever reason, you merely condense and edit your project diary.
This method doesn't suck and is a MUCH better method of project creation for several reasons. First, you spend much less time reinventing the wheel. Secondly, the project turns out much closer to a medieval object as a result of your research and investigation before you expend any energy in the creation. Third, your accumulation of skills and knowledge is more focused on the object. Fourth, your research is likely to help you with medieval techniques and will improve your ability to carry on intelligent discussion with other craftsmen about the various medieval methods and tools involved. Lastly, writing up documentation, whether for an exhibition or a competition, is very simple (mostly done already).
Describing the Problem - (What Is A Project and How do we do it)
First off, we must figure out what resources you have available. Your resources are finite. What resources are we referring to? First is Money. Second is your Time. Last, there is the "Freebies", meaning the knowledge, tools, and skills you already have.
On any project, you spend your resources on five broad categories of constraints:
Every project can be described as an allocation of your resources to the constraining categories for that project
1. Time can be swapped for Money. [Time IS Money]. If you have a lot of time, and little money, you can search swap-meets for appropriate fabric, you can barter with friends, you can use inter-library loan to get the books you can't afford, you can do lots of things to make up for a lack of funds. If you have lots of money, and little free time, you can buy labour-saving tools, hire friends to do simple time-consuming things (pay with pizza, beer, trips to events, or whatever...), buy books containing information on what you need to know, and so on.
2. The Freebies (knowledge, skills, and tools you already possess) are the ONLY things that you carry from one project to the next. As such, they are the only resource you can "store" and use over and over again. Further, note that the resources you spend on the Research and Practice constraints will increase your Freebie resources for further projects.
The Doctrine of Conscious Compromise
The Doctrine of Conscious Compromise comes from the basic knowledge that we are applying finite resources to these categories. That means some projects are impossible. For example, you probably don't have the resources to paint the Sistine Chapel; neither the time, nor the money (for that much paint), nor the skill.
It is important to remember that the SCA is a hobby. We just can't do everything as well as we want. So we make compromises. THIS IS NOT BAD! It would be unreasonable to expect anything else. We have to draw the line somewhere. So, the question becomes, "Where do we draw the line?" More specifically, "Where do we draw the lines?"
It is not important where you draw the lines, but what is important is that you choose where to draw the lines and that in doing so, you are aware of the compromises you are making. Everything is a tradeoff. If you understand that, and you understand what the tradeoffs are, then you can assign your resources to the project constraints with the assurance that you are doing the best that you can with the resources available. The only real tragedy when making a project is the ignorant assignment of resources. Examples are 40 hours spent sewing a houpellande with modern fabrics or purchasing $100 of oak that is made into a table of a non-medieval design.
Some thoughts on Documentation
A. EXAMPLE: Mead (A weak honey drink by Sir Kenelme Digbie)
B. BRIEF. One to two pages of text. Normally one page is enough. For example, if I were documenting a new recipe based on the frequency that a particular spice or combination of spices was used in 200 period recipes, then it may take a couple extra paragraphs to lead folks through my research on the combination of spices. If I am merely using Digbie's recipe, then quoting it as my primary source is adequate.
One good technique is for sections to correspond (approximately) to the constraint categories given earlier, with paragraphs at least covering Materials and Techniques & Tools. You may need to have some additional categories here, such as "artistic design" (in terms of combining certain spices in your mead) or other specific things like "lockplates" if I put one on the chest. These are sort-of an addendum
Within each section, organize the information along the lines of: a) WHAT THEY DID, b) WHAT I DID, and c) WHY THE DIFFERENCE (if any). So, for example: what kind of spices a 15th century brewer would have used; what spices I used; and why I chose those spices.
The other valuable thing to do is to read over the judging criteria. The criteria may focus on certain things that you can easily address in your documentation, but didn't remember. Have you created the project with certain "special considerations" like a rose petal wine for a new Countess?
D. FOOTNOTES. Everything you say can be split into three classes:
1. Stuff Everybody knows. "Mead is made with honey and water." Don't even bother writing this down--everyone knows it. For example: "They wore clothes!" – No one wants to read a 5 page explanation of how we know people wore clothes in the Middle Ages.
2. Stuff Somebody else said. "Mead was always made in oak barrels in England but not in France." Everything like this should be footnoted. If you didn't make it up, give credit (or blame) to the person who did. Show where you got that statement from. You ought to be talking about this in your Materials paragraph
3. Stuff you yourself made up. "it is virtually certain that my tools (pots and fermentation vessels) would have been familiar to a brewer from the early 15th century." This would be discussed in the Techniques paragraph. If you make it up, you should give enough supporting arguments that a reader can follow your reasoning.
E. ILLUSTRATIONS. Use photocopies and illustrations as necessary to illustrate your text. Some well-chosen pictures can really enhance your documentation. For example, a photocopy of the original recipe for mead, goes a long way.
F. RELATION TO THE PROJECT. It is important to keep your documentation related directly to the project. Example: If I have raised my own bees and harvested the honey from the hives, it still has nothing to do with my skill in brewing a mead. Medieval brewers often purchased their materials, and then brewed their beverage. The fact that I raised the bees has "nothing" to do with the quality of the mead I have made or the recipe I have used. So, have a few sentences about the hand-harvested honey, and focus on documentable aspects related to the recipe and brewing techniques. Provide a separate entry with documentation for the material preparation of the honey.
G. TYPICAL PROBLEMS WITH DOCUMENTATION. A survey of problems from around the knowne world reveals three main problems often seen with documentation: 1) Not describing what the item is, 2) general statements that add little (because they aren't about this specific item) and 3) Not accrediting where statements (made in the documentation) are from.
1) Start with a beginning paragraph which tells briefly what the thing IS, what it's for - and all that kind of information. A brief overview which puts the item into (a specific) historical context.
2) General statements that add virtually nothing to the documentation (and are really better in a set of class notes), rather than the specifics about the item you used as your model. Lots of documentation often has very broad and sweeping statements about parts of the project, almost as if the person is trying to teach a class on the subject, rather than documenting what they specifically did. From a recent set of cotehardie documentation we read the following paragraph:
"The cut of the sleeves varied from simple straight pieces to complex constructions, like the grande assiette cut (very wide armseyes, several gussets). Grande assiette allowed great movement of the arm, together with a tight fit, and has its best example in the Charles de Blois' pourpoint (pre-1364). Simpler variations of the cut are also traceable in the Queen Margareta's Golden gown 100 years later (slightly larger armseyes at the back, and several gussets under the arm), and the Herjolfsnes dresses from Greenland (gusset inserted at the back, behind the arm)."
The problem with this paragraph is that although it would be great in a set of class notes about cotehardies, it does not provide any information about what the person did in her cotehardie. The next paragraph is the information we are really interested in, which is what she did in the cotehardie she has submitted.
"For the sleeves, I used a pattern inspired by the Herjolfsnes cut (see picture 5). The lack of fabric resulted in piecing the sleeves from four pieces, instead of the usual one piece + one gusset. Still, the gussets are placed at the back of the arm, as in the Herjolfsnes finds and the de Blois' cote. The armseyes for my cote are slightly enlarged, but not as much as in the de Blois' pourpoint - which is the extravagant example of that fashion in the mainland Europe."
3) Documentation often contains lots of statements that sound like fact, and the problem is that it is often unclear whether the person writing the documentation is making the claim (possibly based on research the person has done), or whether some author has made the claim. (See section C above on Footnotes.) Using the same cotehardie example, we read:
"Multicoloured checks and stripes were woven using yarns of different colour as weft and/or warp. In the dyes analysed from the finds of the London excavations, there is a predominance of reds. The most common dye was madder, which produced warm brick-red, but also peach, yellow, violet, brown and tan. If it was combined with blue (woad or indigo), it gave purple or black. With yellow, it gave orange, gold or brown. Undyed wool of different shades of brown was also used."
There are several problems here. First problem: Is it relevant to this entry that you get different colors when using madder? The second problem: Where does the bold statement come from? Is the artist making this up, saying this based on the number of finds she has researched / examined, or it also from the London finds book?
Similarly, from a recent soap-making documentation example:
"The people of Britain were the first to try oils such as palm, coconut, linseed and cottonseed in soaps."
Is this statement from some source? (Example: "According to so-and-so, the people of Britain were the first ..." ) Or is the entrant making this claim and if so, based on what? (For example: "Based on the earliest evidence of non-tallow soaps being found in Britain, it seems that the people of Britain were the first ...")
These three common problems are easy to avoid if you carefully read through your documentation specifically looking for these.
New method of creating a project:
- Decide upon a project
- Find out how such things were done in the Middle Ages
- Record it as a sort of project diary
- Make conscious compromises
- Record the compromises and why you made those decisions
- Finish the project
- Record any insights you come to while making the project
- IF you wish documentation for whatever reason, merely condense and edit your project diary.
At this point, the documentation is easy to create.
Brevity is important. Typically one page of single-spaced text, possibly two for very involved or detailed projects.
Footnote everything! Footnotes can be broken down three ways. Avoid the things that everybody knows. Document the stuff that someone else said or the stuff you made up.
Format your documentation according to the constraint categories with extra categories for special things, like artistic design. Review the judging criteria for special points to address, and organize each section to cover three specific things: What THEY did, what YOU did, and WHY the difference (if any).
Keep your documentation directly related to the item you are entering.
Lastly, illustrations and photocopies can really improve your documentation by allowing others to "see" the original you were working from or trying to re-create.
Click here for a real example of documentation that needs to be improved, and one way it could be improved.
Return to the Greydragon library ...