subject: [Wikitech-l] dealing with deletions

body:
Jonathan Walther wrote:
> What is the desired behavior?  If someone creates an article that was
> previously deleted, should the articles previous history get restored?

Currently, the previous history is only restored if it is restored from
the deleted pages archive via Special:Undelete. If a new page was since
created with the title, the old revisions are simply integrated into the
existing history (generally at the end -- but if the new page was
renamed from an older title, it's possible that the histories could
intermix when presented sorted by date).

Here's a diagram of what exists in what tables over the lifetime of such
an event:

Page creation:
rev A -> cur

Later edit:
rev B -> cur
rev A -> old

Deletion
rev B -> archive (hidden)
rev A -> archive (hidden)

New creation with same title:
rev C -> cur
rev B -- archive (hidden)
rev A -- archive (hidden)

Later edit:
rev D -> cur
rev C -> old
rev B -- archive (hidden)
rev A -- archive (hidden)

Restoration of deleted revisions:
rev D -- cur
rev C -- old
rev B -> old
rev A -> old

Since deletions are usually done to suppress vandalism or unusuable text
due to copyright infringement, there would be little use in
automatically restoring such revisions.

-- brion vibber (brion @ pobox.com)


list: wikitech-l

source: pipermail-mbox

from_name: Tomasz Wegrzanowski

subject: [Wikitech-l] TeX

body:
Here is first version of TeX rendering extension to Wikipedia.
It's not production code yet.

Please comment.

= How does it work =

New preference is introduced which says whether to:
* always render images as PNGs
* render them as HTML if they are simple enough, or as PNGs otherwise.
* leave them as pseudo-TeX (mainly for text browsers where neither PNG
  nor HTML rendering would be visible)

ISSUE 1: While HTML reduces bandwidth, it is much uglier, so default is PNG-only.
ISSUE 2: PNGs are rendered with "a bit too big" font. That's on purpose.
         A big too big works well in big and medium resolution, and is still readable
	 in small resolution. But "a bit too little" with big resolution would be very
	 hard to read.

Also new table is introduced:
CREATE TABLE math (
    math_inputhash char(32) NOT NULL,
    math_outputhash char(32) NOT NULL,
    math_html text NOT NULL,
    UNIQUE KEY math_inputhash (math_inputhash)
);

math_inputhash is MD5 of input markup, math_outputhash
is MD5 of output markup, math_html is HTML rendering or ""
if it's too difficult for HTML.

ISSUE 3: MD5 should be stored in binary in final version.

OutputPage.php calls renderMath() for every occurence of <math></math>
in code. If user decided he likes pseudo-TeX, then that's the end.
Otherwise it checks in database whether it is already rendered or not.
If it is, then it either takes HTML or generates link to image.

ISSUE 4: Directory for math images should be configurable and it should be
	 also known to texvc (command line ? compilation option ?).
	 It should not be upload directory.
ISSUE 5: Maybe it should use a/ab/ab*.png like other images. Or maybe
	 Wikipedia servershould move to reserfs.
ISSUE 6: Image should have ALT= tag

If image/html isn't generated yet, texvc is called. If it fails, message
is generated.

ISSUE 7: this message should be localized.
ISSUE 8: texvc shouldn't be in cgi-bin or care should be taken it can't
         be called with any evil options.

Depending on return value of texvc results are generated and put into table
for caching.

ISSUE 9: failures are not cached. In final version they should be cached,
         but cleaned on every upgrade of texvc (which may support more
	 TeX than previous version).

Now texvc takes input in first argument.

ISSUE 10: I'd rather use stdin but proc_open (popen2 for perl hackers) appears
	  only in PHP 4.3, but PHP 4.2 is still the standard

Then it LALR-parses it. What it parses is not real TeX. If HTML contains &foo;
and TeX doesn't, this preudo-TeX will contain \foo anyway. This ensures
that it's very easy to use.

Then it is standarized and md5 of standarized version computed.

ISSUE 11: race condition of 2 runs of texvc trying to generate the same PNG,
	  will have to be investigated
ISSUE 12: texvc should check here whether output PNG already exists (HTML is fast
	  to generate so it doesn't hurt to regenerate it). It may happen not only
	  in case of race condition, but also if it was generated from different
	  input markup (say from "x + y", and we do it from "x+y" now)

Then it prints md5 and HTML (if any) on stdout.

ISSUE 13: PHP should not wait for texvc to finish from this point. texvc should
	  probably fork() here.

Now latex, dvips and convert (which in turn uses ghostscript) are called.

ISSUE 14: Latex creates some temporary files. They should be created in some
	  tmp/ directory, not in current directory.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tex.diff.gz
Type: application/octet-stream
Size: 6074 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20021201/aca3aa6b/attachment.obj>


subject: [Wikitech-l] TeX

body:
ISSUE 15: texvc is written in Ocaml

Ocaml is best available language for writing interpreters for special
purpose languages because:
* it is really fast, comparable in performance to "traditional" compiled
  languages with GC like Java, and in cases where GC doesn't introduce
  much overhead, to C/C++
* it doesn't segfault
* it has yacc/lex
* it has advanced symbolic processing functionality
* it can do a lot to ensure correctness of programs and programs in Ocaml
  are very easy to reason about (texvc doesn't contain single variable)
* programs can be written at much higher level, so developement is faster,
  yet low level functionality is also available if needed.

I hope this explanation in enough for you.

To learn more about Ocaml visit Polish Wikipedia, in particular:
http://pl.wikipedia.org/wiki/Ocaml
http://pl.wikipedia.org/wiki/Ocamlyacc

ISSUE 16: this pseudo-TeX is very incomplete. Please tell me what
          functionality do you need (sums/integrals come to mind ...).

ISSUE 17: texvc uses double-dollar math, not single-dollar math. It
	  uses more space but looks nicer.


from_name: Jens Frank

subject: [Wikitech-l] more on namespaces

body:
On Sat, Nov 30, 2002 at 11:36:04PM -0800, Jonathan Walther wrote:
> Namespaces appear to exist so that actual encyclopedia articles can be
> distinguished from everything else. Instead of namespaces, could
> Wikipedia live with a flag that said "This is an article" for each
> article?
>
What is the problem you have with namespaces? Namespaces provide
much more information than a binary article/no article. Page layout
is different for talk than for user pages: User pages have links
like "user contributions". Talk pages have not. And image-pages
bevave very differently to the above. That's why there are namespaces.

JeLuF


subject: [Wikitech-l] TeX

body:
On Sun, Dec 01, 2002 at 02:00:26AM +0100, Tomasz Wegrzanowski wrote:
> Here is first version of TeX rendering extension to Wikipedia.
> It's not production code yet.
>
> Please comment.

Hello taw,

just looked into your diff. Making HTML-rendering an option is
a good idea.

One thing I would strongly propose to change:

function renderMath( $matches )
{
   ...
       $pid = popen ("./math/texvc \"{$tex}\"", "r"); # texvc shouldn't be in cgi-bin

This allows nasty attacks before the TeX-code is validated. Let, for
example, $tex be $(find / -type f|xargs rm)
Then popen starts a shell to start the program and its parameters are expanded by
the shell. A lot of nasty things could be performed this way.

Workaround:
a) use a bi-directional proc_open and put the $tex via stdin
b) create a file with the md5-hash as filename.

Workaround (a) is currently not available in standard PHP.

Regarding funtions to be provided:
\mbox
\sum
\int
\left, \right
\infty
blackboard letters
\sin, \cos, \lim, \log, ...

This OCAML looks funny, I think I will have to dig deeper into it before
commenting it :-)

	Regards,

		JeLuF


list: wikipedia-l

from_name: Anthere

subject: [Wikipedia-l] Vandalism spree

body:
Vandalisme :

N'oubliez pas de mettre un message sur la liste
fran?aise en cas de vandalisme : plus de chance
d'attraper un sysop non actif sur la wikip?dia

Eventuellement, mettre aussi un message ? Tarquin sur
la wikip?dia anglaise, il peut s'y trouver et venir
aider ? bloquer les ip

Aussi, en cas de submergement, mettre un message sur
la main liste pour demander de l aide ? la r?version

Peut-etre mettre un mot sur la wikitech si il est
n?cessaire de bloquer un vandale logu?

Oui, il faut que plus de personnes prennent le status
sysop pour aider en cas de pb

N?anmoins cela ne changera rien en cas de vandalisme
logu?, ou en cas de vandalisme aux heures creuses.

Heureusement que Shai etait la...

http://www.wikipedia.org/pipermail/wikipedia-l/2002-November/007713.html

ant

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


subject: [Wikipedia-l] Vandalism spree

body:
Brion,

Quand un utilisateur a ?t? bloqu?, pourquoi son ip
apparait t elle toujours avec (bloque) dans les recent
change ???
La seule facon de savoir si il est effectivement
bloque est d aller voir sur la liste des adresses
bloquees. C est une perte de temps. Il faudrait
pouvoir voir directement dans les recent changes si
une ip a ?t? bloqu?e en aval ou pas.

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


subject: [Wikipedia-l] Vandalism spree

body:
Please, could so promote some sysop for the fr.wiki
and come help...I cannot stay...and shai is the only
sysop to be avail

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


list: wikien-l

from_name: Tucci

subject: [WikiEN-l] Re: WikiEN-l digest, Vol 1 #25 - 9 msgs

body:
> You forgot a vital piece of information. By which
> user name do you want sysop
> user rights? Tokerboy or Tucci528 (I assume Tokerboy
> since that is the user
> name you seem to be using these days).

Tokerboy, definitely.  I only used Tucci528 before I
could think of anything better (I'm indecisive).

I was out of town for a few days, and I thought for
sure I'd have about a million digests waiting for me.
Turns out there were three, so I guess I'm not the
only one who was vacationing from wikipedia during Thanksgiving.

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


from_name: Jason "Rodzilla" Rodzik

subject: [Wikipedia-l] Subpages

body:
As a possible alternative to implementing this on wikipedia.org, would
anyone be willing to work on implementing this on your own and distributing
the code changes, but not implementing it in CVS?

---------------------------------------------------
Jason "Rodzilla" Rodzik
Seriously! Owner & Director of Operations
http://www.seriouszone.com

----- Original Message -----
From: "Jonathan Walther" <krooger at debian.org>
To: <wikipedia-l at wikipedia.org>
Sent: Saturday, November 30, 2002 7:31 PM
Subject: Re: [Wikipedia-l] Subpages


list: sifter-l

source: wayback-mbox

subject: [Sifter-l] Opinions

body:
:There are a few basic principles too that sound
:plausible to me:
:* Approved articles must not be known to contain
:errors, and any
:  questionable factual assertions must be checked.
:* Biased articles (per either or both of Wikipedia's
:and Nupedia's
:nonbias
:  policies) should not be posted.
:* The content should be accessible to the people who
:might actually
:need
:  the article.  So some of Axel's math articles need
:not be accessible
:to
:  me, but they should be accessible to undergrads
that :study the stuff.
:* The content should be of reasonably high quality
:from a professional
:  point of view.  Would you be embarrassed for the
:leaders in your
:field
:  to see this article as an allegedly authoritative
:statement about
:this
:  subject?

The only thing I would add to this is the citation of
sources for at least some types of articles.  A lot of
the sciencey-type stuff probably doesn't need sources
unless it's controversial.

I fear that this could become useless if we aren't
somewhat strict about accepting reviewers.  Ideally, I
think, the way it should wind up working one year from
now is that, for example, a science team approves
science articles.  If an active Wikipedian applies to
the science team, the team looks over what he's done
on Wikipedia and either approves or does not.  Once it
becomes necessary, the science team could split into
geology, meteorology, physics and whatever (in
reality, a "science" team is probably too broad to
even begin with, but it's a good example).  It could
become as specific as necessary or useful.  So, the
music team can split into jazz, disco and heavy metal
as needed.  Then, if needed, the heavy metal team
could fork into death metal or nu-metal or even an
Iron Maiden team if it becomes necessary or useful.

That's my thoughts.  The only question is how to reach
that point, how to gather that first "music" or
"science" team members and assure that they are useful
people.

I also like the idea of having copyediting separate
from fact-checking.  Specifically, a box next to
"import this article" (unchecked by default) and an
easily accessible status of "copyeditor" to find a
list of articles that need to be copyedited.  The only
absolutely final articles should be ones that are
approved in both ways, factually and
stylistically/grammatically.

Tokerboy

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


subject: [Wikitech-l] TeX

body:
On Sun, Dec 01, 2002 at 09:22:14AM +0100, Jens Frank wrote:
> One thing I would strongly propose to change:
>
> function renderMath( $matches )
> {
>    ...
>        $pid = popen ("./math/texvc \"{$tex}\"", "r"); # texvc shouldn't be in cgi-bin
>
>
> This allows nasty attacks before the TeX-code is validated. Let, for
> example, $tex be $(find / -type f|xargs rm)
> Then popen starts a shell to start the program and its parameters are expanded by
> the shell. A lot of nasty things could be performed this way.
>
> Workaround:
> a) use a bi-directional proc_open and put the $tex via stdin
> b) create a file with the md5-hash as filename.
>
> Workaround (a) is currently not available in standard PHP.

PHP has standard function that escapes shell metacharacters,
exactly for this purpose.

I just forgot to put it there.


from_name: tarquin

subject: [Wikipedia-l] the "changes starting from ..." link

body:
well done to whoever thought of this one.
I didn't get it at first -- but then it dawned on me how useful this is
-- each time you click on it you get only changes you haven't seen yet.
the best thing is this: when you sign off from the pedia, go to your
open RC page, and drag that link up to the bookmarks bar. You now have a
link to pick up exactly where you left off ready for next time you log on.

cool stuff! :-)


from_name: Axel Boldt

subject: [Wikitech-l] TeX

body:
I wonder if it would be beneficial to skip the external parsing step
and leave all parsing to TeX. The advantage would be that all TeX
functionality is immediately available without any additional work,
including macro packages such as those for
* commutative diagrams and graphs (xypic)
* chemical structure formulas (chemtex)
* music scores (musictex)
* chess diagrams

There is no safety issue, since TeX can be made to run safely so that
no shell processes can be called and only the standard files can be
generated.

The only disadvantage I see is that we would lose the optional HTML
rendering of formulas. While I like that feature, I think we can live
without it: most advanced formulas cannot be rendered in HTML anyway,
and those that can should probably be written in HTML in the first
place to be nice to anonymous users with non-graphical browsers.

Axel

---
Payment: http://www.wikipedia.org/wiki/K%F6nig%27s_lemma

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


subject: [Sifter-l] Copyediting: First Thoughts

body:
Dear Larry and Fellow-sifters,

     Larry presented two options for copy editing the Sifter articles. He wrote:

1. Use "the honor system," where we have reviewers say that they have
*thoroughly* copyedited the article, or, if they're not sure they can do
an excellent job at that, they've had someone else who is copyedit it.
We might just add a checkbox to the article import routine (default would
be unchecked) labeled "I have thoroughly copyedited this article, or I am
satisfied that someone else has already done so."

2. Designate a new category of worker in the system, the copyeditor.
Reviewers could be copyeditors, and in that case, any article uploaded by
the reviewer would automatically be posted.  But in cases where reviewers
are not copyeditors, the reviewer could only upload the article into a
staging area where articles would have to be approved--again, just the
press of one button--by *any* copyeditor, before being posted.

Now that I've spelled out these two options, I already favor option 1, as
long as we had set up some page on Wikipedia, on the new project, or via a
special mailing list whereby reviewers could let it be known to
copyeditors that a given article needs to be copyedited *now*.

     I have considered both options, as well as others, and see both strengths
and weaknesses in both of Larrys options. Option 1 and option 2, presented
above, are actually not that different. For me, it boils down to whether we
hold the reviewer responsible for review and copy edit (option 1) or we hold
the reviewer responsible for review only and copyedit only if he/she can and
wants to (option 2.)

     I realize I am writing to a group where members may have very little
knowledge of Nupedia. In Nupedia, articles go through 3 steps in the review
process and 3 more in the copy edit process. In each of these 6 steps, a
particular part of the review or copy edit process takes place. It is easy to
see how articles can get stuck in any of these 6 steps.
     Larrys present proposal for Sifter has either one or two steps for each
article to pass through, where the step/steps are to be accomplished by Sifter
members. Then, either option presents a great reduction in processing and
potential bottlenecks. However, the Nupedia processing does have a rationale
for having so many steps in it. The idea was that, if an article is reviewed
for content by 2 experts and then the whole membership, and, then, reviewed for
style, grammar, etc. by 2 dedicated copy editors and finally by the whole
membership, article quality should be very high and the chance of error should
be very small.

Potential problem with option 1:
     Sifter option 1 leaves all the responsibility for content and copy edit
with one individual. Sifter option 2 leaves this responsibility with 1 or 2
individuals, for the most part. I, for one, am a little wary of leaving so much
responsibility with one individual, as proposed in option 1. Note, that under
option 2, one can get the same result  one person responsible for review and
copyedit.

Potential problem with option 1:
     Further, we will have to recruit these reviewers, in most cases. Although
they may already be members of wikipedia or nupedia, they may be new. Aside
from their function as reviewers, they will eventually have to learn the wiki
mark-up and HTML (if they dont know it) to make changes. Under option 1, they
will also have to either copy edit or approve their copy editors work; this
may be more work than it seems. I would not like to see reviewers signing up
enthusiastically, to find many of them resigning over their first article,
because they had no idea how much work was involved.

     So, in summary, I guess I lean toward option 2, because it allows
reviewers to do it all, review and copyedit, or to do the review and let a
copyeditor be responsible for the copyedit.

     There is at least one other problem involved in introducing copyedit. In
Nupedia we have standards for copy edit in our policy statement as well as a
requirement for copyeditors to have two reference books. These books establish
copyedit standards in great detail. In Wikipedia, I am not aware of any set of
standards for copyedit, in the same kind of detail. For example, almost all
articles in Nupedia are required to have a For Further Reading section, with
suggestions for books to read to learn more on the subject. And, the For
Further Reading section is required to be in a particular format. Such
standards add a professional and polished look to articles and are found in
most encyclopedias. Do we want such standards and, if so, how are we going to
establish and implement them?

     Well, these are my first thoughts on introducing copyedit into the Sifter
process and the two options presented by Larry. Clearly, there is a third
option of having reviewers only review and copyeditors, only copyedit. This
option guarantees another step in complexity of the sifter process, but insures
that responsibility for processing an article is shared by two people.

     It seems that each discreet step one adds to the Sifter process is an
opportunity to improve our product, but also a place where unforeseen problems
can develop. For this reason, I can't say definitively that option "x" is
better.

     I hope this is some help to other members in considering the options
available for copyedit.

                                  As Ever,

                                     Ruth Ifcher

--


subject: [Wikipedia-l] Helga banned

body:
On Sat, Nov 30, 2002 at 11:21:29AM -0800, Toby Bartels wrote:
> Eclecticology wrote:
>
> >Vicki Rosenzweig wrote:
>
> >>Helga is back on the Wikipedia (see the user talk for H. Jonat). As far as
> >>I can tell, she was banned on September 9, for three months. Have I missed
> >>an announcement, or is this return without Jimbo's knowledge/assent?
>
> >If she's here that's a fact.  The arbitrary 3-month period should not be
> >treated so significantly.  What's really important is her behaviour from
> >now forward.  Dwelling on her past sins doesn't help anybody.
>
> There is the issue of the integrity of banning procedures.
> She can only have been unbanned by an administrator,
> and there was discussion earlier on the list that her time was about up.
> I suspect that somebody simply messed up the timing.
> If this is correct, and there was no subversion of the process,
> then you're right, we should concentrate on her behaviour now.
> But if she did an end run on the system (and Jimbo's wishes) somehow,
> then that shouldn't be rewarded.

I think Jimbo unbanned her. But I think it was a fault. Frau Jonat is
doing what she's done before (List in no particular order):

* Shows disrespect against the Polish national border:
http://www.wikipedia.org/w/wiki.phtml?title=Wolin&diff=452458&oldid=452448

* reverting articles to a status that was considered
  wrong by other experts, without providing prove or
  arguments for her position
http://www.wikipedia.org/w/wiki.phtml?title=Boleslaus_I_of_Poland&diff=456005&oldid=443686

* Changing articles from NPOV
http://www.wikipedia.org/w/wiki.phtml?title=History_of_Lithuania&diff=456047&oldid=452553

* Articles which do not cover the subject
http://www.wikipedia.org/w/wiki.phtml?title=Galindan_language&oldid=456004

JeLuF


subject: [Wikitech-l] TeX, version 2

body:
Version 2:
* it doesn't generate PNG if it already exists
* it supports more TeX
* TeX used as a shell argument is escaped properly now

ISSUE 18:
Escaping from further passes is very important.
Following things must me protected from interpretation:
* TeX markup if uses choses "leave it as TeX" mode
* contents of alt= tags
* Messages saping that some TeX couldn't be generated.

Should I just generate unique character strings like <nowiki> does ?

ISSUE 19:
I'm not sure if \mbox is right thing to have.
Isn't it meant to do things other than math ?
I'm no TeX expert so please comment.

ISSUE 20:
How ugly HTML will we allow ?

Sums and integrals in HTML will be redable but extremely ugly.
Well, we could implement more sophisticated HTML rendering algorithms,
for example using a table for that.

But I'm not sure if it's worth the effort.

ISSUE 21:

I'm using:
http://www.fi.uib.no/Fysisk/Teori/KURS/WRK/TeX/symALL.html
http://pl.wikipedia.org/wiki/Encje_HTML

to get list of things we should support.

Is there some better list ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tex2.diff.gz
Type: application/octet-stream
Size: 6792 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20021202/89e0db3e/attachment.obj>


from_name: Ray Saintonge

subject: [Wikipedia-l] Helga banned

body:
Jens Frank wrote:

>I think Jimbo unbanned her. But I think it was a fault. Frau Jonat is
>doing what she's done before (List in no particular order):
>
>* Shows disrespect against the Polish national border:
>http://www.wikipedia.org/w/wiki.phtml?title=Wolin&diff=452458&oldid=452448
>
>* reverting articles to a status that was considered
>  wrong by other experts, without providing prove or
>  arguments for her position
>http://www.wikipedia.org/w/wiki.phtml?title=Boleslaus_I_of_Poland&diff=456005&oldid=443686
>
>* Changing articles from NPOV
>http://www.wikipedia.org/w/wiki.phtml?title=History_of_Lithuania&diff=456047&oldid=452553
>
>* Articles which do not cover the subject
>http://www.wikipedia.org/w/wiki.phtml?title=Galindan_language&oldid=456004
>
I've reviewed these articles, and although some of the changes seem
debatable, or involve exchanging one POV for another, that is nothing
unusual in the thrust and parry of debate.  To say that adding the
single word "current" to "Polish border"  is a disrespect of Polish
borders  makes arguments out of nothing.  The addition is at worst a
redundency of trivial importance.

If temporary bans are to have any value, fair-mindedness demands that
when the offender returns to the community her contributions be judged
with the same objectivity that would be applied to any other
contributors.  There is no need to look at her contributions through a
microscope for every tiny point that you may find offensive.  If you
look hard enough you can find that in anybody's contributions.

Eclecticology


from_name: Brion Vibber

subject: [Wikitech-l] Vandalism

body:
On Mon, 2 Dec 2002, Guillaume Blanchard wrote:
> Hello everybody there.
> Yesterday (sunday, december 1st) the french wikipedia was attacked by a
> vandal bot (Iala'29899).
>
> Luck for us, at the time the bot attacked there were some sysops logged on
> the site and they were able to block the 10 successive IP address it used.
> We are worring about new attack and we though about some idea to prevent
> vandal to make hell on Wikipedias:

The same had hit Meta, Esperanto, and German wikis a few hours earlier
(using randomly titled pages, easily deletable); I cleaned them up and put
a note in the English vandal-watch page (ie, the biggest audience of
active users) asking people to keep an eye open for more activity while I
was asleep.

> - Display already blocked address in RecentChange in a different way (bold?
> italic? different color?) to be able to see quickly witch address was
> already blocked and witch are not yet.

Could be done.

> - Allow Sysop to have an easy way to block a logged user (in RecentChange if
> possible).

Hmm, right now it would be fairly easy to set it up to ban a username, but
they could still log out and continue with the raw IP or a new username,
which you'd have to block separately again...

> - Send warning mail to Sysop (who solicited it) when a user modify some
> pages in strange ways (articles size seriously reduced, too many articles
> modify in a short laps, ...)

Hmm...

> - Provide a tool to repair the dommage. Reverse action of a user/IP from
> "date/time 1" to "date/time 2".

In the works, not done yet.

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] TeX

body:
On Sun, Dec 01, 2002 at 05:06:06PM -0800, Axel Boldt wrote:
> I wonder if it would be beneficial to skip the external parsing step
> and leave all parsing to TeX. The advantage would be that all TeX
> functionality is immediately available without any additional work,
> including macro packages such as those for
> * commutative diagrams and graphs (xypic)
> * chemical structure formulas (chemtex)
> * music scores (musictex)
> * chess diagrams
>
> There is no safety issue, since TeX can be made to run safely so that
> no shell processes can be called and only the standard files can be
> generated.
>
> The only disadvantage I see is that we would lose the optional HTML
> rendering of formulas. While I like that feature, I think we can live
> without it: most advanced formulas cannot be rendered in HTML anyway,
> and those that can should probably be written in HTML in the first
> place to be nice to anonymous users with non-graphical browsers.

∞

∫x2 dx

0

3
 - π

2π

Ok. That was silly.
But you can see a diference between "possible to do in HTML"
and "sane to do in HTML" now.

Now back to topic. texvc's markup is not really TeX or some subset of it.
It is pseudo-TeX that is much nicer to write. It fixes all the usual
problems (%, &foo; not having \foo counterpart, some {}-ing issues),
and provides us with full information that we can use for many purposes,
rendering HTML being one. But it could also be extended to render ascii-arts
MathML or really awesome HTML code like one in previous example.
And from other side too, to accept other kinds of math markup (OpenOffice
math markup has been suggested).

I'm not completely sure about safety. Probably we should both validate and
run TeX in safe mode.

texvc is extremely easy to extend. It shouldn't take too much time just to
add a few dozens of new tags, and a night or two should be enough for
completely new kind of markup, be it chemistry (which certainly should be added),
chess, music or whatever.

Payment: http://pl.wikipedia.org/wiki/Rezolucja


subject: Re: [Sifter-l] Copyediting: First Thoughts

body:
As someone with editorial duties for a number of journals in my subject
areas, I would like to remind the group of the importance of reviewers in
this process.  I think that Rose is correct; some type of independent
review/copy-editing process needs to be in place.  The first thing I see
when I review articles for my editorial duties is the lack of simple
English writing structure skills that most people have, and if we want this
project to be validated, used, and referenced, then we need to make the
articles as readable and professional as possible.  Just my two cents'
worth.

Brad

                    rose.parks@att.n
                    et                      To:     sifter-l@nupedia.com
                    Sent by:                cc:
                    sifter-l-admin@n        Subject:     [Sifter-l] Copyediting: First Thoughts
                    upedia.com

                    12/01/02 12:17
                    PM

Dear Larry and Fellow-sifters,

     Larry presented two options for copy editing the Sifter articles. He
wrote:

1. Use "the honor system," where we have reviewers say that they have
*thoroughly* copyedited the article, or, if they're not sure they can do
an excellent job at that, they've had someone else who is copyedit it.
We might just add a checkbox to the article import routine (default would
be unchecked) labeled "I have thoroughly copyedited this article, or I am
satisfied that someone else has already done so."

2. Designate a new category of worker in the system, the copyeditor.
Reviewers could be copyeditors, and in that case, any article uploaded by
the reviewer would automatically be posted.  But in cases where reviewers
are not copyeditors, the reviewer could only upload the article into a
staging area where articles would have to be approved--again, just the
press of one button--by *any* copyeditor, before being posted.

Now that I've spelled out these two options, I already favor option 1, as
long as we had set up some page on Wikipedia, on the new project, or via a
special mailing list whereby reviewers could let it be known to
copyeditors that a given article needs to be copyedited *now*.

     I have considered both options, as well as others, and see both
strengths
and weaknesses in both of Larry's options. Option 1 and option 2, presented

above, are actually not that different. For me, it boils down to whether we

hold the reviewer responsible for review and copy edit (option 1) or we
hold
the reviewer responsible for review only and copyedit only if he/she can
and
wants to (option 2.)

     I realize I am writing to a group where members may have very little
knowledge of Nupedia. In Nupedia, articles go through 3 steps in the review

process and 3 more in the copy edit process. In each of these 6 steps, a
particular part of the review or copy edit process takes place. It is easy
to
see how articles can get stuck in any of these 6 steps.
     Larry's present proposal for Sifter has either one or two steps for
each
article to pass through, where the step/steps are to be accomplished by
Sifter
members. Then, either option presents a great reduction in processing and
potential bottlenecks. However, the Nupedia processing does have a
rationale
for having so many steps in it. The idea was that, if an article is
reviewed
for content by 2 experts and then the whole membership, and, then, reviewed
for
style, grammar, etc. by 2 dedicated copy editors and finally by the whole
membership, article quality should be very high and the chance of error
should
be very small.

Potential problem with option 1:
     Sifter option 1 leaves all the responsibility for content and copy
edit
with one individual. Sifter option 2 leaves this responsibility with 1 or 2

individuals, for the most part. I, for one, am a little wary of leaving so
much
responsibility with one individual, as proposed in option 1. Note, that
under
option 2, one can get the same result ? one person responsible for review
and
copyedit.

Potential problem with option 1:
     Further, we will have to recruit these reviewers, in most cases.
Although
they may already be members of wikipedia or nupedia, they may be new. Aside

from their function as reviewers, they will eventually have to learn the
wiki
mark-up and HTML (if they don't know it) to make changes. Under option 1,
they
will also have to either copy edit or approve their copy editors' work;
this
may be more work than it seems. I would not like to see reviewers signing
up
enthusiastically, to find many of them resigning over their first article,
because they had no idea how much work was involved.

     So, in summary, I guess I lean toward option 2, because it allows
reviewers to do it all, review and copyedit, or to do the review and let a
copyeditor be responsible for the copyedit.

     There is at least one other problem involved in introducing copyedit.
In
Nupedia we have standards for copy edit in our policy statement as well as
a
requirement for copyeditors to have two reference books. These books
establish
copyedit standards in great detail. In Wikipedia, I am not aware of any set
of
standards for copyedit, in the same kind of detail. For example, almost all

articles in Nupedia are required to have a "For Further Reading" section,
with
suggestions for books to read to learn more on the subject. And, the "For
Further Reading" section is required to be in a particular format. Such
standards add a professional and polished look to articles and are found in

most encyclopedias. Do we want such standards and, if so, how are we going
to
establish and implement them?

     Well, these are my first thoughts on introducing copyedit into the
Sifter
process and the two options presented by Larry. Clearly, there is a third
option of having reviewers only review and copyeditors, only copyedit. This

option guarantees another step in complexity of the sifter process, but
insures
that responsibility for processing an article is shared by two people.

     It seems that each discreet step one adds to the Sifter process is an
opportunity to improve our product, but also a place where unforeseen
problems
can develop. For this reason, I can't say definitively that option "x" is
better.

     I hope this is some help to other members in considering the options
available for copyedit.

                                  As Ever,

                                     Ruth Ifcher

--

_______________________________________________
Sifter-l mailing list
Sifter-l@nupedia.com
http://www.nupedia.com/mailman/listinfo/sifter-l


from_name: Toby Bartels

subject: [Wikitech-l] Vandalism

body:
Brion Vibber wrote:

>Guillaume Blanchard wrote:

>>- Allow Sysop to have an easy way to block a logged user (in RecentChange if
>>possible).

>Hmm, right now it would be fairly easy to set it up to ban a username, but
>they could still log out and continue with the raw IP or a new username,
>which you'd have to block separately again...

If we block the raw IP, then the logged in user is also blocked.
So what we really need is a way to see the IP of a logged in user.
(No additional blocking functionality is needed, just IP viewing functionality.)

If moreover changes are tracked by IP as well as user name
(I believe that these are already separate entries in the database tables),
then we could track the effects of our bans better
(in the case of dynamic IPs that might be used by good logged in contributors)
by seeing *all* the contribs by an IP, not just anonymous contribs.

-- Toby


from_name: Larry Sanger

subject: Re: [Sifter-l] Reply-to trap

body:
On Mon, 2 Dec 2002, Poor, Edmund W wrote:

> Please fix the reply-to, so that when users like me and Magnus click
> the "Reply" button in our e-mail software, the "to" line includes the
> sifter-l@nupedia.com address.

Done!

Larry
--
"We have now sunk to a depth at which the re-statement of the obvious is
the first duty of intelligent men." --George Orwell


subject: Re: [Sifter-l] Copyediting

body:
On Sat, 30 Nov 2002 rose.parks@att.net wrote:

>      In the mean time, I have a question about the "sifter" process. I
> am told that when a reviewer selects an article for "sifter," if the
> reviewer wants to make any changes before approval, they will make
> them on wikipedia. My question is, how do we assure that the chosen
> article remains stable in wikipedia, while the reviewer makes his/her
> changes?
>      Due to the strange mixture of mark-up in wikipedia, it seems a
> reviewer can only check his/her change/changes from within wikipedia.
> Never the less, it doesn't make sense to leave the article
> "unprotected" while the reviewer works; he might find an article
> changed by another wikipedian, while he/she is reviewing it. Worse, in
> time, as wikipedians become aware that the sifter process is going on
> in a particular article, some wikipedian, looking to cause trouble,
> may really mess up an article being reviewed. Shouldn't the review
> process be protected?

It doesn't look like anyone has replied to this, but I think it's
reasonably important.  Wikipedians know that when one starts vigorously
editing an article, others often join in.  Moreover, we might very well
want to make some sort of special announcement mechanism whereby reviewers
can tell Wikipedia that a certain article is impending, "...and please
make your changes sometime soon!"  (The mechanism might just be a special
wiki page, or a special "sifter" page.)

Either of these things will tend to mean that, while making final edits, a
reviewer might also have to take account of other people's edits.
Possibly other reviewers' edits.  I'm sure at least some editors would be
bothered by that situation--they'd prefer to work alone in peace, and deal
with comments and new changes *after* the actual button-pressing
(approval) is finished.

I can tell you from my own experience that when I'm working on an article
and making extensive changes, I'll put a special notice on the Wikipedia
edit summary line: "Changes in progress, please don't edit."  I don't
think I have ever had someone edit an article I was working on when I
posted such a notice.  So that's one solution.

Another simple bloodless solution is to make all of your changes offline,
using a word processing program, so that you can quickly hit the Wikipedia
"Save" button and then hit the "sifter" "Approve" button.

Another solution, which I'm sure Magnus wouldn't like to hear, would be to
import a local working copy to the "sifter" website, and when it's
finished, the updated version is posted both to the "sifter" website and
Wikipedia.  (But one would always *fetch* the working copy *from*
Wikipedia--no forks.)

Larry
--
"We have now sunk to a depth at which the re-statement of the obvious is
the first duty of intelligent men." --George Orwell


subject: Re: [Sifter-l] Roles in the approval process

body:
On Mon, 2 Dec 2002, Magnus Manske wrote:

> Poor, Edmund W wrote:

Ed brings up a thorny issue I was putting off, but OK, into the breach!

> >So why not designate 2 or more classes of reviewers?
> >
> >The primary reviewing role would be that of the expert who certifies the overall correctness and quality level of the article. But there can also be a "copyediting expert" (like Ruth). And why not a "fact checker" like Newsweek and the New York Times (supposedly :-) have.
> >
> That would mean that a "fact checker" can not completely approve an
> article? That sounds somewhat impractical, especially for smaller
> articles. Why not do that on a case-by-case basis?

"Reviewer" as I was using the term would be restricted to subject matter
experts--the sort of people who librarians and teachers think they can
trust to make sure that an article really is authoritative.  By the way,
we can very reasonably expect that the system will fail in some cases, and
if they're not naive, so will librarians and teachers.  So we aren't
aiming for perfection--merely something that looks like credible
certification.  This might sound cynical, but I think it's the best we can
do.

Anyway, to add to the above exchange, I think we should have *really* good
reasons for making any new category of operator in the system.  One of the
responsibilities of the reviewers would be to check facts, I'd think.
Why not?  It's not like it's drudgework beneath reviewers, and who better
than subject matter experts?

> >Anyway, aren't there going to be multiple reviewers on certain articles? Like, an article which 3 different Political Science reviewers all approve?
> >
> The software is designed for a single reviewer to approve an article.
> There's also a Recent Changes page where every reviewer (everyone, in
> fact) can check recent imports.
>
> Would a "delete this article" function for reviewers be helpful? So, if
> Reviewer A imported an article, and Reviewer B discovers major errors
> that cannot be fixed with a minor edit on wikipedia and a reimport,
> Reviewer B can delete the article from the sifter system, giving time to
> redo the wikipedia article.

Absolutely, we need to have a "delete this article" function, simply as a
safeguard against abuse.  But the deletion should be logged of course on
the Recent Changes page.  And we should discuss what conditions there
should be on the "delete" button's use.

And, of course, we (reviewers) need a place where we can discuss this...
perhaps, again, simply Wikipedia itself (the article's Wikipedia talk
page).

Larry
--
"We have now sunk to a depth at which the re-statement of the obvious is
the first duty of intelligent men." --George Orwell


from_name: Bridget

from_email: Bridget

subject: [Wikipedia-l] Plz stop harrassing Helga

body:
Plz stop harrassing Helga. It was argued that her changes were POV by changing German ultimatum to German/Lithuana treaty --- it seems to me that Helga was making the article not only NPOV but also more informative, as ultimatum is a much more weighted word than treaty.

On Boleslaus I - the changes do not make me wish to ban Helga-it makes me wonder why, if Helga is wrong and Boleslaus managed to pass the crowd to successors, then why doesn't the page link to these successors?

---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20021202/f21f6171/attachment.htm


subject: Re: [Sifter-l] What version is imported? - was: Copyediting

body:
On Mon, 2 Dec 2002, Poor, Edmund W wrote:

> I think it should be made clear that what is imported from Wikipedia
> will always be a specific version of an article. This need not be the
> current version.

Yes, that's how Magnus has written the importing software: the "sifter"
project has its own local copy of the article, which might correspond to
some historical version of the article.

> Supposed a determinedly non-neutral Wikipedian keeps changing an
> article on Copernicus (just to pick an entirely random subject ;-),
> and 30 seconds after our expert history reviewer has finished looking
> at it, she is ready to press the "import this article" button. But by
> now, Madame Malicious has changed the article. Would we want Wendy
> Wonderful's approval to go automatically to the malicious version? I
> would hope not.
>
> Please explain again, for the technically challenged (including me),
> how our heroic reviewers will be assured they will get only the
> wonderful version.

Since the review project will only import each article once with each
press of the "import" button (or whatever it's labelled), the only problem
left along these lines is the one Ruth Ifcher raised--what if someone
changes it just before the reviewer imports the wonderful version?

There are, as I was saying, many ways to solve that problem.  Another one
is to make all "sifter" reviewers Wikipedia sysops, and if they're
concerned, have them protect the Wikipedia article before approving it.
(Then, hopefully they'll remember to unprotect it--or it will be
automatically unprotected after 24 hours, or something like that.)

Larry
--
"We have now sunk to a depth at which the re-statement of the obvious is
the first duty of intelligent men." --George Orwell


from_name: Magnus Manske

subject: Re: [Sifter-l] Opinions

body:
Tucci wrote:

>I fear that this could become useless if we aren't
>somewhat strict about accepting reviewers.  Ideally, I
>think, the way it should wind up working one year from
>now is that, for example, a science team approves
>science articles.  If an active Wikipedian applies to
>the science team, the team looks over what he's done
>on Wikipedia and either approves or does not.
>
The software already contains some parts to do this (including the split
you mentioned). Problem is, how to check this? I imagine:
* without categories, we trust the reviewers to only approve articles
they know enough about
* with categories, we'd have to trust reviewers to keep to "their
corner" of topics to import
Reviewers who import "stupid" articles will be removed either way by the
sysops. OTOH, if I sign up for the biology team, I might still be fit
to, say, import the PHP article. Would I have to sign up for computer
science as well? But, I have no degree there (but, studied a few
semesters on the side, and programming for some years). Still, in the
category scheme, that would be "wrong" of me.

I do support adding category tags to imported articles, though, giving
more options to the reader (list all biology articles etc.)

>I also like the idea of having copyediting separate
>from fact-checking.  Specifically, a box next to
>"import this article" (unchecked by default) and an
>easily accessible status of "copyeditor" to find a
>list of articles that need to be copyedited.  The only
>absolutely final articles should be ones that are
>approved in both ways, factually and
>stylistically/grammatically.
>
>
IMHO fact-checking should be enough to import an article.
*Additionally*, it should be marked as "needs copyedit" (maybe even
"needs layout workover" as an additional option) if necessary, so
copyeditors (and/or HTML freaks;-) know the wikipedia article needs
work, and reimport it. That will avoid the "Nupedia effect", while still
having a copyedit, for the price of some articles not copyedited for a
brief period of time. I could live with that...

Magnus


subject: Re: [Sifter-l] Opinions

body:
On Mon, 2 Dec 2002, Magnus Manske wrote:

> Tucci wrote:
>
> >I fear that this could become useless if we aren't
> >somewhat strict about accepting reviewers.  Ideally, I
> >think, the way it should wind up working one year from
> >now is that, for example, a science team approves
> >science articles.  If an active Wikipedian applies to
> >the science team, the team looks over what he's done
> >on Wikipedia and either approves or does not.

Wikipedia work might be one factor in making a decision.  The point of the
"sifter" project is decidely not to reward Wikipedians or to designate
experts as such and to puff them up.  As far as I'm concerned, it has the
very simple :-) goal of creating a set of "expert"-approved articles.
The reason for this is to be able to announce to the world, "OK, Nupedia
might be slow, and Wikipedia might be unreliable, but the Reviewed
Encyclopedia combines the virtues of the two, being rapidly-growing *and*
reliable: librarians and teachers can feel safe recommending that students
and researchers use the resource because articles have been approved by
experts.  And what do we mean by experts?  This: ..."

We are going to have to take a deep breath and talk about what goes after
"This".

Ph.D.-level expertise seems required--not necessarily, or for that matter,
not always, a Ph.D. itself, but some *publicly-verifiable* proof of a
*similar* level of accomplishment in an area seems necessary.  (I will
appreciate it if you do not make facile assumptions about my views about
the requirements of or the very notion of expertise, as some people on
Wikipedia have done.)  The proof could come in numerous forms:  journal
articles on a topic published, books written, presentations given, a
well-known and -respected website, certifications, degrees of course, and
so forth.  When looking at our list of reviewers, librarians should be
able to say to themselves, "OK, so this project really does require
subject area expertise."

The latter (what librarians should be able to say to themselves) is one
criterion I think we should follow in determining a policy about who
reviewers can be and what they can approve.  Another criterion is one I
mentioned before: would people who are *clearly and unequivocally* experts
on the subject in question be able to look at the article and say, "OK,
maybe I could do better, but it's all basically correct, reasonably
well-written, and covers all of the important points that need to be
covered on this subject."

We as the directors of this project need to set up the conditions where we
can be adequately sure that actual experts will have *that* reaction to
the vast majority of our articles.  Apart from the magic of Wikipedia
itself, which is already doing its work, we need a reliable mechanism to
*ensure* that articles will have this degree of expert wow-ability.

> The software already contains some parts to do this (including the split
> you mentioned). Problem is, how to check this? I imagine:
> * without categories, we trust the reviewers to only approve articles
> they know enough about
> * with categories, we'd have to trust reviewers to keep to "their
> corner" of topics to import
> Reviewers who import "stupid" articles will be removed either way by the
> sysops. OTOH, if I sign up for the biology team, I might still be fit
> to, say, import the PHP article. Would I have to sign up for computer
> science as well? But, I have no degree there (but, studied a few
> semesters on the side, and programming for some years). Still, in the
> category scheme, that would be "wrong" of me.

I agree with all of this.

Ed Poor added:

> On the other hand, are we planning to restrict reviewers only to
> certain subject matter realms? Like, the physics reviewer wouldn't
> review (or delete) political science articles.
>
> How about letting the statistics expert review meteorology articles
> (e.g., global warming)?
>
> Or were you folks primarily thinking about traditional,
> non-controversial subjects?

Definitely my idea was that we should restrict reviewers to their own
areas of expertise.  This means among other things that I should not
approve articles on Greek philosophy or aesthetics, even though I am a
philosopher and I do know a thing or two about both subjects.  On the
other hand, there are many article topics within epistemology and early
modern philosophy I could do.  I'm not the world's greatest expert on
*any* topic in philosophy, but I think I can tell when at least basic
articles on topics most familiar to me will pass muster with those who are
*truly* in the know on those topics.

> I do support adding category tags to imported articles, though, giving
> more options to the reader (list all biology articles etc.)

I do too, actually, I just think we need not to botch it (mess it up).
It's so easily botchable.

> >I also like the idea of having copyediting separate
> >from fact-checking.  Specifically, a box next to
> >"import this article" (unchecked by default) and an
> >easily accessible status of "copyeditor" to find a
> >list of articles that need to be copyedited.  The only
> >absolutely final articles should be ones that are
> >approved in both ways, factually and
> >stylistically/grammatically.
> >
> >
> IMHO fact-checking should be enough to import an article.
> *Additionally*, it should be marked as "needs copyedit" (maybe even
> "needs layout workover" as an additional option) if necessary, so
> copyeditors (and/or HTML freaks;-) know the wikipedia article needs
> work, and reimport it. That will avoid the "Nupedia effect", while still
> having a copyedit, for the price of some articles not copyedited for a
> brief period of time. I could live with that...

Having thought some more about this, I don't think we should have any such
things, at all.  Let's keep this project bare-bones simple.  More in
response to Ruth Ifcher.

Larry
--
"We have now sunk to a depth at which the re-statement of the obvious is
the first duty of intelligent men." --George Orwell


subject: [Wikitech-l] TeX, version 2, ISSUES 19,20

body:
On Mon, Dec 02, 2002 at 02:18:49AM +0100, Tomasz Wegrzanowski wrote:
>
> ISSUE 19:
> I'm not sure if \mbox is right thing to have.
> Isn't it meant to do things other than math ?
> I'm no TeX expert so please comment.

Yes, that's what it's for. You need it if you want to have
text inside of a formula. $${x\in\bbN: x \mbox{is prime}}$$
(where \bbN is a capital N in a blackboard font).
Or if you want to have
$$\frac{\mbox{divisor}}{\mbox{divident}}$$

> ISSUE 20:
> How ugly HTML will we allow ?
>
> Sums and integrals in HTML will be redable but extremely ugly.
> Well, we could implement more sophisticated HTML rendering algorithms,
> for example using a table for that.
>
> But I'm not sure if it's worth the effort.

Agreed. It would be hard to have the borders of the integral in place
with HTML. You might implement it later, if it's really asked for.

	Regards,

		JeLuF


subject: [Wikipedia-l] Plz stop harrassing Helga

body:
Bridget [name omitted for privacy reasons] wrote:

> Plz stop harrassing Helga. It was argued that her changes were POV by
> changing German ultimatum to German/Lithuana treaty --- it seems to me
> that Helga was making the article not only NPOV but also more
> informative, as ultimatum is a much more weighted word than treaty.
>
>
> On Boleslaus I - the changes do not make me wish to ban Helga-it makes
> me wonder why, if Helga is wrong and Boleslaus managed to pass the
> crowd to successors, then why doesn't the page link to these successors?
>
With all due respect, Lir, you will appreciate that your impaired
credibility on Wikipedia means that your intervention on issues
concerning Helga may be counterproductive to your apparent
intentions.... or more crudely put:  With friends like you she doesn't
need enemies.

Eclecticology


from_name: Poor, Edmund W

subject: [Sifter-l] Roles in the approval process

body:
In response to several people who have raised the copy-editing issue, I say let's endeavor to make the approval process as simple as possible. Anything that makes it cumbersome should be left out, if possible.

So why not designate 2 or more classes of reviewers?

The primary reviewing role would be that of the expert who certifies the overall correctness and quality level of the article. But there can also be a "copyediting expert" (like Ruth). And why not a "fact checker" like Newsweek and the New York Times (supposedly :-) have.

Anyway, aren't there going to be multiple reviewers on certain articles? Like, an article which 3 different Political Science reviewers all approve?

Ed Poor


body:
On Sun, 1 Dec 2002 rose.parks@att.net wrote:

>      Larry presented two options for copy editing the Sifter articles.
> He wrote:
>
> 1. Use "the honor system," where we have reviewers say that they have
> *thoroughly* copyedited the article, or, if they're not sure they can do
> an excellent job at that, they've had someone else who is copyedit it.
> We might just add a checkbox to the article import routine (default would
> be unchecked) labeled "I have thoroughly copyedited this article, or I am
> satisfied that someone else has already done so."
>
> 2. Designate a new category of worker in the system, the copyeditor.
> Reviewers could be copyeditors, and in that case, any article uploaded by
> the reviewer would automatically be posted.  But in cases where reviewers
> are not copyeditors, the reviewer could only upload the article into a
> staging area where articles would have to be approved--again, just the
> press of one button--by *any* copyeditor, before being posted.
>
> Now that I've spelled out these two options, I already favor option 1, as
> long as we had set up some page on Wikipedia, on the new project, or via a
> special mailing list whereby reviewers could let it be known to
> copyeditors that a given article needs to be copyedited *now*.
>
>      I have considered both options, as well as others, and see both
> strengths and weaknesses in both of Larrys options. Option 1 and
> option 2, presented above, are actually not that different. For me, it
> boils down to whether we hold the reviewer responsible for review and
> copy edit (option 1) or we hold the reviewer responsible for review
> only and copyedit only if he/she can and wants to (option 2.)

Yes, that's pretty much it.

>      Larrys present proposal for Sifter has either one or two steps
> for each article to pass through, where the step/steps are to be
> accomplished by Sifter members.

Yes, and the "where" qualification is important.  On Wikipedia, all
aspects of the writing and editing process and jumbled together.  The
question now is what steps should be required for the review project.

> Then, either option presents a great reduction in processing and
> potential bottlenecks. However, the Nupedia processing does have a
> rationale for having so many steps in it. The idea was that, if an
> article is reviewed for content by 2 experts and then the whole
> membership, and, then, reviewed for style, grammar, etc. by 2
> dedicated copy editors and finally by the whole membership, article
> quality should be very high and the chance of error should be very
> small.

Precisely.

> Potential problem with option 1:
>      Sifter option 1 leaves all the responsibility for content and
> copy edit with one individual. Sifter option 2 leaves this
> responsibility with 1 or 2 individuals, for the most part. I, for one,
> am a little wary of leaving so much responsibility with one
> individual, as proposed in option 1. Note, that under option 2, one
> can get the same result  one person responsible for review and
> copyedit.

Potential for abuse and incompetence is possible regardless of the number
of people, but is huge when there is one individual who is not answerable
to anyone else.  That seems platitudinous.

That, however, isn't the case here.  In the context of Wikipedia and the
annoyingly as-yet-unnamed sifter project, reviewers' approvals will be
public record and will be open to criticism.  (But where and how?  We've
got to think about that.)

Nevertheless, you've got an excellent point here.  Under either option,
but especially under option 2, it's not a question of whether, it's a
question of how soon and how often we will see approved articles that just
shouldn't have been approved.

> Potential problem with option 1:
>      Further, we will have to recruit these reviewers, in most cases.
> Although they may already be members of wikipedia or nupedia, they may
> be new. Aside from their function as reviewers, they will eventually
> have to learn the wiki mark-up and HTML (if they dont know it) to
> make changes.

But it's not that hard, really.  HTML isn't required.

> Under option 1, they will also have to either copy edit
> or approve their copy editors work; this may be more work than it
> seems. I would not like to see reviewers signing up enthusiastically,
> to find many of them resigning over their first article, because they
> had no idea how much work was involved.

You've got a good point there.  If reviewers were to understand that *they
personally* were tasked with copyediting a long list of articles, of
course they'd find the notion arduous.  But we needn't make that part of
the job description.  They are simply button-pressers.  If an article
isn't up to snuff in terms of copyediting, they simply don't press the
button.  They don't actually have to *do* the copyediting.

Of course, if they believe in the project's mission as much as we do,
they'll be highly inclined to do the copyediting, which would be great,
but it would *then* create the problem you mention.  I can see a reviewer
saying, "Well, I really liked pressing the approval button, and I want the
project to succeed, but I got tired of constantly having to go into the
article itself and spend an hour making all sorts of copyediting changes.
Maybe if someone else had already done that, I'd be more inclined to
participate."  Yes, I can see that happening.

>      So, in summary, I guess I lean toward option 2, because it allows
> reviewers to do it all, review and copyedit, or to do the review and let a
> copyeditor be responsible for the copyedit.

Feel free of course to add option 3 or option 4 etc.  :-)

You've made a good case.  I think you might have changed my mind...

I just want to avoid creeping complication.  The mere activity of
approving articles is a very simple thing.

>      There is at least one other problem involved in introducing
> copyedit. In Nupedia we have standards for copy edit in our policy
> statement as well as a requirement for copyeditors to have two
> reference books. These books establish copyedit standards in great
> detail. In Wikipedia, I am not aware of any set of standards for
> copyedit, in the same kind of detail. For example, almost all articles
> in Nupedia are required to have a For Further Reading section, with
> suggestions for books to read to learn more on the subject. And, the
> For Further Reading section is required to be in a particular
> format. Such standards add a professional and polished look to
> articles and are found in most encyclopedias. Do we want such
> standards and, if so, how are we going to establish and implement
> them?

I don't know.

What I would tentatively suggest is that people who take responsibility
for approving copyediting should use at least *some* source as they feel
they need to.

As to a "further reading" section, that would go under the heading of
"article requirements," which we haven't started discussing at all and I'd
like not to think about it quite yet, personally--gives me a headache.

Of course, we could simply import, lock, stock and barrel, all Nupedia
requirements:

http://www.nupedia.com/policy.shtml

Especially if Nupedia hosts the project, this will make *some* sense.
See especially "Guidelines for writing and formatting articles."

Article requirements is a huge can of worms.

>      Well, these are my first thoughts on introducing copyedit into
> the Sifter process and the two options presented by Larry. Clearly,
> there is a third option of having reviewers only review and
> copyeditors, only copyedit. This option guarantees another step in
> complexity of the sifter process, but insures that responsibility for
> processing an article is shared by two people.

We can always begin with one option and make it *very* explicit that the
process "is *not* set in stone and we might very well change it, so don't
get yer knickers in a twist if we decide to make it harder for an article
to get approved."

>      It seems that each discreet step one adds to the Sifter process
> is an opportunity to improve our product, but also a place where
> unforeseen problems can develop. For this reason, I can't say
> definitively that option "x" is better.

Exactly.

I think public review and feedback is incredibly effective, especially
when those making the change are granted some "moral authority" within the
system, as reviewers would and as rank-and-file Wikipedia members all too
often are not by each other, sadly.  (It wasn't always that way.  This is
my opinion, by the way.)  This makes the act of criticism more significant
and therefore, more powerful.

>      I hope this is some help to other members in considering the
> options available for copyedit.

Absolutely and I hope others will post on these options as well.

Larry
--
"We have now sunk to a depth at which the re-statement of the obvious is
the first duty of intelligent men." --George Orwell


subject: Re: [Sifter-l] Opinions

body:
My opinions, as a librarian, are that the articles need to be copyedited
and reviewed before being posted.  Once there are a substantial number of
articles in the system, I could assist in marketing and advertising the
site to librarians through their usual review/information process, which
includes listservs and annotated bibliographic services that announce such
ventures.  Of course, this would be predicated on my belief that the
articles and the venture was being successful in its goals and was
producing a quality product.  Brad

                    Larry Sanger
                    <lsanger@nupedia        To:     <sifter-l@nupedia.com>
                    .com>                   cc:
                    Sent by:                Subject:     Re: [Sifter-l] Opinions
                    sifter-l-admin@n
                    upedia.com

                    12/02/02 10:03
                    AM
                    Please respond
                    to sifter-l

On Sun, 1 Dec 2002, Tucci wrote:

> The only thing I would add to this is the citation of
> sources for at least some types of articles.  A lot of
> the sciencey-type stuff probably doesn't need sources
> unless it's controversial.

We might indeed want a whole list of principles along these lines when we
discuss specific article requirements.

> I fear that this could become useless if we aren't
> somewhat strict about accepting reviewers.

And if we *are* strict about accepting reviewers, for most of them our
article requirements will just go without saying.

> Ideally, I
> think, the way it should wind up working one year from
> now is that, for example, a science team approves
> science articles.  If an active Wikipedian applies to
> the science team, the team looks over what he's done
> on Wikipedia and either approves or does not.  Once it
> becomes necessary, the science team could split into
> geology, meteorology, physics and whatever (in
> reality, a "science" team is probably too broad to
> even begin with, but it's a good example).  It could
> become as specific as necessary or useful.  So, the
> music team can split into jazz, disco and heavy metal
> as needed.  Then, if needed, the heavy metal team
> could fork into death metal or nu-metal or even an
> Iron Maiden team if it becomes necessary or useful.

We haven't talked about teams at all, yet.  Just individuals.

> That's my thoughts.  The only question is how to reach
> that point, how to gather that first "music" or
> "science" team members and assure that they are useful
> people.

I know how to do that.  :-)

> I also like the idea of having copyediting separate
> from fact-checking.  Specifically, a box next to
> "import this article" (unchecked by default) and an
> easily accessible status of "copyeditor" to find a
> list of articles that need to be copyedited.  The only
> absolutely final articles should be ones that are
> approved in both ways, factually and
> stylistically/grammatically.

Do you mean "fact-checking" specifically or "review" generally?
Fact-checking in the world of publishing means actually checking to see
whether specific factual claims in an article really do check out.  This
is a distinct endeavor from ensuring that the content of the article is at
a professional level--having the facts right is necessary, but not
sufficient.

There's one thing that's always been clear in my mind but perhaps I
haven't said it and others would disagree: the final product of the sifter
project might *not* be as high-quality as Nupedia, and a revived Nupedia
might want to use "sifted" articles.

It will be impossible to convince librarians and other (properly) critical
types that the sifter project is 100% reliable.  But I do think many of
them will be very impressed, enough to be able to recommend it.

I wonder what Brad Eden, UNLV librarian, thinks of these off-the-cuff
remarks about what librarians would think...

Larry
--
"We have now sunk to a depth at which the re-statement of the obvious is
the first duty of intelligent men." --George Orwell

_______________________________________________
Sifter-l mailing list
Sifter-l@nupedia.com
http://www.nupedia.com/mailman/listinfo/sifter-l


body:
No, it doesn't need to be separate, but as an editor, I don't think that it
is my job to correct spelling, syntax, and presentation; I do think that my
job is to do a critical review of the content for correctness.  If you want
reviewers to do both together, then you will have a harder time getting
volunteers, because in the scholary/academic community, we don't waste time
helping authors with English grammar and presentation; that's their job.
Brad

                    Larry Sanger
                    <lsanger@nupedia        To:     <sifter-l@nupedia.com>
                    .com>                   cc:
                    Sent by:                Subject:     Re: [Sifter-l] Copyediting: First Thoughts
                    sifter-l-admin@n
                    upedia.com

                    12/02/02 10:10
                    AM
                    Please respond
                    to sifter-l

On Mon, 2 Dec 2002 beden@ccmail.nevada.edu wrote:

> As someone with editorial duties for a number of journals in my
> subject areas, I would like to remind the group of the importance of
> reviewers in this process.  I think that Rose is correct; some type of
> independent review/copy-editing process needs to be in place.  The
> first thing I see when I review articles for my editorial duties is
> the lack of simple English writing structure skills that most people
> have, and if we want this project to be validated, used, and
> referenced, then we need to make the articles as readable and
> professional as possible.  Just my two cents' worth.

Just to be clear, are you saying that copyediting needs *necessarily* to
be separate from review ("content approval")--that the system should
guarantee that the person who approves grammar etc. is different from the
person who approves content?

The project is all about reviewers and their importance, indeed.  The very
purpose of the project is to have a simple but hopefully effective
mechanism whereby expert reviewers can put their stamp of approval on
Wikipedia articles that are up to snuff.  No reviewers, no project.

Larry
--
"We have now sunk to a depth at which the re-statement of the obvious is
the first duty of intelligent men." --George Orwell

_______________________________________________
Sifter-l mailing list
Sifter-l@nupedia.com
http://www.nupedia.com/mailman/listinfo/sifter-l


subject: Re: [Sifter-l] Opinions

body:
On Sun, 1 Dec 2002, Tucci wrote:

> The only thing I would add to this is the citation of
> sources for at least some types of articles.  A lot of
> the sciencey-type stuff probably doesn't need sources
> unless it's controversial.

We might indeed want a whole list of principles along these lines when we
discuss specific article requirements.

> I fear that this could become useless if we aren't
> somewhat strict about accepting reviewers.

And if we *are* strict about accepting reviewers, for most of them our
article requirements will just go without saying.

> Ideally, I
> think, the way it should wind up working one year from
> now is that, for example, a science team approves
> science articles.  If an active Wikipedian applies to
> the science team, the team looks over what he's done
> on Wikipedia and either approves or does not.  Once it
> becomes necessary, the science team could split into
> geology, meteorology, physics and whatever (in
> reality, a "science" team is probably too broad to
> even begin with, but it's a good example).  It could
> become as specific as necessary or useful.  So, the
> music team can split into jazz, disco and heavy metal
> as needed.  Then, if needed, the heavy metal team
> could fork into death metal or nu-metal or even an
> Iron Maiden team if it becomes necessary or useful.

We haven't talked about teams at all, yet.  Just individuals.

> That's my thoughts.  The only question is how to reach
> that point, how to gather that first "music" or
> "science" team members and assure that they are useful
> people.

I know how to do that.  :-)

> I also like the idea of having copyediting separate
> from fact-checking.  Specifically, a box next to
> "import this article" (unchecked by default) and an
> easily accessible status of "copyeditor" to find a
> list of articles that need to be copyedited.  The only
> absolutely final articles should be ones that are
> approved in both ways, factually and
> stylistically/grammatically.

Do you mean "fact-checking" specifically or "review" generally?
Fact-checking in the world of publishing means actually checking to see
whether specific factual claims in an article really do check out.  This
is a distinct endeavor from ensuring that the content of the article is at
a professional level--having the facts right is necessary, but not
sufficient.

There's one thing that's always been clear in my mind but perhaps I
haven't said it and others would disagree: the final product of the sifter
project might *not* be as high-quality as Nupedia, and a revived Nupedia
might want to use "sifted" articles.

It will be impossible to convince librarians and other (properly) critical
types that the sifter project is 100% reliable.  But I do think many of
them will be very impressed, enough to be able to recommend it.

I wonder what Brad Eden, UNLV librarian, thinks of these off-the-cuff
remarks about what librarians would think...

Larry
--
"We have now sunk to a depth at which the re-statement of the obvious is
the first duty of intelligent men." --George Orwell


subject: [WikiEN-l] Tokerboy as sysop - was: WikiEN-l digest, Vol 1 #25 - 9 msgs

body:
I second Mav's endorsement of Tokerboy.

Your special helper,
Ed Poor


body:
On Mon, 2 Dec 2002 beden@ccmail.nevada.edu wrote:

> As someone with editorial duties for a number of journals in my
> subject areas, I would like to remind the group of the importance of
> reviewers in this process.  I think that Rose is correct; some type of
> independent review/copy-editing process needs to be in place.  The
> first thing I see when I review articles for my editorial duties is
> the lack of simple English writing structure skills that most people
> have, and if we want this project to be validated, used, and
> referenced, then we need to make the articles as readable and
> professional as possible.  Just my two cents' worth.

Just to be clear, are you saying that copyediting needs *necessarily* to
be separate from review ("content approval")--that the system should
guarantee that the person who approves grammar etc. is different from the
person who approves content?

The project is all about reviewers and their importance, indeed.  The very
purpose of the project is to have a simple but hopefully effective
mechanism whereby expert reviewers can put their stamp of approval on
Wikipedia articles that are up to snuff.  No reviewers, no project.

Larry
--
"We have now sunk to a depth at which the re-statement of the obvious is
the first duty of intelligent men." --George Orwell


subject: Re: FW: [Sifter-l] Roles in the approval process

body:
On Mon, 2 Dec 2002, Magnus Manske wrote:

> Poor, Edmund W wrote:
>
> >On the other hand, are we planning to restrict reviewers only to certain subject matter realms? Like, the physics reviewer wouldn't review (or delete) political science articles.
> >
> As wikipedia does not contain categories, there's no (automatic) way to
> check if an import takes place only in an assigned category. We'd have
> to rely on a reviewer to stick to his/her field of knowledge. So, why
> put reviewers into categories anyway?

Indeed.  If we're going to hard-wire categories for purpose of article
*and* reviewer classification, we can't just blunder our way into it.  We
need to think very clearly about why we're doing it, what it's for, and
the best way to implement it.

> >How about letting the statistics expert review meteorology articles (e.g., global warming)?
> >
> I wouldn't approve [[global warming]] either, because I don't know
> enough about it. Any responsible reviewer should judge himself in such a
> way, IMHO. So, automatically, the statistics people, or maybe
> ecologists, will be the ones to import such an article anyway.

I would think it would be a big mistake for a statistics expert who was
inexpert in meteorology (i.e., most of them) to approve meteorology
articles.  Remember, "review" doesn't mean "write critical remarks about"
here.  ReviewERS don't actually review anything for the sifter project,
strictly speaking, except in the sense of "carefully examining"--their
official brief is to press the "approve" button when warranted.

> >Or were you folks primarily thinking about traditional, non-controversial subjects?
> >
> >
> There's another reason against artificial reviewer classification.
> Sometimes you just know it's good, or crap ;-)

Well, let's be careful about having people self-selecting their own areas
of expertise on the fly.  The world has no shortage of self-designated
experts who do not properly appreciate the extent of their ignorance.

Larry
--
"We have now sunk to a depth at which the re-statement of the obvious is
the first duty of intelligent men." --George Orwell


subject: [Wikitech-l] TeX

body:
--- Tomasz Wegrzanowski <taw at users.sourceforge.net> wrote:

> But you can see a diference between "possible to do in HTML"
> and "sane to do in HTML" now.

Yes. But do we agree that formulas that are "sane to do in HTML", like
x2 + y2 ≥ 0 for instance, should be written in
HTML even when the TeX system is in place?

> I'm not completely sure about safety. Probably we should both
> validate and
> run TeX in safe mode.

For safety concerns, preparsing of TeX is not necessary: the safety
issues of running PHP and calling an external parser are much larger.

> texvc is extremely easy to extend. It shouldn't take too much time
> just to
> add a few dozens of new tags, and a night or two should be enough for
> completely new kind of markup, be it chemistry (which certainly
> should be added),
> chess, music or whatever.

Unfortunately, the xypic package (which I consider the one feature that
is really needed in the math area right now) as well as the other
packages I listed all use their own idiosyncratic syntax quite unlike
ordinary TeX. So extending texvc may not be quite as simple, and I'm
afraid we are creating a development bottleneck by requiring the
external parsing stage.

Axel

Payment: http://www.wikipedia.org/w/wiki.phtml?title=Tree_(graph_theory)&diff=0&oldid=456065

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


subject: FW: [Sifter-l] Roles in the approval process

body:
> > Are there going to be multiple reviewers on
> > certain articles? Like, an article which 3 different
> > Political Science reviewers all approve?
>
> The software
> is designed for a single reviewer to approve an article.
> There's also a Recent Changes page where every reviewer
> (everyone, in fact) can check recent imports.
>
> Would a "delete this article" function for reviewers be
> helpful? So, if Reviewer A imported an article, and
> Reviewer B discovers major errors that cannot be fixed
> with a minor edit on wikipedia and a reimport, Reviewer
> B can delete the article from the sifter system, giving
> time to redo the wikipedia article.

I like the "delete" or "un-approve" function Magnus proposed. This gives any reviewer Veto Power over any other reviewer.

On the other hand, are we planning to restrict reviewers only to certain subject matter realms? Like, the physics reviewer wouldn't review (or delete) political science articles.

How about letting the statistics expert review meteorology articles (e.g., global warming)?

Or were you folks primarily thinking about traditional, non-controversial subjects?

Ed Poor


subject: FW: [Sifter-l] The issues

body:
I agree with Larry's statement of basic principles (note: third bullet point made slightly more "accessible"):

* Approved articles must not be known to contain errors, and any
  questionable factual assertions must be checked.

* Biased articles (per either or both of Wikipedia's and Nupedia's nonbias
  policies) should not be posted.

* The content should be accessible to the people who might actually need
  the article (i.e., readily comprehensible to someone with the expected
  background). A math article about integral calculus may assume the reader
  has mastered algebra, etc.

* The content should be of reasonably high quality from a professional
  point of view.

Ed Poor


subject: [Sifter-l] Adjudicators, not reviewers

body:
On Mon, 2 Dec 2002 beden@ccmail.nevada.edu wrote:

> No, it doesn't need to be separate, but as an editor, I don't think
> that it is my job to correct spelling, syntax, and presentation; I do
> think that my job is to do a critical review of the content for
> correctness.  If you want reviewers to do both together, then you will
> have a harder time getting volunteers, because in the
> scholary/academic community, we don't waste time helping authors with
> English grammar and presentation; that's their job.
> Brad

OK, I understand.  But do you see that under the present system, reviewers
per se are not actually tasked with writing critical reviews?  Let's use a
different word in place of "reviewer."  Something like "certifier,"
"approver," "button-presser," or "judge."  No, I have it:

	adjudicator

Henceforth, I think we should use the word "adjudicator" in place of
"reviewer."

Now, by all means, there should be a mechanism whereby a "sifter"
adjudicator *can* (if they want) place remarks on the Wikipedia talk page
so that Wikipedians can benefit and improve the article.  But that would
be neither necessary nor sufficient to do the job of "adjudicating" (i.e.,
deciding whether or not to press the button).

So it was never part of the proposal that adjudicators (reviewers) should
necessarily help authors with *anything*.  They just press buttons.

Brad, is this sounding better, or worse, than the proposal as you
understood it?

Larry
--
"We have now sunk to a depth at which the re-statement of the obvious is
the first duty of intelligent men." --George Orwell


subject: [Sifter-l] Reply-to trap

body:
To the list administrator:

Please fix the reply-to, so that when users like me and Magnus click the "Reply" button in our e-mail software, the "to" line includes the sifter-l@nupedia.com address.

Or make me a list administrator, and I will do this (as I did for the WikiEN-l list.

Ed Poor


subject: [Wikitech-l] dealing with deletions

body:
Brion,

Thanks for explaining the page lifecycle. I have clipped this diagram for reference.

> Here's a diagram of what exists in what tables over the lifetime of such
> an event:
>
> Page creation:
> rev A -> cur
>
> Later edit:
> rev B -> cur
> rev A -> old
>
> Deletion
> rev B -> archive (hidden)
> rev A -> archive (hidden)
>
> New creation with same title:
> rev C -> cur
> rev B -- archive (hidden)
> rev A -- archive (hidden)
>
> Later edit:
> rev D -> cur
> rev C -> old
> rev B -- archive (hidden)
> rev A -- archive (hidden)
>
> Restoration of deleted revisions:
> rev D -- cur
> rev C -- old
> rev B -> old
> rev A -> old

Gratefully,

Ed Poor


subject: Re: [Sifter-l] Adjudicators, not reviewers

body:
Soo, in other words, the "adjudicator's" job is to approve or disapprove
submissions, just push a button?  If so, then this is similar to the
peer-reviewed journal idea, giving the article back to the author to "clean
up, revise, etc" if they wish to resubmit once things have been cleaned up?
Do you really think that submitters of articles are going to accept this
kind of feedback, without some explanation or guidance to assist them?  I
get many articles that, because the English syntax and grammar are so
horrible in the first two paragraphs, that I disapprove immediately without
looking at the content, and send back to the author with the instructions
to have two colleagues read through their work and correct as necessary,
and then resubmit for content review.  And this is for librarians and
academicians; I can only imagine what problems in this area will come from
amatuer and even first-time authors.  Brad

                    Larry Sanger
                    <lsanger@nupedia        To:     <sifter-l@nupedia.com>
                    .com>                   cc:
                    Sent by:                Subject:     [Sifter-l] Adjudicators, not reviewers
                    sifter-l-admin@n
                    upedia.com

                    12/02/02 10:26
                    AM
                    Please respond
                    to sifter-l

On Mon, 2 Dec 2002 beden@ccmail.nevada.edu wrote:

> No, it doesn't need to be separate, but as an editor, I don't think
> that it is my job to correct spelling, syntax, and presentation; I do
> think that my job is to do a critical review of the content for
> correctness.  If you want reviewers to do both together, then you will
> have a harder time getting volunteers, because in the
> scholary/academic community, we don't waste time helping authors with
> English grammar and presentation; that's their job.
> Brad

OK, I understand.  But do you see that under the present system, reviewers
per se are not actually tasked with writing critical reviews?  Let's use a
different word in place of "reviewer."  Something like "certifier,"
"approver," "button-presser," or "judge."  No, I have it:

           adjudicator

Henceforth, I think we should use the word "adjudicator" in place of
"reviewer."

Now, by all means, there should be a mechanism whereby a "sifter"
adjudicator *can* (if they want) place remarks on the Wikipedia talk page
so that Wikipedians can benefit and improve the article.  But that would
be neither necessary nor sufficient to do the job of "adjudicating" (i.e.,
deciding whether or not to press the button).

So it was never part of the proposal that adjudicators (reviewers) should
necessarily help authors with *anything*.  They just press buttons.

Brad, is this sounding better, or worse, than the proposal as you
understood it?

Larry
--
"We have now sunk to a depth at which the re-statement of the obvious is
the first duty of intelligent men." --George Orwell

_______________________________________________
Sifter-l mailing list
Sifter-l@nupedia.com
http://www.nupedia.com/mailman/listinfo/sifter-l


subject: [Sifter-l] What version is imported? - was: Copyediting

body:
I think it should be made clear that what is imported from Wikipedia will always be a specific version of an article. This need not be the current version.

Supposed a determinedly non-neutral Wikipedian keeps changing an article on Copernicus (just to pick an entirely random subject ;-), and 30 seconds after our expert history reviewer has finished looking at it, she is ready to press the "import this article" button. But by now, Madame Malicious has changed the article. Would we want Wendy Wonderful's approval to go automatically to the malicious version? I would hope not.

Please explain again, for the technically challenged (including me), how our heroic reviewers will be assured they will get only the wonderful version.

Ed Poor


subject: [Sifter-l] Reviewer feedback

body:
I think we should keep sifter really simple and leave as much work as
possible to Wikipedians. In particular, Wikipedia already has excellent
copyeditors, and there's no need to build a parallel structure in
sifter.

Sifter reviewers will undoubtedly have different styles. Some will jump
head first into Wikipedia and clean up an article before approving it,
facts, presentation, grammar and all, while others will prefer to be
mere button pressers.  For the latter type, we need an easy way to give
feedback about an article. They could for example write: "Topic xyz
needs to be covered; spellchecking is necessary before the article can
be approved". This would then go on the article's Talk page in
Wikipedia, but could also be logged on a central Wikipedia page about
articles under sifter review. Wikipedians who are looking for a task
could always go there and find an article to fix. This feedback in
itself would be very helpful to Wikipedia, even without the sifter
project.

Ultimately, the button presser should be fully responsible for the
approved article: facts, presentation and style. If they are not
comfortable with any of this, they simply shouldn't press the button,
but either fix it themselves or solicit help as above.

Regarding the topic classification: I think a code of honor is
sufficient. You describe on some page what your qualifications are, and
then you agree to approve only articles in your area. People abusing
that system are kicked out.

The problem of substandard articles being approved can be dealt with
like this: the person who notices the problem fixes the Wikipedia
article, then notifies the original approver and tells them about the
superior version. If the approver agrees, all is fine and the new
version is approved; if not, it's a matter of professional
disagreement. If a reviewer consistently approves substandard articles,
they're kicked out.

Axel

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


body:
--- beden@ccmail.nevada.edu wrote:
>
> Soo, in other words, the "adjudicator's" job is to approve or
> disapprove
> submissions, just push a button?

That is my understanding.

> If so, then this is similar to the
> peer-reviewed journal idea, giving the article back to the author to
> "clean
> up, revise, etc" if they wish to resubmit once things have been
> cleaned up?

It's like peer-review in the sense that the reviewer can give a simple
Yes/No reply if they so chose, or they can give more feedback. It's
unlike peer-review because authors don't "submit" or "resubmit"
anything.
You find an article on Wikipedia you like: you push the button to
approve. You find an article on Wikipedia that needs work: you don't
push the button, and if you so choose,

 * you fix the article yourself, or
 * you give some feedback so that Wikipedians can improve the article

Again, the latter two are strictly optional.

Axel

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


body:
On Mon, 2 Dec 2002 beden@ccmail.nevada.edu wrote:

> Soo, in other words, the "adjudicator's" job is to approve or
> disapprove submissions, just push a button?  If so, then this is
> similar to the peer-reviewed journal idea, giving the article back to
> the author to "clean up, revise, etc" if they wish to resubmit once
> things have been cleaned up?

Well, not exactly.  Unlike the case with Nupedia, people do not actually
submit articles to you for review.  (Although one feature we might think
about adding is a page for "nominations," that non-adjudicators could use
to suggest Wikipedia articles.)  Instead, you browse through articles
already existing on Wikipedia, and if you find any that you think are up
to snuff in your area (whatever that turns out to require), you push the
approve button, and the article is imported from Wikipedia to the "sifter"
website.

To see the test version in action (it works, thanks to Magnus!), please
have a look at

http://www.seeatown.com/misc/main.php

for a mock-up.  Make a user ID (go to "log in") and apply to become a
sysop, and I'll make you one.  (I'm making everyone who requests it a
sysop, so we can test out the system.  This will not be permanent.)

Then from the home page, click on any article and try importing it.
(Doesn't matter if it's no good--we're just testing at this point.)

> Do you really think that submitters of
> articles are going to accept this kind of feedback, without some
> explanation or guidance to assist them?

On Wikipedia, it's entirely possible that nobody will care much about
which articles are approved by the sifter project.  Wikipedians will in
theory be able to go on in blissful ignorance of what's going on in the
Sifter project.  In reality, I suspect that *some* people will be very
upset when their pet article isn't immediately approved by the sifter
project.  I also suspect that the sifter project will exert a subtle but
powerful influence in the direction of quality over Wikipedia.

So: there will be no submitters unless we, for example, specifically set
up a Sifter page where non-adjudicators can nominate Wikipedia articles.
And if we do set up such a page, then we should definitely have a space
where an adjudicator can explain what problems still exist in the article.

> I get many articles that,
> because the English syntax and grammar are so horrible in the first
> two paragraphs, that I disapprove immediately without looking at the
> content, and send back to the author with the instructions to have two
> colleagues read through their work and correct as necessary, and then
> resubmit for content review.  And this is for librarians and
> academicians; I can only imagine what problems in this area will come
> from amatuer and even first-time authors.  Brad

Definitely, but you'd be surprised at how well-written some Wikipedia
articles are.  (Of course, some of them are really bad, but they tend not
to stay that way for long.)

Larry
--
"We have now sunk to a depth at which the re-statement of the obvious is
the first duty of intelligent men." --George Orwell


subject: Re: [Sifter-l] Reviewer feedback

body:
On Mon, 2 Dec 2002, Axel Boldt wrote:

> I think we should keep sifter really simple and leave as much work as
> possible to Wikipedians. In particular, Wikipedia already has
> excellent copyeditors, and there's no need to build a parallel
> structure in sifter.

The issue isn't whether *actual copyediting* should be assigned to the
sifters (nobody thinks that), but whether there should be a separate
category of sifter that is responsible for *certifying* copyediting.

With the latter caveat (and that Ruth Ifcher might well be right that we
should at least *permit* a separate category of copyediting-approver), I
agree with all the rest.

It does of course raise the question of how we decide to kick out an
adjudicator.

Larry

> Sifter reviewers will undoubtedly have different styles. Some will jump
> head first into Wikipedia and clean up an article before approving it,
> facts, presentation, grammar and all, while others will prefer to be
> mere button pressers.  For the latter type, we need an easy way to give
> feedback about an article. They could for example write: "Topic xyz
> needs to be covered; spellchecking is necessary before the article can
> be approved". This would then go on the article's Talk page in
> Wikipedia, but could also be logged on a central Wikipedia page about
> articles under sifter review. Wikipedians who are looking for a task
> could always go there and find an article to fix. This feedback in
> itself would be very helpful to Wikipedia, even without the sifter
> project.
>
> Ultimately, the button presser should be fully responsible for the
> approved article: facts, presentation and style. If they are not
> comfortable with any of this, they simply shouldn't press the button,
> but either fix it themselves or solicit help as above.
>
> Regarding the topic classification: I think a code of honor is
> sufficient. You describe on some page what your qualifications are, and
> then you agree to approve only articles in your area. People abusing
> that system are kicked out.
>
> The problem of substandard articles being approved can be dealt with
> like this: the person who notices the problem fixes the Wikipedia
> article, then notifies the original approver and tells them about the
> superior version. If the approver agrees, all is fine and the new
> version is approved; if not, it's a matter of professional
> disagreement. If a reviewer consistently approves substandard articles,
> they're kicked out.
>
> Axel
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> _______________________________________________
> Sifter-l mailing list
> Sifter-l@nupedia.com
> http://www.nupedia.com/mailman/listinfo/sifter-l
>

--
"We have now sunk to a depth at which the re-statement of the obvious is
the first duty of intelligent men." --George Orwell


from_name: Erik Moeller

subject: [Wikitech-l] TeX, version 2

body:
Tomasz,

perhaps I have missed something, but where can I find this texvc you are
using? Google turns up nothing.

Regards,

Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de