from_name: Ken Arromdee

subject: [WikiEN-l] The vexed issue of sources

body:
On Sat, 9 Dec 2006, Thomas Dalton wrote:
> The source being used in the article is not the writing on the wall.
> The source is the few Wikipedians that have seen the writing. While
> the writing is probably reliable, the few Wikipedians are not.

By this reasoning, a source isn't a book, it's the few Wikipedians who have
read the book.

How exactly is the writing on the wall different from a book?  (Sure, not
every Wikipedian can go read the writing, but not every Wikipedian has access
to a particular book either.)


list: foundation-l

source: pipermail-mbox

from_name: Gerard Meijssen

subject: [Foundation-l] Introducing a new mailing list

body:
Hoi,
Many do think of Wikipedia as "their baby"; ie something that they feel
strongly about. Given the numbers our baby is particularly fed by males
and yes, we all want our baby to become big and strong. The BBC has an
article about gender bias where it shows that it is when WOMEN control
the household, the best opportunity for the child to be fed properly are
provided..

You might say nothing new here, but then again, giving the reaction by
some, I expect it to be news for others.

http://news.bbc.co.uk/2/hi/south_asia/6162959.stm

Thanks,
    GerardM


list: wikimedia-l


list: wikien-l

from_name: Utkarshraj Atmaram

subject: [WikiEN-l] How to clear a backlog

body:
On 12/11/06, theProject <wp.theproject at gmail.com> wrote:
> I've spent the last week or two observing and trying to help out with the
> backlog on [[Category:Articles to be merged]]. Unfortunately, it looks like
> the backlog is rapidly spinning out of control -- I haven't actually kept
> track, but I have a sneaking suspicion that there are many more merge
> requests added than are serviced every day. Right now the backlog is a
> little under 10,000 articles, and I would like to see if we can't brainstorm
> a new way to deal with backlogs, because our current methods aren't dealing
> with our worst backlogs. (Our worst backlogs, ironically but expectedly, are
> the ones users are least likely to start tackling.)
>

Unlike wikification and other such tasks, in most cases, a merge is best done by
somebody who has little knowledge about the subject. I do hunt out the articles
to be merged that I know something about.

Right now, many people who put the [[Template:Merge]] or [[Template:Mergeto]]
don't use [[Template:Mergefrom]]. This is one of the main reasons behind the
backlog.

The article to be merged is usually an orphaned or little known about
article. On
the other hand, the article that is to receive the merged material is usually on
many watchlists. If [[Template:Mergefrom]] is used, many editors will notice
it and help with the merge.

--
Utkarshraj Atmaram
http://en.wikipedia.org/wiki/User:Utcursch


list: wikitech-l

from_name: Travis Derouin

subject: [Wikitech-l] ImportFreeImages Extension

body:
Hi,

Thanks. I've fixed this.

Travis

On 12/10/06, Bence Damokos <bdamokos at gmail.com> wrote:
>
> Hi
> I also found, that if you search for something and click on next, then you
> get an empty page, because the next link doesn't pass on the query (ie. it
> links to
>
> http://wikidiy.com/mediawiki-1.8.2/index.php?title=Special:ImportFreeImages&p=2instead
> of
>
> http://wikidiy.com/mediawiki-1.8.2/index.php?title=Special:ImportFreeImages&p=2&q=tate
> )
> Also if you use the search box after clicking next it passes on the query
> to
> index.php instead of index.php/Special:ImportFreeImages (eg. I get
> http://wikidiy.com/mediawiki-1.8.2/index.php?q=tate+gallery when searching
> after clicking next). Could this be because after clicking next the url
> changes to index.php?title=<title> form from index.php/<title> ?
>
> Regards, Bence
>
>


from_name: Aerik Sylvan

subject:
[Wikitech-l] Wikitech-l Digest, Vol 41,
	Issue 24 (Category Intersections again)

body:
Rob Church and Timwi wrote (regarding frequency of edits that change
categories):

> >
> > Probably higher than that, to be honest, especially with all those
> > Wikipedians running around, dealing with Special:Uncategorisedpages,
> > and correcting stub templates and so forth.
>
> Also don't forget about vandals just blanking a (categorised) page, plus
> the immediately following revert.

Okay, well, so that we have some quantified data and can think make a firm
decision one way or the other about the suitability of a MyISAM table for
category intersections, I'll take a random sample of edits (of some
statistically significant size - doesn't take much) and see how many involve
a category change and report back.

And, as always, anybody else got any ideas?  If this can't work, I can't
think of anything else beside a separate Lucene index (which will then not
be real time and have to be updated every so often) as I don't think
excluding large categories from an intersection search is an acceptable
solution.

Thanks,
Aerik


subject: [Wikitech-l] ImportFreeImages Extension

body:
Thanks. I've updated the global variable names to be more specific.

I support an improvement that could be made could be to put the display
configuration parameters, the license parameter and the sorting parameter as
an option in the Mediawiki namespace. It might not be a good idea though to
put the API key there however.

Travis

On 12/10/06, Rob Church <robchur at gmail.com> wrote:
>
>
> You probably also want to review your naming of global configuration
> variables, and make sure that there won't be any possible ambiguity
> later. Also consider where the MediaWiki namespace can be used
> effectively to make things more customisable for the administrators.
>
>
> Rob Church
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


subject: [Wikitech-l] ImportFreeImages Extension

body:
On 12/10/06, Brianna Laugher <brianna.laugher at gmail.com> wrote:
>
> As Rob suggested, I have a feeling $wgTemplateName should just point
> to something in MediaWiki: namespace.

Yeah, this might be good, but if it's a template, when you want to change
the look/feel or wording of the message, you can do so without having to
update all of the images that are already imported.

As Luiz said, we really need to download the original hi-res version
> of images, too.
>
> Also, it really needs an option to write a filename in. Flickr
> filenames are frequently meaningless. In the same vein, it appears to
> silently overwrite existing images of that name (see
> http://wikidiy.com/mediawiki-1.8.2/index.php/Image:Punk.jpg ). This is
> very, very bad. :)

A good idea - but it interferes with the one-click ease of the tool. Do you
have any ideas of ways to add this feature and still have it really easy to
use?

Travis


from_name: theProject

subject: [WikiEN-l] How to clear a backlog

body:
On 12/11/06, Guettarda <guettarda at gmail.com> wrote:
>
> On 12/11/06, Ilmari Karonen <nospam at vyznev.net> wrote:
> >
> > <snip>
> > a) Advise admins to always perform the merge when closing, if at all
> > possible.  This could mean just cut-and-pasting the text and slapping a
> > cleanup tag on it, but at least the merge itself would get done.
>
>
> No, this is unacceptable - a text dump, even from another article, is
> horrible, borderline vandalism.  Have you ever seen the results of
> something
> like that?  Article quality is more important than making AfD closings
> easy
> and mechanical.  If anything, the onus should be on the people voting
> merge... the closing admin could drop a note to the people voting "merge"
> (after all, these people should know enough about the topic to carry out
> the
> merge).
>
> b) Suggest that busy admins just redirect the page to be merged and put
> > a notice on the talk page of the target page with a link to the text to
> > be merged.  We could even make a special template for this.  This will
> > only take care of one half of "merge and redirect", but half done is
> > better than nothing at all.
> >
> > c) Make a new "afdmerge" template (or templates), for use in cases where
> > the decision to merge has already been reached on AfD.  This template
> > would state that consensus has already been reached and would strongly
> > recommend that anyone having the time to carry out the merge go ahead
> > and do it.
> >
> > None of these are, of course, mutually exclusive.  If anyone can suggest
> > other possible approaches, please do.
> >
> > --
> > Ilmari Karonen
> > _______________________________________________
> > 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
>

Well, I disagree that it's borderline vandalism, because it's at least half
of a merge, even if merging does bring an article's quality down before
bringing it back up.

I see there are a lot of ideas for how to prevent future backlogs, but I was
also hoping to encourage discussion as to how we can deal with the backlogs
(all of the large ones) we've got right now.

--
theProject


from_name: Jimmy Wales

subject: [WikiEN-l] "Fair use" images of living people

body:
Gregory Maxwell wrote:
> On 11/15/06, Fastfission <fastfission at gmail.com> wrote:
> [snip]
>> That's all well and good. But does this mean that NO images of people
>> who are currently alive can be used under "fair use"? After all, if
>> they are alive, potentially one could take a picture of them and
>> license it as GFDL.
> [snip]
>
> It's not hard (finally) to find examples where our policy has
> increased the pool of free content. I don't think you're disputing
> that from that perspective our policy wins.
>
> That alone makes a pretty compelling argument, and as you pointed
> out.. it's that thinking that underlies much of that policy.

I dug up this old thread as a platform to talk about something I just
noticed the other day.  I think Greg is exactly right... even in its
current "weak" state, the policy of preferring not to have fair use
photos when free is possible is generating wonderful incentives for the
creation of free content.

Here is my new example, one I just noticed.  It may be instructive for
us to take a snapshot of the current state of affairs as an anecdotal
benchmark of where we are a year from now or two years from now.

Elvis.

If you look in Wikimedia Commons right now, you will see some US
government photos (public domain, no problem) and a couple of others
that, in my opinion, are there on some very shaky grounds and probably
should be deleted.

If you look in English Wikipedia, you will see several "fair use" photos
which are quite unremarkable and which almost certainly should be replaced.

But how can one get a freely licensed photo of Elvis now?  He's quite
dead or anyhow, if you remember the tabloid craze of a few years back,
quite in hiding. ;-)

But we CAN.  There must be literally hundreds of thousands of photos of
Elvis, some of them quite good, which were taken by Elvis fans
throughout the years.  Surely we can find a handful that the
photographers would love to have in Wikipedia.  Why isn't this happening
already on a massive scale?

I can tell you why... because from the point of view of "free as in
beer" the photos we have (via fair use) in the article are just "good
enough" to kill free alternatives.

What if instead of the photos we have there now, we had a template
{{fair use wanted}}.

The template says "Help!  We need a freely licensed image!"

Clicking takes you to a page with some simple instructions...

1. You must have taken the photo YOURSELF, no uploads of anything else.

2. You agree to release the photo under GFDL and/or CC BY-SA at a minimum.

3. You must have taken the photo YOURSELF.  (Yes, we said that already,
but we want you to know how important it is.)

I suspect if we did this for tons of famous people, the photos would
come pouring in... preserving a bit of history that is currently rotting
in people's photo albums... and making Wikipedia not just a place where
people can rehash tired publicity photos under fair use arguments, but a
place where new culture is formed and born and distributed.

Right now, our reliance on fair use (which I support only in some narrow
historically unique cases!) is killing the birth of a culture of free
photography in wikipedia.

--Jimbo


body:
Sarah wrote:
> The usual response when I write to a living person to ask for a freely
> licensed image of them is 'Yes of course you have my permission,"
> followed by how much they love Wikipedia. I have to write again
> explaining about our policies, our aim of making freely licensed
> material available, the need not to rule out commercial use etc.
> Sometimes they get it the second time. Often they reply: "I hereby
> license the image for anyone to use with no restrictions, for
> educational purposes." I have to write again and tell them "for
> educational purposes" is a restriction. I usually have to give them
> the precise words they need to say in order to release the image
> entirely.
>
> By the time this is done, I feel very exploitative of them. I want
> their image on WP, they want it on WP, and the article is more
> informative for having it. So it's win-win. And yet I have to insist
> that they abandon all rights before that win-win situation can be
> acted upon. It feels irrational.

It seems like a partial practical resolution to this difficulty would
involve something only slightly technical... a special page to which we
could direct people where they could grant permissions.  A simple wizard.

For example, Sarah uploads the image, along with the email address of
the person who says "yes of course you have my permission".  This
triggers an email to them giving them a link to visit to finalize the
process.  The link is some kind of hash of the email address.

They visit the link.  They see the image in question.  They click a box
that says "Yes, I own the copyright to this image, and I release it
under CC BY-SA."  (And that's a link to the CC page about BY-SA.)

This gets recorded in the image history.

It's reasonably secure, if done well, and generates a paper trail of how
Sarah got the permission.

And it is a lot less frightening to people than a long conversation in
email.

--Jimbo


from_name: Jeff V. Merkey

subject: [Foundation-l] Revised Bylaws posted

body:
Has Brad refiled these by-laws with the state of Florida for the
non-profit and are they in affect now?

Jeff

>The revised Bylaws of the Wikimedia Foundation can now be found at:
>http://wikimediafoundation.org/wiki/Wikimedia_Foundation_bylaws
>
>Differences to the previous version:
>http://wikimediafoundation.org/w/index.php?title=Wikimedia_Foundation_bylaws&diff=16676&oldid=14947
>
>These changes were approved at the Board meeting in St. Petersburg. A few notes.
>
>1) Statement of purpose now reflects the current mission statement. It
>will be updated if needed when the mission statement is finalized.
>
>2) Membership does not legally exist. Membership was previously
>described in the bylaws but not actually implemented. We've discussed
>this issue at some length and decided that the risk of membership do
>not outweigh the potential benefits. The risks include:
> - Disclosure of identity to others. We do not want to limit
>participation in WMF
>   activities to those who are willing to disclose their identity to
>other members.
> - Hostile takeover. Given the power of members to elect or recall the
>Board, the
>   risk then arises of large numbers of people being affiliated with
>some entity
>   (economic, political or religious) to attempt to restructure the
>organization to
>   their liking.
>- Unnecessary hierarchy. It is possible that legal membership would negatively
>  impact the social dynamics of the project when members and non-members
>  are treated differently.
>- Administrative overhead. WMF is simply not presently in an organizational
>  position to effectively manage thousands of membership registration.
>- Questionable benefits. We can have most of the benefits of a membership system
>  without legally encoding it in our bylaws.
>
>It was argued that this kind of organizational representation could
>find a home in chapter organizations, some of which already have legal
>members.
>
>3) Terms defined. Both appointed and elected Board members now have
>clearly defined terms (1 and 2 years, respectively). That is, even
>Jimmy and Michael are now not "members for life," but will have to be
>re-appointed in the future (unless they want to stand for election
>instead). No Board members are named in the bylaws.
>
>4) The notion of community elections is described in the bylaws, as is
>a commitment that a majority of the Board will come from the community
>through appointment or election (the scope of "community" is to be
>defined by the Board).
>
>5) The Executive Secretary and Treasurer do not need to be Board
>members anymore. The roles of the Board positions were simplified and
>clarified.
>
>6) Annual financial audits and quarterly reviews.
>
>7) Some further legal adjustments and clarifications to reflect the
>reality of organizational operations.
>
>Again, see the diff above for the full list of changes. Comments &
>questions welcome.
>
>
>


subject: [Foundation-l] Revised Bylaws posted


from_name: Brianna Laugher

subject: [Wikitech-l] ImportFreeImages Extension

body:
On 11/12/06, Simetrical <Simetrical+wikitech at gmail.com> wrote:
> Glancing over the code, I didn't notice any permission controls.
> Maybe it would be best to set up a user permission.  It could default
> to everybody but be configurable, so that only
> sysops/autoconfirmed/etc. could upload them.  IIRC, on Commons there's
> a huge queue of images from Flickr that need to be reviewed by sysops
> to ensure that their license as labeled is actually correct, so they
> might want to restrict this easy-upload to sysops only.

But these are essentially already reviewed! That's why it appears so
useful to me. The only case this would miss is where the Flickr
uploader has lied and the work is not actually their own (eg they
uploaded all the promo images for their favourite band, and just
happened to set the license as CC-BY for all their files).But I think
only human intervention can avoid these cases and they seem to be
luckily relatively rare, anyway.

$wgFlickrLicense should take CC-BY *and* CC-BY-SA.

As Rob suggested, I have a feeling $wgTemplateName should just point
to something in MediaWiki: namespace.

As Luiz said, we really need to download the original hi-res version
of images, too.

Also, it really needs an option to write a filename in. Flickr
filenames are frequently meaningless. In the same vein, it appears to
silently overwrite existing images of that name (see
http://wikidiy.com/mediawiki-1.8.2/index.php/Image:Punk.jpg ). This is
very, very bad. :)

cheers
Brianna
user:pfctdayelise


from_name: The Cunctator

subject: [WikiEN-l] The vexed issue of sources

body:
On 12/11/06, Ken Arromdee <arromdee at rahul.net> wrote:
>
> On Sat, 9 Dec 2006, Thomas Dalton wrote:
> > The source being used in the article is not the writing on the wall.
> > The source is the few Wikipedians that have seen the writing. While
> > the writing is probably reliable, the few Wikipedians are not.
>
> By this reasoning, a source isn't a book, it's the few Wikipedians who
> have
> read the book.
>
> How exactly is the writing on the wall different from a book?  (Sure, not
> every Wikipedian can go read the writing, but not every Wikipedian has
> access
> to a particular book either.)

A wall carving is more likely to last longer.


from_name: Steve Bennett

subject: [WikiEN-l] <Ref> tags s__k

body:
On 12/10/06, geni <geniice at gmail.com> wrote:
> It isn't garbage formatting. It is a template designed to make
> reference more standard and less work and it manages both for those
> who learn how to use it. For the rest of us there is long hand.

The benefit of storing citations in a semantically marked up format
(such as the cite templates) should be self-evident. The fact that
this is difficult to achieve at the present without producing
unreadable wikitext is a problem - but it doesn't mean we should
abandon the goal of maintaning references at a high level.

The references: namespace idea is certainly attractive, but would need
more advanced searching capabilities than mediawiki has at present,
both to find existing references, as well as to assure yourself they
don't exist if you can't find them. Definitely worth exploring this
idea further...

Also, if the major problem with separating the reference to a
reference from its definition is broken references, then maybe some
more technical solutions would help. Warnings to the user as soon as
they break stuff, that type of thing.

Steve


subject: [Wikitech-l] What does the "undo" link do?

body:
On 12/10/06, Andrew Garrett <andrew at epstone.net> wrote:
> > I don't see a particular reason not to show it; it would just be the
> > same as clicking 'edit' on the previous revision. :)
>
> Precisely why it's unnecessary.

You deserve a visit from Phil, the Prince of Insufficient Light.

Steve


from_name: Gregory Maxwell

body:
On 12/11/06, Matt R <matt_crypto at yahoo.co.uk> wrote:
> --- Jimmy Wales <jwales at wikia.com> wrote:
> > It seems like a partial practical resolution to this difficulty would
> > involve something only slightly technical... a special page to which we
> > could direct people where they could grant permissions.  A simple wizard.
>
> I've negotiated free images from a number of different sources, and I can also
> testify that it is very awkward when you end up having to press people on the
> issue of a free license. So much so that I don't really like to do it any more.
> A wizard would be a great help.

<AOL/>

Actually, I think the hardest part isn't explaining the free license..
but rather getting the people to reply-to or cc the permissions queue
in their response.  This solves *that* issue completely.

Of course, it's a great idea.

What I don't think it would handle well as proposed is multiple
images. Whomever implements this should make it cover those some way.
:)


subject: [WikiEN-l] First fair use criterium

body:
On 12/8/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> It is an explicit goal of the project to produce an encyclopedia of
> free content. Fair use images are not free. Thus it is harmful because
> the explicit goals of the project define unfree content as a
> non-solution.  The fact that other factors may make the harm
> preferable to other harms does not change the fact that unfree content
> is a harm.

Let's paraphrase into parable language:

"The explicit goal of the project is to acquire a collection of
apples. Therefore, every time someone gives us an orange, this is
harmful to our project."

This, by itself, is not logical. The implied extra clause that
supposedly makes this logical is that people think that if we have
enough oranges, we don't need any more apples. I would suggest that
this attitude is what needs correcting, rather than our lovely orange
collection.

Steve


from_name: Guettarda

subject: [WikiEN-l] How to clear a backlog

body:
On 12/11/06, Ilmari Karonen <nospam at vyznev.net> wrote:
>
> <snip>
> a) Advise admins to always perform the merge when closing, if at all
> possible.  This could mean just cut-and-pasting the text and slapping a
> cleanup tag on it, but at least the merge itself would get done.

No, this is unacceptable - a text dump, even from another article, is
horrible, borderline vandalism.  Have you ever seen the results of something
like that?  Article quality is more important than making AfD closings easy
and mechanical.  If anything, the onus should be on the people voting
merge... the closing admin could drop a note to the people voting "merge"
(after all, these people should know enough about the topic to carry out the
merge).

b) Suggest that busy admins just redirect the page to be merged and put
> a notice on the talk page of the target page with a link to the text to
> be merged.  We could even make a special template for this.  This will
> only take care of one half of "merge and redirect", but half done is
> better than nothing at all.
>
> c) Make a new "afdmerge" template (or templates), for use in cases where
> the decision to merge has already been reached on AfD.  This template
> would state that consensus has already been reached and would strongly
> recommend that anyone having the time to carry out the merge go ahead
> and do it.
>
> None of these are, of course, mutually exclusive.  If anyone can suggest
> other possible approaches, please do.
>
> --
> Ilmari Karonen
> _______________________________________________
> 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: Brion Vibber

subject: [Wikitech-l] Multiple image namespaces in the same wiki

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alex Powell wrote:
> Any ideas on this or is it just "unsupported at this time"?

No such ability is supported at this time, and we don't really expect to
add it. At some point there'll be more aliases for 'Image', but only one
file store area.

You'd need to do a lot of hacking.

- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFFfcRVwRnhpk1wk44RAvjsAJ44fpBu3SDu4ZJCzLIA6qwlHG7o4gCXabJB
1q8R0N96TLZtkbBCGu/PHA==
=WMf5
-----END PGP SIGNATURE-----


from_name: cohesion

body:
On 12/11/06, geni  wrote:

> First getting outsiders involved in wikipedia is always tricky.
> Perhaps this can be delt with through some form of marketing.
>
> Secondly we would be looking towards some of the smaller subsets of
> internet users. For a lot of the internet users elvis has been dead
> longer than they have been alive. This could to a degree be delt with
> by going looking for material rather than expecting it to come to us
>

That's true, but I think for most of the internet users all we have
really been asking them to do (from their perspective) is correct
typos. If all you ever did on wikipedia was read occasional articles
that were google search results you wouldn't know of any other way to
help out. This is evidenced by all our experience I think. When we
tell people we spend a lot of time on wikipedia, I think we have all
had the experience of people not even understanding what that means,
or what, other than reading we could possibly be doing.

If these image requests are actually on the articles, this could
become a major change in how average readers perceive helping
wikipedia. It would become not only correcting typos, but supplying
content. Not everyone is willing to write an article, but I bet some
people are willing to upload a photo, especially if they have an
interesting one they are proud of. Make the fact that they will get
attribution clear, and that they are helping a non-profit, I think
that will be beneficial.

This could turn out really well.

Judson
[[:en:User:Cohesion]]


subject: [WikiEN-l] How to clear a backlog

body:
On 12/11/06, theProject <wp.theproject at gmail.com> wrote:
>
> On 12/11/06, Guettarda <guettarda at gmail.com> wrote:
> >
> > On 12/11/06, Ilmari Karonen <nospam at vyznev.net> wrote:
> > >
> > > <snip>
> > > a) Advise admins to always perform the merge when closing, if at all
> > > possible.  This could mean just cut-and-pasting the text and slapping
> a
> > > cleanup tag on it, but at least the merge itself would get done.
> >
> >
> > No, this is unacceptable - a text dump, even from another article, is
> > horrible, borderline vandalism.  Have you ever seen the results of
> > something
> > like that?  Article quality is more important than making AfD closings
> > easy
> > and mechanical.  If anything, the onus should be on the people voting
> > merge... the closing admin could drop a note to the people voting
> "merge"
> > (after all, these people should know enough about the topic to carry out
> > the
> > merge).
> >
> > b) Suggest that busy admins just redirect the page to be merged and put
> > > a notice on the talk page of the target page with a link to the text
> to
> > > be merged.  We could even make a special template for this.  This will
> > > only take care of one half of "merge and redirect", but half done is
> > > better than nothing at all.
> > >
> > > c) Make a new "afdmerge" template (or templates), for use in cases
> where
> > > the decision to merge has already been reached on AfD.  This template
> > > would state that consensus has already been reached and would strongly
> > > recommend that anyone having the time to carry out the merge go ahead
> > > and do it.
> > >
> > > None of these are, of course, mutually exclusive.  If anyone can
> suggest
> > > other possible approaches, please do.
> > >
> > > --
> > > Ilmari Karonen
> > > _______________________________________________
> > > 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
> >
>
> Well, I disagree that it's borderline vandalism, because it's at least
> half
> of a merge, even if merging does bring an article's quality down before
> bringing it back up.

That's silly - blanking a page is half of a total re-write, but
justblanking a page is still seen as vandalism (even if the person
uses an edit
summary saying "blanking to make way for a re-write" and then doesn't
re-write the page)

I see there are a lot of ideas for how to prevent future backlogs, but I was
> also hoping to encourage discussion as to how we can deal with the
> backlogs
> (all of the large ones) we've got right now.
>
> --
> theProject
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


body:
On 12/11/06, Aerik Sylvan <aerik at thesylvans.com> wrote:
[snip]
> And, as always, anybody else got any ideas?  If this can't work, I can't
> think of anything else beside a separate Lucene index (which will then not
> be real time and have to be updated every so often) as I don't think
> excluding large categories from an intersection search is an acceptable
> solution.

If we're willing to go external, there are lots of possible solutions.
(Including lucene).  Being external doesn't preclude real-time or near
real time.  Something could scan recent changes, and go and check to
see if the categories have changed.  Load could be limited by
dampening the polling of a single article to N times in a M hour
window.

And of course, I agree that excluding large categories is not a
solution. In an ideal world where we had working support for category
logic, many categories would be rather long.  Categories as a tool for
direct navigation is an antiquated idea, ... more flexible and
suitable tools like portals and navboxes mostly replaced categories as
a direct navigational tool ages ago.


subject: [Wikitech-l] ImportFreeImages Extension

body:
On 11/12/06, Simetrical <Simetrical+wikitech at gmail.com> wrote:
> On 12/10/06, Brianna Laugher <brianna.laugher at gmail.com> wrote:
> > But these are essentially already reviewed! That's why it appears so
> > useful to me. The only case this would miss is where the Flickr
> > uploader has lied and the work is not actually their own (eg they
> > uploaded all the promo images for their favourite band, and just
> > happened to set the license as CC-BY for all their files).
>
> They're already reviewed by someone who, quite likely, is not very
> familiar with copyright law (like, it must be admitted, most people
> who can upload to the Commons).  However, this is a decision for
> Commonsers to make, and I won't venture an opinion.  I was just
> suggesting that permissions functionality might be welcomed by some
> who'd like to use the extension.

OK, sure.

  Heck, there are some wikis that are
> totally locked down, and those certainly wouldn't want anons uploading
> random images to them.

If you try to import a Flickr image when you're not logged in, the
"you need to login to upload" MediaWiki warning still comes up. I
already tried it. :)

cheers,
Brianna


subject:
[Foundation-l] Principal Chief of Creek Nation Endorses WMG
 Wikipedia Translation Projects

body:
I received a letter of endorsement from the Principal Chief of the Creek
Nation endorsing the Muskogee/Creek Wikipedia
Translation projects for Muskogean Language Preservation.  I am emailing
a copy of the letter in PDF form to the foundation.

Jeff


subject: [Foundation-l] Revised Bylaws posted

body:
Brad Patrick wrote:

>Bylaws don't need to be filed with the state.  Articles of incorporation
>do.  These are not Articles.
>
>

Different here in Utah. By laws that call for issuance of stock have to
be refiled if you change the total amount of shares
the corporation will issue. Have to be approved by the Lieutenant Governor.

:-)

Jeff

>
>


subject: [Foundation-l] Revised Bylaws posted


from_name: Luna

subject: [WikiEN-l] Citation templates s__k

body:
Huh -- is there a good reason to split first and last into seperate
parameters, in that case? I'm not sure why we couldn't just use a single
parameter for the name. Maybe I'm missing something, though.

On 12/11/06, Daniel P. B. Smith <wikipedia2006 at dpbsmith.com> wrote:
>
> > From: "Steve Bennett" <stevagewp at gmail.com>
>
> > The benefit of storing citations in a semantically marked up format
> > (such as the cite templates) should be self-evident. The fact that
> > this is difficult to achieve at the present without producing
> > unreadable wikitext is a problem - but it doesn't mean we should
> > abandon the goal of maintaning references at a high level.
>
> Agree, absolutely, but I'd certainly like to see a whole lot of
> improvement. This is an area where I think there could be a lot of
> technical fixes.
>
> I use the "cite book" template a lot.
>
> It's a mess.
>
> About half the time, I have no clue what to enter for "first=" and
> "last=". I type in something, anything, that makes the formatted
> citation have a reasonable _appearance_, but the semantics are all
> wrong.
>
> --What if the author has a middle name or initial? What if the author
> customarily is known only by initials and surname?
>
> First=Katharine Anne|Last=Porter?
> First=H. G.|Last=Wells?
>
> --What if the author has an honorific or other prefix or suffix?
>
> First=Roy|Last=Blount Jr.?
> First=Dr. Phil|Last=McGraw?
> First=Isidore|Last=Rosenfeld, M.D.?
>
> --What if the book has no "authors" as such, only editors?
>
> Title=The American Heritage Dictionary of the English Language|
> First=Editors|last=of the American Heritage Dictionaries?
> Title=The Norton Anthology of American Literature|First=M. H.|
> Last=Abrams (General Editor)?
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


subject: [Wikitech-l] ImportFreeImages Extension

body:
On 12/10/06, Brianna Laugher <brianna.laugher at gmail.com> wrote:
> But these are essentially already reviewed! That's why it appears so
> useful to me.

They aren't reviewed however. It takes the flickr page for granted...
better than nothing but still.

> The only case this would miss is where the Flickr
> uploader has lied and the work is not actually their own (eg they
> uploaded all the promo images for their favourite band, and just
> happened to set the license as CC-BY for all their files).But I think
> only human intervention can avoid these cases and they seem to be
> luckily relatively rare, anyway.

It happens.

Also this doesn't address flicker users who have accidentally selected
a free licenses without conscious intent. Such cases are not a release
under a free license.

Also this fails to take the opportunity to invite free content
friendly flickr uploaders to come participate in our community
directly.

These issues could be addressed by coupling the images with a review
process which will have us contact the flickr uploader, as we've
currently been doing for our older flickr images.

[snip]
> As Luiz said, we really need to download the original hi-res version
> of images, too.

Yes. Nothing like this should be implemented without support for
grabbing the full image.

> Also, it really needs an option to write a filename in. Flickr
> filenames are frequently meaningless. In the same vein, it appears to
> silently overwrite existing images of that name (see
> http://wikidiy.com/mediawiki-1.8.2/index.php/Image:Punk.jpg ). This is
> very, very bad. :)

Good catch.


from_name: Timwi

subject: [Wikitech-l] Wikitech-l Digest, Vol 41, Issue 23

body:
Rob Church wrote:
> On 11/12/06, Aerik Sylvan <aerik at thesylvans.com> wrote:
>
>>Well... we've already established that this would have to live in a separate
>>table, since it would have to be MyISAM.  The table doesn't need to be
>>written to for each edit, only when a category is added/changed/deleted from
>>a page, which must be a pretty small subset of edits (wild guess: 10%?), so
>>maybe it's not that big a problem...?
>
> Probably higher than that, to be honest, especially with all those
> Wikipedians running around, dealing with Special:Uncategorisedpages,
> and correcting stub templates and so forth.

Also don't forget about vandals just blanking a (categorised) page, plus
the immediately following revert.


subject: [WikiEN-l] How to clear a backlog

body:
On 12/11/06, theProject <wp.theproject at gmail.com> wrote:

> ... anyway, it might not even involve actually performing the merge. A lot
> of old merge requests are merges that have not gained consensus and should
> just be removed. Also, since a merge request typically entails two merge
> templates, it's likely we have "only" somewhere on the order of 6000~7000
> actual requests. So if 100 Wikipedians, every day for a few months:

It's a problem that the same template (merge, mergefrom, mergeto,
mergewith...) is used to mean:

a) Maybe these articles should be merged? What do you think?
b) I think these articles should be merged. If no one objects, I'm
going to do it.
c) We all think these articles should be merged. Does anyone have time to do it?

Maybe explicit "merge-todo" templates would be useful, to indicate
that the work should be done, by anyone who feels up to it. Or
alternatively, using "merge-proposal" templates to indicate that a
discussion needs to be had.

IMHO, a big merge backlog is not necessarily a huge problem. At least
contributors will be aware of the existence of the other article and
will hopefully not be adding duplicate information, even if they have
to fairly arbitrarily decide which article to contribute to.

Steve


subject: [WikiEN-l] How to clear a backlog

references:
<28a1bd6e0612101755j5e654eabh4bca5eeaea02ae91@mail.gmail.com>
	<99c742680612101945n225b74det5bf6535d92e8b491@mail.gmail.com>
	<elimvo$ssu$1@sea.gmane.org>

body:
On 12/11/06, Tim Starling <tstarling at wikimedia.org> wrote:
> You want to ugly up major articles with "merge from" templates for obscure
> orphans?

Probably a better option would be to put the [[Template:Mergefrom]] on the
talk pages.

--
Utkarshraj Atmaram
http://en.wikipedia.org/wiki/User:Utcursch


subject: [WikiEN-l] Hello

body:
Hey, there!

This particular mailing list is home to just about any topic having to do
with the English Wikipedia -- recently, we've had topics about clearing
various work backlogs, deletion policy, verifiability and reliable sources
to cite for information... you name it. I suppose the most common topic is
"policy stuff," but occassionally proposals and such come up. There's a
pretty wide range of discussion, on here.

And just a random tip, if you're not comfortable posting and would just like
to see "how things are done," for awhile, you're welcome to subscribe to the
list without posting to it. Many internet regulars would call this
"lurking," and I imagine most of the subscribers to the list are doing just
that. ;)

Anyway, welcome aboard. Feel free to let me know if you have any questions,
I'll try to be helpful.

-Luna

On 12/11/06, Marc Riddell <michaeldavid86 at comcast.net> wrote:
>
> Hello,
>
> I'm a new kid on the block. I am sending this first email mostly to see
> what
> happens when I do, and to find out how the process works. What type of
> subjects are open for discussion? My only warning is that I am hard
> science
> and math challenged - in these areas, I will gladly act as an astounded
> observer. My education, background and experience is in clinical
> psychology.
> My interests are many - my curiosity insatiable.
>
> Regards,
>
> Marc Riddell, Ph.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
>


subject: [WikiEN-l] Citation templates s__k

body:
On 12/11/06, Stephen Bain <stephen.bain at gmail.com> wrote:
>
>
> Basically, if you want to put some free text for the author, use the
> author parameter, which you can format however you want:
>
> | author = H. G. Wells
> | author = Wells, H. G.
> | author = [[H. G. Wells|Wells, H. G.]]

Although, just for clarity's sake (surely not everyone one the list is a
template nut), we could only use a given parameter once. If you have
multiple authors, they'd all need to be listed in the same line (author =
George, Bill, Adam).

Then again, anybody who's read this far into the thread probably *is* a
template nut. But eh. :p

-Luna


subject: [Wikitech-l] ImportFreeImages Extension

body:
Thankfully since it's in SVN if someone feel particularly strong about
something like this - they have the option of implementing it themselves.

On 12/11/06, Rob Church <robchur at gmail.com> wrote:
>
> On 11/12/06, Travis Derouin <travis at wikihow.com> wrote:
> > Thanks. I've updated the global variable names to be more specific.
> >
> > I support an improvement that could be made could be to put the display
> > configuration parameters, the license parameter and the sorting
> parameter as
> > an option in the Mediawiki namespace. It might not be a good idea though
> to
> > put the API key there however.
>
> That's kinda the reason I said, "consider where" - I didn't mean,
> "shove it all in there", of course.
>
> *Configuration* stuff should *not* go in the MediaWiki namespace.
> *Formatting* stuff should.
>
>
> Rob Church
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: Tim Starling

subject: [WikiEN-l] How to clear a backlog

body:
Utkarshraj Atmaram wrote:
> On 12/11/06, theProject <wp.theproject at gmail.com> wrote:
>> I've spent the last week or two observing and trying to help out with the
>> backlog on [[Category:Articles to be merged]]. Unfortunately, it looks like
>> the backlog is rapidly spinning out of control -- I haven't actually kept
>> track, but I have a sneaking suspicion that there are many more merge
>> requests added than are serviced every day. Right now the backlog is a
>> little under 10,000 articles, and I would like to see if we can't brainstorm
>> a new way to deal with backlogs, because our current methods aren't dealing
>> with our worst backlogs. (Our worst backlogs, ironically but expectedly, are
>> the ones users are least likely to start tackling.)
>>
>
> Unlike wikification and other such tasks, in most cases, a merge is best done by
> somebody who has little knowledge about the subject. I do hunt out the articles
> to be merged that I know something about.
>
> Right now, many people who put the [[Template:Merge]] or [[Template:Mergeto]]
> don't use [[Template:Mergefrom]]. This is one of the main reasons behind the
> backlog.
>
> The article to be merged is usually an orphaned or little known about
> article. On
> the other hand, the article that is to receive the merged material is usually on
> many watchlists. If [[Template:Mergefrom]] is used, many editors will notice
> it and help with the merge.

You want to ugly up major articles with "merge from" templates for obscure
orphans? Why? You won't get things done even by having todo templates fly
across every article on the site in flashing red reindeer-shaped boxes.
Merging does not need to be centralised, it's a simple task which can be
done by any interested editor. Like every other editorial task, it can be
organised from the wikiprojects, perhaps with a rotation of requests on a
wiki-wide forum like the community portal.

-- Tim Starling


from_name: Brad Patrick

subject: [Foundation-l] Revised Bylaws posted

body:
Bylaws don't need to be filed with the state.  Articles of incorporation
do.  These are not Articles.

Jeff V. Merkey wrote:
> Has Brad refiled these by-laws with the state of Florida for the
> non-profit and are they in affect now?
>
> Jeff
>
>
>> The revised Bylaws of the Wikimedia Foundation can now be found at:
>> http://wikimediafoundation.org/wiki/Wikimedia_Foundation_bylaws
>>
>> Differences to the previous version:
>> http://wikimediafoundation.org/w/index.php?title=Wikimedia_Foundation_bylaws&diff=16676&oldid=14947
>>
>> These changes were approved at the Board meeting in St. Petersburg. A few notes.
>>
>> 1) Statement of purpose now reflects the current mission statement. It
>> will be updated if needed when the mission statement is finalized.
>>
>> 2) Membership does not legally exist. Membership was previously
>> described in the bylaws but not actually implemented. We've discussed
>> this issue at some length and decided that the risk of membership do
>> not outweigh the potential benefits. The risks include:
>> - Disclosure of identity to others. We do not want to limit
>> participation in WMF
>>   activities to those who are willing to disclose their identity to
>> other members.
>> - Hostile takeover. Given the power of members to elect or recall the
>> Board, the
>>   risk then arises of large numbers of people being affiliated with
>> some entity
>>   (economic, political or religious) to attempt to restructure the
>> organization to
>>   their liking.
>> - Unnecessary hierarchy. It is possible that legal membership would negatively
>>  impact the social dynamics of the project when members and non-members
>>  are treated differently.
>> - Administrative overhead. WMF is simply not presently in an organizational
>>  position to effectively manage thousands of membership registration.
>> - Questionable benefits. We can have most of the benefits of a membership system
>>  without legally encoding it in our bylaws.
>>
>> It was argued that this kind of organizational representation could
>> find a home in chapter organizations, some of which already have legal
>> members.
>>
>> 3) Terms defined. Both appointed and elected Board members now have
>> clearly defined terms (1 and 2 years, respectively). That is, even
>> Jimmy and Michael are now not "members for life," but will have to be
>> re-appointed in the future (unless they want to stand for election
>> instead). No Board members are named in the bylaws.
>>
>> 4) The notion of community elections is described in the bylaws, as is
>> a commitment that a majority of the Board will come from the community
>> through appointment or election (the scope of "community" is to be
>> defined by the Board).
>>
>> 5) The Executive Secretary and Treasurer do not need to be Board
>> members anymore. The roles of the Board positions were simplified and
>> clarified.
>>
>> 6) Annual financial audits and quarterly reviews.
>>
>> 7) Some further legal adjustments and clarifications to reflect the
>> reality of organizational operations.
>>
>> Again, see the diff above for the full list of changes. Comments &
>> questions welcome.
>>
>>
>>
>>
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
>


subject: [Foundation-l] Revised Bylaws posted


from_name: Angela

subject: [WikiEN-l] How to clear a backlog

body:
On 12/11/06, Steve Bennett <stevagewp at gmail.com> wrote:
> a) Maybe these articles should be merged? What do you think?
> b) I think these articles should be merged. If no one objects, I'm
> going to do it.
> c) We all think these articles should be merged. Does anyone have time to do it?

d) I don't see any reason for a merge but "merge and redirect" was the
outcome of an AfD so I'd better chuck a {{merge}} template on it.

Articles listed for reason (d) are rather likely to stay in the
backlog since they're on articles no one cares about which only
narrowly survived deletion. Before those templates existed, people
could [[WP:BB]] and redirect the page, but now it seems more common to
use a template than to "fix" the problem. I don't know if this is a
policy/guideline issue with people being obligated to add {{merge}}
before doing so or just a cultural change where many editors no longer
feel confident to "be bold in updating pages".

http://en.wikipedia.org/wiki/Wikipedia:Be_bold_in_updating_pages says
"If in doubt, fix it", not "If in doubt, chuck on a template."

Angela


from_name: phoebe ayers

subject: [WikiEN-l] How to clear a backlog

body:
On 12/11/06, charles.r.matthews at ntlworld.com <
charles.r.matthews at ntlworld.com> wrote:
>
> theProject wrote
>
> > I see there are a lot of ideas for how to prevent future backlogs, but I
> was
> > also hoping to encourage discussion as to how we can deal with the
> backlogs
> > (all of the large ones) we've got right now.
>
> Well, I started looking at the month-by-month, from start of 2006. The
> numbers of articles there are quite small, initially. A small sample
> suggests that many of the merge notices relate to merges that have had
> significant opposition. I took down a couple.
>
> Rather than quoting a figure of 10000 in total, which no one feels they
> could have much impact in clearing, you might do better to look at older
> subcategories.
>
> Charles

In part this is a technical issue; the merge-by-month category was just set
up this September, and there wasn't a complete retrospective conversion done
for older merge tags. Thus, September 2006 may contain articles that were
tagged at any point in the past, though this is slowly getting cleared out.
The months after September should be mostly accurate.

I was working on the backlog when the merge-by-month categories were
implemented, and the simple act of sorting out the older requests from the
newer ones was actually a huge step towards clearing it out; lots of
articles got fixed or the merge tags were found to be no longer relevant and
so on.

-- phoebe


from_name: Daniel P. B. Smith

subject: [WikiEN-l] Citation templates s__k

body:
> From: "Steve Bennett" <stevagewp at gmail.com>

> The benefit of storing citations in a semantically marked up format
> (such as the cite templates) should be self-evident. The fact that
> this is difficult to achieve at the present without producing
> unreadable wikitext is a problem - but it doesn't mean we should
> abandon the goal of maintaning references at a high level.

Agree, absolutely, but I'd certainly like to see a whole lot of
improvement. This is an area where I think there could be a lot of
technical fixes.

I use the "cite book" template a lot.

It's a mess.

About half the time, I have no clue what to enter for "first=" and
"last=". I type in something, anything, that makes the formatted
citation have a reasonable _appearance_, but the semantics are all
wrong.

--What if the author has a middle name or initial? What if the author
customarily is known only by initials and surname?

First=Katharine Anne|Last=Porter?
First=H. G.|Last=Wells?

--What if the author has an honorific or other prefix or suffix?

First=Roy|Last=Blount Jr.?
First=Dr. Phil|Last=McGraw?
First=Isidore|Last=Rosenfeld, M.D.?

--What if the book has no "authors" as such, only editors?

Title=The American Heritage Dictionary of the English Language|
First=Editors|last=of the American Heritage Dictionaries?
Title=The Norton Anthology of American Literature|First=M. H.|
Last=Abrams (General Editor)?


from_name: Alphax (Wikipedia email)

subject: [WikiEN-l] How to clear a backlog

body:
Utkarshraj Atmaram wrote:
<snip>
> The article to be merged is usually an orphaned or little known about
> article. On
> the other hand, the article that is to receive the merged material is usually on
> many watchlists. If [[Template:Mergefrom]] is used, many editors will notice
> it and help with the merge.
>

You assume that people actually check their watchlists. This would be a
whole lot easier if enotif was enabled...

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 542 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20061211/f6426233/attachment.pgp


subject: [WikiEN-l] The vexed issue of sources

body:
> From: Ken Arromdee <arromdee at rahul.net>
>
> On Sat, 9 Dec 2006, Thomas Dalton wrote:
>> The source being used in the article is not the writing on the wall.
>> The source is the few Wikipedians that have seen the writing. While
>> the writing is probably reliable, the few Wikipedians are not.
>
> By this reasoning, a source isn't a book, it's the few Wikipedians
> who have
> read the book.
>
> How exactly is the writing on the wall different from a book?
> (Sure, not
> every Wikipedian can go read the writing, but not every Wikipedian
> has access
> to a particular book either.)

I have access to an _awful_ lot of books through my library's
interlibrary loan network. Of books that I wanted to get because they
were relevant to something in Wikipedia that I was working on, I've
probably been able to get three out of four. Not fantastically
obscure books, but not exactly Barnes and Noble fodder, either.
Specific examples (all long out of print): Abram Sachar's "Brandeis
University: A Host at Last" (his 1995 history of Brandeis); Elsie de
Wolfe's autobiography, _After All_; de Seversky's "Victory Through
Air Power" (the 1942 book, not the Disney version!); B. Traven's
novel, "The Death Ship."

Actually if my library can't get it through the Minuteman network,
they can get it from the Boston Public Library, the Commonwealth's
"library of last resort." The Boston Public Library has fourteen
million volumes which makes it bigger than Yale's and only a tad
smaller than Harvard's. They've done this for me twice.

I don't know exactly what resources other Wikipedians have, but
interlibrary loan networks are not unique to my region of the U. S.

I'm not sure how I could get the wall of College Hall, University of
Pennsylvania sent to me by interlibrary loan.

Reference librarians are very accommodating, but I don't think I
could ask the Penn reference librarian to go there and take a
snapshot of it for me. (Although you never know, and I admit that I
haven't actually tried).


from_name: Matt R

body:
--- Jimmy Wales <jwales at wikia.com> wrote:
> It seems like a partial practical resolution to this difficulty would
> involve something only slightly technical... a special page to which we
> could direct people where they could grant permissions.  A simple wizard.

I've negotiated free images from a number of different sources, and I can also
testify that it is very awkward when you end up having to press people on the
issue of a free license. So much so that I don't really like to do it any more.
A wizard would be a great help.

-- Matt

Wikipedia: http://en.wikipedia.org/wiki/User:Matt_Crypto
Blog: http://cipher-text.blogspot.com

___________________________________________________________
The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html


from_name: Ilmari Karonen

subject: [WikiEN-l] How to clear a backlog

body:
Utkarshraj Atmaram wrote:
> On 12/11/06, Tim Starling <tstarling at wikimedia.org> wrote:
>> You want to ugly up major articles with "merge from" templates for obscure
>> orphans?
>
> Probably a better option would be to put the [[Template:Mergefrom]] on the
> talk pages.

Yes, this would probably be the solution to this problem.  The people we
want to reach with that template will notice them on talk pages, but
they won't annoy casual readers there.

--
Ilmari Karonen


from_name: Bence Damokos

subject: [Wikitech-l] ImportFreeImages Extension

body:
Maybe by default be one-click, but have a checkbox for changing the default
name, and also ask for a new name if a file by the same name exists.

Bence

On 12/11/06, Travis Derouin <travis at wikihow.com> wrote:
>
> On 12/10/06, Brianna Laugher <brianna.laugher at gmail.com> wrote:
> >
> > As Rob suggested, I have a feeling $wgTemplateName should just point
> > to something in MediaWiki: namespace.
>
>
> Yeah, this might be good, but if it's a template, when you want to change
> the look/feel or wording of the message, you can do so without having to
> update all of the images that are already imported.
>
> As Luiz said, we really need to download the original hi-res version
> > of images, too.
> >
> > Also, it really needs an option to write a filename in. Flickr
> > filenames are frequently meaningless. In the same vein, it appears to
> > silently overwrite existing images of that name (see
> > http://wikidiy.com/mediawiki-1.8.2/index.php/Image:Punk.jpg ). This is
> > very, very bad. :)
>
>
> A good idea - but it interferes with the one-click ease of the tool. Do
> you
> have any ideas of ways to add this feature and still have it really easy
> to
> use?
>
> Travis
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: The Cunctator

subject: [WikiEN-l] The vexed issue of sources

body:
On 12/11/06, Daniel P. B. Smith <wikipedia2006 at dpbsmith.com> wrote:
>
> > From: Ken Arromdee <arromdee at rahul.net>
> >
> > On Sat, 9 Dec 2006, Thomas Dalton wrote:
> >> The source being used in the article is not the writing on the wall.
> >> The source is the few Wikipedians that have seen the writing. While
> >> the writing is probably reliable, the few Wikipedians are not.
> >
> > By this reasoning, a source isn't a book, it's the few Wikipedians
> > who have
> > read the book.
> >
> > How exactly is the writing on the wall different from a book?
> > (Sure, not
> > every Wikipedian can go read the writing, but not every Wikipedian
> > has access
> > to a particular book either.)
>
> I have access to an _awful_ lot of books through my library's
> interlibrary loan network. Of books that I wanted to get because they
> were relevant to something in Wikipedia that I was working on, I've
> probably been able to get three out of four. Not fantastically
> obscure books, but not exactly Barnes and Noble fodder, either.
> Specific examples (all long out of print): Abram Sachar's "Brandeis
> University: A Host at Last" (his 1995 history of Brandeis); Elsie de
> Wolfe's autobiography, _After All_; de Seversky's "Victory Through
> Air Power" (the 1942 book, not the Disney version!); B. Traven's
> novel, "The Death Ship."
>
> Actually if my library can't get it through the Minuteman network,
> they can get it from the Boston Public Library, the Commonwealth's
> "library of last resort." The Boston Public Library has fourteen
> million volumes which makes it bigger than Yale's and only a tad
> smaller than Harvard's. They've done this for me twice.
>
> I don't know exactly what resources other Wikipedians have, but
> interlibrary loan networks are not unique to my region of the U. S.
>
> I'm not sure how I could get the wall of College Hall, University of
> Pennsylvania sent to me by interlibrary loan.
>
> Reference librarians are very accommodating, but I don't think I
> could ask the Penn reference librarian to go there and take a
> snapshot of it for me. (Although you never know, and I admit that I
> haven't actually tried).

I'd be willing to bet you could.


subject: [WikiEN-l] How to clear a backlog

body:
Angela wrote:
>
> d) I don't see any reason for a merge but "merge and redirect" was the
> outcome of an AfD so I'd better chuck a {{merge}} template on it.
>
> Articles listed for reason (d) are rather likely to stay in the
> backlog since they're on articles no one cares about which only
> narrowly survived deletion. Before those templates existed, people
> could [[WP:BB]] and redirect the page, but now it seems more common to
> use a template than to "fix" the problem. I don't know if this is a
> policy/guideline issue with people being obligated to add {{merge}}
> before doing so or just a cultural change where many editors no longer
> feel confident to "be bold in updating pages".

More likely just laziness and/or lack of time on behalf of the closing
admins.  Some merges can be non-trivial, and determining whether a given
merge is trivial or not can itself take time.  If you're already busy
clearing a backlog of AfD closures, the temptation to just slap a merge
tag on it and move on can be great.

The positive side here is that, since it's mostly an issue with admin
behavior rather than that of random editors, it can be solved by coming
up with a new recommended procedure and communicating it the admins
doing the closures (via [[WP:AN]], this list, personal talk pages etc).
  The negative side is that any viable solution needs to ensure it
doesn't just turn the merge backlog into an even bigger AfD closure backlog.

Some possible solutions I can think of off the top of my head include:

a) Advise admins to always perform the merge when closing, if at all
possible.  This could mean just cut-and-pasting the text and slapping a
cleanup tag on it, but at least the merge itself would get done.

b) Suggest that busy admins just redirect the page to be merged and put
a notice on the talk page of the target page with a link to the text to
be merged.  We could even make a special template for this.  This will
only take care of one half of "merge and redirect", but half done is
better than nothing at all.

c) Make a new "afdmerge" template (or templates), for use in cases where
the decision to merge has already been reached on AfD.  This template
would state that consensus has already been reached and would strongly
recommend that anyone having the time to carry out the merge go ahead
and do it.

None of these are, of course, mutually exclusive.  If anyone can suggest
other possible approaches, please do.

--
Ilmari Karonen


from_name: Rob Church

body:
On 11/12/06, Timwi <timwi at gmx.net> wrote:
> Also don't forget about vandals just blanking a (categorised) page, plus
> the immediately following revert.

Quite. In fact, I'd be willing to bet that the proportion of
maintenance edits (janitorial) is increasing against normal content
edits.

Rob Church


from_name: geni

body:
On 12/11/06, Jimmy Wales <jwales at wikia.com> wrote:

> Elvis.

> The template says "Help!  We need a freely licensed image!"
>
> Clicking takes you to a page with some simple instructions...
>
> 1. You must have taken the photo YOURSELF, no uploads of anything else.
>
> 2. You agree to release the photo under GFDL and/or CC BY-SA at a minimum.
>
> 3. You must have taken the photo YOURSELF.  (Yes, we said that already,
> but we want you to know how important it is.)
>

People currently submit images selecting options that are listed as
invalid. I doubt people would follow these instructions either.

> I suspect if we did this for tons of famous people, the photos would
> come pouring in... preserving a bit of history that is currently rotting
> in people's photo albums... and making Wikipedia not just a place where
> people can rehash tired publicity photos under fair use arguments, but a
> place where new culture is formed and born and distributed.
>

3 problems:

First getting outsiders involved in wikipedia is always tricky.
Perhaps this can be delt with through some form of marketing.

Secondly we would be looking towards some of the smaller subsets of
internet users. For a lot of the internet users elvis has been dead
longer than they have been alive. This could to a degree be delt with
by going looking for material rather than expecting it to come to us

Thirdly a lot of people don't have scanners.
--
geni


subject:
[Wikitech-l] [MediaWiki-CVS] SVN: [18256]
	trunk/extensions/ImportFreeImages/ImportFreeImages.php

body:
On 11/12/06, travis at svn.wikimedia.org <travis at svn.wikimedia.org> wrote:
> -$wgFlickrAPIKey  = '';
> +$wgIFI_FlickrAPIKey  = '';

Might be an idea to change that back, since a Flickr API key could be
useful for more than this extension. When I said change global names,
I meant in terms of removing any ambiguities over a particular
configuration variable's purpose. A Flickr API key is, quite plainly,
a Flickr API key.

Rob Church


subject: [Wikitech-l] ImportFreeImages Extension

body:
On 11/12/06, Travis Derouin <travis at wikihow.com> wrote:
> Thanks. I've updated the global variable names to be more specific.
>
> I support an improvement that could be made could be to put the display
> configuration parameters, the license parameter and the sorting parameter as
> an option in the Mediawiki namespace. It might not be a good idea though to
> put the API key there however.

That's kinda the reason I said, "consider where" - I didn't mean,
"shove it all in there", of course.

*Configuration* stuff should *not* go in the MediaWiki namespace.
*Formatting* stuff should.

Rob Church


list: wikipedia-l

subject: [Wikipedia-l] Abuse on mo.wiki

body:
I'll like to report an abuse on mo.wiki. This came from http://meta.wikimedia.org/wiki/User:Yann (Yann). As it seems he edited http://mo.wikipedia.org/wiki/Main_Page to redirect to http://mo.wikipedia.org/wiki/%D0%9F%D0%B0%D3%82%D0%B8%D0%BD%D0%B0_%D0%BF%D1%80%D0%B8%D0%BD%D1%87%D0%B8%D0%BF%D0%B0%D0%BB%D1%8D . I guess he also changed the default entry page (the first page that apairs when entering mo.wikipedia.org in the adress bar) from http://mo.wikipedia.org/wiki/Main_Page to http://mo.wikipedia.org/wiki/%D0%9F%D0%B0%D3%82%D0%B8%D0%BD%D0%B0_%D0%BF%D1%80%D0%B8%D0%BD%D1%87%D0%B8%D0%BF%D0%B0%D0%BB%D1%8D . This changes should be reverted as the decision taken some while ago was to block this Wikipedia, and as he recognised on this page , there was no discussion to change that in anyway. Moreover it was decided finaly that this Wikipedia should be closed, but Yann chose unilateraly to break the decision taken by Wikipedians all over the world.

Regards, Danutz

__________________________________________________
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi
http://mail.yahoo.it


from_name: Marc Riddell

subject: [WikiEN-l] Hello

body:
Hello,

I'm a new kid on the block. I am sending this first email mostly to see what
happens when I do, and to find out how the process works. What type of
subjects are open for discussion? My only warning is that I am hard science
and math challenged - in these areas, I will gladly act as an astounded
observer. My education, background and experience is in clinical psychology.
My interests are many - my curiosity insatiable.

Regards,

Marc Riddell, Ph.D.


from_name: TSO1D From Wikpedia

subject: [Wikipedia-l] Abuse on mo.wiki

body:
Gerard, could you please tell me if the committee's deliberations are made open to the general public for viewing and/or participation? Also, do you know what a prospective date for a decision might be? Thanks, TSO1D.

Gerard Meijssen <gerard.meijssen at gmail.com> wrote:  Hoi,
For your information, the language sub committee has been asked to come
up with an advise about the mo.wikipedia.

>From my perspective, the first thing that will be required to come to a
solution is to first clean up the mo.wikipedia by normalising it. This
should lead to a situation where it is discussed how we can come to an
integration where both Romanian in Cyrillic and Latin will have there
place. Effectively the mo.wikipedia has not been closed and, certainly
not all wikipedians of the world agreed on this.

Having a standard main page for the mo.wikipedia like any other project
is a good first step for some normalisation. I do welcome Yann's courage.

Thanks,
GerardM

ro.wiki schreef:
> I'll like to report an abuse on mo.wiki. This came from http://meta.wikimedia.org/wiki/User:Yann (Yann). As it seems he edited http://mo.wikipedia.org/wiki/Main_Page to redirect to http://mo.wikipedia.org/wiki/%D0%9F%D0%B0%D3%82%D0%B8%D0%BD%D0%B0_%D0%BF%D1%80%D0%B8%D0%BD%D1%87%D0%B8%D0%BF%D0%B0%D0%BB%D1%8D . I guess he also changed the default entry page (the first page that apairs when entering mo.wikipedia.org in the adress bar) from http://mo.wikipedia.org/wiki/Main_Page to http://mo.wikipedia.org/wiki/%D0%9F%D0%B0%D3%82%D0%B8%D0%BD%D0%B0_%D0%BF%D1%80%D0%B8%D0%BD%D1%87%D0%B8%D0%BF%D0%B0%D0%BB%D1%8D . This changes should be reverted as the decision taken some while ago was to block this Wikipedia, and as he recognised on this page , there was no discussion to change that in anyway. Moreover it was decided finaly that this Wikipedia should be closed, but Yann chose unilateraly to break the decision taken by Wikipedians all over the world.
>
> Regards, Danutz

_______________________________________________
Wikipedia-l mailing list
Wikipedia-l at Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/wikipedia-l

---------------------------------
Everyone is raving about the all-new Yahoo! Mail beta.


from_name: Gregory Maxwell

subject: [Wikitech-l] ImportFreeImages Extension

body:
On 12/11/06, Brianna Laugher <brianna.laugher at gmail.com> wrote:
> > They aren't reviewed however. It takes the flickr page for granted...
> > better than nothing but still.
>
> What do you mean it takes it for granted? You mean it assumes the
> flickr page is correct? Well... that is all we humans do as well...

No it's not.. hopefully you are also sanity checking in other ways...
For example, the human readable flicker comments sometimes make it
clear that the image is a copyright violation. Sometimes the image is
of a movie poster or is something else that is clearly a derived work.
People do catch these sort of problems in flickr review.

> I guess people who manually upload Flickr images are not
> double-checking the photographer's intent, so I don't know why an
> automated process should.

The current review process asks the reviewer to leave the flickr
contributor a comment thanking them for freely releasing their image.

> As above...it is hard to imagine why a flickr user would stop using
> flickr and start using Commons, though. We offer basically no benefits
> for them over Flickr, superior species classification is about the
> only thing I can think of. Without even using Commons, their images
> are already being used in Wikipedia, so why would they switch? ;)

For the same reasons that anyone else would contribute.

Many people don't know that Wikipedia is user submitted content.
Thanking a photographer whos work we are using is a great opportunity
to educate and solicit participation from a wider collection of
people.

> Having said that, it would be cool to extend an invitation, but I
> don't think that necessarily has a lot to do with an extension like
> this. As you said it's more of a review process.

I only replied because your prior post caused me to think that you
considered this tool a replacement for a review process.

I think an uploader tool is great, especially if we can figure out how
to make it facilitate the review process, for example by pre-tagging
the image for review and by collecting as much data as possible.


from_name: florencedevouard

subject: [Foundation-l] Agreement between local chapters and Foundation

body:
The resolution concerning the agreement between local chapters and WMF
may be found here:
http://wikimediafoundation.org/wiki/Resolution:Agreement_between_chapters_and_Wikimedia_Foundation

More interesting is the agreement itself:
http://wikimediafoundation.org/wiki/Agreement_between_chapters_and_Wikimedia_Foundation

The agreement proper was essentially drafted by the local chapters
coordinator, Delphine M?nard, the UK chapter, Alison Wheeler and our GC,
Brad Patrick.

That's a good step !

----------

A few comments

* http://wikimediafoundation.org/wiki/Local_chapters needs update
**for example, it still refers to Serbian chapter as S&M chapter
**<small>and the UK chapter is not mentionned</small>

* At the board retreat, guidelines for chapter creation were drafted,
but the draft was never finalized. The board agreed to have the
guidelines validated asap, but can not do it until the guidelines are
actually put down on paper (well, wiki). So, there are still no
guidelines for creation. Can the chapter committee give us a date when
the guidelines will be ready ?

* There is still pending an agreement for commercial use of the
trademarks by the chapters. Let us be realistic, it should not be
expected before a while, because commercial use of the trademarks in
general first need to be analysed and assessed. Let's talk about it in a
couple of months when the work on trademarks themselves is basically done.

Florence Devouard
Wikimedia Foundation Chair


subject: [WikiEN-l] Hello

body:
Hello, Luna,

Thank you for responding. I have been contributing to Wikipedia for nearly a
year now, and the only ongoing controversy - problem! - I have had regards
categorizing articles.

My work is in Clinical Psych. The most important work by far is done, of
course, when sitting across from a real, live human being. However, long
before encountering this person - and during the course of their treatment -
a competent clinician will have studied countless case histories of other
persons who have experienced similar problems. By identifying and
understanding these similarities, the clinician can more confidently make
decisions regarding the person?s treatment.

When I came upon Wikipedia early this year I was thrilled. Here were
countless biographies (case histories if you will) of persons who, among
other things, were categorized according to similar traits and life
experiences. I could, for instance, click on the Category ?Writers who
committed suicide? and have hours of work done for me. Now, as the
categories become more and more diluted, this is becoming more and more
unavailable.

I have complained, but, so far to no avail. All I get in response is a
reminder of the "limitations of Wikipedia's server".

I shall persevere ? and periodically bitch and moan.

Now that I?ve told you far more than you wanted to know ? I?ll thank you for
your ear ? and stop whining (for now).

As for the WikiEN-L - I believe I'll observe for a little while (just a
little while) and post and/or respond to an issue when I feel I have
something constructive to offer.

Thanks again.

Be healthy,

Marc Riddell

> From: Luna <lunasantin at gmail.com>
> Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
> Date: Mon, 11 Dec 2006 15:05:56 -0800
> To: "English Wikipedia" <wikien-l at wikipedia.org>
> Subject: Re: [WikiEN-l] Hello
>
> Hey, there!
>
> This particular mailing list is home to just about any topic having to do
> with the English Wikipedia -- recently, we've had topics about clearing
> various work backlogs, deletion policy, verifiability and reliable sources
> to cite for information... you name it. I suppose the most common topic is
> "policy stuff," but occassionally proposals and such come up. There's a
> pretty wide range of discussion, on here.
>
> And just a random tip, if you're not comfortable posting and would just like
> to see "how things are done," for awhile, you're welcome to subscribe to the
> list without posting to it. Many internet regulars would call this
> "lurking," and I imagine most of the subscribers to the list are doing just
> that. ;)
>
> Anyway, welcome aboard. Feel free to let me know if you have any questions,
> I'll try to be helpful.
>
> -Luna
>
> On 12/11/06, Marc Riddell <michaeldavid86 at comcast.net> wrote:
>>
>> Hello,
>>
>> I'm a new kid on the block. I am sending this first email mostly to see
>> what
>> happens when I do, and to find out how the process works. What type of
>> subjects are open for discussion? My only warning is that I am hard
>> science
>> and math challenged - in these areas, I will gladly act as an astounded
>> observer. My education, background and experience is in clinical
>> psychology.
>> My interests are many - my curiosity insatiable.
>>
>> Regards,
>>
>> Marc Riddell, Ph.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
>>
> _______________________________________________
> 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 Garrett

body:
Bence Damokos wrote (Sunday, December 10, 2006 9:36 PM)
> I concur, having an undo link on the last revision would be more intuitive
> then clicking on edit (at least for new users). Also if they see the undo
> link at the last revision, they might learn how to use it on older
> revisions
> as well.
>
> On 12/10/06, Rob Church <robchur at gmail.com> wrote:
> >
> > On 10/12/06, Andrew Garrett <andrew at epstone.net> wrote:
> > > Precisely why it's unnecessary.
> >
> > It's not exactly unnecessary if it's something helpful we can add. Or
> > do you despise convenient user interfaces?

I've just added this in r18254.

Andrew Garrett


from_name: Erik Moeller

subject: [Foundation-l] Revised Bylaws posted

body:
The revised Bylaws of the Wikimedia Foundation can now be found at:
http://wikimediafoundation.org/wiki/Wikimedia_Foundation_bylaws

Differences to the previous version:
http://wikimediafoundation.org/w/index.php?title=Wikimedia_Foundation_bylaws&diff=16676&oldid=14947

These changes were approved at the Board meeting in St. Petersburg. A few notes.

1) Statement of purpose now reflects the current mission statement. It
will be updated if needed when the mission statement is finalized.

2) Membership does not legally exist. Membership was previously
described in the bylaws but not actually implemented. We've discussed
this issue at some length and decided that the risk of membership do
not outweigh the potential benefits. The risks include:
 - Disclosure of identity to others. We do not want to limit
participation in WMF
   activities to those who are willing to disclose their identity to
other members.
 - Hostile takeover. Given the power of members to elect or recall the
Board, the
   risk then arises of large numbers of people being affiliated with
some entity
   (economic, political or religious) to attempt to restructure the
organization to
   their liking.
- Unnecessary hierarchy. It is possible that legal membership would negatively
  impact the social dynamics of the project when members and non-members
  are treated differently.
- Administrative overhead. WMF is simply not presently in an organizational
  position to effectively manage thousands of membership registration.
- Questionable benefits. We can have most of the benefits of a membership system
  without legally encoding it in our bylaws.

It was argued that this kind of organizational representation could
find a home in chapter organizations, some of which already have legal
members.

3) Terms defined. Both appointed and elected Board members now have
clearly defined terms (1 and 2 years, respectively). That is, even
Jimmy and Michael are now not "members for life," but will have to be
re-appointed in the future (unless they want to stand for election
instead). No Board members are named in the bylaws.

4) The notion of community elections is described in the bylaws, as is
a commitment that a majority of the Board will come from the community
through appointment or election (the scope of "community" is to be
defined by the Board).

5) The Executive Secretary and Treasurer do not need to be Board
members anymore. The roles of the Board positions were simplified and
clarified.

6) Annual financial audits and quarterly reviews.

7) Some further legal adjustments and clarifications to reflect the
reality of organizational operations.

Again, see the diff above for the full list of changes. Comments &
questions welcome.

--
Erik M?ller, Executive Secretary, Wikimedia Foundation


subject: [Foundation-l] Revised Bylaws posted


body:
Maybe a comment little off:
Is http://scg.vikimedija.org/ really the actual site of Wikimedia Serbia
(and what happens to Montenegro?), and if yes, is there a way to go past the
explanation of "*ALALA*" ?

Bence Damokos*
*
On 12/11/06, florencedevouard <anthere at anthere.org> wrote:
>
> The resolution concerning the agreement between local chapters and WMF
> may be found here:
>
> http://wikimediafoundation.org/wiki/Resolution:Agreement_between_chapters_and_Wikimedia_Foundation
>
> More interesting is the agreement itself:
>
> http://wikimediafoundation.org/wiki/Agreement_between_chapters_and_Wikimedia_Foundation
>
> The agreement proper was essentially drafted by the local chapters
> coordinator, Delphine M?nard, the UK chapter, Alison Wheeler and our GC,
> Brad Patrick.
>
> That's a good step !
>
> ----------
>
> A few comments
>
> * http://wikimediafoundation.org/wiki/Local_chapters needs update
> **for example, it still refers to Serbian chapter as S&M chapter
> **<small>and the UK chapter is not mentionned</small>
>
> * At the board retreat, guidelines for chapter creation were drafted,
> but the draft was never finalized. The board agreed to have the
> guidelines validated asap, but can not do it until the guidelines are
> actually put down on paper (well, wiki). So, there are still no
> guidelines for creation. Can the chapter committee give us a date when
> the guidelines will be ready ?
>
> * There is still pending an agreement for commercial use of the
> trademarks by the chapters. Let us be realistic, it should not be
> expected before a while, because commercial use of the trademarks in
> general first need to be analysed and assessed. Let's talk about it in a
> couple of months when the work on trademarks themselves is basically done.
>
> Florence Devouard
> Wikimedia Foundation Chair
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>


from_name: Alex Powell

body:
Any ideas on this or is it just "unsupported at this time"?

On 12/9/06, Alex Powell <alexp at exscien.com> wrote:
>
> Hi,
>
> I was wondering if it were possible to create two image namespaces in a
> single mediawiki install. I would like to have some files stored in one
> location and others in another.
>
> Docs:Worddoc.doc would put Worddoc.doc into a folder named Docs/<hashed
> folder>/Worddoc.doc
>
> Image:Picture.gif would put Picture.gif into a folder named images/<hashed
> folder>/Picture.gif
>
> I can create custom namespaces, but it appears that only the Image
> namespace responds with a file upload, and I cannot see how to flag a
> namespace for media.
>
> Any help would be much appreciated,
>
> Alex
>


from_name: Brion Vibber

subject: [Wikitech-l] Password reset changes

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've introduced new handling for e-mailed password resets in r18288.

Previously, the random password generated at e-mail time was allowed to
be used transparently for regular logins. Both the previous and the
generated passwords would continue to be valid for logins until a new
password was manually set at Special:Preferences.

Now, use of the temporary password at Special:Userlogin will instead
shunt over to a password-change form (via the new special-purpose
Special:Resetpass).

So:
* The only thing you can do with an e-mailed password now is choose a
new password
* Once you've changed your password, both the previous password and the
e-mailed temporary password are no longer valid for anything

This should discourage people from using the e-mailed passwords
permanently, and make password resets safer (since the old password will
definitely no longer be valid once the person has logged in with the
new one).

Internally, User::setPassword() now does some validity checking, talks
to $wgAuth directly, and throws PasswordError exceptions for failure
cases. These can be caught for error reporting in the user interface.

User::checkPassword() no longer returns true for the temporary password;
use the separate User::checkTemporaryPassword() to check for a match there.

LoginForm::authenticateUserData() returns a new error code for this
case; the bot API may or may not need to be updated.

- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFfjBLwRnhpk1wk44RAlQCAJ40AB8wmeasyP5bx1X9KGWup/rT6wCfeTpC
WVU/FJQ68E8sC725EyEEcFc=
=Ufdp
-----END PGP SIGNATURE-----


from_name: Thomas Dalton

subject: [WikiEN-l] The vexed issue of sources

body:
> > The source being used in the article is not the writing on the wall.
> > The source is the few Wikipedians that have seen the writing. While
> > the writing is probably reliable, the few Wikipedians are not.
>
> By this reasoning, a source isn't a book, it's the few Wikipedians who have
> read the book.

Technically, yes, by my reasoning the source is always the author of
the Wikipedia article, however in the case of that Wikipedian reading
a published source that a significant number of readers can verify,
the fact that the information reached the article via a Wikipedian
becomes trivial, so we ignore it. If we can verify the source, then
the Wikipedian is just as reliable as the source itself - the
important thing in all of this is reliability.

> How exactly is the writing on the wall different from a book?  (Sure, not
> every Wikipedian can go read the writing, but not every Wikipedian has access
> to a particular book either.)

The difference is simply the number of people that have access to the
source. I'm not going to try and give an exact definition of how many
people is enough, because there are bound to be exceptions to any
definition I could come up with. A book with copies in any large
library is clearly accessible enough, some writing on a wall in one
place is not. The line is drawn somewhere inbetween, but I'm not going
to try and say where.


subject: [WikiEN-l] The vexed issue of sources

body:
> A wall carving is more likely to last longer.

A carving in a cave, maybe. A carving on the wall of a building,
probably not. All it takes is for that building to be knocked down,
and the information is lost. With a book, every single copy ever made
would need to be destroyed to lose the information.


from_name: Mark Clements

body:
"Alex Powell" <alexp at exscien.com> wrote in
message news:c4ec7cd60612111136x4c188fate614e616623c6219 at mail.gmail.com...
> Any ideas on this or is it just "unsupported at this time"?
>
> On 12/9/06, Alex Powell <alexp at exscien.com>
wrote:
> >
> > Hi,
> >
> > I was wondering if it were possible to create two image namespaces in a
> > single mediawiki install. I would like to have some files stored in one
> > location and others in another.
> >
> > Docs:Worddoc.doc would put Worddoc.doc into a folder named Docs/<hashed
> > folder>/Worddoc.doc
> >
> > Image:Picture.gif would put Picture.gif into a folder named
images/<hashed
> > folder>/Picture.gif
> >
> > I can create custom namespaces, but it appears that only the Image
> > namespace responds with a file upload, and I cannot see how to flag a
> > namespace for media.
> >
> > Any help would be much appreciated,
> >
> > Alex
> >

I remember looking into patching MW back when it was on v1.3, so that each
namespace had a 'type' associated with it, where type would be one of
Standard, Media or Category (with Special, Template and Messages as special
types which can only have one associated namespace) but never got beyond the
ideas stage.

The most useful application of that in the current implementaiton of MW
would be to have multiple 'image' namespaces, but there are other potential
future uses (e.g. a 'Database' type if we ever implement DB functionality).

I think this is something to consider adding to the Namespace manager before
it makes it into trunk.

- Mark Clements (HappyDog)


from_name: Ray Saintonge

subject: [WikiEN-l] The vexed issue of sources

body:
Thomas Dalton wrote:

>>A wall carving is more likely to last longer.
>>
>>
>A carving in a cave, maybe. A carving on the wall of a building,
>probably not. All it takes is for that building to be knocked down,
>and the information is lost. With a book, every single copy ever made
>would need to be destroyed to lose the information.
>
Not to mention the effect of acid rain.  The paintings at the Lescaux
caves have been there a long time, but they have been affected by those
visitors who insist on breathing while they look at the pictures.  We
can believe something if enough Wikipedians have seen it, but it would
be nicer if one of them had the presence of mind to bring a camera.

Ec


from_name: Aphaia

subject: [Foundation-l] Community project?

body:
That is why I mentioned to TCPLs as a similar project and their effort
to build up teams on meta, where we can see good examples how people
who are unfamiliar with meta are organized, building a community
covering two or more projects (meta, wp sometimes other ...).  In my
observation keys are devout promoters and at least one visible place
where they can gather up and have communications. Meta awareness is a
problem but not serious,  you can intereact with existent editors'
community and if necessary can invite your friends, just as Drini did
on the Spanish community during the Election.

On 12/8/06, Bence Damokos <bdamokos at gmail.com> wrote:
> I take it back, not half, just the last section..., so its not a so bad
> place after all, just its not known to all...
>
> Maybe a Meta awareness program, is what we really need?
>
> On 12/7/06, Bence Damokos <bdamokos at gmail.com> wrote:
> >
> > Well, I guess the problem is twofold:
> > Meta is not well known enough, and its not a big help either if the
> > creators of local resources don't know, where to share their work.
> > Its actually a bit in need of clean-up : half of the skins should be on
> > mediawiki.org, shouldn't they?
> >
> > Bence
> >
> >
> > On 12/7/06, geni <geniice at gmail.com > wrote:
> > >
> > > On 12/7/06, Bence Damokos <bdamokos at gmail.com > wrote:
> > > > Hi!
> > > > That English page doesn't seem like the hive of collaboration,
> > > discussion,
> > > > sharing and learning.
> > > >
> > > > Anyway I support Birgitte's idea too.
> > > >
> > > > Though I don't speak German, this page looks promising, as a source
> > > for new
> > > > ideas (even for enwiki):
> > > > http://de.wikipedia.org/wiki/Wikipedia:Skin
> > > >
> > >
> > > http://meta.wikimedia.org/wiki/Gallery_of_user_styles
> > >
> > >
> > > --
> > > geni
> > > _______________________________________________
> > > foundation-l mailing list
> > > foundation-l at wikimedia.org
> > > http://mail.wikipedia.org/mailman/listinfo/foundation-l
> > >
> >
> >
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>

--
KIZU Naoko
  Wikiquote: http://wikiquote.org
  * Nessuna poesia prima di noi *


subject: [Foundation-l] Community project?


subject: [WikiEN-l] The vexed issue of sources

body:
Thomas Dalton wrote:

>>Reference librarians are very accommodating, but I don't think I
>>could ask the Penn reference librarian to go there and take a
>>snapshot of it for me. (Although you never know, and I admit that I
>>haven't actually tried).
>>
>>
>However, there is no reason why someone who's already there couldn't
>take a picture and upload it, and use that as the source. (I don't
>know what the copyright is on walls, but it should be fair use if it
>isn't free)
>
It's copyrightable.  How long has the text been there?  Copyright may
have expired.

Ec


body:
Thanks for the response. I'll come up with another mechanism.

Kind regards,

Alex

On 12/11/06, Mark Clements <gmane at kennel17.co.uk> wrote:
>
> "Alex Powell" <alexp at exscien.com> wrote in
> message news:c4ec7cd60612111136x4c188fate614e616623c6219 at mail.gmail.com...
> > Any ideas on this or is it just "unsupported at this time"?
> >
> > On 12/9/06, Alex Powell <alexp at exscien.com>
> wrote:
> > >
> > > Hi,
> > >
> > > I was wondering if it were possible to create two image namespaces in
> a
> > > single mediawiki install. I would like to have some files stored in
> one
> > > location and others in another.
> > >
> > > Docs:Worddoc.doc would put Worddoc.doc into a folder named
> Docs/<hashed
> > > folder>/Worddoc.doc
> > >
> > > Image:Picture.gif would put Picture.gif into a folder named
> images/<hashed
> > > folder>/Picture.gif
> > >
> > > I can create custom namespaces, but it appears that only the Image
> > > namespace responds with a file upload, and I cannot see how to flag a
> > > namespace for media.
> > >
> > > Any help would be much appreciated,
> > >
> > > Alex
> > >
>
> I remember looking into patching MW back when it was on v1.3, so that each
> namespace had a 'type' associated with it, where type would be one of
> Standard, Media or Category (with Special, Template and Messages as
> special
> types which can only have one associated namespace) but never got beyond
> the
> ideas stage.
>
> The most useful application of that in the current implementaiton of MW
> would be to have multiple 'image' namespaces, but there are other
> potential
> future uses (e.g. a 'Database' type if we ever implement DB
> functionality).
>
> I think this is something to consider adding to the Namespace manager
> before
> it makes it into trunk.
>
> - Mark Clements (HappyDog)
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: Michael Bimmler

body:
Hm. According to meta: the address is http://sr.vikimedija.org/
But this goes to the same content, where it's written in the footer
"Telekommunisten is a project of the Haagenti Group".
http://www.vikimedija.org/ is a nearly-emptly page.
However, Whois contact is still a person whom I know to be involved in
Wikimedia Serbia, so it can't be a case of "domain expired and
squatted". I'll now wait for the more-knowing people to comment on
this ;-)
Michael

On 12/11/06, Bence Damokos <bdamokos at gmail.com> wrote:
> Maybe a comment little off:
> Is http://scg.vikimedija.org/ really the actual site of Wikimedia Serbia
> (and what happens to Montenegro?), and if yes, is there a way to go past the
> explanation of "*ALALA*" ?
>
> Bence Damokos*
> *
> On 12/11/06, florencedevouard <anthere at anthere.org> wrote:
> >
> > The resolution concerning the agreement between local chapters and WMF
> > may be found here:
> >
> > http://wikimediafoundation.org/wiki/Resolution:Agreement_between_chapters_and_Wikimedia_Foundation
> >
> > More interesting is the agreement itself:
> >
> > http://wikimediafoundation.org/wiki/Agreement_between_chapters_and_Wikimedia_Foundation
> >
> > The agreement proper was essentially drafted by the local chapters
> > coordinator, Delphine M?nard, the UK chapter, Alison Wheeler and our GC,
> > Brad Patrick.
> >
> > That's a good step !
> >
> > ----------
> >
> > A few comments
> >
> > * http://wikimediafoundation.org/wiki/Local_chapters needs update
> > **for example, it still refers to Serbian chapter as S&M chapter
> > **<small>and the UK chapter is not mentionned</small>
> >
> > * At the board retreat, guidelines for chapter creation were drafted,
> > but the draft was never finalized. The board agreed to have the
> > guidelines validated asap, but can not do it until the guidelines are
> > actually put down on paper (well, wiki). So, there are still no
> > guidelines for creation. Can the chapter committee give us a date when
> > the guidelines will be ready ?
> >
> > * There is still pending an agreement for commercial use of the
> > trademarks by the chapters. Let us be realistic, it should not be
> > expected before a while, because commercial use of the trademarks in
> > general first need to be analysed and assessed. Let's talk about it in a
> > couple of months when the work on trademarks themselves is basically done.
> >
> > Florence Devouard
> > Wikimedia Foundation Chair
> > _______________________________________________
> > foundation-l mailing list
> > foundation-l at wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/foundation-l
> >
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>