[Draft] Process Suggestion: EO in TR: Don't

[I was going to send this to process-issues, but then I realised it
was actually a trifling issue: there are dozens more things that one
could hassle the W3T on, especially the current rampant public
accountability issue. Moreover, so what if the W3C isn't particularly
good at writing tutorials due to process? When the W3C takes up the
role of tutorialising, it means that the public is failing, so there
must be a reason for that--that's probably at least half the reason
why W3C tutorials always seem a bit flat to me. So anyway, here's what
I was working on:]

"Each group MUST have a charter. Requirements for the charter depend
on the group type."
- 6.1 Requirements for All Working, Interest, and Coordination Groups
  http://www.w3.org/2005/10/Process-20051014/process.html#ReqsAllGroups

I suggest that there ought to be universal requirements for the
authors of charters, as well as the local requirements currently
mentioned in the process document as quoted above. Future version of
the process document should link to such universal requirements.

I further suggest that one potential starting place for universal
charter requirements is that Education and Outreach work should not be
conducted in /TR/ space. The TR process doesn't make sense with
respect to tutorialising: I believe the class of tutorials and the
class of specifications to be disjoint.

Here's my rationale for that assertion:

* Specifications are prescriptive. They define new technologies, and
as such it is important to make sure that the new technologies are
implementable. This is why there is a CR step. But tutorials are
descriptive: they describe how to use technologies defined in
specifications that already exist. The CR phrase is meaningless to
them, unless it were to be redefined as a test of how understandable
the tutorial is or something along those lines; but then that would be
a redefinition.
* Tutorials have different scope. Specifications are the reference
manuals of a technology: but though they be exacting, they must also
be clear. Indeed I would say that clarity is a necessary component of
precise specificationeering. Wherefore, then, must the tutorials
enter? Presumably, as in the case of WAI EO and SemWeb EO, because
specifications define a technology but not its usage. They're recipes
and proselytisation; they can be humourous, they can be trivial.
* Tutorials have different consumers. If I want to learn about W3C XML
Schema on a general basis, I'll read some articles about it, maybe a
tutorial. I probably won't read the specification; I don't think many
do. If I were implementing a W3C XML Schema validator, I would read
the specification. That would be my primary reference. This links back
to the scope: the consumers of tutorials are expecting casuality and
mnemonic information.

In summary of that last point, tutorials that are drafted as
specifications cannot be good tutorials because they must necessarily
lack the tone and the style of a good tutorials. Here's a concrete
example:

http://www.w3.org/TR/swbp-n-aryRelations/

I have to scroll through two screenfuls of administrivia before I get
to the content. This was previously a Working Draft, which means it
was on the REC track; now I notice that has been changed which is a
good step, but I don't think it should end up being a W3C Note either.
[@@]

-- 
Sean B. Palmer, http://inamidst.com/sbp/

Received on Monday, 13 November 2006 12:59:39 UTC