problems than they prevent. Better is case-by-case action, with
justification necessary. The establishment of common law based on precedent,
if you will.
> --In response to the obvious question, Cunc (because I know you worry about
> this type of thing), my assumption is that it would work this way. I would be
> involved in (or witness -- I wouldn't feel comfortable locking a page without
> consulting anyway, but that's just me) an interminable edit war. I would say
> to myself, "Self, I can see no contributions here, only angry reversions, I
> think this should be locked till tempers cool and people have something
> constructive to offer." I would then write a note to the list "Attention
> sysops: there is a flame/edit/revert war going on at article x. I think it
> needs locking for a bit. What do you think?" Then, I would wait to see
> responses. I wouldn't know in advance who would respond. The second person
> to agree (unless someone disagrees) would perform the lock.
I'd just say we should never lock such articles. That makes the
decision-making process much easier.
something through Google I'd like to find out what Wikipedia knows
about the given subject.
Would it be difficult to :
* implement Wikipedia toolbar
* prepare Wikipedia entry as a search engine for the Mozilla sidebar
Regards,
kpj.
(Of course, TeX is not known for being user friendly either.
But is there really a user friendly alternative?)
-- Toby Bartels
<toby+wikipedia-l(a)math.ucr.edu>
But I think that in many cases the most natural wiki syntax
will simply be to copy directly the syntax of the HTML tag.
This will primarily be when the tag is reasonable to use
and has no security issues but will be used rarely.
If it's used often, then it's time to look for something simpler.
This is exactly what we're doing now on SourceForge for <table>
and on Jan's page for <var>, <sup> and <sub>; that's good.
But lack of < and > isn't inherently simpler;
any idea needs to be judged on its own merits.
And we shouldn't stop supporting a markup method that appears on our pages
(except when we're no longer supporting the HTML that it rendered as).
>As comfortable as all of us are with HTML, /we/ aren't the kind of
>people we want editing articles (except maybe those on computer
>subjects). We want Bridge players writing about Bridge, and cat
>breeders writing about cats, and campers writing about camping--the
>kind of people who have never even heard of HTML are the kind of
>people we want most to attract and make use of. We computer nerds
>are used to dealing with special syntaxes; it is we who should adapt
>to them, not the other way around.
I've argued that <b> is marginally better than '''
because more newbies (including some bridge players) will already know it.
Without that, I see minor arguments for both, but think that they're even.
(OTOH, I admit that '' is better than <em> when you ignore that
more people already know it, since <em> is hard to guess the meaning of.)
But I still don't see why it's wrong to have both,
written up on [[Wikipedia:How to edit a page]] for the uninitiated.
(And I wouldn't breathe a word of HTML on that page, BTW --
the origin of the markup used is of no relevance to the end user.)
-- Toby Bartels
<toby+wikipedia-l(a)math.ucr.edu>
> 2) The number of 'sysop's is rapidly rising, and the chances of
> somebody accidentally (or maliciously) performing a slow, complex
> query that tied up the database for a long time would increase.
It's pretty hard to do that with a SELECT, and it's only temporary.
I think it's handly for sysops to be able to find things out like how
many users use a certain skin, how many page titles contain a certain
word, etc., without having to provide special pages for every
possible query.
Select "Display" from list of Categories; then for "Transparency Type:"
select "Light Checks" or "White only" or whatever you fancy.
-- brion vibber (brion @ pobox.com)