subject: [Wikipedia-l] Edit Wars

body:
Although I just expressed support for KQ's banning the Bible bot,
in general I have a strong revulsion to banning individuals
for individual reasons.  If threats get people banned,
then we should have a specific policy that says so,
and ban people on the grounds of that policy.

I wasn't around for 24, but I've read some his stuff
on talk pages and meta, and I must say that he disgusts me.
I take much of what he writes as a personal insult,
because he claims political alliance with ideas that I support
(such as distributive democracy, for example),
although his actions show these claims to be complete lies.
(For example, ordinary users' editing his remarks is democracy,
while setting up revolutionary commissars to reeducate people --
something that he suggested a few places although not in those words --
is not.)

Nevertheless, I think that he should be unbanned ''now''.
That's the default action without a reason not to,
and the fact that it's more pleasant without him is no such reason.

We can, of course, have a policy to ban people that make threats
(although I don't think that this is a good idea in general)
or people that a community consenus agrees are consistently biased
and refuse to work with others (very difficult to implement).
If he runs afoul of policy, then we can treat him like a vandal.
But we shouldn't ban him for personal reasons.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


list: wikipedia-l

source: pipermail-mbox

from_name: Toby Bartels

subject: [Wikipedia-l] Parsing TeX

body:
Jan Hidders wrote:

>Note that I was talking about math *expressions* and not about simple
>variable names! For simple variable names the required knowledge of LaTeX is
>going to be near zero.

And are they going to know that if we tell them that $$ invokes LaTeX?
They'll know if we tell them to put $$ around variable names.

>I would even argue that always using the TeX markup
>makes things simpler there. An example in your notation:

>  .. let $$v1$$, ..., $$vn$$ be a finite list ..

There are many versions of "my notation" around, but this is none of them.

  .. let <var>v</var>1, ..., <var>v</var><var>n</var> be a finite list ..

This is what I write now, and the HTML that we should produce.

  .. let $$v$$1, ..., $$v$$$$n$$ be a finite list ..

This is where $$ parses as <var>.

  .. let $$v$$_{1}, ..., $$v$$_{$$n$$} be a finite list ..

This is with a wiki notation for subscripts too.

  .. let [[math:v_1, \ldots, v_n]] be a finite list ..

This calls LaTeX to create a PNG stored in a [[math:]] namespace.

>and in mine:

> .. let [$v_1$], ..., [$v_n$] be a finite list ..

Other than the suboptimal TeX (which may be preferable in our context,
since we want to allow for line breaks from time to time),
this is like the [[math:]] namespace, as you know.
The question is, how do we tell people to write like that?
We can't say "Put [$ and $] around math expressions.",
because it isn't that simple, and things won't come out right.
We can't say "Put [$ and $] around a math expression to call LaTeX.",
because it isn't that difficult, and people won't want to try it.

Do you want to write up all of the LaTeX that we use?

>Note that all that I'm arguing here is that we have one markup for math and
>not two (one for <var> and one for LaTeX).

I'd rather have two markups for math than one that won't get used.
I think that we have a long way to go before getting a good LaTeX system.
But we can implement <var> support (and  and  support) much sooner.

----

OK, new suggestion.

There really are two different kinds of math expression,
one kind mosly used for short things, one kind mostly for complicated stuff.
These are inline equations (TeX $) and displayed equations (TeX $$).
One possibility is to use wiki markup for <var> and the like inline
and [[math:]] calling LaTeX for displayed equations.
We wouldn't be able to write $\int_a^b f(x)\,dx$ inline,
but I don't think that that's much of a problem.

I haven't thought this one through all the way.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


subject: [Wikipedia-l] policy suggestion: SAMPA

body:
Brion Vibber wrote:

>Toby Bartels wrote:

>>IANAB (I am not a Brit), but I think that you are wrong.
>>But this doesn't invalidate your ultimate point;
>>it just means that the guide should say "CHAHP-ek" instead.

>Great! Then please change it.

Done.

>>Brion Vibber wrote:

>>>See [[Clitoris]] for an example: it has a link to [[SAMPA|pronounced]],
>>>a SAMPA representation (correctly in [phonetic transcription brackets]),
>>>an approximation in English orthography, and a wav file (should it be an
>>>ogg?).

>>How are the phonetic brackets correct?  *I* don't pronounce it that way!
>>But change it to phonemic slashes, and suddenly I do.
>>Unless we're describing distinct dialects, brackets will always be wrong.

>Is the wav file incorrect, then? It's much more precise and dialect-
>specific, including detail that the phonetic transcription does not.

The wav file is fine (although it disagrees with the bracketed transcription).
But it's obvious that this is just one person's pronunciation.
Sure, it's obvious that the bracketed transcription is just one dialect,
but why are we trying to claim more precision than is justified?
There's no way for a recording to give less precision than
the sound of a single, unique, ultimately unreproduceable utterance,
but there's an easy way to make a phonetic transcription give less precision,
and that's to use slashes to indicate that the transcription is phonemic.

Even that may be too precise for a language as broadly varying as English,
but it should do in this case, and in many others.

And what dialect is that bracketed transcription supposed to be anyway?
Or is the lack of aspiration on the [k] a mistake?

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


from_name: Fred Bauder

subject: [Wikipedia-l] Easton's Bible Dictionary

body:
Well this was always a marginal project, but might as well make some
lemonade...

The thing to do is to edit that concordance, better references to an olive
branch, for example, along with an explanation of the symbolism might be
useful. I think all of the entries will need serious editing; just have to
jump in with those shears, at least they are not the product of some other
wikipedian's careful if misguided effort, so no one around to get sore.

Fred

>Another question: at what point do we decide that we don't need this, because
>it's not important to the article in question.
>
>We *have* a good article on [[olive]]s, for example: is there any good
>reason to
>toss in the bible concordance at the bottom?
>--
>Vicki Rosenzweig
>vr at redbird.org
>http://www.redbird.org
>
>[Wikipedia-l]
>To manage your subscription to this list, please go here:
>http://www.nupedia.com/mailman/listinfo/wikipedia-l


from_name: Ray Saintonge

subject: [Wikipedia-l] Easton's Bible Dictionary

body:
Vicki Rosenzweig wrote:

> We *have* a good article on [[olive]]s, for example: is there any good
> reason to
> toss in the bible concordance at the bottom?

Probably not.  When this sort of thing shows up all we can do is see if
it adds anything to the article, integrate the valuable information (if
any) and dump the rest.

For [[olive]]s, as for [[tax]]es where I did a little work to integrate
Easton, the biblical references are only incidental to the main subject.
 As much as I may believe that references are valuable, I don't think we
need them for every minor point in an article.  If we find biblical
references useful there's an established way to cite them without the
secondary reference to Easton.

Eclecticology


from_name: lcrocker at nupedia.com

subject: [Wikipedia-l] Transitioning toward a clean wiki syntax.

body:
> I think parsing [http://www.someurl.com] as <a
> href="http://www.someurl.com">[1]</a> is very useful
> for documenting sources within articles, particularly
> quotes from web-accessible material. See the
> breastfeeding article, for example.

But you can still do that with [http://... (1)] (or
[http://...|(1)] -- I plan to allow the use of "|" to be
consistent with internal link syntax).

> Would it be possible to have [http://www.someurl.com
> description] expanded in the printable version?

That's certainly doable, but I think I'll just make the
conversion do this:

  [http://...]   ==>  [http://...|(1)]
  http://...     ==>  [http://...]

And since the latter will print the URL, the functionality
won't change much.


from_name: Vicki Rosenzweig

subject: [Wikipedia-l] Easton's Bible Dictionary

body:
Another question: at what point do we decide that we don't need this, because
it's not important to the article in question.

We *have* a good article on [[olive]]s, for example: is there any good
reason to
toss in the bible concordance at the bottom?
--
Vicki Rosenzweig
vr at redbird.org
http://www.redbird.org


from_name: daniwo59 at aol.com

subject: [Wikipedia-l] Easton's Bible Dictionary

body:
In a message dated 8/9/2002 8:59:22 AM Eastern Standard Time,
daniel at copyleft.no writes:

>
> On Fri, 9 Aug 2002, Toby Bartels wrote:
>
> > This means that I'm coming out against Neil's plan entirely.
> > As I mentioned under the last heading, his intentions were good,
> > but the plan itself, not just the execution, was IMO flawed.
> > If we want to use the EBD to write Biblically themed articles,
> > then that's great, and I don't expect Neil to do it all himself,
> > but we should set up a Bible article writing group to do it,
> > with human editing for each entry before it appears (in the [[:]]
> namespace).
>
> I agree. The automatic committing of articles from out dated works should
> stop.
>
> -- Daniel
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
>

Also agree. I don't think these articles are worth very much
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020809/76c5806c/attachment.htm


subject: [Wikipedia-l] Re: MetaTree

body:
>> Then just add links.

> One word: spaghetti. Just because it's a web, it doesn't mean it
> can't be a cleanly organized web.

Sometimes--in fact frquently--spaghetti is /better/ than structure,
because the subject being described really is spaghetti-like. I
have no problem with organization per se; I reorganized the policy
pages to make things easier to find.  But I /don't/ think we should
impose structure for its own sake unless there's a real problem.


from_name: Daniel Mayer

subject: [Wikipedia-l] Re: EBD and bots

body:
Toby Bartels wrote:

>It's unreasonable for people to copy in
>these old texts, include a warning that
>the material may be biased or out of date,
>and then expect somebody watching
>Recentchanges to fix them. If I create
>or edit an entry, then *I* am responsible
>for checking that the material is neutral
>and accurate. This isn't asking for
>perfection, a standard that I don't meet
>anyway, but for a reasonable human judgement
>that the material is good. Mass copying,
>whether by a script or not, whether filtered
>or not, doesn't provide this.

I agree completely. We already have over 35,000
articles and we have done this in year an a half - if
anything we should be concentrating on quality not
quantity at this point. One thing we have is a lot of
is articles. Another thing we have is a lot of are
stubs that need to be fixed. Yet another thing we have
gobs of is unimproved 1911 and other public domain
text that also needs to be fixed. Need we pile on a
lot more at this point with automatic uploads? This
made perfect sense a year ago when there were many
major chunks of human knowledge missing from the
'pedia but is no longer the case (at least in terms of
what is being uploaded -- we already have lots of that
type of stuff).

>If we want to use the EBD to write Biblically
>themed articles, then that's great, and I don't
>expect Neil to do it all himself, but we should
>set up a Bible article writing group to do it,
>with human editing for each entry before it
>appears (in the [[:]] namespace).

It sounds like the EBD would be an excellent resource
for a themed WikiProject -- participants would
rewrite, NPOVize, improve and expand the EBD text.
Remember part of what we are doing here is community
building -- bots don't make for very good community
members. Humans should be the ones that review, fix
and expand content before uploading it.

But then I'm not sure how we could prevent bots from
doing what they do without also preventing humans who
happen to use text browsers to edit the pedia (banning
bots in general would be nice in the vandal prevention
dept. though). Perhaps all we could do is have a
stated policy on this.

--mav

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com


subject: [Wikipedia-l] Discussion forum for bugs/features

body:
Under Phase II, we used [[Bug reports]] and [[Feature requests]]
not merely to list desired features and undesired bugs
but also to talk about them in a wiki way.
Under Phase III, we instead use SourceForge for this.
But SourceForge doesn't lend itself to discussion.
Because Lee is essentially the only programmer,
he will close an entry there if he doesn't want to do it.
Of course, we know that he's willing to be convinced,
but there's not much chance of that if there's no discussion.

There are alternatives.
[[Bug reports]] and [[Feature requests]] still exist,
but nobody has used them since the change,
and I doubt that very many people are watching them.
Much discussion of features has taken place on this list,
but that doesn't reach nearly as wide an audience as before.
Most people that submit an item to SourceForge
aren't going to think to take it up on the list.

In short, I think that we miss the discussion that we had in Phase II.
We need a place for people to submit items for Wikipedians' approval
other than SourceForge, but we need to use SourceForge too.
Ideas?

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


body:
> The difference is that the automatic numbering is lost. It's a
> serious difference, in that it pretty much ensures that people
> will stop using that notation.

> If we don't think the numbered url references are useful, then
> it's fine that it's being lost.

Yes, that's pretty much the issue I agree.  From my point of view,
it's good riddance.  I didn't much like the feature (I think every
link should be described in place), so I have no problem getting
rid of it.  But if there are lots of other people who think it's
the greatest thing since sliced bread and can convince me that it's
vitally needed for something, then I'll reconsider.


from_name: Brion VIBBER

subject: [Wikipedia-l] policy suggestion: SAMPA

body:
Toby Bartels wrote:
> The wav file is fine (although it disagrees with the bracketed transcription).
> But it's obvious that this is just one person's pronunciation.
> Sure, it's obvious that the bracketed transcription is just one dialect,
> but why are we trying to claim more precision than is justified?
> There's no way for a recording to give less precision than
> the sound of a single, unique, ultimately unreproduceable utterance,
> but there's an easy way to make a phonetic transcription give less precision,
> and that's to use slashes to indicate that the transcription is phonemic.
>
> Even that may be too precise for a language as broadly varying as English,
> but it should do in this case, and in many others.
>
> And what dialect is that bracketed transcription supposed to be anyway?
> Or is the lack of aspiration on the [k] a mistake?

Alright, you caught me; stick with the phoneme slashes.

-- brion vibber (brion @ pobox.com)


from_name: Krzysztof P. Jasiutowicz

subject: [Wikipedia-l] Re: MetaTree

body:
On 08-08-2002, Daniel Mayer wrote thusly :
> On Thursday 08 August 2002 08:20 pm, tarquin wrote:
> > The reasoning was fairly simple: Wikiprojects are organized in a
> > hierarchy. Naming conventions are increasingly hierarchic too.
> > When I create a page, I seek information about how to name it and how to
> > present it. It's stupid having to career halfway across the Wikipedia to
> > find those two pieces of information.
[snip]
> "conventions". As a matter of fact, I do not want us to have /any/ content
> convention other than NPOV -- anything more will tend to stifle innovation
> (consistency is nice, and I do strive for that, but it should /not/ be in any
> way confused with policy).
[snip]

I sympathise with Tarquin. There seems to be a need for
1. conventions - sparing us the tedious task of renaming lots of articles'
names, giving Wikipedia consistency that is needed more for casual readers
but for regulars
2. IMO there is need for some meta information. The idea has been already
mentioned and generally refuted as "a bad thing". However, now we have 36k
articles, and with 100k+ ? Wouldn't we drown in a kind of information soup
? The process of classification is going on constantly. There are numerous
lists and lists of lists. I am not advocating imposing some strict rules
but to gradually improve and implement meta-info in some sort of
unobtrusive way like the software upgrade has been.
Once we had Manning with us. I suppose he is a meta information
professional.

As a side note, Wikipedia is growing (not a grown-up yet) and there is
accumulating more and more outdated information (probably in Wikipedia:
namespace mostly) examples are Wikipedia NEWS, Most popular pages etc
I think there is a need for putting some information on Wikipedia and
META Wikipedia into a "historical" perspective.

Best wishes,
kpj.

P.S I dropped in on Wikipedia chat yesterday but it was stagnant.
That was because Wikipedians' main passtime is writing and copy editing
articles. Silly me ;-))


from_name: tarquin

subject: [Wikipedia-l] Re: MetaTree

body:
Daniel Mayer wrote:

>On Thursday 08 August 2002 08:20 pm, tarquin wrote:
>
>
>>The reasoning was fairly simple: Wikiprojects are organized in a
>>hierarchy. Naming conventions are increasingly hierarchic too.
>>When I create a page, I seek information about how to name it and how to
>>present it. It's stupid having to career halfway across the Wikipedia to
>>find those two pieces of information.
>>
>>
>
>Then just add links.
>
One word: spaghetti. Just because it's a web, it doesn't mean it can't
be a cleanly organized web.

I'm afraid I can't explain it any more simply than I have on
http://meta.wikipedia.com/wiki.phtml?title=Presentation+Conventions ,
but I shall endeavour to try:

For each subject area, and for each "class" of page (eg chemical element
pages, people, ships etc), there are several different pieces of
meta-information. They are:
* what should be covered in this area? what are the priorities?
* what's the scheme for naming pages in this area, or in this class?
* conventions for presentation: is there, should there be, or what is
the agreed layout style?
* is there a group of Wikipedians who intend to flesh out this area?
* ... we may find the need to other things in the future

It merely seems good refactoring style to bring all those together.

>Also keep in mind that the only content policy we have is NPOV (everything
>else is just a 'rule to consider') -- I do not want to have WikiProject
>guidelines even to begin to appear as if they are a kind of content policy
>
I absolutely agree.
This is not about restricting new content.
We don't expect people to produce fully-fledged articles on their first
edit, or the grammar, spelling or typing to be perfect -- I'm not
questioning that at all, and in fact I agree with it.
However, there is a lot of cleaning up work going on, and part of that
involves harmonizing presentation. Articles about people are a good
example: I have seen half a dozen or so ways of presenting a person's
name, dates of birth & death and principal achievements. That doesn't
diminish the value of the content, and consistency in look & feel should
be very low on our priorities. But I am not the only one who takes
random walks through the Wikipedia & tidies up what (s)he finds -- while
I'm fixing typos or rewriting for clarity I might as well take care of
the formatting too -- *if* I knew what the agreed conventions were.

I hope I've not been misunderstood: I am *not* trying to impose or set
out new style rules in these pages on Meta. I'm trying to bring together
existing conventions, and set out a forum where debates about style can
take place.

>Also troubling is the term "Presentation Conventions" which is /far/ too
>similar to "naming conventions" and will cause confusion with newbies about
>the importance that naming conventions have in relation to any presentation
>"conventions".
>
Agreed. The name "Presentation Conventions" is gone, as far as I'm concerned. It was a poor choice. I haven't got round to renaming the page on Meta, that's all.

>As a matter of fact, I do not want us to have /any/ content
>convention other than NPOV -- anything more will tend to stifle innovation
>(consistency is nice, and I do strive for that, but it should /not/ be in any
>way confused with policy).
>
*Being consistent* must not be policy, but *what* the consistency is, should one choose to be consistent -- there's got to be a consensus, otherwise it's not consistent!
I get the impression we're looking at this from opposite angles:

You (seem to) think these pages will say:
  "here are the presentation rules! obey them!"
I want them to say:
  "*if* you wish to be consistent in presentation (and naming, etc), here are the agreed guidelines *and* the place to debate them"

regards
- tarquin


subject: [Wikipedia-l] Search - problems

body:
On 08-08-2002, lcrocker at nupedia.com wrote thusly :
> >> Using lynx to change the number of displayed entries gives
> >> "Bad request error".
> >> I think the extra space character is the culprit.
> >> http://www.wikipedia.com/w/wiki.phtml?search=History
> &limit=50&offset=0
> I can't see how you managed to enter that extra space.  Spaces
> are illegal in URLs, and I couldn't find any way to get Lynx to
> let me enter one.  The links on the page are correct, the code
> does exactly the right thing, and even when I typed in the URL
> manually Lynx removed the space for me.
I was not entering the link manaully, I followed it and the above link
is copypasted from the Lynx's address line.
> In any case there's nothing I can do--you are in fact making
> an illegal request, and software is correctly reporting that fact.
> If the software were itself /generating/ a bad link or someting,
> then that would be a bug.
I can't reproduce the bug today. Never mind.

Regards,
kpj.


body:
>> In short, I think that we miss the discussion that we had
>> in Phase II.  We need a place for people to submit items for
>> Wikipedians' approval other than SourceForge, but we need to
>> use SourceForge too.  Ideas?

> Use bugzilla instead, which lends itself to discussion.

I'm certainly open to that; does anyone here have any experience
setting that up?


body:
Toby Bartels wrote:
> Under Phase II, we used [[Bug reports]] and [[Feature requests]]
> not merely to list desired features and undesired bugs
> but also to talk about them in a wiki way.

I can assure you, that was completely untenable. The pages quickly
because so long and unwieldy that they were hard to edit; half the time
they got truncated by someone with a buggy browser; it was hard to find
some particular item of interest; something that didn't get implemented
got quickly lost and forgotten in the huge pile of text...

Good riddance.

> Under Phase III, we instead use SourceForge for this.
> But SourceForge doesn't lend itself to discussion.

If you login with your e-mail address, any comments tacked onto your bug
report/feature request are e-mailed directly to you. If that's not
lending to discussion, what is?

> Because Lee is essentially the only programmer,
> he will close an entry there if he doesn't want to do it.
> Of course, we know that he's willing to be convinced,
> but there's not much chance of that if there's no discussion.

I also check those fairly regularly, and can and have reopened items
where I disagree with Lee.

> There are alternatives.
> [[Bug reports]] and [[Feature requests]] still exist,
> but nobody has used them since the change,
> and I doubt that very many people are watching them.

Thank goodness!

> Much discussion of features has taken place on this list,
> but that doesn't reach nearly as wide an audience as before.
> Most people that submit an item to SourceForge
> aren't going to think to take it up on the list.
>
> In short, I think that we miss the discussion that we had in Phase II.
> We need a place for people to submit items for Wikipedians' approval
> other than SourceForge, but we need to use SourceForge too.
> Ideas?

Some have suggested bugzilla; I have no experience with it, nor do I
know whether it will be any easier than the Sourceforge tracker to deal
with.

-- brion vibber (brion @ pobox.com)


from_name: Tom Parmenter

subject: [Wikipedia-l] Easton's Bible Dictionary

body:
|From: "Hr. Daniel Mikkelsen" <daniel at copyleft.no>
|Date: Fri, 9 Aug 2002 15:58:16 +0200 (CEST)
|
|On Fri, 9 Aug 2002, Toby Bartels wrote:
|
|> This means that I'm coming out against Neil's plan entirely.
|> As I mentioned under the last heading, his intentions were good,
|> but the plan itself, not just the execution, was IMO flawed.
|> If we want to use the EBD to write Biblically themed articles,
|> then that's great, and I don't expect Neil to do it all himself,
|> but we should set up a Bible article writing group to do it,
|> with human editing for each entry before it appears (in the [[:]] namespace).
|
|I agree. The automatic committing of articles from out dated works should stop.
|
|-- Daniel
|

No batch procedure for content can be relied on to produce good
articles.

Tom Parmenter
Ortolan88


from_name: Karen AKA Kajikit

subject: [Wikipedia-l] Mh hammer |1.jpg

body:
Pierre Abbat wrote:
>
> The listing of this file has twice been removed from the votes for deletion,
> once by Andre Engels and once by Kaji, both with a note that they are
> removing from the list pages that have been removed from the server. The file
> still exists. The link doesn't work; it shows up as "1.jpg" and when you
> click on it it takes you to "Image:Mh hammer ", which doesn't exist. Should
> this be removed or not?

I just did my best to delete it! If it didn't want to go it's not my
fault... (seriously, I went to the page and said 'delete the image' and
it said it had, then I said 'delete the page' and it said it had.) There
seems to be a bug related to image pages - if you delete the image page
but there is a link to it somewhere, the link will always show up as a
valid page, only when you go there it contains no content.

--

Karen AKA Kajikit

And on the seventh day, God said 'What my world needs is a creature that
will truly appreciate it in all its facets' -
and so He made the kitten.

Come and visit my part of the web:
Kajikit's Corner: http://Kajikit.netfirms.com/
Aussie Support Mailing List: http://groups.yahoo.com/group/AussieSupport
Allergyfree Eating Recipe Swap:
http://groups.yahoo.com/group/Allergyfree_Eating
Ample Aussies Mailing List: http://groups.yahoo.com/group/ampleaussies/

Love and huggles to all!


subject: [Wikipedia-l] Mh hammer |1.jpg

body:
Pierre Abbat wrote:
>
> The listing of this file has twice been removed from the votes for deletion,
> once by Andre Engels and once by Kaji, both with a note that they are
> removing from the list pages that have been removed from the server. The file
> still exists. The link doesn't work; it shows up as "1.jpg" and when you
> click on it it takes you to "Image:Mh hammer ", which doesn't exist. Should
> this be removed or not?

Oh... I get it now - somebody uploaded an image with the | character in
the title, so it's basically irremovable :(

There should be something to prevent this... if a filename contains
illegal characters it should tell you to rename it before uploading.

--

Karen AKA Kajikit

And on the seventh day, God said 'What my world needs is a creature that
will truly appreciate it in all its facets' -
and so He made the kitten.

Come and visit my part of the web:
Kajikit's Corner: http://Kajikit.netfirms.com/
Aussie Support Mailing List: http://groups.yahoo.com/group/AussieSupport
Allergyfree Eating Recipe Swap:
http://groups.yahoo.com/group/Allergyfree_Eating
Ample Aussies Mailing List: http://groups.yahoo.com/group/ampleaussies/

Love and huggles to all!


from_name: The Cunctator

body:
On 8/9/02 12:10 PM, "lcrocker at nupedia.com" <lcrocker at nupedia.com> wrote:

>
>> I think parsing [http://www.someurl.com] as <a
>> href="http://www.someurl.com">[1]</a> is very useful
>> for documenting sources within articles, particularly
>> quotes from web-accessible material. See the
>> breastfeeding article, for example.
>
> But you can still do that with [http://... (1)] (or
> [http://...|(1)] -- I plan to allow the use of "|" to be
> consistent with internal link syntax).
>
>> Would it be possible to have [http://www.someurl.com
>> description] expanded in the printable version?
>
> That's certainly doable, but I think I'll just make the
> conversion do this:
>
> [http://...]   ==>  [http://...|(1)]
> http://...     ==>  [http://...]
>
> And since the latter will print the URL, the functionality
> won't change much.
>
The difference is that the automatic numbering is lost. It's a serious
difference, in that it pretty much ensures that people will stop using that
notation.

If we don't think the numbered url references are useful, then it's fine
that it's being lost.

But it's incorrect to believe that removing the automatic numbering won't
eliminate the usage.


body:
> Having [someurl] turn automatically into [1] is an elegant
> solution.  The heedless coder leaves a clean external link
> behind, not a godawful URL, which might be two lines long and
> rife with % signs, and the careful coder has a choice of simple
> footnote or prettified link.

Yeah, that's a pretty good argument.

How about this:

[http://www...] renders (a href="http://www...")[1](/a) with
autonumbering, [http://www...|text] renders (a href="http://www...")
text(/a) (the pipe can optionally be a space), and [http://www...|]
(note trailing pipe) expands to [http://www...|www...] ?


body:
On 8/9/02 2:12 PM, "Toby Bartels" <toby+wikipedia-l at math.ucr.edu> wrote:
> In short, I think that we miss the discussion that we had in Phase II.
> We need a place for people to submit items for Wikipedians' approval
> other than SourceForge, but we need to use SourceForge too.
> Ideas?

Use bugzilla instead, which lends itself to discussion.


from_name: Sean Barrett

body:
"We're going to need a real markup syntax, consistent, predictable,
documented, bug free, and with all the features needed..."

But we MUST NOT violate the sacred principle of Not Invented Here, which
strictly forbids the use of the markup language that has real markup
syntax, consistent, predictable, documented, bug free, and with all the
features needed ... HTML.

</sarcasm>

-----Original Message-----
From: wikipedia-l-admin at nupedia.com
[mailto:wikipedia-l-admin at nupedia.com]On Behalf Of lcrocker at nupedia.com
Sent: Friday, August 09, 2002 15:01
To: wikipedia-l at nupedia.com; The Cunctator
Subject: Re: Re: [Wikipedia-l] Transitioning toward a clean wiki syntax.

>> How about this:
>>
>> [http://www...] renders (a href="http://www...")[1](/a)
>> with autonumbering, [http://www...|text] renders (a
>> href="http://www...")text(/a) (the pipe can optionally
>> be a space), and [http://www...|] (note trailing pipe)
>> expands to [http://www...|www...] ?

> Why not just render
> http://www... as www... ? I've done that for my own wikis
> and it looks very nice, also for mailto:'s etc.

If we just keep adding and adding more wiki syntax on top of
the old, we'll end up with an incomprehensible mess and code
that's impossible to debug.  We're going to have to simplify
the markup before we extend it, and interpreting URLs outside
of brackets is the most egregious problem in my opinion--it's
an exception to the other forms of markup, it causes the
punctuation problem, and it causes real coding headaches (like
the bug of URLs with contained URLs, for example).

For a small, limited-purpose wiki, a limited feature set is fine
and it doesn't matter if the markup language--which doesn't need
to have a lot of features--is a bit awkward.  But we've outgrown
that.  We're going to need a real markup syntax, consistent,
predictable, documented, bug free, and with all the features
needed for a complete general-purpose encycopedia.

Far better we should go through the pain of adjustment that will
entail now, than later after we've got even more people to confuse.

[Wikipedia-l]
To manage your subscription to this list, please go here:
http://www.nupedia.com/mailman/listinfo/wikipedia-l


body:
>> How about this:
>>
>> [http://www...] renders (a href="http://www...")[1](/a)
>> with autonumbering, [http://www...|text] renders (a
>> href="http://www...")text(/a) (the pipe can optionally
>> be a space), and [http://www...|] (note trailing pipe)
>> expands to [http://www...|www...] ?

> Why not just render
> http://www... as www... ? I've done that for my own wikis
> and it looks very nice, also for mailto:'s etc.

If we just keep adding and adding more wiki syntax on top of
the old, we'll end up with an incomprehensible mess and code
that's impossible to debug.  We're going to have to simplify
the markup before we extend it, and interpreting URLs outside
of brackets is the most egregious problem in my opinion--it's
an exception to the other forms of markup, it causes the
punctuation problem, and it causes real coding headaches (like
the bug of URLs with contained URLs, for example).

For a small, limited-purpose wiki, a limited feature set is fine
and it doesn't matter if the markup language--which doesn't need
to have a lot of features--is a bit awkward.  But we've outgrown
that.  We're going to need a real markup syntax, consistent,
predictable, documented, bug free, and with all the features
needed for a complete general-purpose encycopedia.

Far better we should go through the pain of adjustment that will
entail now, than later after we've got even more people to confuse.


from_name: Michael R. Irwin

subject: [Wikipedia-l] Revision Control H2G2.com

body:
Stephen Gilbert wrote:
>
> --- lcrocker at nupedia.com wrote:
>
> > But again, I think it needs to develop in a
> > centralized way for
> > a while before risking that.  I may be labelled a
> > heretic for
> > saying this, but part of what make Wikipedia great
> > is its /lack/
> > or freedom and universal participation.  Everything2
> > showed us
> > what that devolves into.  We have a central goal
> > here--a narrow
> > focus, and people to keep the masses pointed in the
> > right direction.
>
> Yeah, I think that's kind of heretical. But you write
> good articles *and* software, so I'll engage in some
> religious tolerance. :)
>
> Has anyone ever surfed around H2G2.com? Its entries
> seem to be of consistantly better quality than most of
> Everything2, and they have a peer-review system in
> place. I'm going to poke around there a bit and see if
> they have any useful techniques that could be adapted
> to Wikipedia. Fishing out a few new Wikipedians
> wouldn't hurt either.

I browsed around H2G2 a bit.  I agree, the "peer" reviewed
writing quality seemed good given the starting focus of Life,
the Universe, and Everthing from "The Hitchhiker's Guide
to the Galaxy".

The "peer" review scheme appears to be a top down controlled
hiearchy.  Essentially they are using site volunteers to reduce
staff writing/editing workload while retaining all authority
at the top (inhouse paid staff).  Draft or proposed material
is available in special collaboration or viewing rooms for site
goers who wish to view it.   The proposed material works it way
upward as it is noticed and approved by the hiearchy. The focus
is on entertaining material well written in a consistent site style.

In addition to promoting the material, some reviewers can bounce
the material down the pyramid to a level matching their
perception of its state of readiness.  There is a garbage collection
room named the "Flea Market" where abandoned draft work is
accumulated either automatically or manually for adoption.

I did not see anything that looked easily adaptable to Wikipedia
or wikis in general but I have not created an account and used
their editing and collaboration tools yet.

regards, mirwin


in_reply_to:
<B9797A77.27E6%cunctator@kband.com> (message from The Cunctator
	on Fri, 09 Aug 2002 13:56:07 -0400)

body:
Having [someurl] turn automatically into [1] is an elegant solution.
The heedless coder leaves a clean external link behind, not a godawful
URL, which might be two lines long and rife with % signs, and the
careful coder has a choice of simple footnote or prettified link.

Tom Parmenter
Ortolan88


from_name: Hr. Daniel Mikkelsen

subject: [Wikipedia-l] Easton's Bible Dictionary

body:
On Fri, 9 Aug 2002, Toby Bartels wrote:

> This means that I'm coming out against Neil's plan entirely.
> As I mentioned under the last heading, his intentions were good,
> but the plan itself, not just the execution, was IMO flawed.
> If we want to use the EBD to write Biblically themed articles,
> then that's great, and I don't expect Neil to do it all himself,
> but we should set up a Bible article writing group to do it,
> with human editing for each entry before it appears (in the [[:]] namespace).

I agree. The automatic committing of articles from out dated works should stop.

-- Daniel


subject: [Wikipedia-l] Meta-Tree

body:
Stephen Gilbert wrote:
>
> I think the method we've been using since the
> beginning is pretty good. It is as follows:
>
> 1. Propose a convention.
> 2. Discuss the convention with any interested parties.
> Note objections and proposed improvements.
> 3. If most people agree, start using the convention.
> 4. If it's not working, or if Wikipedians don't find
> the convention useful, stop using it.
>
> Rules and bureaucracy would just kill the organic
> development that we have here.

The method proposed merely counted supporters.  The
use of the word rule was unfortunate.  Its intended
meaning was similar to the existing guidelines of
which one is to disregard guidelines as per personal
preference.

Automated information reporting is not bureaucracy.

It is empowerment.  The individual user choosing to
exercise personal preference has better information to
judge potential consequences which may result from the
community at large.

To a newcomer a list of 5 or 6 handles may be deceptive if
they have perused the Wikipedian list page.  Five or six
out of hundreds is not terribly influential.

Whereas 10 to 50 percent of active editors or participatory
voters taking time to judge the rules is substantial and
likely to matter in the stacks.

regards, mirwin


from_name: Neil Harris

subject: [Wikipedia-l] Easton's Bible Dictionary

body:
Andre Engels wrote:

>My opinion is that automatic uploading of such texts is a bad thing, but for
>slightly different reasons. My problem is that automatic uploading brings 'the
>good, the bad and the ugly'. Some EBD articles form a good basis for a
>Wikipedia article, others are of little use (I don't think we want the EBD
>entry on Egypt, nor do we want an article from a 1911 encyclopedia on
>Ljubljana, stating that it is a city in the Austria-Hungarian empire). Someone
>who wants to upload material from a source like the EBD should him/herself
>make the selection as to which entries are interesting for Wikipedia, not
>brush that responsibility onto the community after the fact or upload
>everything just because it is there.
>
>Andre Engels
>
>
>[Wikipedia-l]
>To manage your subscription to this list, please go here:
>http://www.nupedia.com/mailman/listinfo/wikipedia-l
>
>
>
Ok, there seems to be a consensus in the most recent comments that this
is a now a bad thing, so I've stopped uploading the articles. I think
there are some interesting lessons to be learned.

* auto-uploading is a mixed blessing
* some of the articles were rather interesting
* some were dross
* automatic content filtering was only partially successful
* uploading rapidly is bad: Wikipedia's NPOV processes can only
assimilate a certain rate of addition of added content
* it seems to have stimulated a fair bit of editing of non-uploaded
articles: creating a sort of "theme day" for Wikipedia
* auto-Wikification is more difficult than it at first seems

This was a pilot for possible larger projects. Given the response, I
think I need to take a different approach: I didn't anticipate the load
on the community's goodwill.

The PD NIH disease factsheets are the ideal target for this sort of
work: Easton's was a sort of dry run for the idea.

How about, as was suggested before by someone else, a new namespace:
something like "PDresource:" that can be used by auto-uploaders to get
PD info into a Wikified format without polluting the main namespace, but
can then be used as source material for the 'pedia by human contributors.

That way, the effort can be split: the natural thing to do with
auto-uploading _is_ massive data-dumps at a time, and this would benefit
the human contributors by getting a lot of text into a suitable format,
ready for human selection.

Neil


subject: [Wikipedia-l] Easton's Bible Dictionary

body:
"Hr. Daniel Mikkelsen" wrote:
>
> On Fri, 9 Aug 2002, Toby Bartels wrote:
>
> > This means that I'm coming out against Neil's plan entirely.
> > As I mentioned under the last heading, his intentions were good,
> > but the plan itself, not just the execution, was IMO flawed.
> > If we want to use the EBD to write Biblically themed articles,
> > then that's great, and I don't expect Neil to do it all himself,
> > but we should set up a Bible article writing group to do it,
> > with human editing for each entry before it appears (in the [[:]] namespace).
>
> I agree. The automatic committing of articles from out dated works should stop.
>

I also found Toby's reasoning persuasive in the context of our
current approach to content management.   I would have no problem with
material automatically loading into a draft area for random users
or Wikipedians to review and edit at their leisure.

regards, mirwin


from_name: Jan Hidders

subject: [Wikipedia-l] Easton's Bible Dictionary

body:
On Fri, Aug 09, 2002 at 03:58:16PM +0200, Hr. Daniel Mikkelsen wrote:
> On Fri, 9 Aug 2002, Toby Bartels wrote:
>
> > This means that I'm coming out against Neil's plan entirely.
> > As I mentioned under the last heading, his intentions were good,
> > but the plan itself, not just the execution, was IMO flawed.
> > If we want to use the EBD to write Biblically themed articles,
> > then that's great, and I don't expect Neil to do it all himself,
> > but we should set up a Bible article writing group to do it,
> > with human editing for each entry before it appears (in the [[:]] namespace).
>
> I agree. The automatic committing of articles from out dated works should stop.

I agree with Daniel and Toby here. Wikipedia is not in a big rush and
quality should go before quantity. It is great that there are such resources
out there that we can copy from, but automatically pumping them into
Wikipedia means that the natural responsibility that writers take for
correctness, NPOV-ness, et cetera, is no longer there. Even if I would copy
stuff from such resources I would still verify such things because I am putting it
in Wikipedia under my name.

-- Jan Hidders


subject: [Wikipedia-l] Easton's Bible Dictionary

body:
Fred Bauder wrote:
>
> Well this was always a marginal project, but might as well make some
> lemonade...
>
> The thing to do is to edit that concordance, better references to an olive
> branch, for example, along with an explanation of the symbolism might be
> useful. I think all of the entries will need serious editing; just have to
> jump in with those shears, at least they are not the product of some other
> wikipedian's careful if misguided effort, so no one around to get sore.

Excellent point!  That makes it more useful as a draft starting
point, particularly for newcomers learning the ropes.

regards, mirwin


from_name: Andre Engels

subject: [Wikipedia-l] Easton's Bible Dictionary

body:
> Another question: at what point do we decide that we don't need this, because
> it's not important to the article in question.
>
> We *have* a good article on [[olive]]s, for example: is there any good
> reason to
> toss in the bible concordance at the bottom?

In my opinion, in such a case the EBD entry should be scanned for interesting
information that is not in the article yet, and this should be edited in
(either the information or the text). After that the EBD text can be removed.
I have done this with [[Phoenicia]], although I have not thrown away the EBD
text YET as there might be people who are of the opinion that there is more
from it that should be added (*).

Andre Engels

(*) Basically, I only used the following facts from the EBD article, throwing
the rest of a full-page article away:
- Sometimes the Phoenicians are called 'Sidonians' rather than 'Canaanites'
  in the Bible
- Phoenicia had important trade with Asia as well, being the middle man
  between Mesopotamia and Egypt
- King Hiram II of Tyrus cooperated with Salomon in the building of his
  temple.


body:
> "We're going to need a real markup syntax, consistent, predictable,
> documented, bug free, and with all the features needed..."
>
> But we MUST NOT violate the sacred principle of Not Invented Here,
> which strictly forbids the use of the markup language that has real
> markup syntax, consistent, predictable, documented, bug free, and
> with all the features needed ... HTML.
>
> </sarcasm>

I thought I made it pretty clear that I had a lot of respect for
that viewpoint, and I don't intend to make up new sytaxes for
everything; indeed, I plan to eliminate a few of the current
extras we have, adopt CSS in its entirety unmodified for stylesheets,
and only use wiki syntax for those parts of HTML that are
simply broken or don't work for the wiki.  I'm sorry, but tables
are hopelessly complex for new users, as are tags with attributes,
HTML tags for style, and some other things.

Little things like "(br)" and "(i)" will remain wiki syntax (but
simplified: "(i onClick='deleteDatabase()')" will NOT be legal
wiki styntax!), and character entity refs with "&" will not change.

I think it's quite possible to make a wiki syntax that does
everything I mention above, and be simpler, smaller, and easier
to use for both experts and novices.  I really think it can be
done, but it will take some hard work and making a few hard
choices.


subject: [Wikipedia-l] Easton's Bible Dictionary

body:
> I agree with Daniel and Toby here. Wikipedia is not in a big rush and
> quality should go before quantity. It is great that there are such resources
> out there that we can copy from, but automatically pumping them into
> Wikipedia means that the natural responsibility that writers take for
> correctness, NPOV-ness, et cetera, is no longer there. Even if I would copy
> stuff from such resources I would still verify such things because I am putting it
> in Wikipedia under my name.

My opinion is that automatic uploading of such texts is a bad thing, but for
slightly different reasons. My problem is that automatic uploading brings 'the
good, the bad and the ugly'. Some EBD articles form a good basis for a
Wikipedia article, others are of little use (I don't think we want the EBD
entry on Egypt, nor do we want an article from a 1911 encyclopedia on
Ljubljana, stating that it is a city in the Austria-Hungarian empire). Someone
who wants to upload material from a source like the EBD should him/herself
make the selection as to which entries are interesting for Wikipedia, not
brush that responsibility onto the community after the fact or upload
everything just because it is there.

Andre Engels


body:
> What if "http:" was a namespace like "user:", you would use
> [[namespace:<data>]] for all sorts of links and that would be it.
> No more bare URLs and no [URL] with single brackets.

Hmm.  That might work too, and would be even simpler. Thanks for
the suggestion--I solicit comments on that as well. I don't think
it would be too bad, though, to have an "external/internal"
separation between one-bracket and two-bracket links if your idea
has some technical problem I don't see right now.  That's pretty
simple to understand an use.


subject: [Wikipedia-l] Re: EBD and bots

body:
Daniel Mayer wrote:
>

> Remember part of what we are doing here is community
> building -- bots don't make for very good community
> members. Humans should be the ones that review, fix
> and expand content before uploading it.

I disagree.  Properly utilized, bots could be very useful
in the exact fashion that Neil is prototyping.  There is
a lot of old information lying around that belongs online
and in an encyclopedia.

The advantage of uploading the bot collected and screened
draft material is that it becomes available to all users
via the simple and known Wikipedia interface for editing.

I agree that humans should review it prior to posting
to the main namespace.

regards, mirwin


subject: [Wikipedia-l] Software updates

body:
I made a round of bug fixes and other planned software updates today;
most ofthem shouldn't even be noticeable by most of you, but one will
be, so I'm giving the militia a heads up: "Move page" is now
available to all logged in users.

Just keep an eye out for any potential abuse, and move things back if
necessary. It still takes a sysop to move things back, because you
have to delete the target, but I may be able to fix that soon.
Also, "delete" is now not as thoroughly destructive--it saves stuff
in an archive, so we don't have to walk on eggshells quite as much
about that (though it is still locked for sysops only).


subject: [Wikipedia-l] Re: EBD and bots

body:
> I agree that humans should review it prior to posting
> to the main namespace.

Our proposals for review are similar, but have slightly different
terminology and an opposite point of view: you'd like to have a
"draft" area and a "main" area with reviewed works.  In my point
of view, the main Wikipedia IS the "draft" area, and articles
that have been human-reviewed are a small specially-marked subset
of that.  At some point in our future, we might make the user
option of viewing reviewed articles only more prominent.  But I
think that's quite a ways off.


body:
On 8/9/02 5:23 PM, "lcrocker at nupedia.com" <lcrocker at nupedia.com> wrote:

>> Having [someurl] turn automatically into [1] is an elegant
>> solution.  The heedless coder leaves a clean external link
>> behind, not a godawful URL, which might be two lines long and
>> rife with % signs, and the careful coder has a choice of simple
>> footnote or prettified link.
>
> Yeah, that's a pretty good argument.
>
> How about this:
>
> [http://www...] renders (a href="http://www...")[1](/a) with
> autonumbering, [http://www...|text] renders (a href="http://www...")
> text(/a) (the pipe can optionally be a space), and [http://www...|]
> (note trailing pipe) expands to [http://www...|www...] ?

Why not just render
http://www... as www... ? I've done that for my own wikis and it looks very
nice, also for mailto:'s etc.


subject: [Wikipedia-l] Mh hammer |1.jpg

body:
lcrocker at nupedia.com wrote:
>
> > Oh... I get it now - somebody uploaded an image with the |
> > character in the title, so it's basically irremovable :(
>
> I'm obviously missing something.  There's no such image in the
> upload directory, no such entry in the database, and no such
> description page.  What is it, exactly, that you don't think has
> been deleted?

It's taken care of... I think I misunderstood AGAIN! sorry for that...

--

Karen AKA Kajikit

And on the seventh day, God said 'What my world needs is a creature that
will truly appreciate it in all its facets' -
and so He made the kitten.

Come and visit my part of the web:
Kajikit's Corner: http://Kajikit.netfirms.com/
Aussie Support Mailing List: http://groups.yahoo.com/group/AussieSupport
Allergyfree Eating Recipe Swap:
http://groups.yahoo.com/group/Allergyfree_Eating
Ample Aussies Mailing List: http://groups.yahoo.com/group/ampleaussies/

Love and huggles to all!


from_name: Ray Saintonge

body:
Toby Bartels wrote:

>Under Phase II, we used [[Bug reports]] and [[Feature requests]]
>not merely to list desired features and undesired bugs
>but also to talk about them in a wiki way.
>Under Phase III, we instead use SourceForge for this.
>But SourceForge doesn't lend itself to discussion.
>
>In short, I think that we miss the discussion that we had in Phase II.
>We need a place for people to submit items for Wikipedians' approval
>other than SourceForge, but we need to use SourceForge too.
>Ideas?
>
Toby makes a good point.  It strikes me that this is just another of
these techie/non-techie debates.  Whatever the value of SourceForge (or
Bugzilla for that matter) it still means going to another site with a
whole new set of rules and operatiung procedures.  These are certainly
essential for any system but sometimes for the non-techie even little
bumps in the road can seem like huge learning cliffs to climb.  The mere
thought of going to another site can be user unfriendly.

My guess is (and the techies can probably confirm this) that many of the
"bugs" are rooted in a user's failure to grasp some technical detail
that is second nature to another user.  If these problems are put on the
bug report page, it's also easier for another non-techie user to
respond.  The techies can scout that page as easily as anyone else, and
move it to a more technical environment as appropriate.

The argument that these pages just seemed to get longer makes sense too,
but a little housecleaning from time to time helps too.  Once a simple
answer has been given to a simple question that thread will have
outlived its usefulness after a month, and should be deleted.  If the
article is too long and a new person has the same problem, he will
probably enter it anew instead of reading the whole long article.

As Toby said, the article is still there and editable, so why not just
use it if you don't feel like going to SourceForge.

Eclecticology


subject: [Wikipedia-l] Trolling

body:
Tonight I received this message:

> Return-Path:
>                  <lsanger at nupedia.com>
>      Delivered-To:
>                  mri_icboise at surfbest.net
>         Received:
>                  from ross.bomis.com (unknown [130.94.122.195]) by server10.safepages.com
>                  (Postfix) with ESMTP id 58DAC3C5E4 for <mri_icboise at surfbest.net>; Fri, 9
>                  Aug 2002 18:08:11 +0000 (GMT)
>         Received:
>                  from localhost (lsanger at localhost) by ross.bomis.com (8.11.5/8.11.5) with
>                  ESMTP id g79IJSJ02302 for <mri_icboise at surfbest.net>; Fri, 9 Aug 2002
>                  11:19:28 -0700
>             Date:
>                  Fri, 9 Aug 2002 11:19:28 -0700 (PDT)
>             From:
>                  Larry Sanger <lsanger at nupedia.com>
>         X-Sender:
>                  <lsanger at ross.bomis.com>
>               To:
>                  <mri_icboise at surfbest.net>
>       Message-ID:
>                  <Pine.LNX.4.30.0208091117060.19852-100000 at ross.bomis.com>
>    MIME-Version:
>                  1.0
>      Content-Type:
>                  TEXT/PLAIN; charset=US-ASCII
>   X-Mozilla-Status:
>                  8003
>  X-Mozilla-Status2:
>                  00000000
>          X-UIDL:
>                  1028916500.56225_3.server10.safepages.com
>
>
>
>
> I'd just like to point out cheerfully that indeed nearly everyone seems to
> be successfully ignoring your latest attempt at trolling, despite lie
> after lie after lie so tempting to refute.  :-)
>
>

to which I responded:

> X-Mozilla-Status:
>                          0001
>          X-Mozilla-Status2:
>                          00000000
>              Message-ID:
>                          <3D5458B3.CB3E13D9 at surfbest.net>
>                     Date:
>                          Fri, 09 Aug 2002 17:05:07 -0700
>                    From:
>                          "Michael R. Irwin" <mri_icboise at surfbest.net>
>              Organization:
>                          Irwin Consulting
>                 X-Mailer:
>                          Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U)
>        X-Accept-Language:
>                          en,pdf
>            MIME-Version:
>                          1.0
>                       To:
>                          Larry Sanger <lsanger at nupedia.com>
>                   Subject:
>                          Re:
>               References:
>                          <Pine.LNX.4.30.0208091117060.19852-100000 at ross.bomis.com>
>             Content-Type:
>                          text/plain; charset=us-ascii
>  Content-Transfer-Encoding:
>                          7bit
>
>
>
>
>
> Larry Sanger wrote:
> >
> > I'd just like to point out cheerfully that indeed nearly everyone seems to
> > be successfully ignoring your latest attempt at trolling, despite lie
> > after lie after lie so tempting to refute.  :-)
>
> On the contrary, there seems to be a natural ongoing dialogue
> that naturally fades out when no one has anything substantial to
> add and resumes with new talking points.
>
> Toby has pointed out that retroactive application of newly
> formulated policy may not among be our best options in
> self governance.   This may protect you should influential
> people get tired of people shouting troll or other
> unsubstantiated allegations.
>
> A simple public apology for an unwarranted public attack might
> go a long ways towards reestablishing your credibility as one
> of the project's founders.
>
> Have you thought about whether it is truly a fallacy to attack
> the arguer rather than the argument?
>
> Would you care to publicly quote the "lies" as a basis for discussion?
>
> regards, mirwin

I find it bit disturbing to be receiving emails self
alleged to be associated with Nupedia.com and Bomis which are
obviously intended to be inflammatory.

If we are to remain a successful anarchy ruled only occasionally
by an owner informed by public opinion then I think it is
important that public opinion be at least somewhat informed
to encourage good government.

Is this an unknown "troll" attempting to fan the flames of
local controversy or is this actually Mr. Sanger (perhaps unwisely)
using an old account at Bomis?

Hopefully, the reference information included will be useful
in clarifying the matter for any internet wizards among us.
I still have copies of the original files if those would be
more useful.

I can be reached, as indicated above, at this address:
mri_icboise at surfbest.net

I would prefer public dialogue via this list as I
feel this pertains to "public" policy.

regards, mirwin


subject: [Wikipedia-l] Parsing TeX

body:
On Fri, Aug 09, 2002 at 07:31:54AM -0700, Toby Bartels wrote:
> Jan Hidders wrote:
>
> >Note that I was talking about math *expressions* and not about simple
> >variable names! For simple variable names the required knowledge of LaTeX is
> >going to be near zero.
>
> And are they going to know that if we tell them that $$ invokes LaTeX?
> They'll know if we tell them to put $$ around variable names.

People don't read manuals, they first look in other articles how it is done
there.

> >I would even argue that always using the TeX markup
> >makes things simpler there. An example in your notation:
>
> >  .. let $$v1$$, ..., $$vn$$ be a finite list ..
>
> There are many versions of "my notation" around, but this is none of them.

This is how the mark-up you suggested could be used. Perhaps it is not how you
would like it to be used, but it's still your notatation. But whether you
want people to write $$x$$$$n$$ or $$xn$$ is not
really to the point anyway.

>   .. let <var>v</var>1, ...,
>   <var>v</var><var>n</var> be a finite list ..
>
> This is what I write now, and the HTML that we should produce.

Says who? I don't agree, even apart from the question whether we should
support <var> at all (<var> was not included in HTML to write mathematical
variables), but since it is not relevant for this discussion I'm
going to save that for later.

> The question is, how do we tell people to write like that?
> We can't say "Put [$ and $] around math expressions.",
> because it isn't that simple, and things won't come out right.

Yes we can, yes it is, and yes they will. As I already explained and Lee
also suggested we can analyze what is between the [$ and $] and check which
browser is looking and then decide what we are going to output. We could
even do a little experimenting and see what looks best.

> We can't say "Put [$ and $] around a math expression to call LaTeX.",
> because it isn't that difficult, and people won't want to try it.

I assume "difficult" -> "simple"? For simple math you only need to know
what [$ x_n $] does and maybe not even that if you don't use subscripts.

> Do you want to write up all of the LaTeX that we use?

No, I don't intend to do that all by myself. :-) The request for LaTeX is an
old one and has been made several times. I know several people who write
mathematics in Wikipedia who cannot wait to get their hands on this. There's
no doubt that it will be used.

-- Jan Hidders


subject: [Wikipedia-l] Software updates

body:
On Friday 09 August 2002 05:15 pm, Lee wrote:
> I made a round of bug fixes and other planned software updates today;
> most ofthem shouldn't even be noticeable by most of you, but one will
> be, so I'm giving the militia a heads up: "Move page" is now
> available to all logged in users.

I thought you were going to make an automatic promotion for this type of
thing based on some criteria beyond mere logged-in status? It is potentially
dangerous with newbie experiments and a drain on sysop resources to let
somebody who has been logged-in for 5 minutes the ability to do something
that can /only/ be corrected by a sysop and not by any other member of the
community.

After a /great/ deal of effort over several months a majority of articles are
now correctly named.

There should be some reasonable expectation that a user with such an ability
has been exposed to our naming conventions on capitalization, pluralization,
common names ect. It took me a month to figure out how to manually move an
article and by that time I learned how I was aware of and followed our naming
conventions. Now there is a simple button for that that can be pressed on a
whim by an experimenting newbie.

Does the move feature fix redirects now? Does it move talk pages
automatically? These are non-obvious things for a newbie to know about in the
first place, let alone fix after a move.

As I stated before I'm all for letting old hands the ability to do this and
many other sysop functions (if not all in one way or another), but newbies
who tend to improperly capitalize and pluralize article names because they
are unaware of our naming conventions?

Furthermore without a log of moved pages and a summary field for explaining
why a move is being made, it will be darn near impossible to catch these
things after they have dropped off of RecentChanges.

Please reconsider. It already takes me two hours a day just to greet new
users and check past edits for vandalism in RecentChanges. This is yet
another thing I and the other sysops have to review and fix when needed.

--mav


from_name: Toby Bartels

subject: [Wikipedia-l] Easton's Bible Dictionary

body:
Neil Harris wrote in part:

>How about, as was suggested before by someone else, a new namespace:
>something like "PDresource:" that can be used by auto-uploaders to get
>PD info into a Wikified format without polluting the main namespace, but
>can then be used as source material for the 'pedia by human contributors.

Something like this would be a good idea.

There's a difference between a direct upload
and the ordinary draft status of most of Wikipedia,
where at least the contributor thinks that the article is good,
at least to the extent that it's been written
(and hopefully leaves notes about the gaps).

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


from_name: Lars Aronsson

body:
lcrocker at nupedia.com wrote:
> If we just keep adding and adding more wiki syntax on top of
> the old, we'll end up with an incomprehensible mess and code
> that's impossible to debug.  We're going to have to simplify
> the markup before we extend it, and interpreting URLs outside

What if "http:" was a namespace like "user:", you would use
[[namespace:<data>]] for all sorts of links and that would be it.
No more bare URLs and no [URL] with single brackets.  That would be a
reduction in complexity, and give you a modular design, with a new
module for each namespace that would interpret <data> following.
You could have [[tex:<data>]] for TeX math formulas and
[[ISBN:<data>]] for ISBN numbers.  The only rule for <data> would be
it couldn't contain a double closing bracket.

Existing links and patterns that fall outside of this would have to
be converted, but data has been converted before.

I haven't tried this, and don't know if it would work out.

--
  Lars Aronsson (lars at aronsson.se)
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


subject: [Wikipedia-l] Parsing TeX

body:
Jan Hidders wrote:

>Toby Bartels wrote:

>>And are they going to know that if we tell them that $$ invokes LaTeX?
>>They'll know if we tell them to put $$ around variable names.

>People don't read manuals, they first look in other articles how it is done
>there.

One of the first pages that I looked at was
[[Wikipedia:How does one edit a page]].
I didn't edit any pages seriously until reading that.
Not everybody is like this, but some people are.
Now, if I hadn't known TeX already,
I wouldn't have been heartened to see a reference to it.
What do you propose to write there?

>>>  .. let $$v1$$, ..., $$vn$$ be a finite list ..

>>There are many versions of "my notation" around, but this is none of them.

>This is how the mark-up you suggested could be used. Perhaps it is not how you
>would like it to be used, but it's still your notatation. But whether you
>want people to write $$x$$$$n$$ or $$xn$$ is not
>really to the point anyway.

The point is that you keep criticising "my notation",
but you don't seem to have any idea what that is.
If the notation above had been suggested by a third party,
I would have argued against it.

>>  .. let <var>v</var>1, ...,
>>  <var>v</var><var>n</var> be a finite list ..

>>This is what I write now, and the HTML that we should produce.

>Says who? I don't agree, even apart from the question whether we should
>support <var> at all (<var> was not included in HTML to write mathematical
>variables), but since it is not relevant for this discussion I'm
>going to save that for later.

I didn't think that that was a controversial statement anymore;
the only controversy being if the distinction was important enough.
If you argue that  is truly correct and <var> is not,
then this has an effect on *my* outlook on the matter, at least.

>>We can't say "Put [$ and $] around a math expression to call LaTeX.",
>>because it isn't that difficult, and people won't want to try it.

>I assume "difficult" -> "simple"? For simple math you only need to know
>what [$ x_n $] does and maybe not even that if you don't use subscripts.

That's why I say that it's *not* that difficult.
You don't have to know very much to do this, as you just pointed out,
yet the direction that I wrote makes it seem as if you do.
If I didn't know LaTeX already, I'd question whether or not
I want to get involved in a project that seems to demand that I know it
(assuming that I want to edit math articles, which I do).

>>Do you want to write up all of the LaTeX that we use?

>No, I don't intend to do that all by myself. :-) The request for LaTeX is an
>old one and has been made several times. I know several people who write
>mathematics in Wikipedia who cannot wait to get their hands on this. There's
>no doubt that it will be used.

You don't have to convince me that it would be useful, and used.
I'm one of the people that has voiced support for the idea,
and I'm one of the people that would certainly use it, given the opportunity.
I'm just having trouble seeing how it can be implementd in a user friendly way.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


body:
Brion Vibber wrote:

>Toby Bartels wrote:

>>Under Phase II, we used [[Bug reports]] and [[Feature requests]]
>>not merely to list desired features and undesired bugs
>>but also to talk about them in a wiki way.

>I can assure you, that was completely untenable. The pages quickly
>because so long and unwieldy that they were hard to edit; half the time
>they got truncated by someone with a buggy browser; it was hard to find
>some particular item of interest; something that didn't get implemented
>got quickly lost and forgotten in the huge pile of text...

I'm not sure what you plan to do to assure me of this untenability,
because I took part in that system, and it seemed to work.
There were problems with it, such as rare refactorisation
and the lack of tracking -- SourceForge solves the latter problem,
and as I said before, SourceForge is good.  But it's not sufficient.

>>Under Phase III, we instead use SourceForge for this.
>>But SourceForge doesn't lend itself to discussion.

>If you login with your e-mail address, any comments tacked onto your bug
>report/feature request are e-mailed directly to you. If that's not
>lending to discussion, what is?

I want to see more than just *my* bug reports and feature requests!
I discovered how to get email sent about other items, by clicking "Monitor".
What I haven't discovered is how to get email about all items automatically.
Even if there is such a way, and you tell it to me,
that doesn't change the fact that most people won't know how to do this.
But any regular user knows how to watch Wikipedia pages.

I don't always have the opportunity to view SourceForge within 48 hours.
Yet Lee will close an item after 48 hours.  What have I missed?
When something is deleted from Wikipedia, it's still in the history.
Again, there may be a way to view closed items in SourceForge,
and you may tell me what it is, and I'll be grateful,
but we *already* know how to that on Wikipedia.

And Lee does not treat it as a discussion forum.
He said as much in a comment to an item on SourceForge.
Perhaps you didn't see that, because the item was closed.
If SourceForge is to be a discussion forum, then that may be the solution,
but then we have to redesign how it's going to be used.
I came to the mailing list because I accepted Lee's statement
that SourceForge does *not* work as a discussion forum;
I don't care how it comes out, but I do think that we need one.

>>Because Lee is essentially the only programmer,
>>he will close an entry there if he doesn't want to do it.
>>Of course, we know that he's willing to be convinced,
>>but there's not much chance of that if there's no discussion.

>I also check those fairly regularly, and can and have reopened items
>where I disagree with Lee.

That's good.  Can the ordinary user do that?  *I* don't know how.

>Some have suggested bugzilla; I have no experience with it, nor do I
>know whether it will be any easier than the Sourceforge tracker to deal
>with.

That may be the solution.  I have no experience with Bugzilla;
I'd like to hear from the people that have how it would work.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


subject: [Wikipedia-l] Trolling

body:
mirwin wrote in part:

>Is this an unknown "troll" attempting to fan the flames of
>local controversy or is this actually Mr. Sanger (perhaps unwisely)
>using an old account at Bomis?

I always thought that it was silly when people put disclaimers in their sig:
"The views expressed are mine alone and not those of my ISP.".
I mean, who would ever think that an entity was supporting a view
just because it appeared after the @ in an address or in a Received: header?
But perhaps these disclaimers are necessary after all.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>

Disclaimer: The views expressed here are mine alone
and are not those of the University of California,
the mathematics community at large, my parents,
or the guy sitting next to me at the next computer.
They are, however, the views of most residents of Kinshasa,
although that's just one of those freaky coincidences.


subject: [Wikipedia-l] Parsing TeX

body:
Jan Hidders wrote:

>Toby Bartels wrote:

>>One of the first pages that I looked at was [[Wikipedia:How does one edit
>>a page]]. I didn't edit any pages seriously until reading that. Not
>>everybody is like this, but some people are. Now, if I hadn't known TeX
>>already, I wouldn't have been heartened to see a reference to it. What do
>>you propose to write there?

>That mathematical variables are preferrably enclosed in [$ and $] and that
>if you want to use sub- and superscript in them you can write [$x_n$] and
>[$c^2$].

And that you'd better not write "[$x% = x/100$]", because that won't work.
And you'd better not write "the right [[coset]] [$H\G$]".
And woe to the person that tries to say "the set [${a,b,c}$]".
These aren't just features that one would expect but that don't appear;
they're serious flaws in LaTeX -- *if* you don't know the easy
(but difficult to guess) ways around them.

>Apart from that there would be another section containing more explanation
>for writing complex math with [$ .. $] and [$$ .. $$]. This would probably
>be the same as what you would write for [[math: ..]]. We cannot get around
>mentioning LaTeX somewhere.

Well, that's just it.
We must mention LaTeX to make [$c^2$] work your way.
But we don't need to mention it for other solutions.

You have taught me well, Jan, perhaps too well.
I've learned from you why generic HTML is bad in wiki,
and while I still think that  is harmless,
I see now why  is a bad idea.
(Not that I used that before, but I might have.)
I see that we need wiki syntax for tables
not just, or even primarily, because that'd be convenient for *me*,
but because it'd be possible *at*all* for many others to read.
And I see that it's bad to have 2 systems (wiki and HTML) at once,
which is why I don't think that we should accept any HTML,
only wiki tags that resemble HTML but which we parse,
and which are documented as wiki and not as HTML at all.

Yet now it is you that argue for having 2 systems, wiki and LaTeX.
You seem to like TeX; well, I like it too, and use it often.
Heck, I've lately been creating images for Wikipedia using Xy-pic.
Nobody would ever try to do that if they didn't love TeX.
But LaTeX is a complicated system.  I know people that don't like it,
smart people, professional mathematicians, that don't want to deal with it.
Now, we may be forced to use it, or something as complicated as it,
to write the sort of complicated expression that it's so famous for.
But we can't let it infect [$x% = x/100$].

>>The point is that you keep criticising "my notation", but you don't seem
>>to have any idea what that is. If the notation above had been suggested by
>>a third party, I would have argued against it.

>Please, Toby, I get the impression you are taking this a bit too personally.

Hum ... no, if you called it "Jim's notation" instead of "Toby's notation",
I'd still be miffed.  (I sometimes do take things personally,
but rarely because my name is attached.  See a recent post about 24.)

>I'm not criticizing your notation per se, I'm criticizing the idea of having
>two separate markups for variables and more complex math expressions, as
>opposed to just one for math expressions. Whether you want to allow only
>$$x$$$$y$$ or also $$xy$$ is not really relevant for
>that question; the arguments stay the same.

That's because you haven't seen my arguments against the latter ^_^.
But I agree that having 2 systems of notation is problematic.
I just find it even *more* problematic to have 1 system of notation
that will mystify anybody that tries to use a percent symbol or a brace.

>I don't remember any discussion about, assuming that we should use <var>,
>how <var> should be used with variables with subscripts. But again, IMO this
>is all besides the point so I'll be happy to discuss this with you in
>another discussion when I have some more time. Right now I'd like to limit
>this dicussion to the question at hand.

That's not what I meant; what's relevant to me is the argument against <var>.
If that's really not right, then it could put a new perspective
on *my* view of the matter, even if it doesn't affect *yours*.
But since you and I are the only people discussing this now,
and I'm standing in opposition to you, still you should care about that.
So if you want to put it on my talk page instead, then that's OK by me,
but I'd still like to hear what the objection to <var> is.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


subject: [Wikipedia-l] Easton's Bible Dictionary

body:
Toby Bartels wrote:

>Neil Harris wrote in part:
>
>
>>How about, as was suggested before by someone else, a new namespace:
>>something like "PDresource:" that can be used by auto-uploaders to get
>>PD info into a Wikified format without polluting the main namespace, but
>>can then be used as source material for the 'pedia by human contributors.
>>
>>
>
>Something like this would be a good idea.
>
>There's a difference between a direct upload
>and the ordinary draft status of most of Wikipedia,
>where at least the contributor thinks that the article is good,
>at least to the extent that it's been written
>(and hopefully leaves notes about the gaps).
>
>
>
If we had a "review score" system, then we could say that
* a page generated by a human edit starts with  a review score of 1:
that is to say, at least one human being (the original poster) thought
that it was good.
* a page generated by a bot starts with a review score of 0, since no
human being has reviewed it

More than this, we could auto-detect bots by setting a minimum
inter-edit threshold of say 10 seconds, and mark all rapid sequences of
edits by a user, logged-on or not, as bot-generated.

Then, humans browsing the Wikipedia would normally operate at a review
cutoff level of 1: seeing all human-contributed pages, and no
bot-contributed pages. This would also mean that casual visitors would
not edit those pages, as they would never see them: if they created a
page with the same title as a bot-created one, they would supersede it,
and never know: this follows the principle that human contributions
would take precedence over mechanical article creation. Only logged-in
users who deliberately wanted to would set their review cutoff to 0, and
therefore be able to see and edit bot-contributed pages.

The scheme could be extended: the review score could be bumped by
counting page views and edits, and applying weighted or thresholded
increments.

Neil


from_name: Vicki Rosenzweig

subject: [Wikipedia-l] Trolling

body:
At 03:11 AM 8/10/02 -0700, Toby Bartels wrote:
>mirwin wrote in part:
>
> >Is this an unknown "troll" attempting to fan the flames of
> >local controversy or is this actually Mr. Sanger (perhaps unwisely)
> >using an old account at Bomis?
>
>I always thought that it was silly when people put disclaimers in their sig:
>"The views expressed are mine alone and not those of my ISP.".
>I mean, who would ever think that an entity was supporting a view
>just because it appeared after the @ in an address or in a Received: header?
>But perhaps these disclaimers are necessary after all.

Context is everything. I worked for the ACM for 15 years; for most of that
time, I had an email account @acm.org. The standard sig on that was
"Vicki Rosenzweig, Associate Editor, ACM Computing Reviews." I used
a disclaimer exactly *once*: when I was commenting on something in
comp.risks, which is (loosely) an ACM project, and wanted to make clear
that I was commenting as Vicki, not as an ACM employee.

--
Vicki Rosenzweig
vr at redbird.org
http://www.redbird.org


body:
The Cunctator wrote:
> Just wondering: when did LDC become in charge of determining what
> Wikipedia's syntax should be?

When he got the gumption to do most of the programming work. As has been
pointed out before, Wikipedia is a do-ocracy.

> WRT to the double/single bracket issue: We're suffering from a legacy
> problem, since the double-bracket syntax was originally uncommon (as opposed
> to CamelCase), it was okay that it was more tedious than single-bracket.
>
> The best thing from a usability standpoint to do would be to switch from
> double brackets to single brackets.

Single brackets are regularly used for things that _aren't_ links
(phonetic transcriptions, programming snippets, etc); making them links
would mean a horrible nightmare of <nowiki>s. If such a terrible thing
did come to pass, do NOT forget to do automatic conversion on the
database to add in the thousands of necessary <nowiki>s.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Easton's Bible Dictionary

body:
On 09-08-2002, Michael R. Irwin wrote thusly :
> "Hr. Daniel Mikkelsen" wrote:
> > On Fri, 9 Aug 2002, Toby Bartels wrote:
> > > This means that I'm coming out against Neil's plan entirely.
> > > As I mentioned under the last heading, his intentions were good,
> > > but the plan itself, not just the execution, was IMO flawed.
> > > If we want to use the EBD to write Biblically themed articles,
> > > then that's great, and I don't expect Neil to do it all himself,
> > > but we should set up a Bible article writing group to do it,
> > > with human editing for each entry before it appears (in the [[:]] namespace).
> > I agree. The automatic committing of articles from out dated works should stop.
> I also found Toby's reasoning persuasive in the context of our
> current approach to content management.   I would have no problem with
> material automatically loading into a draft area for random users
> or Wikipedians to review and edit at their leisure.

yes, bots and scripts might prove useful. They are not a bad thing per se.
Just the way we use them might be inappropriate.

For example I have some data in the form :
John Doe 1900-1977 American celebrity, inventor of anonimity

the file could be turned by a script into
[[John Doe]] 1900-1977 American celebrity, inventor of anonimity
and put into temporary namespace so then it would be open for review,
changes and removal of unnecessary chunks.
After a time we could decide in the mailing list when this particular page
is to be "ingested" be a bot.

Regards,
kpj.


body:
The Cunctator wrote:
> On 8/10/02 1:52 PM, "Brion VIBBER" <brion at pobox.com> wrote:
>>The Cunctator wrote:
>>
>>>Just wondering: when did LDC become in charge of determining what
>>>Wikipedia's syntax should be?
>>
>>When he got the gumption to do most of the programming work. As has been
>>pointed out before, Wikipedia is a do-ocracy.
>
>
> That's been asserted. It's not a truism.
>
> I believe it's a valid assertion within the WikiWiki context, where the
> playing field for making edits is level (Be bold in updating pages, etc.).
>
> I don't think it's valid in terms of the backend software.

Perhaps you can prove it incorrect; don't do anything, and see whether
things go the way you want them to. ;)

-- brion vibber (brion @ pobox.com)


body:
On 8/9/02 7:38 PM, "lcrocker at nupedia.com" <lcrocker at nupedia.com> wrote:

>
>> What if "http:" was a namespace like "user:", you would use
>> [[namespace:<data>]] for all sorts of links and that would be it.
>> No more bare URLs and no [URL] with single brackets.
>
> Hmm.  That might work too, and would be even simpler. Thanks for
> the suggestion--I solicit comments on that as well. I don't think
> it would be too bad, though, to have an "external/internal"
> separation between one-bracket and two-bracket links if your idea
> has some technical problem I don't see right now.  That's pretty
> simple to understand an use.
>
Just wondering: when did LDC become in charge of determining what
Wikipedia's syntax should be?

WRT to the double/single bracket issue: We're suffering from a legacy
problem, since the double-bracket syntax was originally uncommon (as opposed
to CamelCase), it was okay that it was more tedious than single-bracket.

The best thing from a usability standpoint to do would be to switch from
double brackets to single brackets.


body:
On Fri, Aug 09, 2002 at 11:12:59AM -0700, Toby Bartels wrote:
>
> In short, I think that we miss the discussion that we had in Phase II.
> We need a place for people to submit items for Wikipedians' approval
> other than SourceForge, but we need to use SourceForge too.
> Ideas?

Add a link to this mailing list on [[Wikipedia:Bug reports]]? Mailing lists
are the best way to have discussions and they are also archived.

-- Jan Hidders


body:
The Cunctator wrote:
> On 8/10/02 2:13 PM, "Brion VIBBER" <brion at pobox.com> wrote:
>>Perhaps you can prove it incorrect; don't do anything, and see whether
>>things go the way you want them to. ;)
>
>
> Or maybe we can have guidance come from consensus, not fiat.

Guidance and consensus are lovely and good, but nothing gets _done_
until somebody's willing to _do_ it. If the _doer_ doesn't consent to
the consensus, you need to find another one.

Ergo, Lee (as the person most likely to be implementing any changes to
the wiki syntax) is an important factor in any discussion about changing
the wiki syntax.

<sarcasm>Shame on him for making suggestions on the mailing list about
how he'd prefer to do it, to which you and other interested parties may
reply, converse, and attempt to reach a consensus acceptable to
all!</sarcasm>

-- brion vibber (brion @ pobox.com)


in_reply_to: <000801c23fef$df7bee90$6701a8c0@ORGOCH>; from sean@epoptic.org on Fri, Aug 09, 2002 at 02:58:18PM -0700

body:
On Fri, Aug 09, 2002 at 02:58:18PM -0700, Sean Barrett wrote:
> "We're going to need a real markup syntax, consistent, predictable,
> documented, bug free, and with all the features needed..."
>
> But we MUST NOT violate the sacred principle of Not Invented Here, which
> strictly forbids the use of the markup language that has real markup
> syntax, consistent, predictable, documented, bug free, and with all the
> features needed ... HTML.
>
> </sarcasm>

Apart from the fact that you forgot an opening tag you are right of course.
If consistency, et cetera, was all we wanted then HTML (I'd actually prefer
XML) would be an excellent solution. There are even more advantages:
- There are good free XML parsers in PHP out there, so writing a parser
  would be relatively trivial and it would be easy to get total control over
  what XML is allowed.
- Documenting the mark-up could simply be done by defining a DTD.
- Combined with CSS and/or XSL we would have an excellent way to separate
  content and presentation.
- Our internal format would at the same time be the best possible export
  format.
- Any extension we will think of in the future can be easily
  integrated then. (That's what the X in XML promises, anyway. :-))


body:
Toby Bartels wrote:
>
> Under Phase II, we used [[Bug reports]] and [[Feature requests]]
> not merely to list desired features and undesired bugs
> but also to talk about them in a wiki way.
> Under Phase III, we instead use SourceForge for this.
> But SourceForge doesn't lend itself to discussion.
> Because Lee is essentially the only programmer,
> he will close an entry there if he doesn't want to do it.
> Of course, we know that he's willing to be convinced,
> but there's not much chance of that if there's no discussion.
>
> There are alternatives.
> [[Bug reports]] and [[Feature requests]] still exist,
> but nobody has used them since the change,
> and I doubt that very many people are watching them.
> Much discussion of features has taken place on this list,
> but that doesn't reach nearly as wide an audience as before.
> Most people that submit an item to SourceForge
> aren't going to think to take it up on the list.
>
> In short, I think that we miss the discussion that we had in Phase II.
> We need a place for people to submit items for Wikipedians' approval
> other than SourceForge, but we need to use SourceForge too.
> Ideas?

The problem with sourceforge is that it isn't very intuitive to use. I
found it almost impossible to work out how to submit a bug report - it
took me three goes to get it to register and I failed in attaching a
graphic.

Also, the replies to it go to the person who reported the bug, but they
don't appear on the site. What's needed is a bulletin board that threads
everything together so they can be easily seen... or otherwise a
dedicated mailing list. I'd suggest saving this for general discussion
and questions, and putting the bug reports onto a seperate list just for
themselves.

--

Karen AKA Kajikit

And on the seventh day, God said 'What my world needs is a creature that
will truly appreciate it in all its facets' -
and so He made the kitten.

Come and visit my part of the web:
Kajikit's Corner: http://Kajikit.netfirms.com/
Aussie Support Mailing List: http://groups.yahoo.com/group/AussieSupport
Allergyfree Eating Recipe Swap:
http://groups.yahoo.com/group/Allergyfree_Eating
Ample Aussies Mailing List: http://groups.yahoo.com/group/ampleaussies/

Love and huggles to all!


body:
On Sat, 10 Aug 2002, Jan Hidders wrote:

> >From a technical point of view XML is clearly superior. So why don't
> we use it? Because we want a mark-up that is easy to read, easy to
> understand, easy to type and non-intimidating for people who know next to
> nothing about HTML.

I think a good way of viewing the problem is to try not to think of all our
wiki kodes as "markup", but rather as features of our simple editor. When
someone makes a GUI frontend to Wikipedia, those features will become more
sophisticated (wysiwyg).

What we store in the database is an entirely different question, but right now,
since we only have one frontend, storing the plain editor text there is easier.
One day, it will probably be XML.

-- Daniel


subject: [Wikipedia-l] Trolling

body:
Toby Bartels wrote:
>
> mirwin wrote in part:
>
> >Is this an unknown "troll" attempting to fan the flames of
> >local controversy or is this actually Mr. Sanger (perhaps unwisely)
> >using an old account at Bomis?
>
> I always thought that it was silly when people put disclaimers in their sig:
> "The views expressed are mine alone and not those of my ISP.".
> I mean, who would ever think that an entity was supporting a view
> just because it appeared after the @ in an address or in a Received: header?
> But perhaps these disclaimers are necessary after all.
>

A lot of people use mail accounts for both business and
personal purposes.  Sometimes clarification of the specific
role in which they are acting or who they are representing
is useful.  Sometimes it is customary and a matter of courtesy.
Sometimes it is mandatory.

Mr. Sanger used to be employed fulltime by Bomis and played
a lead role in the early establishment of Wikipedia as a
"founder" and as an "editor-in-chief".   I have the impression from
various email reviewed and events witnessed upon Wikipedia
and meta.wikipedia that he also got drawn occasionally into
the role of a community "enforcer".

Mr. Wales has now stepped into an "enforcer" role by default
as the owner since Mr. Sanger left fulltime employment with Bomis.
This is documented in various places on meta.wikipedia, wikipedia,
and the archives of this mailing list.

It would be useful to me to know what role the person using
Mr. Sanger's Nupedia account to send private inflammatory
emails thinks they are acting in and that person's actual identity.
If it is Mr. Sanger then his credibility and reputation is
diminished with me and perhaps with the community, now that I have
chosen to publish it to the mailing list. If it is not Mr. Sanger,
then there may be an issue of security or integrity failure
within the Bomis workforce or the within the community which has access
to the Bomis network beyond sending email through the list servers.

Have other people participating at Wikipedia, and still here
obviously, encountered this type of behavior from Mr. Sanger's
email account?   Was the behavior encouraged by other members
of the community to drive off unpopular people or unpopular
viewpoints?

To summarize some of the issues:

Does Mr. Sanger think he has the widespread
support of the Wikipedia community in attempting to incite me
or is this merely personal recreation?

Is this actually Mr. Sanger or is it someone attempting to
discredit him and/or the Wikipedia community?

Is this a misguided attempt to drive off an unpopular viewpoint
or questions rather than address them via the community discussion
forums?

If a security breach is in progress (someone unknown has logged
into Mr. Sanger's account and used it without regard (or with malicious
intent) for Bomis, Nupedia, Wikipedia and Mr. Sanger's reputation and
credibility) has it been initiated by someone within the community or
an external agent?

regards,
mirwin


subject: [Wikipedia-l] Parsing TeX

body:
Toby Bartels wrote:
>
> Jan Hidders wrote:
>

>
> >Please, Toby, I get the impression you are taking this a bit too personally.
>
> Hum ... no, if you called it "Jim's notation" instead of "Toby's notation",
> I'd still be miffed.

<snip lots of discussion>

> But since you and I are the only people discussing this now,
> and I'm standing in opposition to you, still you should care about that.
> So if you want to put it on my talk page instead, then that's OK by me,
> but I'd still like to hear what the objection to <var> is.

I think this is an important discussion to keep on the list.  I have
not participated with input before because I have not learned enough of
any specific system to have a meaningful opinion.

I am attempting to follow the discussion because advanced math and
diagrams
are critical to many subjects of interest that will ultimately be
covered
by Wikipedia.

regards, mirwin


body:
On 8/10/02 1:52 PM, "Brion VIBBER" <brion at pobox.com> wrote:

> The Cunctator wrote:
>> Just wondering: when did LDC become in charge of determining what
>> Wikipedia's syntax should be?
>
> When he got the gumption to do most of the programming work. As has been
> pointed out before, Wikipedia is a do-ocracy.

That's been asserted. It's not a truism.

I believe it's a valid assertion within the WikiWiki context, where the
playing field for making edits is level (Be bold in updating pages, etc.).

I don't think it's valid in terms of the backend software.


from_name: lcrocker at nupedia.com

body:
> Just wondering: when did LDC become in charge of determining
> what Wikipedia's syntax should be?
>
> WRT to the double/single bracket issue: We're suffering from a
> legacy problem, since the double-bracket syntax was originally
> uncommon (as opposed to CamelCase), it was okay that it was more
> tedious than single-bracket.
>
> The best thing from a usability standpoint to do would be to
> switch from double brackets to single brackets.

An advantage of using double breackets only is that we'll then
be able to use single brackets as regular punctuation, which would
be especially handy in math articles, among others.

The answer to your first question is easy--you know where the code
is.  Like everything else here in Wiki land, the "authority" falls
on the ones willing to do the work.


body:
>> Perhaps you can prove it incorrect; don't do anything, and
>> see whether things go the way you want them to. ;)

> Or maybe we can have guidance come from consensus, not fiat.

So what part of "I'm soliciting input on this" didn't you
understand?  Or do you just prefer to stir up shit rather than
actually providing input?


subject: [Wikipedia-l] Parsing TeX

in_reply_to: <20020810070120.GB691@math-lw-n02.ucr.edu>; from toby+wikipedia-l@math.ucr.edu on Sat, Aug 10, 2002 at 12:01:20AM -0700

body:
On Sat, Aug 10, 2002 at 12:01:20AM -0700, Toby Bartels wrote:
>
> One of the first pages that I looked at was [[Wikipedia:How does one edit
> a page]]. I didn't edit any pages seriously until reading that. Not
> everybody is like this, but some people are. Now, if I hadn't known TeX
> already, I wouldn't have been heartened to see a reference to it. What do
> you propose to write there?

That mathematical variables are preferrably enclosed in [$ and $] and that
if you want to use sub- and superscript in them you can write [$x_n$] and
[$c^2$].

Apart from that there would be another section containing more explanation
for writing complex math with [$ .. $] and [$$ .. $$]. This would probably
be the same as what you would write for [[math: ..]]. We cannot get around
mentioning LaTeX somewhere.

> The point is that you keep criticising "my notation", but you don't seem
> to have any idea what that is. If the notation above had been suggested by
> a third party, I would have argued against it.

Please, Toby, I get the impression you are taking this a bit too personally.
I'm not criticizing your notation per se, I'm criticizing the idea of having
two separate markups for variables and more complex math expressions, as
opposed to just one for math expressions. Wheter you want to allow only
$$x$$$$y$$ or also $$xy$$ is not really relevant for
that question; the arguments stay the same.

> >>  .. let <var>v</var>1, ...,
> >>  <var>v</var><var>n</var> be a finite list ..
>
> >>This is what I write now, and the HTML that we should produce.
>
> >Says who? I don't agree, even apart from the question whether we should
> >support <var> at all (<var> was not included in HTML to write
> >mathematical variables), but since it is not relevant for this discussion
> >I'm going to save that for later.
>
> I didn't think that that was a controversial statement anymore;
> the only controversy being if the distinction was important enough.

I don't remember any discussion about, assuming that we should use <var>,
how <var> should be used with variables with subscripts. But again, IMO this
is all besides the point so I'll be happy to discuss this with you in
another discussion when I have some more time. Right now I'd like to limit
this dicussion to the question at hand.

-- Jan Hidders


body:
On 8/10/02 2:13 PM, "Brion VIBBER" <brion at pobox.com> wrote:
> Perhaps you can prove it incorrect; don't do anything, and see whether
> things go the way you want them to. ;)

Or maybe we can have guidance come from consensus, not fiat.