> Under phase II, deleted articles were retained in the table of old
> versions, and if necessary could have been restored by a sysop
> querying the database. (There never was a pretty interface set up
> for this.)
I didn't realize that. I could make delete less destructive, say, by
moving everything to an "archives" table that gets taped off every
now and then.
> What's the purpose of the sysop status, then?
> The only reason we had the sysop status originally was that we
> really did need to "delete" some pages, and at that time, our
> delete function was royally destructive, i.e. it deleted the page
> and all the history. So it was too powerful to have people using
> it indiscriminately. But we wanted to let a few people use it,
> because it really was useful.
> Now, if the delete is no longer destructive in that way, i.e. if
> there's a way to ordinary users to revive a deleted page, then we
> don't really need sysop status except for "old hand" type of
> functions.
Delete is still every bit as destructive and permanent. The only
history of deleted pages will be in periodic database dumps. (I've
only done two since the new server was in place, and I still don't
have a cron job for it--I need to get some indication of how you plan
to archive them, if you do, before I can do that).
> The main role that the Cunctator has taken for himself here is very
> much appreciated by me... I think that a big part of our success is
> openness and non-cabalism. Social pressure works better than the
> iron rule of code.
I'm all for "openness" in making information available to people, and
letting people add their own. But I utterly reject the idea that one
can deal with malicious, destructive people without some means of
self-defense; and such people do, and will continue to, exist. I
don't think it's too bad an idea for "edit protected pages" and "move
page function" to be open to logged in users, but it does make me a
little nervous. But "delete" should definitely be locked down, and
block/unblock IP.
Here's another suggestion, and one that would be easier to implement:
instead of just "logged in" being the criterion, how about "logged
in, and with an apparently valid e-mail address" (and I'll get
cracking on that "e-mail user" function).
There is already a feature request for a simple wiki
table format on Sourceforge at:
http://sourceforge.net/tracker/index.php?func=detail&aid=584459&group_id=34…
Here is the idea:
<wiki table, center, thin line>
|{light blue} ^ '''Mailing label''' ^|/
|Name: |John Doe |/
|Address: |2000 Main Street |/
| Postal Code: |123456 |/
</wiki table>
NOTE: ^ would signify that the text between should be
centered and / would signify the end of a row.
I'm not sure if this would be possible, but it would
be nice to also have spaces after the | and before the
text to be the same as in an HTML table.
Would render the same as:
<table align="center" border="1">
<tr>
<th colspan="2" bgcolor="lightblue">Mailing
label</th></tr>
<td>Name: </td><td>John Doe </td></tr>
<tr>
<td>Address: </td><td>2000 Main Street </td></tr>
<tr>
<td> Postal Code:
</td><td>123456</td></tr>
</table>
The above wiki table seems a lot more intuitive to me
than either the HTML table or the other wiki table
syntax proposals.
--mav
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
There is already a feature request for a simple wiki
table format on Sourceforge at:
http://sourceforge.net/tracker/index.php?func=detail&aid=584459&group_id=34…
Here is the idea:
<wiki table, center, thin line>
|{light blue} ^ '''Mailing label''' ^|/
|Name: |John Doe |/
|Address: |2000 Main Street |/
| Postal Code: |123456 |/
</wiki table>
NOTE: ^ would signify that the text between should be
centered and / would signify the end of a row.
I'm not sure if this would be possible, but it would
be nice to also have spaces after the | and before the
text to be the same as in an HTML table.
Would render the same as:
<table align="center" border="1">
<tr>
<th colspan="2" bgcolor="lightblue">Mailing
label</th></tr>
<td>Name: </td><td>John Doe </td></tr>
<tr>
<td>Address: </td><td>2000 Main Street </td></tr>
<tr>
<td> Postal Code:
</td><td>123456</td></tr>
</table>
The above wiki table seems a lot more intuitive to me
than either the HTML table or the other wiki table
syntax proposals.
--mav
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
There have been a lot of good suggestions for new wiki markup
elements, and the arguments about whether or not to continue
using/relying on HTML have brought up some good points on both sides,
but I think I'm growing more firmly entrenched in the "simplify,
simplify" position.
There is a tension of goals here: (1) the primary goal of our wiki,
as I see it, is to encourage the totally computer-inept to write and
edit articles. Getting people like that to parse the text out of
<table> syntax and get the tags to match up right will just drive
them away. (2) The goal to have pretty-looking articles.
We can solve the problem of tables by using a clean, easy to read,
and forgiving table markup syntax--I rather like tarquin's, although
I'd make it optional whether to put the cells of a row on one markup
line or subsequent lines, and it needs to do things like produce an
accurate table with sloppy markup that leaves out cells, and so on.
That still leaves us no way to specify headings, caption, spans, and
cell backgrounds, and the like. We would also like to be able to do
things like float images, colorize text, and so on.
So here's a radical proposal: take more advantage of CSS to allow us
gurus to prettify articles without complicating the wikitext. Create
some method of attaching an inline stylesheet to a page or group of
pages, and put things like image floats, table backgrounds, padding,
fonts, and so on in the style sheet, and leave the wikitext alone.
Of course, that will require some way for the stylesheet to identify
elements in the wikitext. We can auto-number things like images and
tables, and use IDs, e.g., "#image1 {float:left; padding-
right:10px;}", etc. But that leaves things like inline quotes,
formulas, and other needs. We can probably take care of most of that
by coming up with a clean, unobtrusive way to indicate "span"
and "div" IDs in the wikitext. Then that will be the only odd
markup, and everything else can go into the stylesheet.
tarquin wrote:
>The key details are:
>* one cell per line (and not one row per line)
>* formatting information is seperate from data
>
>These both increase the clarity considerably. Someonoe who jsut wants to
>edit the data can skip the header line, no matter how ugly and
>comlicated it may be.
That also decreases the usefulness considerably. One *cell* per line? You couldn't organize data in columns--you couldn't have a piece of information with an explanation immediately beside it of what the information is, the way we have on the U.S. Presidents pages, the countries pages, the various tree of life pages.... You must have meant two, at least?
kq
>> I might be wrong, but wouldn't taking powers previously only
>> usable by a relative few and allowing a great deal more people
>> to have them, tend to democratize things?
> Are you suggesting an automatic way of granting sysop status?
> If so, I like it.
No, what he suggested (and with which I agree, though I'm not quite
sure how to implement it yet) is a third status in between J. Random
Anonymous user and sysop, which will be able to edit protected pages
and use the "move" function, and which will be automatically given to
someone who hangs around for a while.
On Wednesday 31 July 2002 03:49 pm, you wrote:
> Official hierarchies of users are still undesirable, whether they're called
> an "old hand" or not.
>
> I still strongly believe in
> http://www.wikipedia.com/wiki/The+Cunctator/How+to+build+Wikipedia
>
> (See "Avoid Cabals".)
Who is expanding the influence of a creating a Cabal (like we ever agree on
anything)? How is allowing the majority of active users the ability to edit
the Main Paqe and other protected pages and the ability to administratively
move pages a top heavy approach? Denying the majority of active users the
ability to do these things is rather un-wiki in my book.
I might be wrong, but wouldn't taking powers previously only usable by a
relative few and allowing a great deal more people to have them, tend to
democratize things?
Wikipedia is a large target and admins are needed to protect the site from
constant vandal abuse and unclutter the database as LDC puts it. This allows
most users to concentrate on creating and editing content.
Old hands will be needed to help maintain Wikpedia and the history of its
articles and all users regardless of database status will do what they always
have done; contribute like hell and learn the wiki way by helping create what
someday might very well be the best darn encyclopedia there is.
--mav
>> tarquin wrote:
>>>The key details are:
>>>* one cell per line (and not one row per line)
>koyaanisqatsi(a)nupedia.com wrote:
>> That also decreases the usefulness considerably. One *cell* per line?
brion vibber wrote:
>That's one cell per line of *markup*.
I'm on a roll misunderstanding things these days. I'm glad school doesn't start again for a few weeks, and the GRE is well behind me.
kq
>> Could the WatchList page be limited to a number of days like
>> RecentChanges?
>> Mine is getting rather long & it takes a while to generate.
>> Maybe a truncated WatchList page could give a link to a complete
>> watchlist which would be displayed as a dumb list with no dates &
>> times of edits (which I presume is what causes the load on the
server)
>At the risk of being slightly sarcastic, wouldn't a better solution
be
>to edit your own WatchList to remove things that you no longer
really
>need to watch?
The software should be able to deal with capacity issues like this,
though I agree that it's probably better to have a smaller
watchlist. Another suggestion is to just create a page under your
user space that's just a collection of links to the pages you're
interested in. Then you can use the "Watch links" feature to look
for changes on all those pages, and the ones on your watchlist will
appear bold there, so you get a two-level watchlist.