Diff for one approach, many benefits
Wed, 2013-05-08 13:57 by eNG1Ne | Wed, 2013-05-08 14:01 by eNG1Ne | ||
---|---|---|---|
typos | |||
Changes to Body | |||
Line 10 | Line 10 | ||
<dl>
| <dl>
| ||
<dt>responsible</dt>
| <dt>responsible</dt>
| ||
- | <dd>the information owner, the person who told me "maximum power consumption for this unit is …</dd>
| + | <dd>the information owner, the person who told me "maximum power consumption for this unit is …" and gets to carry the can if the information is wrong and the unit blacks out the entire building when you plug it in<br />
|
+ | </dd>
| ||
<dt>accountable</dt>
| <dt>accountable</dt>
| ||
<dd>in this case, the hard-working technical author who has to deliver the documentation by a certain date</dd>
| <dd>in this case, the hard-working technical author who has to deliver the documentation by a certain date</dd>
| ||
Line 16 | Line 17 | ||
<dd>possibly less important, the people who had other ideas about the power consumption … or said "I don't know, go and talk to so-and-so"</dd>
| <dd>possibly less important, the people who had other ideas about the power consumption … or said "I don't know, go and talk to so-and-so"</dd>
| ||
<dt>informed</dt>
| <dt>informed</dt>
| ||
- | <dd>in my present situtation, people like resellers who need to know when information becaomes available and when it changes</dd>
| + | <dd>in my present situtation, people like resellers who need to know when information becomes available and when it changes</dd>
|
</dl>
| </dl>
| ||
<p>
| <p>
|
eNG1Ne
one approach, many benefits
All the topics in the test project are now ready: next stage, scrutinise them to see where I can best demonstrate links and re-use. But while I'm grappling with that side of DITA, a whole new potential benefit seems to be dawning – accessible metadata.
Most of the development teams I'm working are quite comfortable with the idea of XML even if they hadn't thought about applying it to documentation. The chance of using custom attributes in the <author> element to have some idea of who provided the information is making them sit up and take notice.
For documentation, I think it makes sense to think of the classic RACI categories:
- responsible
- the information owner, the person who told me "maximum power consumption for this unit is …" and gets to carry the can if the information is wrong and the unit blacks out the entire building when you plug it in
- accountable
- in this case, the hard-working technical author who has to deliver the documentation by a certain date
- consulted
- possibly less important, the people who had other ideas about the power consumption … or said "I don't know, go and talk to so-and-so"
- informed
- in my present situtation, people like resellers who need to know when information becomes available and when it changes
A colleague has suggested the simplified RACI model XLI (eXecute, Lead, Informed); I can see this working in a software development context, but I'm not so sure it matches the documentation process.
Still, it's interesting to say how things are beginning to stir – while remembering the Chinese curse "may you live in interesting times".