[WikiEN-l] What to do about our writing quality?

Abd ul-Rahman Lomax abd at lomaxdesign.com
Mon May 26 03:19:01 UTC 2008


At 09:10 PM 5/25/2008, you wrote:
>Ec wrote:
> > Abd ul-Rahman Lomax wrote:
> >> There is somewhere a recommendation that Talk be refactored. Right
> >> now, what I see, everywhere I've looked, is that Talk pages are
> >> simply archived. And then the same debates occur over and over...
> >
> > Refactoring talk pages is an old notion that was already there when I
> > became involved in early 2002.  I tried it then on a couple of
> > occasions, and found it to be an incredibly difficult task.
>
>A "refactor" that I've long thought could be useful would be
>if every article (potentially) had, along with its Talk page,
>a Rationale page.  The Rationale page would explain, in as much
>details as was necessary, why the article is written as it is,
>why it says the things it says, and why it does not say the things
>it does not say.  The Rationale would evolve and change over time,
>just like the article.  The Rationale would *not* grow inexorably
>over time; it would not need archiving as talk pages do.
>(It might have an interesting history, just as articles do.)

Actually, the Rationale page, if it gets long, would be broken into 
subpages. It *would* grow. As disputes arise and are resolved, the 
nature of the dispute would be detailed -- in NPOV fashion, what 
else! -- and the consensus reached explained. Thus disputes create a 
new kind of content, content about content and how it came to be how 
it is. This would *not* create any new policy, but I'd think an 
editor wanting to change an article in a way that was tried before 
would be expected to read the Rationale page and address the reasons 
or arguments there. The point is certainly not to freeze consensus, 
but to *build* it, efficiently.

The Rationale page would be, in fact, what seems to have been 
considered at one time the function of Talk. Problem is, Talk grew 
and grew and grew, and the refactoring involved in making into 
Rationale was never done. Just more and more talk, archived, and who 
goes through all those archives before editing the article? Few, I'm 
sure, because I see the same arguments repeated over and over, and 
then someone else, maybe, if they are still editing, repeats the same 
answers, wasting everyone's time.

The Rationale page would, at least in part, be organized similarly to 
the article, and thus it would be easy to find rationale for a 
specific section of the article. One could then review the arguments, 
the sources that aren't directly incorporated in the article, etc., 
and decide if some new change really should be made. Edits to the 
Rationale page would not be signed. It's essentially an article about 
how the article came to be the way it is, NPOV, with sourcing 
requirements just like the article, except that here Wikipedia edits 
are admissible sources, and attribution of arguments may also be appropriate.

>In particular, the Rationale would not be a talk page; it would
>not have individual, ~~~~-signed entries.  It would, potentially,
>be as carefully written (rewritten and polished) as the article
>itself.  It would, in a sense, be a mirror of the article, but
>targeted at editors rather than readers.

Great minds think alike.

>Some articles are already doing this sort of thing in an ad-hoc
>way, often using subpages of the talk page.  (I'm thinking, for
>example, of [[Talk:Muhammad]] and its subpage [[Talk:Muhammad/images]],
>although that subpage is a topic-specific talk page, not a
>Rationale as I've described here.)

Subpages should be used much more often than they are. I've seen some 
wrong-headed MfDs, one was on a subpage of an article, consisting of 
sources supporting a POV. Extensive list. It was not an article, it 
was not linked from an article, it was for the use of editors. Who 
were free to turn it into a neutral page, to add notes impeaching 
sources, and all the rest. Add. Generally not delete, except for 
fraudulent citations. Thus the work that editors do accumulates and 
makes it easier for those who come later.




More information about the WikiEN-l mailing list