from_name: uninvited at nerstrand.net

subject: [WikiEN-l] Fair use

body:
I have tried to make a difference in the handling of purportedly "fair
use" materials on Wikipedia.  I believe that we have a plague of
copyvio images, many of them bearing bogus fair use claims.

One of the problems is that there is no project-wide policy on the
requirements for using fair use images.  The validity of a fair use
claim is up to the uploader.

Though I am not an attorney, I am myself unconvinced that such things as
misappropriated news photos and graphics on current events, when
appearing prominently in articles linked from the main page, and edited
by many people, would qualify for OCILLA safe harbor provisions.  Though
we have many dubious fair use claims, the ones involving recent news
media images concern me the most because of the potential for bad press
for us, and because of the potential case to be made for genuine
monetary losses by news media that are in competition with the free
information source we provide.

Some basic things like deleting newly uploadeded, unsourced images would
be a start.  So would a policy that states, specifically, that images
taken from present-day news sources or wire services are against
Wikipedia policy, regardless of the fair use case that the uploader
thinks may apply.

I have been trying to form policy by working through issues on
Wikipedia, but it is becoming clear that (a) the general opposition to
deletion of anything, (b) the inability to undelete images, and (c) the
lack of understanding of the nuances of U.S. copyright law are working
together to prevent any useful work from being done by consensus.  I
believe that leadership, and careful involvement of counsel, will be
necessary to adopt useful policy.

The Uninvited Co., Inc.
(A Delaware corporation)


list: foundation-l

source: pipermail-mbox

from_name: Александр Сигачёв

subject: [Foundation-l] Localization of WikiSource name

body:
Please look at
http://wikisource.org/wiki/Wikisource:Scriptorium#Site_name_and_namespace

It's about transliteration / translation / localization of "WikiSource".

--
meta:user:ajvol


list: wikimedia-l

from_name: Александр Сигачёв


list: wikien-l

subject: [WikiEN-l] Vandalism concerns with commons images

body:
With increasing hosting of images on commons, there arise vandalism
concerns.

Images hosted on commons cannot be protected by admins from
en.wikipedia.  There are only about 25 admins on commons who are also
active on en.wikipedia.  The commons community has turned down several
requests for adminship from en.wikipedia admins in good standing who
wished to become admins at commons in order to deal with vandalism on
commons that affected en.  It is commons policy that significant
involvement in commons in particular is a requirement for adminship,
regardless of involvement in other projects.

Another problem area is that images on en: supercede those on commons
with the same title.  Therefore, an image protected on commons could be
vandalised by uploading a vandalised image by the same name on en
(Unless there is a technical solution to this that I am not aware of.
I haven't tried it).  Though cumbersome, an en admin could conceivably
use this as a workaround for protecting images that have been
vandalized on commons.

In general, I believe that there should be more trust and cooperation
between the projects, to the point of having some process for fairly
routine granting of commons adminship to en admins.  This might be a
situation where partial permissions -- protecting and unprotecting
pages only but not blocking or deleting -- might make sense.  A similar
process should be in place for the other large wikipedias, such as de
and fr.

I do note that there is an agreement to protect main page images that
are on commons.  My concern is with other prominent pages.  The
unexpected vandalism spree that accompanied the last U.S. presidential
elections would be an example.

The Uninvited Co., Inc.


from_name: Karl A. Krueger

subject: [WikiEN-l] Re: [OT] Top posting

body:
On Sun, Sep 11, 2005 at 06:24:27PM -0700, Matt Brown wrote:
> The problem with top-posting is not so much the top-posting itself, it is
> what it generally goes along with: copying the entire text of the article
> being replied to, and not being specific about what you're replying to.

Full-quoting is really annoying for those of us who read mailing lists
in digest mode:  it means that we have to page through reams of repeated
text in order to read the new messages.  Since digest mode is a useful
and supported feature of the list, it makes sense to discourage people
from gratuitously breaking it by full-quoting.

Full-quoting also makes using Web archives more difficult, since a chain
of full-quoted messages tailing off of every subsequent reply will
create false hits on search engines.  If every message includes only the
author's text and a minimum of quoting to establish context, the needs
of per-message readers, digest readers, and Web archives are all
fulfilled pretty damn well.

("I can't help but top-post/full-quote: my mail program puts the cursor
at the top of the message by default" is ... well ... I'll be nice and
say it isn't terribly convincing.  It's right up there with "I can't
click that button, I'd go off the edge of my mouse pad.")

--
Karl A. Krueger <kkrueger at whoi.edu>


from_name: Ryan Norton

subject: [WikiEN-l] Fair use

body:
On Monday, September 12, 2005, at 11:54  AM, uninvited at nerstrand.net
wrote:

> I have tried to make a difference in the handling of purportedly "fair
> use" materials on Wikipedia.  I believe that we have a plague of
> copyvio images, many of them bearing bogus fair use claims.
>
True... but as long as you have no approval process on images that are
uploaded this will always be a problem.

> One of the problems is that there is no project-wide policy on the
> requirements for using fair use images.  The validity of a fair use
> claim is up to the uploader.
It's pretty good right now actually - you've got Carnildo and others
making sure Featured Articles have good copyright stuff for their
images.
>
> Though I am not an attorney, I am myself unconvinced that such things
> as
> misappropriated news photos and graphics on current events, when
> appearing prominently in articles linked from the main page, and edited
> by many people, would qualify for OCILLA safe harbor provisions.
> Though
> we have many dubious fair use claims, the ones involving recent news
> media images concern me the most because of the potential for bad press
> for us, and because of the potential case to be made for genuine
> monetary losses by news media that are in competition with the free
> information source we provide.

It's a dicey issue. It depends on a lot of things. I recommend actually
contacting a real lawyer if someone's really concerned.

> Some basic things like deleting newly uploadeded, unsourced images
> would
> be a start.

What happens if one of those images are valuable?? Doing this without
some kind of "undelete" mechanism could be really bad.

>   So would a policy that states, specifically, that images
> taken from present-day news sources or wire services are against
> Wikipedia policy, regardless of the fair use case that the uploader
> thinks may apply.

How do you define "present day"? The only case for that and say, 10
years ago, is that doing it now might cause more bad press... but if
you're going to do this you may as well just prohibit it altogether.

Thanks,
RN


from_name: Nick Boalch

subject: [WikiEN-l] Article deletion

body:
Angela wrote:
>> For the benefit of those of us without the relevant cultural
>> background, what *is* the pure wiki deletion system?
>
> The basic idea is that a page is "deleted" by being blanked by any
> user. See http://meta.wikimedia.org/wiki/Pure_wiki_deletion_system_(proposal)

I think people probably need to remember that we're using Wiki to *build
an encyclopaedia*: Wiki is a means to an end, not the end itself.

Cheers,

N.

--
Nicholas Boalch
School of Modern Languages & Cultures       Tel: +44 (0) 191 334 3420
University of Durham                        Fax: +44 (0) 191 334 3421
New Elvet, Durham DH1 3JT, UK               WWW: http://nick.frejol.org/


from_name: Fastfission

subject: [WikiEN-l] Article deletion

body:
Lack of closure, for one thing. I don't necessarily think the current
way works but at least you get some centralized discussion. My vision
of the "pure wiki deletion system" is one in which, after a week of
revert warring, people start complaining on some centralized place,
filing RfCs, etc., until finally it comes down to ten editors saying
"don't recreate the page or you'll get banned" which is really all AfD
or VfD was doing anyway.

There will always eventually be "discussion" at some point for the
articles that people are going to force it over. And said discussion
will probably always have bouts of "nastiness" if it's about whether
someone's grandma is notable or not.

In fact... maybe the best approach is not to encourage more commenting
on voting in VfD, but to discourage it! A simple vote of "keep" or
"delete", no discussion, no nastiness! (I'm only half joking.. but the
half that is joking is indeed joking)

The other thing of course is that blank pages are still indexed by
Google and our own sad little search engine, if I understand it
correctly. We could change this, of course, without too much
difficulty in Media Wiki (just have it insert a noindex noarchive
robot tag whenever it creates its cache of a page with no data or less
than X characters or whatever), so that's just a minor quibble. Blank
pages would also not appear as red links in the current
implementation. But this, I'm sure, could also be changed.

FF

On 9/12/05, Bryan Derksen <bryan.derksen at shaw.ca> wrote:
> Mark Gallagher wrote:
>
> >
> > G'day Dan,
> >
> >>
> >> Pure wiki deletion system.
> >
> >
> > A vandal's paradise.
> >
> Vandals can _already_ blank pages. Other people notice the blanking,
> check what's been blanked in the history, and if they think it was
> inappropriate they revert it. What would change?
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


list: wikitech-l

from_name: Rowan Collins

subject: [Wikitech-l] Re: Images dump

body:
On 10/09/05, Timwi <timwi at gmx.net> wrote:
> Rowan Collins wrote:
> > if you do get the Commons dump, you can be fairly sure there are no
> > images in it that are actually copyrighted,
>
> The majority of content in the Commons is copyrighted. If it wasn't, it
> couldn't be licensed, liberally or otherwise.

Oops. I meant "that are actually copyright violations", or perhaps
"that would be copyright violations if *you* used them", but it got
rather too shortened. Normally, I feel the need to apologise because
I've been too *verbose*...!

--
Rowan Collins BSc
[IMSoP]


from_name: Brion Vibber

subject: [Foundation-l] Re: [Wikimediafr-l] Inquiétude au sujet de Yahoo en Chine

body:
Anthere wrote:
> Emmanuel Engelhart <emmanuel at engelhart.org> wrote:
> Bonjour
>
> Je tiens ? faire part de mon inqui?tude ? la vue de cet article:
> http://www.courrierinternational.com/article.asp?obj_id=54946
>
> Il est normal que Yahoo respecte la loi chinoise, m?me si celle-ci est sc?l?rate.
>
> Mais, je serai tr?s (tr?s) m?content d'apprendre qu'un chinois a des difficult?s ? cause de son
> activit? (d?voil?e) sur un des projets de wikim?dia. Si Yahoo fournissait des informations comme
> elle vient de le faire, alors il ne serait pas exag?r? AMHA de poser la question du degr? de
> complicit? de la fondation dans cette affaire.
>
> Une clarification a-t-elle d?j? ?t? faite ? ce sujet ?

For what it's worth, China and South Korea are different countries; so
far as I'm aware we have no dealings with Yahoo!'s subsidiary in China.

(It would be nice to know a bit more about this case; a quick skim of
the linked article doesn't say who passed information along where at
what point, on what authority.)

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/foundation-l/attachments/20050912/8cc73569/attachment.pgp


body:
Anthere wrote:
> Emmanuel Engelhart <emmanuel at engelhart.org> wrote:
> Bonjour
>
> Je tiens ? faire part de mon inqui?tude ? la vue de cet article:
> http://www.courrierinternational.com/article.asp?obj_id=54946
>
> Il est normal que Yahoo respecte la loi chinoise, m?me si celle-ci est sc?l?rate.
>
> Mais, je serai tr?s (tr?s) m?content d'apprendre qu'un chinois a des difficult?s ? cause de son
> activit? (d?voil?e) sur un des projets de wikim?dia. Si Yahoo fournissait des informations comme
> elle vient de le faire, alors il ne serait pas exag?r? AMHA de poser la question du degr? de
> complicit? de la fondation dans cette affaire.
>
> Une clarification a-t-elle d?j? ?t? faite ? ce sujet ?

For what it's worth, China and South Korea are different countries; so
far as I'm aware we have no dealings with Yahoo!'s subsidiary in China.

(It would be nice to know a bit more about this case; a quick skim of
the linked article doesn't say who passed information along where at
what point, on what authority.)

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/foundation-l/attachments/20050912/8cc73569/attachment-0001.pgp


body:
Anthere wrote:
> Emmanuel Engelhart <emmanuel at engelhart.org> wrote:
> Bonjour
>
> Je tiens ? faire part de mon inqui?tude ? la vue de cet article:
> http://www.courrierinternational.com/article.asp?obj_id=54946
>
> Il est normal que Yahoo respecte la loi chinoise, m?me si celle-ci est sc?l?rate.
>
> Mais, je serai tr?s (tr?s) m?content d'apprendre qu'un chinois a des difficult?s ? cause de son
> activit? (d?voil?e) sur un des projets de wikim?dia. Si Yahoo fournissait des informations comme
> elle vient de le faire, alors il ne serait pas exag?r? AMHA de poser la question du degr? de
> complicit? de la fondation dans cette affaire.
>
> Une clarification a-t-elle d?j? ?t? faite ? ce sujet ?

For what it's worth, China and South Korea are different countries; so
far as I'm aware we have no dealings with Yahoo!'s subsidiary in China.

(It would be nice to know a bit more about this case; a quick skim of
the linked article doesn't say who passed information along where at
what point, on what authority.)

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikimedia-l/attachments/20050912/8cc73569/attachment.pgp>


body:
Anthere wrote:
> Emmanuel Engelhart <emmanuel at engelhart.org> wrote:
> Bonjour
>
> Je tiens ? faire part de mon inqui?tude ? la vue de cet article:
> http://www.courrierinternational.com/article.asp?obj_id=54946
>
> Il est normal que Yahoo respecte la loi chinoise, m?me si celle-ci est sc?l?rate.
>
> Mais, je serai tr?s (tr?s) m?content d'apprendre qu'un chinois a des difficult?s ? cause de son
> activit? (d?voil?e) sur un des projets de wikim?dia. Si Yahoo fournissait des informations comme
> elle vient de le faire, alors il ne serait pas exag?r? AMHA de poser la question du degr? de
> complicit? de la fondation dans cette affaire.
>
> Une clarification a-t-elle d?j? ?t? faite ? ce sujet ?

For what it's worth, China and South Korea are different countries; so
far as I'm aware we have no dealings with Yahoo!'s subsidiary in China.

(It would be nice to know a bit more about this case; a quick skim of
the linked article doesn't say who passed information along where at
what point, on what authority.)

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikimedia-l/attachments/20050912/8cc73569/attachment-0001.pgp>


subject: [Wikitech-l] Re: Differential storage

body:
On 12/09/05, Netocrat <netocrat at dodo.com.au> wrote:
[snip]
> The three main reasons to find an improvement to rcs diffs were stated as:
> * moved paragraphs
> * reverted edits
> * minor changes within a line
>
> The 1st and 3rd could be handled by a customised diff format and the 2nd
> could be handled by links in the database - have those possibilities been
> considered and what pros/cons are there to this approach vs the current
> compression scheme?

There was discussion about this when the new DB schema was created
(live in v1.5) - a "revision" is now stored as metadata, distinct from
the "text" it references, so you can have null revisions (appear in
the edit history but point at the same piece of text), and potentially
store reverts by pointing back at an earlier piece of text.

Seems to me, this would be trivial to implement (if it isn't already)
for the admin "rollback" button, pretty easy when people edit an out
of date revision (diff their edit against the version they're
editting; reuse the same text object if same), but slightly harder for
people manually reverting a small change as a normal edit (you'd need
to run diffs against the last few versions to see if any of them were
identical to the new one).

Of course, the same logic needed for the second and third cases would
be what allowed a diff-based system to pick a better version to diff
against rather than assuming the previous. (It could then ignore major
changes which were later reverted, even if the text was also changed
during the revert)

> > Not really. Tagging of revisions is likely to happen soonish, branching
> > not so likely.
>
> Being able to specify a particular revision in a link would be useful - I
> presume that's why tagging is being considered.

You can already specify a particular revision numerically (as of 1.5;
before that, the current revision wasn't stored as a revision) -
indeed, there is now a "permanent link" in the toolbox to bookmark the
current revision.

The point about tagging is for things like releasing "stable"
snapshots of a project - you need to have a database marker on the
"stable" revision of each page.

--
Rowan Collins BSc
[IMSoP]


from_name: Phil Boswell

subject: [WikiEN-l] Re: Re: Top-posting

body:
"Andrew Gray" <shimgray at gmail.com> wrote in
message news:f3fedb0d05091119023d54b0e3 at mail.gmail.com...
On 12/09/05, Daniel P. B. Smith
<dpbsmith at verizon.net> wrote:

> > What I object to is the frequent _flaming_ of people for top-posting,
> > and to the inaccurate claim that top-posting is considered a major,
> > important faux pas in all Internet discussions at all times.
> [Random factoid: first usenet citations I can find are just on eight
> years ago. Which surprises me; I'm sure I remember it around when I
> turned up. OTOH, they reference a pre-existing culture - "You can get
> in a lot of trouble in the Netscape newsgroups for 'Top Posting'." -
> so meh.)

Off the top of my head, ISTR this was not unconnected with the fact that by
default, most Microsoft products implement the "Reply" function in such a
way as to encourage top-posting. It was often immediately obvious that a
user was using a vanilla Microsoft product without having taken the
slightest effort to research the proper netiquette, and was as much of a red
flag to certain types of user as an AOL address. Many newbies were bitten in
those days :-)

IOW this anti-top-posting was in some ways as much "anti-Microsoft" as
anything else. The fact that you are referencing Netscape groups as a source
of early information suggests that my memory for this might not be as faulty
as I feared :-)

HTH HAND
--
Phil
[[en:User:Phil Boswell]]


from_name: Guettarda

subject: [WikiEN-l] Fair use

body:
On 9/12/05, Ryan Norton <wxprojects at comcast.net> wrote:
>
>
> On Monday, September 12, 2005, at 11:54 AM, uninvited at nerstrand.net
> wrote:
> > So would a policy that states, specifically, that images
> > taken from present-day news sources or wire services are against
> > Wikipedia policy, regardless of the fair use case that the uploader
> > thinks may apply.
>
> How do you define "present day"? The only case for that and say, 10
> years ago, is that doing it now might cause more bad press... but if
> you're going to do this you may as well just prohibit it altogether.

I would think that in a case like this "present day" would apply to images
that are still current, for which there is still significant demand from the
wire services. In other words, if a lot of people are still buying the
images from the wire services, if these images are still bringing traffic to
news sites that pay for them, then we should probably not be using them and
calling it "fair use" - with the obvious exception of things like a
screen-shot of a news site in a story about that news site (say, for
example, the NYTimes mistakenly posted Cheney's obituary tomorrow, we should
be able to use a screen shot of their web site, which might happen to
include other images, and call it fair use).

Ian


subject: [WikiEN-l] RE: Fair use

body:
> Where exactly have you been trying to form this policy by working
> through the issues? So far all I've you do is rewrite [[Wikipedia:Fair
> use]], which was on the whole a good thing. (I thought there were a
> few problems with it...)

Indeed, that was a major area, and there does appear to be some progress
there.  As you're aware, I've also edited a couple of of the tag
templates, and the Wikiproject page.  There has also been some
discussion on the speedy deletion page.

> I could be wrong, but it seems like you've nominated a whole single
> image for deletion along these lines in the last two weeks. If you
> think an image is a copyright infringement -- and doesn't qualify for
> fair use -- why not tag it as such and mark it for deletion?

At present I am more interested in policy matters.  I do not believe
that I can accomplish anything meaningful by my own extensive use of
and involvement in an existing copyvio image process that (a) is far
more work for the listing admin than the uploader, (b) takes weeks to
reach resolution in uncontroversial cases, and (c) has an excessive
inclusion bias for copyvio images with a fair use claim.  I'm willing
to review images, and list them for deletion, but not until the policy
issues are properly addressed.  I have had too much Wikistress in the
past trying to work to implement things that lacked definition.

> You added your name to [[Wikipedia:Wikiproject Fair use]], which has
> been quite active in rewriting fair use tags (and deleting problematic
> ones), and is on the cusp of having a workable system for users to
> label suspicious/disputed/approved fair use claims.
>
> If you'd like to participate in the discussion, please do. There are a
> number of people who are trying to draw up guidelines and feasible
> plans. I'm not trying to sound snarky, but you're clearly aware of our
> project, so I'm taking your complaining to the list as being some sort
> of indication that you don't think it is in alignment with your goals
> or thinking.

At present, the project isn't soundly grounded in legal advice.  I'm not
an attorney so I can't fix that.  However I do disagree with the other
WikiProject members in several important areas.  I believe this is a
matter better resolved by competent counsel rather than by compromise
and consensus.  That is why I have brought it here.

I believe, for example, that we do not accomplish anything meaningful by
using low-resolution images and sound clips; consenus appears to be that
resolution limits are important.  I don't think that discussing or
voting on this will help us because it is better settled by sound legal
advice.  I don't think it is in the best interests of the project to
have a bunch of laypeople (non-lawyers) dream up fair use policy.

> After some time assessing things, I think a great deal of our fair use
> images are just fine. The vast majority of them are things like box
> art and movie posters and are low-res, used appropriately in articles,
> have no "free" replacements available, and don't deny anybody future
> profitability.

I am unconvinced of this.  Other than the OCILLA safe harbor provisions,
I don't think we have a uniformly strong claim.  Many of the articles
don't have any meaningful critical content, instead merely serving to
identify the game or movie or book as the case may be and provide
noncritical directory information (credits, year of publication, and so
on).  I don't know what the case law has to say on that.

I don't believe that our fair use claim is in any way strengthened by
the absence of "free" replacements for copyrighted materials.

I believe that publicity photos require no fair use rationale for the
reasons I have stated on the appropriate policy page.

I believe that the non-commercial nature of the project should not be a
guiding factor in our choice of fair use policy, because of the need to
preserve re-use rights for mirrors.

You see it differently, and I understand that, and in most cases I
understand your reasoning.  Again, compromise and consensus are a poor
substitite for counsel in this case, which is why I'm not striving for
compromise and consensus.

> At the moment we've been mostly concentrating on
> sorting these sorts of things out so that it's easy to see get to the
> more problematic cases. These things take time, of course, and the
> efforts of volunteers -- hence a coordinating project.

The categorization efforts are indeed helpful.  It is the policy that
concerns me.


from_name: Travis Mason-Bushman

subject: [Flag] Re: [WikiEN-l] Article deletion

body:
Why do you keep saying they've been "driven away?" They've not been
"driven away," they've set up their own home for information. Wikipedia
is not a general knowledge base, it's an encyclopedia. Detailed
accounts of every single Star Trek thing possible are *not* all
encyclopedic. Creating an independent wiki is a GREAT way to expand
coverage of areas that may not necessarily be encyclopedic but may be
interesting to subsets of specific fans. I *encourage* it, in fact.

There is absolutely nothing stopping people from contributing to more
than one wiki.

-FCYTravis @ en.wikipedia

Travis Mason-Bushman
Public Relations Director
GAINSCO/Blackhawk Racing
travis at gpsports-eng.com


subject: [WikiEN-l] Re: Article deletion (proposed 1 month hiatus)

body:
While I agree with much of David Gerard's reasoning, I am unconvinced
that a one-month hiatus would provide any greater or more meaningful
space for discussion of an alternative than would business-as-usual at
AfD.

I do believe that it would lead to a rash of speedy deletions that lack
sufficient policy basis.

I continue to believe that any discussion of process issues at AfD will
go nowhere until there is greater agreement on what articles we want to
keep and what articles we want to delete.  The process discussions are
all polarized by the winners and losers they would create in the
inclusionism vs. deletionism spectrum.

The Uninvited Co., Inc.


list: wikipedia-l

from_name: Andre Engels

subject: [Wikipedia-l] New request for Cantonese Wikipedia: vote at 29-6

body:
On 9/12/05, Pawe? Dembowski <fallout at lexx.eu.org> wrote:
> > Well, we still wouldn't split the two, because it's still lunacy to split.
>
> Why don't we just have a Serbo-Croatian Wikipedia then instead of
> separate ones for each dialect?

Oh, but we do have that! We have BOTH a Serbo-Croatian Wikipedia (sh:)
AND separate Serbian, Croatian and Bosnian ones. Which I think is a
HIGHLY undesirable situation.

For this reason I have locked the Serbo-Croatian Wikipedia half a year
ago, but the pressure to unlock it got too strong, so I unlocked it
again. But only under protest. I think we should either have sh: or
sr+bs+hr:, but not both.

By the way, there is an issue with the Chinese languages there too -
if we get a separate Kantonese Wikipedia, we should not keep a Chinese
one alongside. Rather, we should make that into a Mandarin Wikipedia,
or even better, move each article to whatever language it has been
written in.

Andre Engels


from_name: Tim Starling

subject: [Wikitech-l] Messages can be blank

body:
UI messages can now be blank, this is now considered to be different to
missing. Unless there are strenuous objections, it will stay that way, I
think it makes more sense than those ugly   workarounds.

There were a few transient bugs over the last 24 hours related to this,
some messages erroneously showed up as blank when they were in fact
missing. This should be fixed now (thanks to Brion for helping with this).

I also improved the cache a bit.

-- Tim Starling


subject: [Wikipedia-l] Re: Re: new request for ASL/English wikipedia

body:
"Andrew Gray" <shimgray at gmail.com> wrote in
message news:f3fedb0d050909110328f83dbb at mail.gmail.com...
> On 09/09/05, Ros' Haruo <rosharuo at gmail.com> wrote:
>>  ... the project would likely cope much better as part of the
>> larger en.wiki community. ? Andrew Gray
>> (these are just a couple of random selections, nothing against either
>> poster
>> personally) could, I think, easily be taken as opposing the basic
>> Wikipedian
>> principle of people's right to access to information in their own
>> languages.
> My point was mainly directed at the "bilingual" idea. If it is to
> involve a large amount of text in English, which is the impression I
> got from the query, alongside the ASL... then it makes sense to try
> and arrange it in such a way as to take advantage of the fact that we
> have a well-developed, organised community writing that English text
> at an astonishing rate.

I concur, at the present time.

I can see very little difference between providing [[en:Wikipedia:Spoken
Wikipedia]] for those who have a problem with their sight and providing
[[en:Wikipedia:Signed Wikipedia]] for those who have a problem with their
hearing.

If the idea takes off and a great many articles are converted into Sign
Language, and someone comes up with a brilliant way of editing Sign Language
in a wiki-like manner, then this material could be used to jump-start a new
Wikipedia.

It seems to me that we could get a great deal done using the material we
already have, rather than waiting for the requisite wheel to be invented.

I sit ready to be corrected, of course, and I await developments eagerly.
--
Phil
[[en:User:Phil Boswell]]


from_name: Alphax

subject: [WikiEN-l] Re: [OT] Top posting

body:
Sam Korn wrote:
> On 9/11/05, MacGyverMagic/Mgm <macgyvermagic at gmail.com> wrote:
>
>>I can't help it, Gmail is set to top post too. And since all messages
>>are displayed in a conversation style, you don't need to worry about
>>that previous message. All quoted text is surpressed unless you reply
>>to specific part of it.
>>
>
> So the answer is clear: everyone subscribing to WikiEN-l should be
> compelled to use Gmail!
>

I do use Gmail, just not it's crappy web interface (and it's POP
interface isn't much better). Mostly, I get my messages forwarded to an
account that doesn't cost me anything to download from. You seem to
forget that not all of us are on unlimited high-speed internet...

--
Alphax                      |   /"\
Encrypted Email Preferred   |   \ /     ASCII Ribbon Campaign
OpenPGP key ID: 0xF874C613  |    X   Against HTML email & vCards
http://tinyurl.com/cc9up    |   / \


from_name: Stan Shebs

body:
David Gerard wrote:

>uninvited at nerstrand.net (uninvited at nerstrand.net) [050913 08:17]:
>
>
>>While I agree with much of David Gerard's reasoning, I am unconvinced
>>that a one-month hiatus would provide any greater or more meaningful
>>space for discussion of an alternative than would business-as-usual at
>>AfD.
>>
>
>
>You're right. Make it three.
>
>(We won't run out of disk space.)
>
I think this would be an interesting experiment. Instead of
deletionist and inclusionist camps throwing around anecdotes, you
get a sizeable body of candidates to study, plus it encourages people
to think about the process that they want to follow when the period
ends and they have a whole pile of articles they want to process
efficiently. We'll discover, how often borderline articles gets
improved into good ones when left alone, or get made into redirs to
existing articles. Some articles might be unfairly speedied, but
if they're being tracked from a protected list, I think admins will
leave the marginals to accumulate rather than risk being sanctioned
for deleting worthwhile material out of hand.

Stan


from_name: Lars Aronsson

subject: [Wikitech-l] [Fwd: [Wikipedia] DICT protocol]

body:
Tomasz Wegrzanowski wrote:
> For wikipedia, dictd is not very useful.
> For wiktionaries it is - this way content from the wiktionary
> becomes just one of many dict data feeds your dict client may use.

What are the scalability issues if wiktionary.org were to run a
central dictd server for the entire world to use?  How many
clients can connect simultaneously and how much traffic should be
expected from the average client?

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik - http://aronsson.se


subject: [WikiEN-l] Article deletion

body:
Takes it out of their hands and puts it into whose? The editors who
happen to have said page on their watchlist? Those who care enough
about an article to continually undelete it? Those with the most
patience?

(I'm not an AfD zealot, personally. There are, I think, reasons for
non-zealots to wonder if a PWDS would be best for this project.)

FF

On 9/12/05, Dan Grey <dangrey at gmail.com> wrote:
> On 12/09/05, Matt Brown <morven at gmail.com> wrote:
> > Having the discussions in a single place e.g. AfD biases the case towards
> > those whose interest is in general deletion policy, whether they be
> > deletionist, inclusionist, or whatever; in other words, regulars of that
> > page. Page deletion by blanking would be accompanied by discussion on the
> > talk page for an article, biasing the case towards those who care about the
> > article. Both have their flaws.
>
> Spot on. Personally, I favour the PWDS because it would take deletion
> out the hands of the folk who just hang around on AfD, and quite
> possibly end the majority democracy which seems to be the norm on AfD.
>
> Further, if deletion was in the hands of everyone, they'd have to
> reach a consensus - if they want to edit war over it, they're welcome
> to take 24 hours every fourth revert to reconsider their position ;-).
>
> Of course, PWDS will never be installed, as the entrenched AfD zealots
> will never concede to any change that threatens their pastime.
>
>
> Dan
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Ray Saintonge

subject: [WikiEN-l] Re: cruft

body:
Daniel P. B. Smith wrote:

>> I think the solution is perfectly clear. We fix the articles at a
>> reasonable rate....
>>
>> What do we really lose by having 100 mediocre-to-crappy articles on
>> obscure Pokemon? I mean, yes, I lose sanity if I try to read them,
>> but if they just sort of exist? The only thing I can think of that we
>> might lose is some respect. Here's the thing, though - this project
>> is four years old. We've built a pretty damn good encyclopedia in
>> four years.
>
>
> It's an equilibrium process.
>
> Bad articles are created _at some rate_, and get fixed _at some rate._
>
> Wikipedia is useful to me, in the areas where I have no expertise,
> _because the bad articles get fixed quickly enough, four years into
> the project, most of the articles in Wikipedia are pretty much OK._
>
> That isn't a law of nature. It's a consequence of the _balance_ of
> the rate of various things that are happening within Wikipedia.

Quite the contrary.  Remember that laws of nature are not the product of
some kind of government legislation.  Balances and trends, statistical
growth and fractals are what laws of nature are all about.  They are
things that just happen that way.

Ec


body:
Pawe? Dembowski wrote:

>>Well, we still wouldn't split the two, because it's still lunacy to split.
>>
>>
>Why don't we just have a Serbo-Croatian Wikipedia then instead of
>separate ones for each dialect?
>
There already is a Serbo-Croatian Wikipedia.  Leaving aside the question
of Cyrillic Serbian what it would take would be for the various flavours
of Serbian, Croatian and Bosnian nationalism to start contributing to
the common project, and letting the separate projects fade into
obscurity.  You won't accomplish anything by shutting down the separate
projects and telling the participants that they can only contribute to
the common one.  It is difficult in an area that has centuries of
experience at stressing differences to suddenly shift gears into a
common enterprise.  Tito had the sort of personality that could enforce
this, but it didn't last long after his death.

In the short run it will take individuals who are willing to copy and
consolidate articles from the three separate projects, preferably
beginning with non-controversial subjects.

Ec


from_name: Jakob Voss

subject: [Wikitech-l] Differencing Engine

body:
Hi!

Can anybody tell my what differencing algorithm MediaWiki uses?
DifferenceEngine.php starts with "see diff.doc" - a file I cannot find.
As far as I know it has been taken from phpwiki but is it still the same
algorithm and what algorithm does phpwiki exactely use? I have not found
any better references on differencing algorithms but the papers listed
at http://en.wikipedia.org/wiki/Diff#References. There seems to be some
new research in differencing XML-files. Is MedaWiki's differencing
algorithm based on E. Myers's algorithm (1986)?

Thanks and greetings,
Jakob


subject: [WikiEN-l] Fair use

body:
On 9/12/05, uninvited at nerstrand.net <uninvited at nerstrand.net> wrote:
> I have been trying to form policy by working through issues on
> Wikipedia, but it is becoming clear that (a) the general opposition to
> deletion of anything, (b) the inability to undelete images, and (c) the
> lack of understanding of the nuances of U.S. copyright law are working
> together to prevent any useful work from being done by consensus.  I
> believe that leadership, and careful involvement of counsel, will be
> necessary to adopt useful policy.

Where exactly have you been trying to form this policy by working
through the issues? So far all I've you do is rewrite [[Wikipedia:Fair
use]], which was on the whole a good thing. (I thought there were a
few problems with it, which I posted on the talk page for half a week
before just changing the text myself since nobody responded one way or
another. Nobody has yet to respond, one way or another.)

I could be wrong, but it seems like you've nominated a whole single
image for deletion along these lines in the last two weeks. If you
think an image is a copyright infringement -- and doesn't qualify for
fair use -- why not tag it as such and mark it for deletion? I'd be
happy to chime in against people who blatantly don't understand the
legal issues in question.

You added your name to [[Wikipedia:Wikiproject Fair use]], which has
been quite active in rewriting fair use tags (and deleting problematic
ones), and is on the cusp of having a workable system for users to
label suspicious/disputed/approved fair use claims.

If you'd like to participate in the discussion, please do. There are a
number of people who are trying to draw up guidelines and feasible
plans. I'm not trying to sound snarky, but you're clearly aware of our
project, so I'm taking your complaining to the list as being some sort
of indication that you don't think it is in alignment with your goals
or thinking. There's a list of people on the page who have all
expressed interest and probably wouldn't mind being contacted if you
had some issue you wanted a lot of interested and informed opinions
on.

After some time assessing things, I think a great deal of our fair use
images are just fine. The vast majority of them are things like box
art and movie posters and are low-res, used appropriately in articles,
have no "free" replacements available, and don't deny anybody future
profitability. At the moment we've been mostly concentrating on
sorting these sorts of things out so that it's easy to see get to the
more problematic cases. These things take time, of course, and the
efforts of volunteers -- hence a coordinating project.

FF


from_name: Dan Grey

subject: [WikiEN-l] Re: Cruft

body:
On 11/09/05, MacGyverMagic/Mgm <macgyvermagic at gmail.com> wrote:
> Some people also say that short articles are more likely to get edited.
> I say:
> 1) They have to be found first.

I just tried this as an experiment: completely at random, I decided to
search for "sheep shearing", and was redirected (I pressed "Go" not
"Search") to [[Sheep shearer]].

Now, this is where it gets interesting: a large part of that article
describes something called "Blade shears". But if you put "Blade
shears" into the search box and click Go, you're taken to a search
page which doesn't list [[Sheep shearer]] anywhere on the first page.
The top two results - [[Shearing]] and [[Shears]] - both lead to a
disambiguation page that doesn't mention blade shears at all, either.

This is just one example, but it's something I've noticed a lot - if
what you're looking for has its' own article, you're a lot more likely
to find it than if it's part of another article.

This isn't, of course, due to mergism - if the article had been
merged, the redirect would've remained. But it illustrates the
limitations of the search engine, and highlights the danger of trying
to write large articles covering lots of stuff, rather than seperate,
interlinked articles.

Dan


from_name: Snowspinner

subject: [WikiEN-l] Re: Cruft

body:
On Sep 11, 2005, at 4:50 AM, Alphax wrote:
>
> Alright, why do the Star Wars wiki and Memory Alpha exist? Can't the
> information in them go into Wikipedia (yes, I know that Memory
> Alpha is
> not GFDL-compatible)?
>
> --

I think this is an excellent point, actually - I think Memory Alpha
is another example of a Very Bad Thing, and that the fact that they
forked and used a different license is a devastating blow to our Star
Trek coverage that will NEVER HEAL. Every article I have read on
Memory Alpha would have made a fine Wikipedia article. And we get
none of it.

I'd say we need to make up our mind on whether we want to be the sum
total of human knowledge or the sum total of human knowledge that
will get us mainstream respect, but there's nothing to make our mind
up about. We want the former.

David is right. We would be better off with disks overflowing with
band vanity, original research, and poo jokes. Those don't do damage
to the community and to the long term success of the project. The
fact that we have to share the volunteers on Star Trek articles with
Memory Alpha, and that the work can never be merged does. So does
every other fork.

-Snowspinner


from_name: Timwi

subject: [Wikitech-l] Re: Differencing Engine

body:
> Can anybody tell my what differencing algorithm MediaWiki uses?

It uses the standard Linux tool "diff", doesn't it?


subject: [WikiEN-l] Systematic violation of the GFDL

body:
On 9/11/05, DF <dragons_flight at yahoo.com> wrote:
> The site boasts having more than 2000 pages of
> content.  Some of that is user submitted and fluff
> pieces, like ghost stories, that seem unlikely to have
> come from us.  But a large chunk is factual and
> historical content about the American Southwest.  If
> my informal survey is representative, we could be
> talking about dozens or even hundreds of pages with
> content copied from us.
>
> Do people have any suggestions for how to pursue this?

Two pages which might be of use if you haven't seen them already:
http://en.wikipedia.org/wiki/Wikipedia:Standard_GFDL_violation_letter
http://en.wikipedia.org/wiki/Wikipedia:Mirrors_and_forks#Non-compliance_process

FF


from_name: Kelly Martin

subject: [WikiEN-l] Article deletion

body:
On 9/10/05, Alphax <alphasigmax at gmail.com> wrote:
> So you don't think that any articles need to be deleted (outside of
> candidates for speedy deletion), ever?

Extreme lesbian support.

Kelly


from_name: Bryan Derksen

subject: [WikiEN-l] Article deletion

body:
Dan Grey wrote:

>Spot on. Personally, I favour the PWDS because it would take deletion
>out the hands of the folk who just hang around on AfD, and quite
>possibly end the majority democracy which seems to be the norm on AfD.
>
>
Hear hear. Instead of moving VfD to AfD, we might as well have moved it
to "Wikiproject Deletion." The last thing we need is a group of people
who _specialize_ in deciding what articles are allowed in Wikipedia. The
small, obscure articles don't get many people from outside the VfD
regulars to consider the matter.

>Of course, PWDS will never be installed, as the entrenched AfD zealots
>will never concede to any change that threatens their pastime.
>
>
The one-month VfD suspension Gerard suggested to force serious reform
might be workable, if we do it in a somewhat more organized manner than
Ed Poor's heroic deletion of VfD. I haven't been paying a lot of
attention to the VfD reform effort until just recently, do you think
perhaps we could get together a posse capable of making such a thing stick?


from_name: JAY JG

subject: [WikiEN-l] Article deletion

body:
>From: fun at thingy.apana.org.au (David Gerard)
>
>I reiterate my suggestion: suspend the deletion mechanism (keep CSD for our
>remaining sanity) for a month working out a deletion mechanism that won't
>drive people away

Have people been driven away?

Jay.


from_name: David Benbennick

body:
On 9/12/05, uninvited at nerstrand.net <uninvited at nerstrand.net> wrote:
> Images hosted on commons cannot be protected by admins from
> en.wikipedia.

An admin on EN need simply download the image, upload it to EN, and
protect.  We even have a template,
http://en.wikipedia.org/wiki/Template:C-uploaded, for this issue.

> Another problem area is that images on en: supercede those on commons
> with the same title.  Therefore, an image protected on commons could be
> vandalised by uploading a vandalised image by the same name on en
> (Unless there is a technical solution to this that I am not aware of.
> I haven't tried it).

You edit the image page on EN (either leaving it blank, or applying
the appropriate protection tag, like {{mprotected}}).  Then protect on
EN like normal.  That stops non-admins from uploading to EN.

> In general, I believe that there should be more trust and cooperation
> between the projects, to the point of having some process for fairly
> routine granting of commons adminship to en admins.

How about the reverse?  Are we prepared to grand EN adminship to all
Commons admins?

> I do note that there is an agreement to protect main page images that
> are on commons.  My concern is with other prominent pages.  The
> unexpected vandalism spree that accompanied the last U.S. presidential
> elections would be an example.

As far as I know, the Commons is perfectly happy to protect images for
other reasons.  They even have a template,
http://commons.wikimedia.org/wiki/Template:Protected.  I've never seen
a request for protection on the Commons Village pump that wasn't
honored.

[[User:Dbenbenn]], [[Commons:User:Dbenbenn]].


from_name: Netocrat

subject: [Wikitech-l] Differential storage

body:
What is/are the reason/s for storing the full text of page revisions in
the database as opposed to some form of differential?  Am I correct in
assuming that speed has been given priority over storage space
requirements, and if so, has any benchmarking been done to find out how
much overhead would be added by storing revision as diffs and how much
space would be saved?

Also, has there been any discussion of the possibility of branching a page
(as is possible in e.g. a CVS repository)?

I haven't seen anything on either of these issues after a quick search
through the list archives and some non-exhaustive reading of the main
wiki, so pointers to anything I've missed are welcome.

--
http://members.dodo.com.au/~netocrat


from_name: Paweł Dembowski

subject: [Wikipedia-l] Re: Bot for French cities on Romanian Wikipedia

body:
An international project for coordinating this kind of thing has been
created:
http://meta.wikimedia.org/wiki/Botopedia

--
Ausir
Wikipedia, wolna encyklopedia
http://pl.wikipedia.org


from_name: Ivan Krstic

subject: [Wikitech-l] Re: Differencing Engine

body:
Timwi wrote:
> It uses the standard Linux tool "diff", doesn't it?

No, since per-character instead of per-line granularity is needed.
MediaWiki ships its own PHP diff implementation. A tremendously
faster-performing C++ implementation is available in CVS along with a
SWIG interface, module 'wikidiff', which is in use at Wikimedia sites.

Jakob, I imagine the C++ code would be the quickest way to see how the
diff is done. It's been a while since I looked at it, so I don't recall
the algorithm used anymore.

-IK


from_name: Phroziac

subject: [WikiEN-l] Article deletion

body:
Then it simply becomes a vote, and not a straw poll to build consensus.
For example, when closing an afd, if someone says it's a copyvio of
www.google.com, it'll be deleted no matter how many keep votes there
are. And [[George W. Bush]] always gets speedy kept. And
[[Wikipedia:Votes for Deletion]] too.
The big thing i hate about vfd is the ban on merging or moving an
article for a week. You don't need consensus other then what any other
regular editorial function would need to merge something. And
non-admins can't speedy keep, can they?

On 9/12/05, Fastfission <fastfission at gmail.com> wrote:
> Lack of closure, for one thing. I don't necessarily think the current
> way works but at least you get some centralized discussion. My vision
> of the "pure wiki deletion system" is one in which, after a week of
> revert warring, people start complaining on some centralized place,
> filing RfCs, etc., until finally it comes down to ten editors saying
> "don't recreate the page or you'll get banned" which is really all AfD
> or VfD was doing anyway.
>
> There will always eventually be "discussion" at some point for the
> articles that people are going to force it over. And said discussion
> will probably always have bouts of "nastiness" if it's about whether
> someone's grandma is notable or not.
>
> In fact... maybe the best approach is not to encourage more commenting
> on voting in VfD, but to discourage it! A simple vote of "keep" or
> "delete", no discussion, no nastiness! (I'm only half joking.. but the
> half that is joking is indeed joking)
>
> The other thing of course is that blank pages are still indexed by
> Google and our own sad little search engine, if I understand it
> correctly. We could change this, of course, without too much
> difficulty in Media Wiki (just have it insert a noindex noarchive
> robot tag whenever it creates its cache of a page with no data or less
> than X characters or whatever), so that's just a minor quibble. Blank
> pages would also not appear as red links in the current
> implementation. But this, I'm sure, could also be changed.
>
> FF
>
> On 9/12/05, Bryan Derksen <bryan.derksen at shaw.ca> wrote:
> > Mark Gallagher wrote:
> >
> > >
> > > G'day Dan,
> > >
> > >>
> > >> Pure wiki deletion system.
> > >
> > >
> > > A vandal's paradise.
> > >
> > Vandals can _already_ blank pages. Other people notice the blanking,
> > check what's been blanked in the history, and if they think it was
> > inappropriate they revert it. What would change?
> >
> > _______________________________________________
> > WikiEN-l mailing list
> > WikiEN-l at Wikipedia.org
> > To unsubscribe from this mailing list, visit:
> > http://mail.wikipedia.org/mailman/listinfo/wikien-l
> >
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Darwin Sadeli

subject:
[Wikitech-l] Is it possible to download wikipedia images using FTP
	connection?

body:
Hi,

I just wondered, since I failed to download the wikipedia image dump
using HTTP connection, do you provide an FTP server and port for us to
download using FTP
connection. Or maybe, is there any other methods of downloading the
file besides using HTTP connection? Thank you in advance for your
assistance.

Regards,
Darwin Sadeli


from_name: Brion Vibber

subject: [Wikitech-l] MediaWiki default problems

body:
Arwel Parry wrote:
> On the cy: wikipedia we have noticed that user "MediaWiki default" (a
> bot?) seems to run every 6 months or so and repeatedly resets many of
> the MediaWiki strings either to an older version which has been
> corrected or (even worse) to English.  I've just had to edit
> :cy:MediaWiki:Go from "mynd" (travel) to "ewch" (imperative) again!
>
> It is intensely annoying to have to repeatedly go through
> Special:Allmessages trying to find out what has been screwed up (our
> users usually notice when the labels of the editing tabs or the sidebar
> go crazy). I know you need to create new strings for new features in
> MediaWiki but for goodness' sake can the bot be altered so that it
> doesn't interfere with pre-existing strings?

Unless someone's requested an explicit overwrite run, only messages
either not present or last edited by 'MediaWiki default' (ie those
created by the installer or periodic upgrades and refreshes) are
automatically updated. If something's been auto-updated that shouldn't
have, perhaps either it's a bug (in which case details always help to
track it down!) or the language file has changed that way and it's a
legitimate update from the software's point of view.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20050912/8a3f5cc9/attachment.pgp>


list: commons-l

from_name: Erik Moeller

subject: [Commons-l] Creative Commons -NC Considered Harmful

body:
For quite a long time, I've been meaning to write a summary of the key
reasons not to use "non-commercial uses only" licenses. It is now online at:

http://intelligentdesigns.net/Licenses/NC

I posted it to Kuro5hin as well, where it is now being discussed:

http://www.kuro5hin.org/story/2005/9/11/16331/0655

The version on the wiki is slightly more comprehensive and will
hopefully evolve over time.

This is not specific to Wikimedia, but I hope that those Wikimedians
lobbying individuals, governments, and educational or scientific
institutions to put their content under truly free licenses or into the
public domain will find this collection of arguments useful.

Best,

Erik


from_name: Fastfission

subject: [WikiEN-l] RE: Fair use

body:
On 9/12/05, uninvited at nerstrand.net <uninvited at nerstrand.net> wrote:
> At present I am more interested in policy matters.  I do not believe
> that I can accomplish anything meaningful by my own extensive use of
> and involvement in an existing copyvio image process that (a) is far
> more work for the listing admin than the uploader, (b) takes weeks to
> reach resolution in uncontroversial cases, and (c) has an excessive
> inclusion bias for copyvio images with a fair use claim.  I'm willing
> to review images, and list them for deletion, but not until the policy
> issues are properly addressed.  I have had too much Wikistress in the
> past trying to work to implement things that lacked definition.

What I was getting at was the fact that you were specifically
complaining about people not wanting to delete anything. I didn't see
where the evidence of that was -- if you could throw a link or two my
way it would make it easier to see that.

> At present, the project isn't soundly grounded in legal advice.  I'm not
> an attorney so I can't fix that.  However I do disagree with the other
> WikiProject members in several important areas.  I believe this is a
> matter better resolved by competent counsel rather than by compromise
> and consensus.  That is why I have brought it here.
>
> I believe, for example, that we do not accomplish anything meaningful by
> using low-resolution images and sound clips; consenus appears to be that
> resolution limits are important.  I don't think that discussing or
> voting on this will help us because it is better settled by sound legal
> advice.  I don't think it is in the best interests of the project to
> have a bunch of laypeople (non-lawyers) dream up fair use policy.

OK. Then don't complain about how you've tried to discuss this and
haven't gotten anywhere with it. You haven't tried to discuss it. In
the end, the hope is that one of our Wikilawyer types will look over
all of the things we've been working on. But they're probably busy
too. Better a dreamed up fair use policy based on some understanding
of copyright law than no fair use policy at all. I don't think most of
our legal understandings are really so baseless -- there is a heap of
caselaw on the usage of small or degraded media in regards to fair use
-- but then again, hey! I'm not a lawyer, so what the hell do I know.
If you want discussion, it's there for you. If you want "just
discussion with lawyers" then you'd better find a few lawyers who want
to participate. They're welcome to participate too if they want to.

You've named a few miscellaneous issues here, none of which you've
bothered raising on the project talk page, or really anywhere else for
that matter. So I'm not sure why you're clamoring about your lack of
discussion -- it's clear that what you really want is some closure.
Which is fine -- wouldn't we all like that? -- but don't make it out
like you're being ignored. You are, erm, "invited" to participate in
the wiki way.

I'd love it if some legal types would stop by and take a look at what
we're up to, give some guidance when it comes down to it. At the
moment we're trying to get something basic together, something to work
with, and correct the obvious problems of the current policy which
have allowed things to get a bit out of control. Which is frankly
better than nothing, in my opinion. If your attempts to get
unequivocal answers to difficult and murky questions turns up anything
useful, please feel free to let the rest of us know. In the meantime,
we'll continue our work.

FF


from_name: Sam Korn

subject: [WikiEN-l] Re: [OT] Top posting

body:
On 9/12/05, Alphax <alphasigmax at gmail.com> wrote:
> I do use Gmail, just not it's crappy web interface (and it's POP
> interface isn't much better). Mostly, I get my messages forwarded to an
> account that doesn't cost me anything to download from. You seem to
> forget that not all of us are on unlimited high-speed internet...

Please see [[irony]] for explanation of my comment.

Sam


from_name: MacGyverMagic/Mgm

subject: [WikiEN-l] Re: Cruft

body:
> This isn't, of course, due to mergism - if the article had been
> merged, the redirect would've remained. But it illustrates the
> limitations of the search engine, and highlights the danger of trying
> to write large articles covering lots of stuff, rather than seperate,
> interlinked articles.
>
>
> Dan
>
I've seen lots of people unfamiliar with Wikipedia complain because
the search engine doesn't list any close matches and the go button
confuses them too.

Regardless of whether mergism is good or not, I think the search
engine could use some upgrading.

-Mgm


from_name: Alphax

subject: [WikiEN-l] Article deletion

body:
Jimmy Wales wrote:
> Dan Grey wrote:
>
>>On 11/09/05, Jimmy Wales <jwales at wikia.com> wrote:
>>
>>
>>>Phroziac wrote:
>>>
>>>
>>>>No, afd just needs to *die*. I still don't see why anyone thought
>>>>renaming it would fix the problems.
>>>
>>>But die to be replaced with what?
>>>
>>>Deletion is absolutely necessary.  A community process for deletion is
>>>absolutely necessary.
>>
>>
>>Pure wiki deletion system.
>
>
> Can you explain what you mean by that?  In some detail?
>

As has been explained a few times now (and will probably need explaining
a few more, because it's such a crazy idea) you "delete" pages by
blanking them. A vandal's paradise.

Of course, we could adopt the "pure wiki deletion system on wheels",
where you delete a page by moving it and then blanking the redirect...

--
Alphax                      |   /"\
Encrypted Email Preferred   |   \ /     ASCII Ribbon Campaign
OpenPGP key ID: 0xF874C613  |    X   Against HTML email & vCards
http://tinyurl.com/cc9up    |   / \


subject: [Wikitech-l] Re: Differential storage

body:
On Mon, 12 Sep 2005 01:56:53 -0700, Brion Vibber wrote:
> Netocrat wrote:
>> What is/are the reason/s for storing the full text of page revisions in
>> the database as opposed to some form of differential?
>
> Expedience; it hasn't been written yet.
>
>>  Am I correct in
>> assuming that speed has been given priority over storage space
>> requirements, and if so, has any benchmarking been done to find out how
>> much overhead would be added by storing revision as diffs and how much
>> space would be saved?
>
> See Tim's presentation from 21C3: http://zwinger.wikimedia.org/berlin/

That's exactly the sort of info I was looking for.  Was any attempt made
to compress the diffs?  I would be interested to know how the result
compared for compression and overall speed to the compressed concatenated
revisions.

The three main reasons to find an improvement to rcs diffs were stated as:
* moved paragraphs
* reverted edits
* minor changes within a line

The 1st and 3rd could be handled by a customised diff format and the 2nd
could be handled by links in the database - have those possibilities been
considered and what pros/cons are there to this approach vs the current
compression scheme?

The disadvantage to the current compression scheme seems to me to be that
the wiki software must work on the full text of a set of revisions at a
time (i.e. when uncompressed).

>> Also, has there been any discussion of the possibility of branching a
>> page (as is possible in e.g. a CVS repository)?
>
> Not really. Tagging of revisions is likely to happen soonish, branching
> not so likely.

Being able to specify a particular revision in a link would be useful - I
presume that's why tagging is being considered.

--
http://members.dodo.com.au/~netocrat


from_name: SPUI

subject: [WikiEN-l] blocked for being bold

body:
SPUI wrote:
> Oh, and I love how I'm blocked for a day by the autoblocker.
>
I was just blocked for an hour, and the autoblocker only gave until the
expiration of the ban. Looks like someone fixed it - good job!

Do your part and kill a deletionist today.


from_name: Snowspinner

subject: [WikiEN-l] Re: Cruft

body:
Despite the well-deserved chastising from Angela, I stand by my
assertion that Memory Alpha has a disastrous long-term effect on
Wikipedia, and that these... I'm not sure what you want to call them.
Other encyclopedias, I suppose. Regardless, I think they have a
profoundly negative effect on the long-term success of Wikipedia.

-Snowspinner

On Sep 12, 2005, at 7:50 PM, Angela wrote:

> On 9/12/05, Snowspinner <Snowspinner at gmail.com> wrote:
>
>
>> I think this is an excellent point, actually - I think Memory Alpha
>> is another example of a Very Bad Thing, and that the fact that they
>> forked and used a different license is a devastating blow to our Star
>> Trek coverage that will NEVER HEAL.
>>
>
> Memory Alpha was never a fork of Wikipedia. Please see
> http://memory-alpha.org/en/wiki/
> Memory_Alpha:General_FAQ#What_are_the_goals_of_Memory_Alpha.3F
> and
> http://memory-alpha.org/en/wiki/Memory_Alpha:History
> for details of how the project got started.
>
> The founders were inspired by the collaborative nature of Wikipedia,
> but they were not intending on forking it, as evidenced by the fact
> the license they (wrongly) chose meant they could never use Wikipedia
> content. This was also not a fork of the Wikipedia community, but
> instead drew individuals from the various Star Trek communities,
> especially since this replaced the former Star Trek Encyclopedia
> project which had started in the mid 90s. Whether or not those people
> might have started editing Wikipedia is unknown, but it is simply
> wrong to claim that they forked either the content or community of
> Wikipedia.
>
> Angela
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Dan Grey

subject: [WikiEN-l] Article deletion

body:
On 12/09/05, Matt Brown <morven at gmail.com> wrote:
> Having the discussions in a single place e.g. AfD biases the case towards
> those whose interest is in general deletion policy, whether they be
> deletionist, inclusionist, or whatever; in other words, regulars of that
> page. Page deletion by blanking would be accompanied by discussion on the
> talk page for an article, biasing the case towards those who care about the
> article. Both have their flaws.

Spot on. Personally, I favour the PWDS because it would take deletion
out the hands of the folk who just hang around on AfD, and quite
possibly end the majority democracy which seems to be the norm on AfD.

Further, if deletion was in the hands of everyone, they'd have to
reach a consensus - if they want to edit war over it, they're welcome
to take 24 hours every fourth revert to reconsider their position ;-).

Of course, PWDS will never be installed, as the entrenched AfD zealots
will never concede to any change that threatens their pastime.

Dan


from_name: Rowan Collins

subject: [Wikitech-l] Re: Re: Differential storage

body:
On 12/09/05, Netocrat <netocrat at dodo.com.au> wrote:
> On Mon, 12 Sep 2005 13:38:57 +0100, Rowan Collins wrote:
> [...]
> > You can already specify a particular revision numerically (as of 1.5;
> > before that, the current revision wasn't stored as a revision) - indeed,
> > there is now a "permanent link" in the toolbox to bookmark the current
> > revision.
>
> I meant in a wiki link.  i.e. something like [[Some Page?Revision]]
>
> As far as I know that isn't possible.

Ah... http://bugzilla.wikimedia.org/268 :p

--
Rowan Collins BSc
[IMSoP]


subject: [WikiEN-l] Article deletion

body:
On 9/12/05, Dan Grey <dangrey at gmail.com> wrote:
> Spot on. Personally, I favour the PWDS because it would take deletion
> out the hands of the folk who just hang around on AfD, and quite
> possibly end the majority democracy which seems to be the norm on AfD.
>
> Further, if deletion was in the hands of everyone, they'd have to
> reach a consensus - if they want to edit war over it, they're welcome
> to take 24 hours every fourth revert to reconsider their position ;-).
>
> Of course, PWDS will never be installed, as the entrenched AfD zealots
> will never concede to any change that threatens their pastime.

Dan, you are one of the most vocal proponents of the PWDS.  Please
explain to me this: what  would we gain by having revert wars over
something, with blatantly obvious vandalism available in page
histories, rather than deleting outright?

This may be "pure wiki" and therefore desirable from a social point of
view, if you take the viewpoint that Wikipedia is a wiki as would
conventionally be seen.  I suggest, however, that many ideas about
wikis do not apply to Wikipedia because of the difference in scale and
therefore vandalism.

In the end, we are going to force discussions over the matter.  It is
conventional WP philosophy that edit wars are not good.  They attract
trolls and POV-pushers and, in the end, force a tyranny of the
majority, as the 3RR will always win.  However, the discussions would
essentially be AfD discussions about controversial articles.

So we are back where we started.

So I ask this:

1) What do we hope to gain by introducing PWDS?
2) How do we handle the vandals who will blank a page (as many already
do for vandalism) then to claim "but I was deleting the article"?

If the only reasons are ideological, I don't think PWDS is valid.
Otherwise, I am open to persuasion.

Yours,
Sam


subject: [WikiEN-l] Re: Cruft

body:
On Sep 12, 2005, at 8:42 PM, Pawe? Dembowski wrote:
>
> And why is that? Memory Alpha is a project for creating a Star Trek
> encyclopedia that just happens to use the MediaWiki software. As seen
> in the history page, if it hadn't, it would just be another Star Trek
> database, not editable by everyone - and it allows for a level of
> details that would be just silly at Wikipedia. Same with other
> fan-wikis. For example, I wrote this article at The Vault:
> http://vault.duckandcover.cx/index.php?title=Two-headed_bear
> and I would definitely vote for the deletion of such article if it
> were created at Wikipedia.

Although I am sure there are articles in Memory Alpha that would not
be suitable for Wikipedia, I have not yet found one.

-Snowspinner


from_name: Mark Williamson

body:
Again, there are many different mutually incomprehensible signed
languages. Countries where English is the primary language don't all
have the same signed language (British sign language is not even
related to American sign language), and American Sign Language is also
used in countries where English is NOT the primary language (most
notably in parts of Mexico).

Mark

On 12/09/05, Phil Boswell <phil.boswell at gmail.com> wrote:
> "Andrew Gray" <shimgray at gmail.com> wrote in
> message news:f3fedb0d050909110328f83dbb at mail.gmail.com...
> > On 09/09/05, Ros' Haruo <rosharuo at gmail.com> wrote:
> >>  ... the project would likely cope much better as part of the
> >> larger en.wiki community. ? Andrew Gray
> >> (these are just a couple of random selections, nothing against either
> >> poster
> >> personally) could, I think, easily be taken as opposing the basic
> >> Wikipedian
> >> principle of people's right to access to information in their own
> >> languages.
> > My point was mainly directed at the "bilingual" idea. If it is to
> > involve a large amount of text in English, which is the impression I
> > got from the query, alongside the ASL... then it makes sense to try
> > and arrange it in such a way as to take advantage of the fact that we
> > have a well-developed, organised community writing that English text
> > at an astonishing rate.
>
>
> I concur, at the present time.
>
> I can see very little difference between providing [[en:Wikipedia:Spoken
> Wikipedia]] for those who have a problem with their sight and providing
> [[en:Wikipedia:Signed Wikipedia]] for those who have a problem with their
> hearing.
>
> If the idea takes off and a great many articles are converted into Sign
> Language, and someone comes up with a brilliant way of editing Sign Language
> in a wiki-like manner, then this material could be used to jump-start a new
> Wikipedia.
>
> It seems to me that we could get a great deal done using the material we
> already have, rather than waiting for the requisite wheel to be invented.
>
> I sit ready to be corrected, of course, and I await developments eagerly.
> --
> Phil
> [[en:User:Phil Boswell]]
>
>
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>

--
SI HOC LEGERE SCIS NIMIVM ERVDITIONIS HABES
QVANTVM MATERIAE MATERIETVR MARMOTA MONAX SI MARMOTA MONAX MATERIAM
POSSIT MATERIARI
ESTNE VOLVMEN IN TOGA AN SOLVM TIBI LIBET ME VIDERE


body:
Andre, the situation with Cantonese is a very different one.

None of the articles at zhwiki -- none of them, even though there are
over 20.000 -- are written in Cantonese.

The vast majority of people looking for a "Chinese Wikipedia" will be
looking for the existing Wikipedia in the Mandarin-based written
vernacular. Some may be surprised or excited at the existance of a
Cantonese Wikipedia and go there instead, but given the numbers I
don't think it would be reasonable to force the current Chinese
Wikipedia to move.

Mark

On 12/09/05, Andre Engels <andreengels at gmail.com> wrote:
> On 9/12/05, Pawe? Dembowski <fallout at lexx.eu.org> wrote:
> > > Well, we still wouldn't split the two, because it's still lunacy to split.
> >
> > Why don't we just have a Serbo-Croatian Wikipedia then instead of
> > separate ones for each dialect?
>
> Oh, but we do have that! We have BOTH a Serbo-Croatian Wikipedia (sh:)
> AND separate Serbian, Croatian and Bosnian ones. Which I think is a
> HIGHLY undesirable situation.
>
> For this reason I have locked the Serbo-Croatian Wikipedia half a year
> ago, but the pressure to unlock it got too strong, so I unlocked it
> again. But only under protest. I think we should either have sh: or
> sr+bs+hr:, but not both.
>
> By the way, there is an issue with the Chinese languages there too -
> if we get a separate Kantonese Wikipedia, we should not keep a Chinese
> one alongside. Rather, we should make that into a Mandarin Wikipedia,
> or even better, move each article to whatever language it has been
> written in.
>
> Andre Engels
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>
>
>

--
SI HOC LEGERE SCIS NIMIVM ERVDITIONIS HABES
QVANTVM MATERIAE MATERIETVR MARMOTA MONAX SI MARMOTA MONAX MATERIAM
POSSIT MATERIARI
ESTNE VOLVMEN IN TOGA AN SOLVM TIBI LIBET ME VIDERE


body:
Hi Ffarr,

It's nice to see you've subscribed to Wikipedia-l.

Although it's a little bit off-topic, I'd like to ask you what you
think of the Traditional-Simplified conversion system in its current
form.

Obviously, it's not perfect, but do you find it satisfactory? Or do
you think it has a long way to go still before it can be accepted?

Mark

On 12/09/05, Far <ffaarr at seed.net.tw> wrote:
> On 9/12/05, Pawe? Dembowski <fallout at lexx.eu.org> wrote:
> > > Well, we still wouldn't split the two, because it's still lunacy to split.
> >
> > Why don't we just have a Serbo-Croatian Wikipedia then instead of
> > separate ones for each dialect?
>
> Oh, but we do have that! We have BOTH a Serbo-Croatian Wikipedia (sh:)
> AND separate Serbian, Croatian and Bosnian ones. Which I think is a
> HIGHLY undesirable situation.
>
> For this reason I have locked the Serbo-Croatian Wikipedia half a year
> ago, but the pressure to unlock it got too strong, so I unlocked it
> again. But only under protest. I think we should either have sh: or
> sr+bs+hr:, but not both.
>
> By the way, there is an issue with the Chinese languages there too -
> if we get a separate Kantonese Wikipedia, we should not keep a Chinese
> one alongside. Rather, we should make that into a Mandarin Wikipedia,
> or even better, move each article to whatever language it has been
> written in.
>
> Andre Engels
>
>
> -----
> The two situations are different at all.  The  ZH Wikipedia is now  in fact Mandarin Wikipedia. No  articles in Kantonese, Minnan, Hakka , Wuu etc.   are written there. If someone  wrote   in zh wikipedia an article by the  language of Test-zh-yue, it will soon be deleted or translated into Chinese to make users of  zh wikipedia understand it.
>
> ffaarr
>
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>

--
SI HOC LEGERE SCIS NIMIVM ERVDITIONIS HABES
QVANTVM MATERIAE MATERIETVR MARMOTA MONAX SI MARMOTA MONAX MATERIAM
POSSIT MATERIARI
ESTNE VOLVMEN IN TOGA AN SOLVM TIBI LIBET ME VIDERE


from_name: Michael Turley

subject: [WikiEN-l] Article deletion

body:
On 9/12/05, Andrew Gray <shimgray at gmail.com> wrote:
> Had you done it a month ago... but people may be resistant to a second
> major upheaval in a couple of weeks, given the mutterings about the
> last one.

Excellent point.  I agree completely.  Even the most extreme
inclusionists should recognize the fact that the deletionists are also
trying in earnest to improve Wikipedia.  Taking away something that
many of them certainly see as <u>a primary tool in their toolbox</u>
for improving Wikipedia for a month is not very considerate of their
feelings.

Some form of "consensus to remove bad articles" is a vital organ to
Wikipedia.  Poison cannot be safely removed from a body by removing a
vital organ.  Something less extreme than suspending AfD/VfD is in
order.

I never tire of explaining, again and again, at various times, my own
views regarding certain articles worth keeping.   I do this mainly
because people who fully understand each others' motives seldom hold
long term grudges.

I suggest we consider adding an optional "hidden from casual browsers"
flag to Wikipedia article records, so that we would have a two level
deletion system: complete crap gets speedied, bad articles get deleted
as usual, good articles get kept as usual, and questionable articles
are shuffled off to limbo where they can be further developed before
being put back into the main articlespace.  (I'm not even sure how
much I like this idea myself, but thought I'd throw it out there.)

--
Michael Turley
User:Unfocused


from_name: Karl A. Krueger

subject: [WikiEN-l] blocked for being bold

body:
On Mon, Sep 12, 2005 at 08:07:24PM -0400, SPUI wrote:
> Do your part and kill a deletionist today.

I'm hoping that someone with administrative access heard this
cry for help and extended that block to indefinite.

--
Karl A. Krueger <kkrueger at whoi.edu>


subject: [WikiEN-l] Article deletion

body:
On 9/12/05, David Gerard <fun at thingy.apana.org.au> wrote:
> Kill it for a month. That month should get people REALLY FOCUSED on a
> deletion mechanism that's less toxic than the present one.

Wow, a little extremist now? Calm down man. The vfd backlog is bad
enough already.


from_name: Jack Lynch

subject: [WikiEN-l] Re: Cruft

body:
I agree, and have often been annoyed that the option to use google
(and now yahoo) to help you search is only available in certain
situations.

Jack (Sam Spade)

On 9/12/05, MacGyverMagic/Mgm <macgyvermagic at gmail.com> wrote:
> > This isn't, of course, due to mergism - if the article had been
> > merged, the redirect would've remained. But it illustrates the
> > limitations of the search engine, and highlights the danger of trying
> > to write large articles covering lots of stuff, rather than seperate,
> > interlinked articles.
> >
> >
> > Dan
> >
> I've seen lots of people unfamiliar with Wikipedia complain because
> the search engine doesn't list any close matches and the go button
> confuses them too.
>
> Regardless of whether mergism is good or not, I think the search
> engine could use some upgrading.
>
> -Mgm
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Bryan Derksen

body:
geni wrote:

>>I think this would be an interesting experiment. Instead of
>>deletionist and inclusionist camps throwing around anecdotes, you
>>get a sizeable body of candidates to study, plus it encourages people
>>to think about the process that they want to follow when the period
>>ends and they have a whole pile of articles they want to process
>>efficiently.
>>
>>
>
>The inclusionist camp could of course just obstruct everything.
>
>
And the deletionists camp could of course just speedy-delete everything.

Or, both camps could assume good faith and relax a bit, each not
thinking that the "other guys" are a bunch of deranged
encyclopedia-haters who want to destroy everything in an orgy of
deletion and/or garage band stubs. :) A lot of people are currently
disagreeing over what sorts of articles merit inclusion in Wikipedia,
but it's not like most of those people think Wikipedia's going to go
down in flames if the "wrong" standards are picked. At least, they
shouldn't. Wikipedia is more resistant than that.

>What risk? Admins on RC patrol will be able to delete stuff before
>anyone else has time to react and digging thourgh the deletion log
>when you don't have admin powers is imposible and when you do it is
>insanely boring.
>
>
>
Are there no inclusionist admins who would go on "deletion log patrol"
if such a thing became common? Would you worry about a corresponding
problem of unchecked undeletion?

As one possible alternative, the "pure wiki deletion" method of simply
blanking pages would make it a lot easier to double-check and revert by
non-admins.


from_name: Ivan Krstic

subject: [Wikitech-l] Re: Differencing Engine

body:
Tim Starling wrote:
> There is indeed a C++ version, but we don't use it. Brion had a bit of
> trouble installing it, [...]

Ah. For some reason I was convinced the C++ version was in use. Out of
curiosity, do you or Brion recall what the installation trouble was?

-IK


from_name: Tomasz Wegrzanowski

body:
On Mon, Sep 12, 2005 at 04:05:33PM +0200, Lars Aronsson wrote:
> Tomasz Wegrzanowski wrote:
> > For wikipedia, dictd is not very useful.
> > For wiktionaries it is - this way content from the wiktionary
> > becomes just one of many dict data feeds your dict client may use.
>
> What are the scalability issues if wiktionary.org were to run a
> central dictd server for the entire world to use?  How many
> clients can connect simultaneously and how much traffic should be
> expected from the average client?

dictd servers typically use read-only preprocessed databases,
and are therefore easily replicable. Just dump wiktionary once a day,
preprocess it to suitable format and copy over nfs or something.

The computational costs and traffic overhead are low (but unlike http
no free gzip-on-fly) - it's a really just a very simple protocol with
clients only reading data from servers.

The only operation that is any expensive are various advanced match strategies,
like "match by regular expression" or "match by substring".
However the RFC requires that we implement only exact match
and prefix match, if it was any problem.

Maintaining one more daemon and the processing scripts would
probably be the highest part of the cost.


from_name: Phroziac

body:
Why is this a good idea? You're going to give Ed ideas. Again.

On 9/12/05, David Gerard <fun at thingy.apana.org.au> wrote:
> uninvited at nerstrand.net (uninvited at nerstrand.net) [050913 08:17]:
>
> > While I agree with much of David Gerard's reasoning, I am unconvinced
> > that a one-month hiatus would provide any greater or more meaningful
> > space for discussion of an alternative than would business-as-usual at
> > AfD.
>
>
> You're right. Make it three.
>
> (We won't run out of disk space.)
>
>
> - d.
>
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Andrew Gray

subject: [WikiEN-l] Article deletion

body:
On 12/09/05, David Gerard <fun at thingy.apana.org.au> wrote:

> > imagine would handle the dozens of silly articles added to Wikipedia each
> > day which rightfully should be deleted.
>
> They can collect for a month while we try to work out a less toxic deletion
> mechanism that will scale.

This, in itself, would form an interesting experiment. slap together a
holding page, redirect VfD to it, have people list anything they would
otherwise have vfd'ed. Then, after a month or so, see how many have
been speedied, redirected, cleaned-up, or otherwise "neutralised"...

--
- Andrew Gray
  andrew.gray at dunelm.org.uk


from_name: Brion Vibber

subject: [Wikitech-l] Re: MediaWiki default problems

references:
<t2+LFqCyDiJDFw5O@cartref.demon.co.uk>
	<432630A1.1060400@pobox.com> <dg5iej$ejp$1@sea.gmane.org>

body:
Tim Starling wrote:
> Avar recently ran it with --rebuild on ruwiki in order to fix a few
> blank messages. This drew complaints, and from what I know of the facts,
> rightly so. Maybe he did it on cy as well.

Basically --rebuild should never be used unless you _want_ to wipe out
*every* customized message and replace it with the default. So hopefully
that's not happening too often. :)

If we have a general problem with blank messages, another way should be
devised to clear them.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20050912/35b489e8/attachment.pgp>


subject: [Wikitech-l] Re: Differential storage

body:
On Tue, Sep 13, 2005 at 12:24:27AM +1000, Netocrat wrote:
> I have ideas, I may do that at some point.  My instinct is that a diff
> scheme that took account of intra-line changes as well as block text moves
> would result in the most compression; and that if that alone didn't, then
> compressing that diff scheme in the way that the entire revision set
> currently is, would.  The question I haven't delved into is: how difficult
> would it be to do that and how computation-intensive compared to what is
> currently done?

Maybe download a dump and try with xdelta ?


subject: [WikiEN-l] Re: Re: Top-posting

body:
Phil Boswell wrote:
> "Andrew Gray" <shimgray at gmail.com> wrote in
> message news:f3fedb0d05091119023d54b0e3 at mail.gmail.com...
> On 12/09/05, Daniel P. B. Smith
> <dpbsmith at verizon.net> wrote:
>
>
>>>What I object to is the frequent _flaming_ of people for top-posting,
>>>and to the inaccurate claim that top-posting is considered a major,
>>>important faux pas in all Internet discussions at all times.
>>
>>[Random factoid: first usenet citations I can find are just on eight
>>years ago. Which surprises me; I'm sure I remember it around when I
>>turned up. OTOH, they reference a pre-existing culture - "You can get
>>in a lot of trouble in the Netscape newsgroups for 'Top Posting'." -
>>so meh.)
>
>
> Off the top of my head, ISTR this was not unconnected with the fact that by
> default, most Microsoft products implement the "Reply" function in such a
> way as to encourage top-posting. It was often immediately obvious that a
> user was using a vanilla Microsoft product without having taken the
> slightest effort to research the proper netiquette, and was as much of a red
> flag to certain types of user as an AOL address. Many newbies were bitten in
> those days :-)
>
> IOW this anti-top-posting was in some ways as much "anti-Microsoft" as
> anything else. The fact that you are referencing Netscape groups as a source
> of early information suggests that my memory for this might not be as faulty
> as I feared :-)
>

Google is the new Microsoft... Hotmail is the new AOL...

Further posts on this topic to flamewars-l at wikimedia.org, please ;)

--
Alphax                      |   /"\
Encrypted Email Preferred   |   \ /     ASCII Ribbon Campaign
OpenPGP key ID: 0xF874C613  |    X   Against HTML email & vCards
http://tinyurl.com/cc9up    |   / \


subject: [WikiEN-l] Re: Cruft

body:
On Sep 12, 2005, at 10:50 PM, Mark Gallagher wrote:
>
> Why is it a Bad Thing to lose /Trek/-only contributions?  Not just
> for /Trek/, but for anything where fans get a little too
> enthusiastic to judge encyclopaedic worth.  Do we need a separate
> article for every planet mentioned in passing in the /Star Wars/
> movies (or in the novels, or cartoons, or comics, or --- it'll
> happen --- fanfic)?

Fanfic is for the most part not verifiable, due to its extremely
ephemeral nature, although I have supported a few highly notable
fanfics getting articles - most memorably the Very Secret Diaries.
Every planet mentioned in passing? No. I've also never said articles
that are perma-stubs should be kept. I think perma-stub is a very
good reason for deletion.

On the other hand, why not have full descriptions of every episode of
Star Trek, and every character who's appeared in more than one
episode? Why not have an article on every actor or actress who has
had a substantive speaking part in a Star Trek episode? It harms
nothing, and has a meaningful benefit.

Yes. I do believe that any article on a topic that is verifiable,
reasonably assured to remain verifiable in ten years, and capable of
having more than a stub written about it should have an article. What
reason is there not to do this? Disk space isn't an issue. Naming
conventions can and have been sorted out in the past. What's the
reason not to do this?

-Snowspinner


subject: [WikiEN-l] Re: Cruft

body:
On Sep 12, 2005, at 11:07 PM, Pawe? Dembowski wrote:

> Well, perma-stubs are certainly welcome at fan wikis.

Perhaps, but I don't think that the need to create perma-stubs is why
people make fan wikis, and I think if this were the only issue, they
mostly wouldn't.

-Snowspinner


from_name: Tim Starling

subject: [Wikitech-l] Re: Differential storage

body:
Netocrat wrote:
> On Mon, 12 Sep 2005 01:56:53 -0700, Brion Vibber wrote:
>>See Tim's presentation from 21C3: http://zwinger.wikimedia.org/berlin/
>
>
> That's exactly the sort of info I was looking for.  Was any attempt made
> to compress the diffs?  I would be interested to know how the result
> compared for compression and overall speed to the compressed concatenated
> revisions.

No, no work has been done along these lines that I'm aware of.

> The three main reasons to find an improvement to rcs diffs were stated as:
> * moved paragraphs
> * reverted edits
> * minor changes within a line
>
> The 1st and 3rd could be handled by a customised diff format and the 2nd
> could be handled by links in the database - have those possibilities been
> considered and what pros/cons are there to this approach vs the current
> compression scheme?

No, these possibilities have not been rigorously examined. Note that
those aren't really reasons. They're illustrative only, addressing each
of them in turn does not guarantee that your compression algorithm is
effective. I was just describing my train of thought in arriving at the
idea that LZ77 might be worth a try. If you have your own idea, please
download a dump and try it out.

The main thing which put me off implementing diff-based compression was
the complexity, in particular the required schema change. If you need to
load some large number of diffs in order to generate a revision, those
diffs need to be loaded in a single database query, if any kind of
efficiency is to be reached.

In other words, don't do a proof of principle and then nag me to write
the real thing, as if that were the easy part.

Since that talk, we've addressed the scalability issue by implementing
external storage, allowing us to store text on the terabytes of apache
hard drive space which were previously unused. Because of this, we're
less concerned about size now, and more about performance and
manageability. We'd like to have faster backups and much simpler
administration. Effective use of the existing compression and external
storage features has been hampered by high system administration
overhead. Any new storage proposal needs to be evaluated in this context.

> The disadvantage to the current compression scheme seems to me to be that
> the wiki software must work on the full text of a set of revisions at a
> time (i.e. when uncompressed).

The advantage is that when a number of adjacent revisions are required
(such as during a backup), those revisions can be loaded quickly with a
minimum of seeking.

-- Tim Starling


body:
Why would protecting images on commons do anything, since the vandals
can simply upload the images to EN?

I don't see why anyone who is not interested in the commons project
should be an admin there.


from_name: Paweł Dembowski

subject: [WikiEN-l] Article deletion

body:
> I refer you again to the two examples that have been brought up repeatedly:
> Memory Alpha and Comixpedia. We're not getting those volunteers back, and
> in the former case we can't ever heal the fork because they chose a
> different licence. Those forks were a stupid and bad idea. And if you
> disagree on that, please explain what good they do Wikipedia, both in
> themselves as forks and as bad examples frustrated contributors may follow
> in the future.
> - d.

I wouldn't say Memory Alpha is bad. Their non-commercial license
allows them to use more materials copyrighted by Paramount, and
some articles that belong to a fan-wiki wouldnt' really belong to
Wikipedia. Same with other fan-wikis, like Battlestar Wiki or The
Vault (a [[Fallout (computer game)]] wiki). I don't think full
dialogue files from a computer game or articles about every minor
character in a game belong to Wikipedia. That's why I founded a
separate wiki for that, not because I was driven away.

--
Ausir
Wikipedia, wolna encyklopedia
http://pl.wikipedia.org


from_name: Netocrat

subject: [Wikitech-l] Re: Differential storage

body:
On Mon, 12 Sep 2005 23:40:55 +1000, Tim Starling wrote:

[...]
> No, these possibilities have not been rigorously examined. Note that
> those aren't really reasons. They're illustrative only, addressing each
> of them in turn does not guarantee that your compression algorithm is
> effective. I was just describing my train of thought in arriving at the
> idea that LZ77 might be worth a try.  If you have your own idea, please
> download a dump and try it out.

I have ideas, I may do that at some point.  My instinct is that a diff
scheme that took account of intra-line changes as well as block text moves
would result in the most compression; and that if that alone didn't, then
compressing that diff scheme in the way that the entire revision set
currently is, would.  The question I haven't delved into is: how difficult
would it be to do that and how computation-intensive compared to what is
currently done?

> The main thing which put me off implementing diff-based compression was
> the complexity, in particular the required schema change. If you need to
> load some large number of diffs in order to generate a revision, those
> diffs need to be loaded in a single database query, if any kind of
> efficiency is to be reached.

Yes, I realise that.

> In other words, don't do a proof of principle and then nag me to write
> the real thing, as if that were the easy part.

To start with I want to get an idea of what's currently done and why, and
any ideas previously proposed and/or rejected and why.  I understand that
the main wikis are huge and that performance issues are important.

--
http://members.dodo.com.au/~netocrat


subject: [Flag] Re: [WikiEN-l] Article deletion

body:
> Er, the Comixpedia people were pretty clearly driven away by truly stupid
> misapplication of truly stupid VFD nonpolicy.
> - d.

True, but I don't think it's the case with MemoryAlpha.

--
Ausir
Wikipedia, wolna encyklopedia
http://pl.wikipedia.org


body:
On Mon, 12 Sep 2005 13:38:57 +0100, Rowan Collins wrote:
> On 12/09/05, Netocrat <netocrat at dodo.com.au>
> wrote: [snip]
>> The three main reasons to find an improvement to rcs diffs were stated
>> as: * moved paragraphs
>> * reverted edits
>> * minor changes within a line
>>
>> The 1st and 3rd could be handled by a customised diff format and the
>> 2nd could be handled by links in the database - have those
>> possibilities been considered and what pros/cons are there to this
>> approach vs the current compression scheme?
>
> There was discussion about this when the new DB schema was created (live
> in v1.5) - a "revision" is now stored as metadata, distinct from the
> "text" it references, so you can have null revisions (appear in the edit
> history but point at the same piece of text), and potentially store
> reverts by pointing back at an earlier piece of text.
>
> Seems to me, this would be trivial to implement (if it isn't already)
> for the admin "rollback" button, pretty easy when people edit an out of
> date revision (diff their edit against the version they're editting;
> reuse the same text object if same),

Yup, that's the sort of thing I was thinking of.

> but slightly harder for
> people manually reverting a small change as a normal edit (you'd need to
> run diffs against the last few versions to see if any of them were
> identical to the new one).

That would have to be done on every save as far as I can see; the previous
revisions would need to be called up from the database.  It may be slow,
but it may also improve compression.

> Of course, the same logic needed for the second and third cases would be
> what allowed a diff-based system to pick a better version to diff
> against rather than assuming the previous. (It could then ignore major
> changes which were later reverted, even if the text was also changed
> during the revert)

Right; the neat thing is that you would generate some meta-data to
indicate which recent version an edit is most similar to.  So in the case
of edit wars, you could kind of have a branched page without explicit
support for branching.

[...]
> You can already specify a particular revision numerically (as of 1.5;
> before that, the current revision wasn't stored as a revision) - indeed,
> there is now a "permanent link" in the toolbox to bookmark the current
> revision.

I meant in a wiki link.  i.e. something like [[Some Page?Revision]]

As far as I know that isn't possible.

--
http://members.dodo.com.au/~netocrat


subject: [WikiEN-l] Re: Cruft

body:
On 9/13/05, Pawe? Dembowski <fallout at lexx.eu.org> wrote
"if it hadn't, it would just be another Star Trek database, not
editable by everyone"

Mediawiki is NOT the only wiki software.


subject: [WikiEN-l] Article deletion

body:
On 13/09/05, Bryan Derksen <bryan.derksen at shaw.ca> wrote:
> Dan Grey wrote:
>
> >Spot on. Personally, I favour the PWDS because it would take deletion
> >out the hands of the folk who just hang around on AfD, and quite
> >possibly end the majority democracy which seems to be the norm on AfD.
> >
> >
> Hear hear. Instead of moving VfD to AfD, we might as well have moved it
> to "Wikiproject Deletion." The last thing we need is a group of people
> who _specialize_ in deciding what articles are allowed in Wikipedia. The
> small, obscure articles don't get many people from outside the VfD
> regulars to consider the matter.
>
> >Of course, PWDS will never be installed, as the entrenched AfD zealots
> >will never concede to any change that threatens their pastime.
> >
> >
> The one-month VfD suspension Gerard suggested to force serious reform
> might be workable, if we do it in a somewhat more organized manner than
> Ed Poor's heroic deletion of VfD. I haven't been paying a lot of
> attention to the VfD reform effort until just recently, do you think
> perhaps we could get together a posse capable of making such a thing stick?

Had you done it a month ago... but people may be resistant to a second
major upheaval in a couple of weeks, given the mutterings about the
last one.

--
- Andrew Gray
  andrew.gray at dunelm.org.uk