from_name: Steve Bennett

subject: [WikiEN-l] POV fork anyone? (coca cola)

body:
On 7/25/06, ikiroid <ikiroid at gmail.com> wrote:
> "Perception" sounds more multidimensional than "Criticism".....but the
> perception better be pretty damn important to have its own article. You
> can't have that sort of thing for every subject......only ones whose
> perception is notable.

Yeah. It's a tough call. Somehow a page called "Criticism of George W
Bush" doesn't seem that bad, because it literally *is* an
encyclopaedic topic. Being a president of the US at war will do that
to you. A balanced article about reactions to his politics from around
the world would probably have more scope and be more interesting
though.

Whereas "criticism of Microsoft", while being fairly copious, is
just...a bad topic.

Hang on, I'm starting to get an idea. A guideline: If you could write
an article about the criticism, without at any stage actually
mentioning the reasons behind the criticism, then maybe the
"criticism" article can fly. Let's try it:

George W Bush: Easy, there have been heaps of public protests in the
US and around the world
Microsoft: Apart from a minor subculture of Microsoft-bashing, what
could you say?
Catholic Church: Hmm...dunno
Gmail, World of Warcraft: don't make me laugh
Family Guy: somewhat in spite of itself [[Criticism of Family Guy]] is
a fairly interesting article documenting negative reactions to it,
mostly in the form of parodies and cheap shots in other cartoons. If
you took out the predictable "is the target of much criticism due to
what some feel are controversial and inappropriate subject matter,
lack of originality, poor animation, random jokes that do not
correspond to the plot, and substandard writing quality.", it could
almost get there.

For articles like "Criticism of sotware egineering", maybe something
like "Software engineering in academia" would work better?

Steve


list: wikien-l

source: pipermail-mbox

subject: [WikiEN-l] Categories for deletion/discussion issues

body:
On 7/27/06, ScottL <scott at mu.org> wrote:
>   I have for a very long time loved this page: http://www.popvssoda.com/
>
> It has a map showing the geographic distribution of pop vs soda vs coke
> vs. other (usually soft drink).

Wow, Coke as a brand name is in trouble!

http://www.popvssoda.com/countystats/total-county.html

Steve


from_name: Erik Moeller

subject: [WikiEN-l] Common sense exceptions to our copyright policy.

body:
On 7/27/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> Much like the arbcom acts as a consensus tool to help us achieve
> consensus on bans and other such methods, a person in this position
> would help us achieve consensus for exceptions to our image use
> policy.

The problem you describe can be generalized to all policymaking.
Changing policy on Wikipedia is a slow and often intensely frustrating
process. A tiny, petulant minority can resist positive change through
sheer repetition. Often the process is cut short by bold admins trying
to do "the right thing" -- which then tends to lead to an all-out
escalation. Months after things have cooled down a bit, a solution may
emerge from the ashes. It may not be the best solution; it may simply
be that everyone is tired of hearing about the problem, and will
accept whatever compromise proposal comes along.

Elected or appointed expert committees are one way to deal with this
problem, and they may often work quite well. However, if we accept an
expert committee as a method to achieve consensus about policy, we
should equally consider direct voting on certain policy amendments.
Certainly, direct voting is a more participatory model than the
election of a decision-making body. And it seems as likely to lead to
an accepted outcome.

"But," I hear some people say, "you can't let ordinary people vote on
these complex issues. They do not understand! That's why we need to
have smart people to make these decisions for us. Through enlightened,
reasoned debate, surely they will find the solution that is best for
us all." I'm not sure that's true. There are good votes and there are
bad votes. A good vote is one where voters are presented with a
concise summary of the different arguments that have come up in a
discussion that preceded the vote, where the _options_ in the vote
have been developed through consensus, and where there is a strong
culture that pressures voters to read and understand all arguments
before voting. A bad vote is one that is done ad hoc, out of process,
with poor methodology and no clear prerequisites.

In my view, establishing clear ground rules for votes to change policy
is a better way to deal with the problem than delegation of authority.
It allows for community consensus processes (and indeed requires them
to be tried first), brings out as many arguments and solutions as
possible, and enables everyone to share the responsibility, credit and
blame for the result.

Erik


list: foundation-l

from_name: geni

subject: [Foundation-l] Latest board resolutions

body:
On 7/27/06, mboverload <mboverload at gmail.com> wrote:
> Layman explanation as to why?
>
> mboverload

The foudation can either stick to the liquid asset option which means
renting servers and keeping enough cash on hand to pay for say a years
worth of rent. That is a fair bit of cash and might make the
foundation a worthwhile target. The other option is to keep the cash
in the form of servers which are rather less worthwhile for people to
try and aquire since they lose value over time. The servers might have
cost x to buy but after a year they could be down to less than 1/2X
but that doesn't really bother the foundation since it still needs the
servers.

Win a court case and get say $100,000 ok. Win a court case and get a
load of servers worth say $50K which you then have to try an sell is
rather less good.
--
geni


list: wikimedia-l

subject: [Foundation-l] Latest board resolutions


body:
On 7/27/06, geni <geniice at gmail.com> wrote:
> On 7/27/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> > However, there are a number of cases such as the recent thread on the
> > image of Treanna where common sense would tell us to permit the
> > image... that it represents no compromise of our goals and no legal
> > threat.  There have been quite a few examples that I've run into...
> >
>
> Where?

Wikipedia-l

Steve


subject:
[WikiEN-l] Dead wikipedians and how to really make a project
	boring to death

body:
On 7/27/06, Steve Bennett <stevagewp at gmail.com> wrote:
> On 7/27/06, Kat Walsh <mindspillage at gmail.com> wrote:
> > In this case, there must be some sort of special case. Purist though I
> > generally am, surely there must be some way to hang on to a few
> > pictures of deceased editors and tag them appropriately to make their
> > status clear. Considering all the copyright issues on the project, it
> > would be a happy day if this were the most pressing of them. I would
> > be loath for this to be some sort of precedent so that everyone and
> > his dog wants an excuse to be a special case, but, well, really, I am
> > OK with this particular image.
>
> Why don't we come up with a "special case" template? "This image is
> copyrighted, and cannot be used under fair use. However, the Wikipedia
> community has decided that in this special case, it is worth breaching
> the copyright anyway".
>
> Steve

Because it risks being overused.

--
geni


from_name: Mark Gallagher

body:
G'day Scott,

>    I have for a very long time loved this page: http://www.popvssoda.com/
>
> It has a map showing the geographic distribution of pop vs soda vs coke
> vs. other (usually soft drink).

That map of the world seems smaller than it ought to be (it's missing
the bits on the edges that most maps of its kind mark "here be dragons").

--
Mark Gallagher
"What?  I can't hear you, I've got a banana on my head!"
- Danger Mouse


subject: [WikiEN-l] POV fork anyone? (coca cola)

body:
On 7/27/06, Steve Bennett <stevagewp at gmail.com> wrote:
> Hang on, I'm starting to get an idea. A guideline: If you could write
> an article about the criticism, without at any stage actually
> mentioning the reasons behind the criticism, then maybe the
> "criticism" article can fly.

I don't see the big difference between "Criticism of George W. Bush"
and "Criticism of Microsoft". If Microsoft had a corporate approval
rating, I doubt it would be very high -- and conversely, the people
who actually take to the streets to protest Bush's policy only form a
relatively small subset of those who disapprove of the job he's doing.

I too would prefer to read about the _perception_ and _reaction_ to
Bush's actions, rather than criticism (the current article mixes both
ideas). For instance, Americans generally "rallied behind the
President" after the 9/11 attacks, and many of the people who
supported him then became vocal critics of his policies later. A
criticism/praise split breaks this narrative, and seems more geared
towards pleasing current Bush supporters and critics than delivering a
coherent and truthful presentation of the facts.

To me, the guideline, in a nutshell, seems very simple:

1) Sectioning negative vs. positive views is generally considered poor
writing  (AKA "the easy way out"), but not prohibited per se. It could
be deserving of a  {{cleanup}} tag.

2) Views cannot be moved to separate pages selectively. An article may
be split when it gets too long, but the primary topic article should
retain summaries. [[George W. Bush]] presently meets that requirement.

3)  A disproportionately long criticism section in an article that, as
a whole, does not exceed our length guidelines should generally not be
moved away -- instead, the rest of the article should be expanded, and
criticism should be carefully reviewed for relevance.

I'm certainly glad that POV forks are now widely considered
unacceptable. This was not always the case.

Erik


from_name: Alphax (Wikipedia email)

subject: [WikiEN-l] more fancruft

body:
stevertigo wrote:
> http://en.wikipedia.org/w/index.php?title=Image:Autofellatio_2.jpg
>
> Its back.
>

And you still don't know how to start new threads.

--
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: 564 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060727/bb0fe458/attachment.pgp


from_name: Jonathan Leybovich

subject: [Foundation-l] Project Proposal: Wikicat

body:
All-

I hereby propose for your consideration Wikicat, a
project to create an open, bibliographic catalog.  The
purpose of Wikicat is to both lay the groundwork for a
scholarly apparatus to be used within Wikipedia as
well as create a unique and valuable information
resource in its own right.  In particular, Wikicat
will:

* facilitate the process of citation by automatically
fetching bibliographic data based upon unique keys
such as ISBN, ISSN, and LCCN
* allow users to more easily navigate between
information resources by grouping them in a
functionally significant manner (in particular,
according to the principles of [[w:FRBR]]) so that,
for example, different editions, translations, etc.
are all joined together
* apply Wikipedia's collaborative content creation
model to bibliographic data, resulting in a catalog of
unprecedented detail

In terms of implementation, Wikicat will be defined
like any other [[m:Wikidata]] dataset and will
integrate with other datasets such as WiktionaryZ to
share common entities and perhaps someday support
something along the lines of a Semantic Mediawiki.  As
Wikidata is currently not code complete, though,
Wikicat will be deployed in stages, during the first
of which it will exist as a read-only database that
populates itself on an as-needed/"as-cited" basis by
importing data from the open catalog servers of such
institutions as the Library of Congress, the
University of California library system, the U.S.
National Library of Medicine, etc.

Details about the project, in increasing technical
detail, are available on the following pages:

http://meta.wikimedia.org/wiki/Proposals_for_new_projects#Wikicat
http://meta.wikimedia.org/wiki/Wikicat
http://meta.wikimedia.org/wiki/Wikicat_Technical_Design

Coding of the first stage of the project is nearly
complete and a list of its operational requirements
will soon be forthcoming.  Here is a demo of Wikicat
integration with the Cite/<ref> extension:

http://meta.wikimedia.org/wiki/Image:Wikicat_Cite_screenshoot.png

Thank you for your time and I look forward to your
comments.

Jonathan Leybovich

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


from_name: mboverload

subject: [WikiEN-l] giving medical advice

body:
Yes, anything as utterly important as the Heimlich Manoeuvre needs to be
directly quoted from a medical source.  We are talking people's immediate
safety.

mboverload

On 7/27/06, zero 0000 <nought_0000 at yahoo.com> wrote:
>
> Sorry if this has been discussed before.  I just noticed
> that [[Abdominal thrusts]] gives detailed advice on how to
> perform a medical procedure.  Maybe there are other such
> articles too.  Given the fashionable practice of filing
> suit whenever a medical procedure fails to work, it seems
> to me that this is rather dangerous for Wikipedia.
> Wouldn't it be legally safer (and more likely to be
> medically correct) if the actual procedure in such articles
> was presented as a direct quotation from a named medical
> authority?   With permission, of course.  Maybe there should
> also be a disclaimer.
>
> Zero.
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


list: textbook-l

from_name: Michael R. Irwin

subject: [Textbook-l] Wikibooks in the press

body:
Piotr "Derbeth" Kubowicz wrote:

>Another story: http://www.westword.com/Issues/2006-07-27/news/message.html
>
>I am curious why did these people decide not to continue to use Wikibooks for developing their textbooks but created new wiki page instead. Was the reason our license, technical limits of the MediaWiki software or something else?
>
>
>
I would guess chaos and non academic bias.   In the early days of
Wikipedia there were quite a few academics who disliked jostling elbows
with commoners presumably less informed in various fields of endeaver.

Interesting.  In the article they express interest in a $300 ebook
reader that can store 100K pages.   I wonder what is wrong with a 400
dollar Dell computer that could be used to support entrepreneurial
business activities using free software when its student owner was not
busy studying.  To be fair they stated they are also interested in MIT's
$100 portable computer  initiative.

Also interesting.  I wonder what they need $400K seed money for to get
started.  It is hard to imagine a U.S. college with no IT deparment and
internet accessible server resources.    Maybe they need the services of
professional copyeditors and secretaries to coordinate finalization of
the etexts.

Further item of interest.   A student written XML book in a U.S. college
class is cited as the inspiration for the project.   Perhaps the only
problem with wikibooks is its lack of publicity and lack of active
participation from active groups of students.   Too bad it has taken a
couple of years to activate/initiate the Wikiversity project.

regards,
lazyquasar


subject: [WikiEN-l] POV fork anyone? (coca cola)

body:
On 7/27/06, Erik Moeller <eloquence at gmail.com> wrote:
> To me, the guideline, in a nutshell, seems very simple:
>
> 1) Sectioning negative vs. positive views is generally considered poor
> writing  (AKA "the easy way out"), but not prohibited per se. It could
> be deserving of a  {{cleanup}} tag.
>
> 2) Views cannot be moved to separate pages selectively. An article may
> be split when it gets too long, but the primary topic article should
> retain summaries. [[George W. Bush]] presently meets that requirement.

Yeah I think I do agree with you after all on these.

> 3)  A disproportionately long criticism section in an article that, as
> a whole, does not exceed our length guidelines should generally not be
> moved away -- instead, the rest of the article should be expanded, and
> criticism should be carefully reviewed for relevance.

An eternal battle: what does one do if one section is
"disproportionately long" for an article which is "too short". Keep it
there and hope the rest gets longer? Move it somewhere and risk being
accused of censorship?

It happens in lots of cases...recently, a guy went around adding
massive unedited slabs from the Catholic Encyclopedia to articles on
small towns in Europe. What was previously 3 paragraphs about the town
became 10, 7 of which were about obscure ecclesiastical history in the
middle ages. Had the article been 5 paragraphs, that might have been
excusable...

Steve


body:
On 7/27/06, Oskar Sigvardsson <oskarsigvardsson at gmail.com> wrote:
> I think you are all missing Antheres point. Who cares whether it's
> fair use or not? Do we really have to be so anal about the rules that
> we will infact bring this to IfD, instead of just quietly ignoring the
> copyright issue in this very special unique case. We are people, for
> christs sake, not automatons! Sometimes, process is not that
> important.

You are really asking, is it ok for Wikipedia to breach people's
copyright when the chance of them suing is very slight? I would say
yes. Most would say no.

Steve


body:
On 7/27/06, Kat Walsh <mindspillage at gmail.com> wrote:
> In this case, there must be some sort of special case. Purist though I
> generally am, surely there must be some way to hang on to a few
> pictures of deceased editors and tag them appropriately to make their
> status clear. Considering all the copyright issues on the project, it
> would be a happy day if this were the most pressing of them. I would
> be loath for this to be some sort of precedent so that everyone and
> his dog wants an excuse to be a special case, but, well, really, I am
> OK with this particular image.

Why don't we come up with a "special case" template? "This image is
copyrighted, and cannot be used under fair use. However, the Wikipedia
community has decided that in this special case, it is worth breaching
the copyright anyway".

Steve


from_name: Daniel R. Tobias

subject: [WikiEN-l] Accented characters (was Re:  fancruft)

body:
On 26 Jul 2006 at 15:31, Ray Saintonge <saintonge at telus.net> wrote:

> mboverload wrote:
>
> >I'm not sure why you're mentioning it, but I recently changed every mention
> >of Pokemon to Pok?mon.

[snip]

> A few years ago there was a big debate over whether names should include
> accents, and I believe that was settled back then.  This doesn't meant
> that we don't have a few retro-luddites who would still believe that the
> results should have been different.

I guess whoever programmed the system that produces and distributes
the digest form of this list is among those "luddites", since the
digest is done in strict US-ASCII, and the accented letter above
shows up as a question mark.

--
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/


body:
On 7/27/06, Anthony <wikilegal at inbox.org> wrote:
> What are the good reasons to "prohibit fair use" in the User namespace
> that don't apply to the Wikipedia namespace?

The user namespace is treated by most of its inhabitants as a space of
personal ownership, and its content is almost unregulated. For
instance, something like [[User:SPUI]] can survive only because it is
a user page, and indeed, attempts to get rid of it would be dealt with
as vandalism. Allowing fair use in that space is likely to lead to
more MySpace pages, with random celebrity photos, O RLY type crap, and
boobie-shaking GIF animations. Allowing only free content in the User:
space is a way to limit it, whereas the content of the Wikipedia:
space is already regulated by the community.

To me, this is not only about the legal validity of the use, it is
also about its impact, and whether it is desirable.

Erik


subject: [Foundation-l] Latest board resolutions

body:
Anthony wrote:

> snip

> Sure, there need to
>be reserves in place, but in the budgets that were released before
>Wikimedia started hiding them from the public a very large portion
>(something like 75%) was being spent on capital expenditures.
>
>
I am confused.  How can budgets or at least expenditures be hidden from
the public indefinitely?

Are there insufficient audit and reporting requirements in Florida law
to assure us that the Wikimedia Foundation's Finances will eventually be
made public?

regards,
lazyquasar


subject: [Foundation-l] Latest board resolutions


subject: [WikiEN-l] POV fork anyone? (coca cola)

body:
On 7/27/06, Steve Bennett <stevagewp at gmail.com> wrote:
> An eternal battle: what does one do if one section is
> "disproportionately long" for an article which is "too short". Keep it
> there and hope the rest gets longer? Move it somewhere and risk being
> accused of censorship?

There was a time when we had this guideline for stubs:

"Try to give more than just a definition ? at least a little more. It
doesn't hurt to be provocative, as long as you attempt to be unbiased
and reasonably accurate. What is interesting and important about the
subject? If your introduction would make someone want to read further,
then it will probably entice someone to write further. As little as
one extra sentence can turn a good description into a brilliant stub,
e.g. Salvador Allende was the President of Chile from 1970 until 1973.
The CIA might have been involved in the coup that ousted him. With a
start like that, you don't have to know any more yourself; a dozen
contributors will be falling over themselves to fill in the details."
http://en.wikipedia.org/w/index.php?title=Wikipedia:Perfect_stub_article&oldid=14557210

It wasn't sustainable, of course, but I think it reflects a very
different wiki philosophy than the notion that an article has be
perfectly balanced at any given point in time. I think the basic
philosophy is valid, [[iff]] the reader is informed about a lack of
balance through the appropriate tags. Of course, the description above
suggests adding unsourced innuendo, which we have rightly become much
more wary of in recent times.

Erik


list: wikitech-l

from_name: brion at pobox.com

subject: [Wikitech-l] MediaWiki automated test run failure 2006-07-28

body:
An automated run of parserTests.php showed the following failures:

Running test Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED!
Running test Link containing double-single-quotes '' (bug 4598)... FAILED!
Running test Magic Word: {{CURRENTMONTHNAMEGEN}}... FAILED!
Running test Template with thumb image (wiht link in description)... FAILED!
Running test message transform: <noinclude> in transcluded template (bug 4926)... FAILED!
Running test message transform: <onlyinclude> in transcluded template (bug 4926)... FAILED!
Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED!
Running test HTML bullet list, unclosed tags (bug 5497)... FAILED!
Running test HTML ordered list, unclosed tags (bug 5497)... FAILED!
Running test HTML nested bullet list, open tags (bug 5497)... FAILED!
Running test HTML nested ordered list, open tags (bug 5497)... FAILED!
Running test Parsing optional HTML elements (Bug 6171)... FAILED!
Running test Inline HTML vs wiki block nesting... FAILED!
Running test Mixing markup for italics and bold... FAILED!
Running test 5 quotes, code coverage +1 line... FAILED!
Running test HTML Hex character encoding.... FAILED!
Running test dt/dd/dl test... FAILED!

Passed 412 of 429 tests (96.04%) FAILED!


subject: [Foundation-l] Latest board resolutions

body:
On 7/28/06, mboverload <mboverload at gmail.com> wrote:
> Are we sure it's a processing problem and not a bandwidth problem?  It seems
> to me that they need some more bandwidth, with new servers being second to
> that.
>

I think it is fairly safe to say the devs know where the problem is.
Certianly they reacted fast enough when we did exceed our bandwidth.

--
geni


subject: [Foundation-l] Latest board resolutions


from_name: Chad Perrin

subject:
[Wikitech-l] OT: What language would *you* have done it in,
	and why?

references:
<20060727160106.GD13295@cgi.jachomes.com>
	<eaau76$j39$1@sea.gmane.org> <eabmds$epi$1@sea.gmane.org>

body:
On Thu, Jul 27, 2006 at 08:40:35PM -0400, Edward Z. Yang wrote:
> Timwi wrote:
> > For the parser, I'm sure the "why" is self-evident. For the rest, the
> > answer to "why" unfortunately includes "I don't know any Python or
> > Ruby". All I know is that PHP is unsuitable for anything larger than a
> > quick hack.
>
> Delighted to see that you've called Yahoo! a quick hack. ;-)

He said it was "unsuitable for a quick hack", not that people don't use
it for anything more than a quick hack.

I (mostly) agree.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"A script is what you give the actors.  A program
is what you give the audience." - Larry Wall


body:
On 7/28/06, Mark Wagner <carnildo at gmail.com> wrote:
> We shouldn't?  Then why do we give everyone an upload button and
> encourage them to use it?
>
> --
> Mark

Technicaly we didn't but in any case were young an inoccent.

--
geni


body:
On Thu, Jul 27, 2006 at 08:03:00PM -0700, mboverload wrote:
> Everyone knows that Mediawiki should have been written in Javascript.  The
> current implementation is a mess.

Frankly, if it was written end-to-end in Javascript, I (and millions of
others) would probably use something else.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The first rule of magic is simple. Don't waste your time waving your
hands and hopping when a rock or a club will do." - McCloctnick the Lucid


body:
On 7/27/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:

> I have not proposed an expert based solution. This is a role which
> practically any established Wikipedian would be qualified for.

Then I misunderstood your proposal. What would this role be advertised
as? Wouldn't candidates who are experts in copyright law be favored
for it, naturally? If not, wouldn't there be a great risk that the
exceptions made by a single person or small group are actually in
violation of the law?

> It's not clear that the facts support your position. Perhaps on
> dewiki?   Experimentation on Enwiki has demonstrated that the majority
> of the participants in at least some of our voting process do not read
> evidence presented preceding or included in the debate (measured by
> placing external links in intros and in individual votes).  Instead it
> would appear that many voters make their decision based on initial
> impression and a passing glance at the standing votes.

I have not seen many votes or polls where the vote was conducted
according to a defined process, where the arguments have to be fully
and carefully summarized long before any voting begins. Rather, in
most cases, it seems to be a mixed process of voting and arguing,
where arguments often have a hard time reaching visibility, and early
voters ignore later arguments -- making the results difficult to
interpret.

It seems more sensible to split the process into first arguing and
then, if no consensus can be found, voting. Then you also avoid the
headcount on processes like AfD and instead have it as a pure
discussion, with a vote only when necessary.

Take a look at the polls and surveys in
http://en.wikipedia.org/wiki/Wikipedia:Current_surveys
where, at best, you will find a brief intro summarizing the _issue_,
but hardly ever a summary of the arguments for and against each
position. Most of these polls are started in moments of frustration,
with little planning and inconsistent prerequisites.

> While it may be true that acceptable results can be achieved through
> good votes, where the participants consist of informed parties, it is
> not clear if such votes ever actually happen on enwiki.

That seems to be a matter of defining policy in such a way that only
good (i.e. well-organized) votes are allowed to go through. The
de.wiki Meinungsbilder do indeed seem to be more well thought-out in
this regard:
http://de.wikipedia.org/wiki/Wikipedia:Meinungsbilder

Take this example:
http://de.wikipedia.org/wiki/Wikipedia:Meinungsbilder/Unver%C3%B6ffentlichte_Filme

It's about whether unpublished movies should have articles. Note the
extensive background information provided, the clearly defined voting
criteria, the rules on (re)moving votes, and the summaries of each
proposal. It still has room for improvement, but is pretty close to
what I'm thinking of. This kind of process can be followed both on a
small and a large scale -- depending on the complexity of the problem.

> I'm not sure if you're aware of [[Dunbar's number]]....

Dunbar's number is the exact reason I propose voting and
summarizing/refactoring as a last resort in large scale
decision-making. Note that both arguments and votes can be anonymized.

> I believe that without the control feedback of a functioning social
> group our users are too unwilling to engage in the mixture of
> compromise and consideration which are required to have a 'good vote'
> and instead their behavior appears to be determined more by a desire
> to assert their authority (by fighting against something rather than
> working with it).

That's why trying to work out a mutually agreeable solution in a
social group should always precede a vote. When the group gets too
large and factions form, a vote may be the best way to find
acquiescence to a particular solution.

Erik


body:
On Fri, Jul 28, 2006 at 01:34:31AM -0000, Greg Sabino Mullane wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> > Unthreaded: in a clear field, Chad, what *would* you have implemented
> > MediaWiki in?
>
> Dunno about Chad, but I would have implemented it in Perl, of course.
> With perhaps bison and Inline::* where needed.

That's actually pretty much my answer.

>
> > And why?
>
> That's a loaded question. :) More experienced people familiar with the
> language available for development. Namespaces. A mature database API.
> No php.ini mess. Unicode. Lexical variables. Real hashes. "use strict".
> Consistent naming, use of case, and return values. The ability to use qq{}.
> Perldoc[1]. Real references and data structures. Good comparison operators.
> XS. True object orientation.

Those are pretty much my reasons.  Are you preplagiarizing me?  (ahem)

>
> However, PHP is what we got, and MediaWiki is pretty well written and
> head and shoulders above 99% of the PHP apps out there. Once I finish
> Postgres support for MediaWiki, I'll be converting it to Perl. Just
> don't hold your breath. :)

Ditto that first sentence.  Cheers and applause for the second.  I
wasn't planning to, with regard to the third.

As for original content, rather than just metoos . . .

Another option, besides Perl, that appeals to me is Ruby -- and for many
of the same reasons as Perl (though it lags in some areas, such as
number of available developers and volume of existing code that could be
used).  It also has some benefits that distinguish it from Perl, such as
a far better syntax for its object model and a tendency to encourage
readable code more readily (that doesn't mean you can't write equally
readable Perl, just that the language's syntax tends to "encourage" it
more than Perl's).  Both languages have thoroughly excellent regex
engines, with Perl's having perhaps a slight advantage, easily made up
by Ruby's facility with iteration.  On the other hand, there's the
simple fact that Perl execution performance kicks butt all over Ruby,
and perhaps every other high-level, reasonably dynamic, comparable
language, for most purposes.

If I knew enough of some Lisp to be functional (ha ha, 'scuse the pun),
I might lean in that direction as well.

I like the proposed idea of writing one or two core, high-load
components in C, or even (if we're really adventurous) something better
performing like Ada, though that's probably really pushing it.  Since I
don't much enjoy looking at C code, though, I might just ask someone
else to write the C, so I guess *I* in particular might not implement
any of it in C.  Eh.

Perl really strikes me as the clear winner, overall, with Ruby a close
second about a hair's-breadth behind it.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The ability to quote is a serviceable
substitute for wit." - W. Somerset Maugham


from_name: Guy Chapman aka JzG

subject: [WikiEN-l] "Exclusion" essay

body:
On Wed, 26 Jul 2006 23:55:19 -0700, Ray Saintonge
<saintonge at telus.net> wrote:

>I prefer to avoid preconceived ideas about what we're supposed to be
>for.  Very recent material and ideas are the history of the future, but
>it's difficult to know which will last.

It is the nature of encyclopaedias to be backward-looking.

Guy (JzG)
--
http://www.chapmancentral.co.uk
http://en.wikipedia.org/wiki/User:JzG


body:
On Tue, 25 Jul 2006 20:38:40 -0400, SPUI <drspui at gmail.com> wrote:

>Which is why I'm trying to get it moved to "freeways and motorways".
>Riiiiight.

Moving the goalposts much? ;-)

Guy (JzG)
--
http://www.chapmancentral.co.uk
http://en.wikipedia.org/wiki/User:JzG


subject: [WikiEN-l] WP:BLP issue at Fred Phelps

body:
On Thu, 27 Jul 2006 11:36:18 +0100, Steve Block
<steve.block at myrealbox.com> wrote:

>I've removed the passages per [[WP:BLP]].

The correct course.  I will put them on my watchlist.  Hopefully some
other people will too.

Guy (JzG)
--
http://www.chapmancentral.co.uk
http://en.wikipedia.org/wiki/User:JzG


subject: [WikiEN-l] POV fork anyone? (coca cola)

body:
On 7/28/06, Erik Moeller <eloquence at gmail.com> wrote:
> It wasn't sustainable, of course, but I think it reflects a very
> different wiki philosophy than the notion that an article has be
> perfectly balanced at any given point in time. I think the basic
> philosophy is valid, [[iff]] the reader is informed about a lack of
> balance through the appropriate tags. Of course, the description above
> suggests adding unsourced innuendo, which we have rightly become much
> more wary of in recent times.

Yeah, it's startling to read, the days when Wikipedia's main goal was
expanding itself. Now our goal seems to be keeping the freaks in
check.

Steve


from_name: MacGyverMagic/Mgm

body:
We can't rely on the common sense of uploaders. Many editors, not
neccesarily new ones, have no clue whatsoever about copyright as is shown by
the vast number of copyvio images circulating the net.

Recently there was a question about someone who wanted to post another image
in an article on anime animation which already included multiple images. Any
more would not illustrate the article any better so including it would be a
bad idea.

To actually have smart/good decisions made and enacted, we need to enlighten
as much people about the existence and finer details of copyright and fair
use.

Take for example [[Nicole Kidman]]. One fair use image to illustrate who
we're talking about is okay. Having an entire gallery isn't. Maps, don't use
Google Earth or commercial maps, there's an entire team for free
alternatives.

We shouldn't rely on the completely clueless when determining rules and
actions with regard to copyright.

Mgm


from_name: Greg Sabino Mullane

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

> Unthreaded: in a clear field, Chad, what *would* you have implemented
> MediaWiki in?

Dunno about Chad, but I would have implemented it in Perl, of course.
With perhaps bison and Inline::* where needed.

> And why?

That's a loaded question. :) More experienced people familiar with the
language available for development. Namespaces. A mature database API.
No php.ini mess. Unicode. Lexical variables. Real hashes. "use strict".
Consistent naming, use of case, and return values. The ability to use qq{}.
Perldoc[1]. Real references and data structures. Good comparison operators.
XS. True object orientation.

However, PHP is what we got, and MediaWiki is pretty well written and
head and shoulders above 99% of the PHP apps out there. Once I finish
Postgres support for MediaWiki, I'll be converting it to Perl. Just
don't hold your breath. :)

[1] As I'm writing this, www.php.net appears to be down.

- --
Greg Sabino Mullane greg at turnstep.com
PGP Key: 0x14964AC8 200607272132
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iD8DBQFEyWkyvJuQZxSWSsgRAiPXAKCApWkqoQ40UhLReiccfvvcG4iTYQCgnIF/
YmnMXtQHTupcym0Pr7/LlUo=
=8A5T
-----END PGP SIGNATURE-----


body:
On Fri, Jul 28, 2006 at 10:46:36AM +0300, Domas Mituzas wrote:
> Hi!
>
> > Dunno about Chad, but I would have implemented it in Perl, of course.
> > With perhaps bison and Inline::* where needed.
>
> Do I have still time to suggest ObjectPerlthonasskelisp++#.net?
>
> Anyway, languages/environments used by bigger web shops:
>
> PHP (Yahoo, Wikipedia!!!)
> Python (parts of Google?)
> Java (um, around)
> ColdFusion (MySpace :-)
Perl (Slashdot)

Don't forget where the term "the slashdot effect" originated.

>
> Amazon has SOA with stuff around implemented in nearly all languages...
> Quite nice approach is Mono with different languages inside (like..
> Python engine by Microsoft ;-)
> As for personal preferences, I'd run away from Perl (did drop it 5
> years ago), and use Python (with psyco \o/ )

Python makes my eyes bleed.  I'd be much happier with Perl -- ESPECIALLY
for anything involving regexen.  Holy mudder o' gob, but Python's regex
syntax is a fork in the eye, comparable in heinousness to PHP's.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The ability to quote is a serviceable
substitute for wit." - W. Somerset Maugham


body:
On 7/28/06, Anthere <Anthere9 at yahoo.com> wrote:
> But seriously... is there a trend toward deletion of images under gfdl
> when the author name is missing ?
>

if there isn't a source.

> If so, would not you consider adding "fields" of information when
> uploading an image, and making them mandatory. For example, author name,
> date and place of shot etc...
>

No that makes it too easy to lie.

--
geni


from_name: Anthere

subject:
[WikiEN-l] Dead wikipedians and how to really make a project
 boring to death

body:
Erik Moeller wrote:
> On 7/26/06, Anthere <Anthere9 at yahoo.com> wrote:
>
>>I uploaded the picture of Treanna on the english wikipedia. It was the
>>picture he had on his user page. A bad image, but the only one we had
>>for him. Certainly an image which will never be reused by anyone. But an
>>image of Treanna.
>
>
> I've tagged the photo as fair use and delisted it from IfD.
>
> Erik

Thank you Erik and thank you Oskar.

Ant


from_name: Tim Starling

subject: [Wikitech-l] New SVN user

body:
mboverload wrote:
> Wait, does this mean Mediawiki is going to get some AJAX elements?  Has that
> been tried outside of Google in a large scale?

MediaWiki has already got some AJAX elements. We've had a server-side
distribution framework since March, and an initial application to go
with it: a search as you type feature. That particular feature is
probably impractical on Wikipedia due to the server load, but there are
plenty of other features which can be implemented which can be done
quite efficiently. For example, I imagine the responses for the category
browser could be cached by squid, and purged in the same way that
category pages are currently purged. From the server point of view, it's
a lightweight way to deliver category data, compared to full category
pages.

Some Wikipedia users have been using AJAX for quite some time, via their
user javascript. I'd like to see those features available to everyone,
if server load allows. And it's easier to optimise for server load if
the development effort on the server side and the client side is
integrated. There are of course other advantages to integration:
client-side developers are prone to spending huge amounts of time trying
to extract data from the machine-unfriendly UI, when an XML or JSON
server-side API could be trivially implemented.

I know there are a lot of usability and accessibility concerns relating
to AJAX, but hopefully, by collaborating with users, we can avoid the
worst of them. This isn't some ecommerce shopping basket rush job,
thrown together overnight by a couple of overpaid consultants. Wikipedia
has always aimed to be accessible from the widest variety of systems.

-- Tim Starling


body:
Death Phoenix wrote:
> On 7/27/06, Anthony <wikilegal at inbox.org> wrote:
>
>>On 7/26/06, Oskar Sigvardsson <oskarsigvardsson at gmail.com> wrote:
>>
>>>I think you are all missing Antheres point. Who cares whether it's
>>>fair use or not? Do we really have to be so anal about the rules that
>>>we will infact bring this to IfD, instead of just quietly ignoring the
>>>copyright issue in this very special unique case. We are people, for
>>>christs sake, not automatons! Sometimes, process is not that
>>>important.
>>>
>>>--Oskar
>>
>>I don't see why it's such a special unique case.  Wikipedia's
>>copyright policies are flawed, and this is one example of it.
>>
>>By the way, isn't there a rule that fair use only applies in articles?
>>
>
>
> Am I missing something here? The image in the fr-wikipedia is under
> CreativeCommons, and this was made by the owner of the copyright, Treanna
> himself [
> http://fr.wikipedia.org/w/index.php?title=Image:Norbert3.jpg&diff=2396051&oldid=701771].
> Doesn't mean that the image on en-wikipedia also counts as CreativeCommons?
>
>
> (that's diving right back into the process part of this whole thing, though)
>
> --DP

It certainly is under a creative commons license, but not allowing
derivative. So, we claim fair use provision, to make it possible to host
it, to do "just as if we could do derivatives".
Of course it is unlikely we will ever make any derivative of this image
  and fair use is not recognised in France (Treanna was french).

But well...

That reminds me...

A few weeks ago, I got an image listed for deletion. It was under the
gfdl licence. The argument to list it for deletion was that no author
was mentionned. With no author specifically mentionned, it was argued
that the validity of the status of the image could be questionned and no
one could be contacted for check.

The good news is that even if no author was mentionned, someone could
contact me to ask me :-)

(and someone nicely run a bot on my images to add to all of them an
author name).

But seriously... is there a trend toward deletion of images under gfdl
when the author name is missing ?

If so, would not you consider adding "fields" of information when
uploading an image, and making them mandatory. For example, author name,
date and place of shot etc...

Would not that make it easier as well to identify data when preparing a
DVD ?

Anthere


body:
Kat Walsh wrote:
> On 7/27/06, Ray Saintonge <saintonge at telus.net> wrote:
>
>>Silas Snider wrote:
>>
>>
>>>Except when process protects us from (potentially lenghty and costly)
>>>legal proceedings. Without a tag, it is not clear whether we have the
>>>right to even host the image.
>>>
>>
>>It would be nice if people who put up these claims about protecting us
>>had half a clue about what they are saying.  Such legal proceedings are
>>always possible no matter what we do.  So too is winning the big prize
>>in a national lottery.  If you sign a binding agreement to donate 50% of
>>that prize to WMF when you win it, I would suggest that the Board not
>>make that eventuality a prominent part of its future plans.
>>
>>Ec
>
>
> I'd like to think I have at least half a clue, having seen loads of
> "you are using my copyrighted material, take it down or else"
> messages. (And then many more "hey, I wrote this press release, and
> you guys called me a copyright violator, take that down immediately."
> You just can't win.)
>
> Most of them are just angry and will never actually go to the trouble
> of a lawsuit, sure. Some of them might. Considering the volume, not
> many of them would have to for it to be a huge waste of the limited
> resources of WMF. It's *possible* for people to attempt to sue us for
> all sorts of frivolous things even if we take as much care as
> possible, yes, but it's not the wisest course of action to invite it
> where we don't need to by failing to be responsible.
>
> However:
>
> In this case, there must be some sort of special case. Purist though I
> generally am, surely there must be some way to hang on to a few
> pictures of deceased editors and tag them appropriately to make their
> status clear. Considering all the copyright issues on the project, it
> would be a happy day if this were the most pressing of them. I would
> be loath for this to be some sort of precedent so that everyone and
> his dog wants an excuse to be a special case, but, well, really, I am
> OK with this particular image.
>
> -Kat

Just a thought... Dismiss it if that sounds stupid.

I suppose only a minority of you guys have known wikipedia before there
were user pages (within a user space).
In the old wiki, there was no user space. Someone could have a user name
and no page associated with it. As long as the wiki was small, no one
really needed a private place to communicate. There was even no
equivalent to the village pump. We just discussed on talk pages. And
when a wiki has 5 modifications per day, it is not an issue to follow
your own discussions :-)

Then, people started having their own page. It was easier to communicate
with other editors, when the community started growing. Of course, there
was no user space, so user articles... were encyclopedic articles. I
remember when I created my user page... [[anthere]]. It was also a
french word, so my user page was sitting at an article place :-)

But do you know why user pages are really necessary ?
Not really to communicate. In a collective project, it is important to
keep some private space for each individual. A place where they can blow
steam. Where they can make their own personnality more important than
the collective. Where they matter as individuals. On projects with rules
such as NPOV, it is also highly suitable to offer a space for people to
express a POV.

The need for that space was quickly recognised. It was identified and
separated from the encyclopedia. In a recurrent fashion, we observe
issues about user images. These user images actually ARE in the
encyclopedic space. Why ? Why could not they be separated in the user
space just as user pages ? NPOV is a very strict rule of Wikipedia and
still, we do allow opinions to be expressed on user pages. Why could not
user images be stored separately from encyclopedic images ?

ant


body:
Erik Moeller wrote:
> On 7/27/06, Anthony <wikilegal at inbox.org> wrote:
>
>>What are the good reasons to "prohibit fair use" in the User namespace
>>that don't apply to the Wikipedia namespace?
>
>
> The user namespace is treated by most of its inhabitants as a space of
> personal ownership, and its content is almost unregulated. For
> instance, something like [[User:SPUI]] can survive only because it is
> a user page, and indeed, attempts to get rid of it would be dealt with
> as vandalism. Allowing fair use in that space is likely to lead to
> more MySpace pages, with random celebrity photos, O RLY type crap, and
> boobie-shaking GIF animations. Allowing only free content in the User:
> space is a way to limit it, whereas the content of the Wikipedia:
> space is already regulated by the community.
>
> To me, this is not only about the legal validity of the use, it is
> also about its impact, and whether it is desirable.
>
> Erik

I agree that allowing fair use in user space would be risky.
Allowing ND or NC seems much less risky. And is a provision many people
would feel like imposing on self-pictures.

Ant


subject: [Wikitech-l] Random page function

body:
Magnus Manske wrote:
> While working on another tool, I noticed that we still have that
> page_random value in the page table. There seems to be a better way to
> do this:
>
> http://jan.kneschke.de/projects/mysql/order-by-rand/
>
> That method only requires the primary key being an integer (which is
> true for the page table), nothing else. The guy who wrote the page
> tested it on a table with 1.000.000 rows, 1.000 "random" queries took
> ~0.6 seconds. Sounds like it would be fast enough for us, and we could
> get rid of that page_random field altogether.

Since the page table on enwiki has 5 million rows and the maximum
page_id is 6 million, I imagine there would be a bit of a bias towards
articles at the top edges of gaps. That's probably better than the
current situation though. I did an interesting back of the envelope
calculation on the degree of bias in the page_random system, in
#wikimedia-tech. Maybe I will write it up if I get time...

-- Tim Starling


body:
On 7/28/06, Anthere <Anthere9 at yahoo.com> wrote:
> I agree that allowing fair use in user space would be risky.
> Allowing ND or NC seems much less risky. And is a provision many people
> would feel like imposing on self-pictures.

Defamation and libel are illegal in their own right, and the really
abusive trolls are not going to care about what some licensing button
says. Commercial use? Who on Earth would want to make commercial use
of my ugly mug? And if you really worry about that, use a copyleft
license -- and force others to license their work freely if they
include yours.

Creative Commons, with its broad license catalog, encourages the
intrusion of law into what should really be social contracts. There's
no need to regulate every single human interaction with copyright.
It's tempting, but unnecessary. Tell people what your wishes are.
Avoid people who violate your social norms. Imagine a world without
copyright -- it wouldn't function all that badly. Some say it would
function better.

Erik


body:
On 7/27/06, Chad Perrin <perrin at apotheon.com> wrote:
>
> On Thu, Jul 27, 2006 at 08:03:00PM -0700, mboverload wrote:
> > Everyone knows that Mediawiki should have been written in
> Javascript.  The
> > current implementation is a mess.
>
> Frankly, if it was written end-to-end in Javascript, I (and millions of
> others) would probably use something else.

Don't take this as an insult, because I'm really not sure, but I was really
joking.  Building Mediawiki in javascript is a joke, which is
impossible....right?.  I mean, how would javascript write to the database.
Maybe you were thinking I was talking about AJAX?

- mboverload


subject: [WikiEN-l] giving medical advice

body:
Directly referenced inline, that's probably a better solution.

On 7/28/06, MacGyverMagic/Mgm <macgyvermagic at gmail.com> wrote:
>
> Perhaps not quoted, but a few good sources to back it up can't hurt.
>
> Mgm
>
>
> On 7/28/06, mboverload <mboverload at gmail.com> wrote:
> >
> > Yes, anything as utterly important as the Heimlich Manoeuvre needs to be
> > directly quoted from a medical source.  We are talking people's
> immediate
> > safety.
> >
> > mboverload
> >
> > On 7/27/06, zero 0000 <nought_0000 at yahoo.com> wrote:
> > >
> > > Sorry if this has been discussed before.  I just noticed
> > > that [[Abdominal thrusts]] gives detailed advice on how to
> > > perform a medical procedure.  Maybe there are other such
> > > articles too.  Given the fashionable practice of filing
> > > suit whenever a medical procedure fails to work, it seems
> > > to me that this is rather dangerous for Wikipedia.
> > > Wouldn't it be legally safer (and more likely to be
> > > medically correct) if the actual procedure in such articles
> > > was presented as a direct quotation from a named medical
> > > authority?   With permission, of course.  Maybe there should
> > > also be a disclaimer.
> > >
> > > Zero.
> > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam?  Yahoo! Mail has the best spam protection around
> > > http://mail.yahoo.com
> > > _______________________________________________
> > > 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
> >
> _______________________________________________
> 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] Happy Sysadmin Day!!!

body:
On 7/28/06, Domas Mituzas <midom.lists at gmail.com> wrote:
>
> Hi,
>
> I'd just like to greet all sysadmins with such a nice* fest!
>
> --
> Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]
>
> * http://sysadminday.com/

I'm running in Windows under an account with administrator privileges, does
that count? =D


subject: [WikiEN-l] Should we block unregistered AOL users?

body:
Oh, I was under the impression that they just enabled XFF (which I don't
understand) and that was that.

On 7/28/06, Ilmari Karonen <nospam at vyznev.net> wrote:
>
> mboverload wrote:
> > On 7/27/06, Ilmari Karonen <nospam at vyznev.net> wrote:
> >>
> >>We still seem to be getting edits from some AOL proxies, at least in the
> >>195.93.21.*, 152.163.100.* and 207.200.116.* ranges.  Maybe some of the
> >>proxies are still not providing the headers, or perhaps they're missing
> >>from our trusted XFF list?
> >>
> >>Given that the XFF setup doesn't seem to work perfectly, the question
> >>remains whether we should apply anon-only range blocks to those proxies.
> >
> > If you look at my history of me and AOL users...I think AOL is a
> shithole
> > that should be banned from accessing any website.
> >
> > However, it's much easier to ban an IP address for vandalism than a
> > username.  People get bitchy.  No one cares about blocking IP users, and
> I
> > want to keep it that way for ease of blocking.
>
> ...
>
> Except this is AOL: for all practical purposes, AOL proxy IPs *can't* be
> effectively blocked, not unless you block the entire range.  And if you
> don't make the block anon-only, you get heavy collateral damage, which
> *does* cause serious bitching; we've just gotten so used to it we don't
> really notice the constant complaints any more.
>
> To repeat my argument earlier in this thread, an anon-only range block
> of the AOL proxies would actually reduce the annoyance, since it would
> override autoblocks, allowing registered users to edit without being hit
> by them.  And, of course, once the XFF setup starts working fully, the
> range blocks will cease to have any effect.
>
> --
> 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
>


body:
Wow, your tests can identify the bugzilla number automatically?  neato =P

On 7/28/06, brion at pobox.com <brion at pobox.com> wrote:
>
> An automated run of parserTests.php showed the following failures:
>
> Running test Table security: embedded pipes (
> http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)...
> FAILED!
> Running test Link containing double-single-quotes '' (bug 4598)... FAILED!
> Running test Magic Word: {{CURRENTMONTHNAMEGEN}}... FAILED!
> Running test Template with thumb image (wiht link in description)...
> FAILED!
> Running test message transform: <noinclude> in transcluded template (bug
> 4926)... FAILED!
> Running test message transform: <onlyinclude> in transcluded template (bug
> 4926)... FAILED!
> Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled...
> FAILED!
> Running test HTML bullet list, unclosed tags (bug 5497)... FAILED!
> Running test HTML ordered list, unclosed tags (bug 5497)... FAILED!
> Running test HTML nested bullet list, open tags (bug 5497)... FAILED!
> Running test HTML nested ordered list, open tags (bug 5497)... FAILED!
> Running test Parsing optional HTML elements (Bug 6171)... FAILED!
> Running test Inline HTML vs wiki block nesting... FAILED!
> Running test Mixing markup for italics and bold... FAILED!
> Running test 5 quotes, code coverage +1 line... FAILED!
> Running test HTML Hex character encoding.... FAILED!
> Running test dt/dd/dl test... FAILED!
>
> Passed 412 of 429 tests (96.04%) FAILED!
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


subject: [Foundation-l] Latest board resolutions

body:
On 7/28/06, Michael R. Irwin <michael_irwin at verizon.net> wrote:

> Are there insufficient audit and reporting requirements in Florida law
> to assure us that the Wikimedia Foundation's Finances will eventually be
> made public?
>
I assumed that all nonprofits had to be completely open, or is that only for
taxes?  I don't know jack shit about anything outside personal finances.
Can someone enlighten me?

-mboverload


subject: [Foundation-l] Latest board resolutions


from_name: Ray Saintonge

subject: [Foundation-l] Latest board resolutions

body:
Anthony wrote:

>On 7/27/06, Brad Patrick <bradp.wmf at gmail.com> wrote:
>
>
>>You have to be kidding.  Are you seriously suggesting the Foundation stop
>>buying servers?
>>
>>
>I seriously think they should look into leasing them instead.
>
I don't know if that's necessarily the solution.  In the absence of
proper and timely financial statements it is difficult to make an
evaluation from that perspective.  We keep hearing about buying more
servers, but precious little is done to project needs on the basis of
the life expectancy of the hardware.

There are also frequent concerns expressed about legal suits that WMF
could be faced with.  Even though I feel that at least some of those
concerns are farfetched, good risk management would suggest that ways of
protecting the assets be devised.  Developing an arm's length
relationship between the ownership of the assets and any potential
liability would serve us well.

Leasing could be a part of this through a sale and leaseback arrangement
with a separately incorporated for profit company.

The feigned, "You have to be kidding," approach reflects a failure to
properly consider these issues.

Ec


subject: [Foundation-l] Latest board resolutions


subject: [Foundation-l] Latest board resolutions

body:
geni wrote:

>On 7/27/06, Brad Patrick <bradp.wmf at gmail.com> wrote:
>
>
>>You have to be kidding.  Are you seriously suggesting the Foundation stop
>>buying servers?
>>
>>
>IANAA but
>
>Once you factor in depreciation the logical end point of his position
>is probably that the foundation should turn liquid assets into servers
>and related products as quickly as posible.
>
That wouldn't do it.  Cash and equipment are both assets on a balance
sheet.  If it ever came to that, either could be used to satisfy a
debt.  Buying hardware just so that it can have an opportunity to
depreciate does not seem like a sensible strategy.  Although it's
important to plan for equipment breakdown and obsolescence there is also
a value to delaying purchases.  The same $10,000 that you might spend
prematurely today for a desired piece of equipment might give you a more
advanced piece of similar equipment a year from now.

Ec


subject: [Foundation-l] Latest board resolutions


from_name: Ivan Krstic

subject:
[Wikitech-l] OT: What language would *you* have done it in,
 and why?

body:
henna wrote:
> google does indeed use python for stuff, as well as C if I'm not mistaken

Java, Python, C++ are the three most common languages at Google, in that
order, according to Greg Stein in '05.

--
Ivan Krstic <krstic at solarsail.hcs.harvard.edu> | GPG: 0x147C722D


body:
My ability to convey sarcasm over the internet sucks.  I suck =(

On 7/28/06, Ivan Krstic <krstic at solarsail.hcs.harvard.edu> wrote:
>
> mboverload wrote:
> > Wow, your tests can identify the bugzilla number automatically?  neato
> =P
>
> Those are hardcoded manually when the tests are being written.
>
> --
> Ivan Krstic <krstic at solarsail.hcs.harvard.edu> | GPG: 0x147C722D
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


body: This discussion is boring to death.  Seriously.


body:
Chad Perrin wrote:
> Perl really strikes me as the clear winner

I'm really reluctant to get involved in this discussion, but I'll pitch
in here. In practice, I've found that the only way to keep shared Perl
codebases from turning into a heaping pile of craptitude is to have them
hacked on exclusively by people with pretty deep Perl expertise, which
tends to not be the case for (most) open source projects that aren't
centered around the language. Your mileage may certainly vary.

FWIW, after reaching the second to last stage of Nat Torkington's 'Seven
stages of a Perl programmer,' and using Perl as a primary language for
more years than I care to count, I've personally found Zen in Python.

--
Ivan Krstic <krstic at solarsail.hcs.harvard.edu> | GPG: 0x147C722D


subject: [Foundation-l] Latest board resolutions

body:
I'm just not comfortable with leasing period.

I find Wikipedia to be too important to leave in anyone's hands other than
the immediate foundation.  A company that leases servers may easily give in
to legal challenges or other backhanded threats. We'd have to have legal
advice about how this would effect the lawsuit situation and consider what
we would be giving up.

On 7/28/06, Ray Saintonge <saintonge at telus.net> wrote:
>
> Anthony wrote:
>
> >On 7/27/06, Brad Patrick <bradp.wmf at gmail.com> wrote:
> >
> >
> >>You have to be kidding.  Are you seriously suggesting the Foundation
> stop
> >>buying servers?
> >>
> >>
> >I seriously think they should look into leasing them instead.
> >
> I don't know if that's necessarily the solution.  In the absence of
> proper and timely financial statements it is difficult to make an
> evaluation from that perspective.  We keep hearing about buying more
> servers, but precious little is done to project needs on the basis of
> the life expectancy of the hardware.
>
> There are also frequent concerns expressed about legal suits that WMF
> could be faced with.  Even though I feel that at least some of those
> concerns are farfetched, good risk management would suggest that ways of
> protecting the assets be devised.  Developing an arm's length
> relationship between the ownership of the assets and any potential
> liability would serve us well.
>
> Leasing could be a part of this through a sale and leaseback arrangement
> with a separately incorporated for profit company.
>
> The feigned, "You have to be kidding," approach reflects a failure to
> properly consider these issues.
>
> Ec
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>


subject: [Foundation-l] Latest board resolutions


subject: [Foundation-l] Latest board resolutions

body:
Whats the name of the Wikimedia lawyer again?  I searched for in in gmail
but I'm really not sure what to search for =P


subject: [Foundation-l] Latest board resolutions


from_name: Fred Bauder

subject: [WikiEN-l] giving medical advice

body:
On Jul 27, 2006, at 11:14 PM, zero 0000 wrote:

> Sorry if this has been discussed before.  I just noticed
> that [[Abdominal thrusts]] gives detailed advice on how to
> perform a medical procedure.  Maybe there are other such
> articles too.  Given the fashionable practice of filing
> suit whenever a medical procedure fails to work, it seems
> to me that this is rather dangerous for Wikipedia.
> Wouldn't it be legally safer (and more likely to be
> medically correct) if the actual procedure in such articles
> was presented as a direct quotation from a named medical
> authority?   With permission, of course.  Maybe there should
> also be a disclaimer.
>
> Zero.

This is the Heimlich Manoeuvre and it would be very irresponsible not
to have detailed advice.

Fred


body:
Steve Bennett wrote:
> I googled this and found references to a seven stages by Tom Christiansen...

Gnat gave the (relatively famous) YAPC talk, though the original 'seven
stages' observation was by Tom, yes.

--
Ivan Krstic <krstic at solarsail.hcs.harvard.edu> | GPG: 0x147C722D


body:
mboverload wrote:
> Wow, your tests can identify the bugzilla number automatically?  neato =P

Those are hardcoded manually when the tests are being written.

--
Ivan Krstic <krstic at solarsail.hcs.harvard.edu> | GPG: 0x147C722D


from_name: Anthony

body:
On 7/27/06, Erik Moeller <eloquence at gmail.com> wrote:
> On 7/27/06, Anthony <wikilegal at inbox.org> wrote:
> > What are the good reasons to "prohibit fair use" in the User namespace
> > that don't apply to the Wikipedia namespace?
>
> The user namespace is treated by most of its inhabitants as a space of
> personal ownership, and its content is almost unregulated. For
> instance, something like [[User:SPUI]] can survive only because it is
> a user page, and indeed, attempts to get rid of it would be dealt with
> as vandalism. Allowing fair use in that space is likely to lead to
> more MySpace pages, with random celebrity photos, O RLY type crap, and
> boobie-shaking GIF animations. Allowing only free content in the User:
> space is a way to limit it, whereas the content of the Wikipedia:
> space is already regulated by the community.
>
> To me, this is not only about the legal validity of the use, it is
> also about its impact, and whether it is desirable.
>
> Erik

That's a reason, I suppose, but I don't consider it to be a good one.
The problem in my opinion is that it attempts to solve one problem
(crap in the user namespace), with a rather unrelated second one (ban
non-free images).

Anyway, looking at the User:SPUI page I guess I see what you're
saying.  And I guess the ban on non-free content would tend to lessen
this type of thing.  Actually my response would probably be a minority
one - I don't really see a problem with providing every Wikipedian
with his or her own little private webspace, wholly unregulated by the
community except for the limits of the law and space considerations.

IOW, good response, I guess you've convinced me that allowing fair use
in the user namespace isn't something that's likely to happen.  For
those of us who want to be individuals who happen to contribute to
Wikipedia as opposed to Wikipedians who happen to have interests
outside of Wikipedia, we can just keep our user pages fairly sparse.
Personally, I don't even bother to log in very much any more.

Anthony


body:
>
> I'm normally against the creation of new projects,
> but this sounds
> like a pretty good idea. Presumably, it'll be a
> little like Commons
> but instead of images, would handle citations. I
> suppose other
> Wikimedia projects will make use of this, do you
> hope to allow
> non-WikiMedia projects to use it?

Strictly speaking, citation is its own project (coming
very shortly, I hope):

http://meta.wikimedia.org/wiki/Wikicite

Wikicat will simply act as the data back-end to
support citation, though both projects are very
interrelated.  For example, citing a work for the
first time will import it into Wikicat, while editing
a work within Wikicat will affect the data displayed
by all Wikipedia articles citing it.

The software for this is being written as an extension
so it should be useable by any Mediawiki installation.

>
> The project will aim to catalogue books, news,
> journals, what else? Film?

Yes, everything that is currently catalogable will be
supported: books, journals, film, artwork and
artifacts, maps, electronic resources, recorded sound,
natural specimens and realia, etc.  It will be like an
IMDB for everything.  What will separate it from
existing catalogs, hopefully, is its detail- entries
for a particular journal will describe every article
contained within its issues, an entry for a movie will
show every song or piece of music used on its
soundtrack, etc.  Wikicat will also use the model
proposed in Functional Requirements for Bibliographic
Records (FRBR) so that the same or related content can
be easily found, no matter what form its published in:

http://www.frbr.org/eg/hp-goblet-1.html

>
> How will different referencing styles be handled?

This is still an open issue, but the idea is to use a
single, very compact style so that every citation can
be captured as structured data and used to populate a
"text relationship" database (the focus of a 3rd
project: http://meta.wikimedia.org/wiki/WikiTextrose).
 This will contain a database of all citations, from
Wikipedia articles to published works, and from those
published works to other published works, including
perhaps someday back to Wikpedia articles :)  This
will allow lots of useful functionality, one example
of which is that users will be able to follow a
citation from a Wikipedia article to a work, see all
the works which it cites, and then perhaps improve the
article by using more specialized material than the
work which the article originally cited.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


from_name: Stan Shebs

subject: [WikiEN-l] User:Hillman's arguments

body:
Steve Bennett wrote:

>
>Now, what's interesting is to think about where most of the
>"deliberate POV" problems in our encyclopaedia reside:
>
>- Currently trading companies
>- Political parties, governments etc
>- Other living people
>- Religions
>- Certain highly emotive debates (abortion, circumcision,
>neurolinguistic programming - for reasons beyond my comprehension)
>
Add crackpot science as the next down in frequency - Hillman has
mostly had to contend with freaky ideas about general relativity
and the like. Although these are usually individuals rather than
interest groups, they often have sufficient energy to sweep through
a whole bunch of articles, and they are clever enough to use
multiple sockpuppets to cover their tracks. These kinds of additions
tend to be well-referenced, and only an expert would recognize that
the references are either bogus or irrelevant.

Stan


from_name: Brad Patrick

subject: [Foundation-l] Latest board resolutions

body:
One of several strategies which may be considered is the plausibility of
separating operations from trademark/IP and having a different corporate
structure for them under the Board umbrella.   Once we have completed
our audit, we will consider the advantages of those different
situations.  These are preliminary concepts, not actual plans at this time.

Domas Mituzas wrote:
>> It reduces the value of your balance sheet. which reduces your
>> atrativeness as a target.
>>
>
> hi!!!! does that mean that all physical operations should be made as
> separate legal body, and all the blame would go to another one? ;-)
>
> Domas
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
>


subject: [Foundation-l] Latest board resolutions


body:
On Fri, Jul 28, 2006 at 03:39:35AM -0700, mboverload wrote:
> On 7/27/06, Chad Perrin <perrin at apotheon.com> wrote:
> >
> > On Thu, Jul 27, 2006 at 08:03:00PM -0700, mboverload wrote:
> > > Everyone knows that Mediawiki should have been written in
> > Javascript.  The
> > > current implementation is a mess.
> >
> > Frankly, if it was written end-to-end in Javascript, I (and millions of
> > others) would probably use something else.
>
>
> Don't take this as an insult, because I'm really not sure, but I was really
> joking.  Building Mediawiki in javascript is a joke, which is
> impossible....right?.  I mean, how would javascript write to the database.
> Maybe you were thinking I was talking about AJAX?

I had the impression it was probably a joke, but decided to answer the
hypothetical unasked question anyway -- and it would be "impossible" to
write the whole thing as it currently exists in Javascript, with current
implementations of Javascript, but it's not impossible to create an
online encyclopedia without any server-side scripting for the website.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The measure on a man's real character is what he would do
if he knew he would never be found out." - Thomas McCauley


body:
On Fri, Jul 28, 2006 at 01:42:45PM +0300, Domas Mituzas wrote:
> > Don't take this as an insult, because I'm really not sure, but I
> > was really
> > joking.  Building Mediawiki in javascript is a joke, which is
> > impossible....right?.  I mean, how would javascript write to the
> > database.
> > Maybe you were thinking I was talking about AJAX?
>
> You haven't heard about bittorrent? There will be no need for the
> database!!!
>
> (BTW, server side javascript, and various mutations, exists too).

Eww.  After reading that, I think my brain needs a shower.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"Real ugliness is not harsh-looking syntax, but having to
build programs out of the wrong concepts." - Paul Graham


from_name: Steve Bennett

subject: [WikiEN-l] Everyone _did_ see the article in The Onion?

body:
On 7/28/06, Daniel P. B. Smith <wikipedia2006 at dpbsmith.com> wrote:
> I don't read the whole mailing list all the time so this may have
> already been discussed to death... but everyone _did_ see the IMHO
> hysterically funny article in The Onion,

No...

> "Wikipedia Celebrates 750 Years Of American Independence?"
>
> http://www.theonion.com/content/node/50902

But I saw that one...

:)

Steve


body:
On 7/28/06, Mark Wagner <carnildo at gmail.com> wrote:
> On 7/27/06, MacGyverMagic/Mgm <macgyvermagic at gmail.com> wrote:
> > We shouldn't rely on the completely clueless when determining rules and
> > actions with regard to copyright.
>
> We shouldn't?  Then why do we give everyone an upload button and
> encourage them to use it?

+1 insightful

Steve


body:
On 7/28/06, geni <geniice at gmail.com> wrote:
> Because it risks being overused.

Maybe, but "it risks..." is rarely a good reason not to try something
with no negative consequences.

Steve


body:
On Fri, Jul 28, 2006 at 06:05:31PM +0300, Ilmari Karonen wrote:
> Chad Perrin wrote:
> > On Fri, Jul 28, 2006 at 01:42:45PM +0300, Domas Mituzas wrote:
> >>
> >>(BTW, server side javascript, and various mutations, exists too).
> >
> > Eww.  After reading that, I think my brain needs a shower.
>
> Modern JavaScript (okay, ECMAScript) is actually a pretty nice language.
>   It's just the browser implementations that generally suck.  But it's
> certainly no worse than PHP.

Oh, it's almost certainly better than PHP.  My brain still needs a
shower -- unless this means that all PHP will now magically be replaced
with server-side Javascript, in which case we might have a net win.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"There comes a time in the history of any project when it becomes necessary
to shoot the engineers and begin production." - MacUser, November 1990


subject: [Wikitech-l] FOLO: What would we lose, speciifically?

body:
On Fri, Jul 28, 2006 at 11:41:42AM -0400, Jay R. Ashworth wrote:
> On Fri, Jul 28, 2006 at 10:46:36AM +0300, Domas Mituzas wrote:
> > Do I have still time to suggest ObjectPerlthonasskelisp++#.net?
>
> That's sorta like the language name version of Chriskwaanzukkah, right?

I think that's "Chrismahannukwanzaaka", actually.

>
> > Python (parts of Google?)
>
> And this is the dog that didn't bark; I was a bit surprised that we
> didn't hear any more comments about Python as a possibility.

I'm glad we didn't.

By the way . . .
When I mentioned Slashdot as a Perl example, I apparently shot too low.
I'd forgotten about Amazon.com, LiveJournal, IMDB, and del.icio.us,
among others.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
This sig for rent:  a Signify v1.14 production from http://www.debian.org/


from_name: Erik Moeller

body:
On 7/27/06, Jay R. Ashworth <jra at baylink.com> wrote:
> Unthreaded: in a clear field, Chad, what *would* you have implemented
> MediaWiki in?  And why?

Much of recent development and administration has focused on caching,
clustering, failover, load balancing, and so on. It seems to me that
the decision to use a ready-made application server like JBoss, Resin
or Zope (or WebSphere if you want proprietary) or a different database
server would make a greater difference for long term deployment of a
very large scale wiki farm like Wikimedia than the choice of a
particular programming language (though of course one may imply the
other).

That being said, from the rough numbers I've seen about similarly
sized sites like eBay or Amazon.com, which typically use such
application server architectures, we are running on a ridiculously
small amount of hardware. For instance, eBay in 2004 was running with
200 database backend servers [1] -- I don't think you'll find detailed
specs for these, but according to [2] we're talking about big Sun
machines. Of course, we're not even close to Amazon.com's or eBay's
reliability.

Nevertheless, it seems clear that our "roll your own" approach, while
more intensive in developer work, can save significantly on hardware.
It's also interesting to compare Flickr's technological evolution,
which is quite similar to our own:
http://www.ludicorp.com/flickr/zend-talk.ppt

Is similar information available about Yahoo!'s setup?

One major downside is that such "perpetually customized" setups can
become very complex and hard to replicate quite quickly.

It's also important to emphasize that _Wikimedia_ (as opposed to
MediaWiki) runs on more than just PHP. In fact, there's probably not a
single mainstream programming language that hasn't been used somewhere
on the Wikimedia servers. Brion seems to greatly enjoy experimenting
with new languages, and even MediaWiki itself comes with an OCaml
extension. :-) It's certainly a rich learning environment.

Erik

[1] http://www.eweek.com/article2/0,1895,1640310,00.asp
[2] http://www.sun.com/service/about/success/ebay.xml


body:
On Fri, Jul 28, 2006 at 12:40:00PM +0200, Tels wrote:
> On Friday 28 July 2006 08:44, Chad Perrin wrote:
> [snipauiteabit]
> > Perl really strikes me as the clear winner, overall, with Ruby a close
> > second about a hair's-breadth behind it.
>
> <offtopic>
>
> I don't know much about Ruby, except that I heard Unicode support is really
> lacking. Which pretty much rules it out for anything serious text
> processing in this age :-D

"Really lacking" seems to be a bit too vehement for the current state of
affairs.  As far as I'm aware, regex support is excellent.  Some kernel
methods don't handle Unicode transformations as well as they could,
though the problem isn't in Unicode support so much as in localization
(handling capitalization in German and Turkish, for instance, which are
a touch quirky by English language standards).  I'm pretty sure Ruby
isn't the only language to run into localization issues from time to
time, and it may be that Ruby runs into them more often because of its
wealth of convenient string operation methods that are often lacking in
other languages.

>
> However, the entire Ruby project always stuck me as a
> me-too-lets-reinvent-the-wheel-and-this-time-make-it-rounder project, like
> so many others (*cough*Perl6*cough).

1.  That could be said of EVERY language.  I suppose we could just
rewrite MediaWiki in Assembly language, after all.

2.  Ruby is quite NOT a "metoo" language.  It's older than most realize
(spending most of its formative years in Japan that largely gained
Western recognition due to the advent of Rails does not equate to a
lifespan measurable entirely in this century).  It also offers a lot of
capabilities and conveniences not found in many other languages.  It may
be the closest thing we've got to a Lisp with an imperative/OO syntax,
for instance.

3.  Perl 6 is an attempt to address some very real problems, not just a
"reinvent and make it rounder" effort as you so easily dismiss it.  The
fact it's vaporware doesn't change the fact that, if it ever completes,
it's likely to be an excellent and needed language.  On the other hand,
I suppose all we really need is a hex editor so we're not reinventing
wheels.

>
> Yes, Perl5 has some problems, like carrying baggage from a decade or two
> that nobody really needs anymore, but I am not sure that
> yet-another-interpreted-language (that is only 60..90% complete,
> undertested etc) is the real answer. It just fragments the coder base even
> more.

Did you perhaps mean "99.60..99.90%" there?

>
> We have way too many programming languages already.

Yeah, progress sucks.  Ahem.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The measure on a man's real character is what he would do
if he knew he would never be found out." - Thomas McCauley


from_name: henna

body:
On 7/28/06, Domas Mituzas <midom.lists at gmail.com> wrote:
> Hi!
>
> > Dunno about Chad, but I would have implemented it in Perl, of course.
> > With perhaps bison and Inline::* where needed.
>
> Do I have still time to suggest ObjectPerlthonasskelisp++#.net?
>
> Anyway, languages/environments used by bigger web shops:
>
> PHP (Yahoo, Wikipedia!!!)
> Python (parts of Google?)
google does indeed use python for stuff, as well as C if I'm not mistaken

henna
--
"Maybe you knew early on that your track went from point A to B, but
unlike you I wasn't given a map at birth!" Alyssa, "Chasing Amy"


body:
On 7/28/06, Domas Mituzas <midom.lists at gmail.com> wrote:

> I'm not aware of any huge-scale environments, that would be running
> on Jboss, Resin or Zope (or Websphere).

The open source ones are fairly untested in _huge_-scale environments
AFAICT (then again, so was PHP until recently). But for "enterprise
level" scalability, see
http://www.zope.com/customers/case_studies.html
http://www.jboss.com/customers/index

eBay is "powered by WebSphere" and probably a good comparison as a
dynamic web application. They're still getting more traffic than we
do. ;-)

> I'm not totally compatible with all enterprise software, but at least
> Amazon is using pretty lightweight setup with most of stuff being
> routed to 'services' around, SOAP, WSDL, yadda yadda. I'm not sure if
> they need full-blown app server for this at the front.

What I do know is that they're making a bloody mess out of all those
aggregated web services. A little tagging here, a little wiki there,
here's some recommendations, and a wishlist and a puppy, too ...

Erik


from_name: Domas Mituzas

subject:
[Foundation-l] Reporting & communication (was: Wolf Mountain
	MediaWiki Appliances Released)

body:
Hi!

> And although you might disagree, I have no reason you are not Hardware
> Officer either. I know Delphine calls herself "the former" Chapter
> Officer (and now Chair of LCCom). Danny thinks himself GrO still,
> Elian resigned, as for other officers, I have no clue.

Right now tech. committee has the authority (even more of that!) than
I did before.
I still handle the work of 'hardware officer', but I guess I did that
before we even invented officers.
And if you want formal hierarchy, then I guess Brion is our chairman ;-)

> Related to a certain website, I would like to know the exact contact
> Wikimedia Officers or their successors concerning updates of reports
> from each field. Is there any latest chart of the Wikimedia Foundation
> Organisation?

I'm sure those reports might be called quite voluntary - at least I
did them before to describe our activities (then someone thought it
was good idea to use them as semi-official documents).

> Or we can say "the officers are still in office, unless
> they resigned"

Or we can say - we have community of nice guys who do stuff. Titles
are nice, but they're not tags that make us act in some specific
ways. :)

> Um, however, as for Hardware, I think we need to argue with whom and
> on what a comcom member should talk to get a new update? <g>

We already discussed that, didn't we? :)

--
Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]


body:
Hi!

> Dunno about Chad, but I would have implemented it in Perl, of course.
> With perhaps bison and Inline::* where needed.

Do I have still time to suggest ObjectPerlthonasskelisp++#.net?

Anyway, languages/environments used by bigger web shops:

PHP (Yahoo, Wikipedia!!!)
Python (parts of Google?)
Java (um, around)
ColdFusion (MySpace :-)

Amazon has SOA with stuff around implemented in nearly all languages...
Quite nice approach is Mono with different languages inside (like..
Python engine by Microsoft ;-)
As for personal preferences, I'd run away from Perl (did drop it 5
years ago), and use Python (with psyco \o/ )

BR,
Domas

--
Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]


body:
On Fri, Jul 28, 2006 at 06:39:12PM +0200, Jens Frank wrote:
> On Fri, Jul 28, 2006 at 12:44:33AM -0600, Chad Perrin wrote:
> >
> > I like the proposed idea of writing one or two core, high-load
> > components in C, or even (if we're really adventurous) something better
> > performing like Ada, though that's probably really pushing it.  Since I
> > don't much enjoy looking at C code, though, I might just ask someone
> > else to write the C, so I guess *I* in particular might not implement
> > any of it in C.  Eh.
> >
> We actually do this. The diff engine exists as a PHP plugin written in C
> (or C++, which is nearly the same).

. . . aside from the fact that it often exhibits an at least arithmetic
increase in execution time as compared with straight C.

Sorry, minor, largely pointless quibble.  There's a bit of a language
execution time debate going on somewhere else that has absorbed me
recently.  The subject is sorta stuck in my head at the moment.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
print substr("Just another Perl hacker", 0, -2);


from_name: Evan Prodromou

subject: [Wikitech-l] New SVN user

body:
On Wed, 2006-26-07 at 20:37 -0700, Ben Garney wrote:

> Too bad MediaWiki isn't Java-based!

It's probably worth mentioning that there's a new project to create a
MediaWiki-workalike engine that runs in a Java Servlets container. It's
called JAMWiki, and it's here:

        http://jamwiki.org/

I've played around with it a little and, while it's definitely Not There
Yet, it's way ahead of 80% of existing Wiki engines. I'm going to be
keeping an eye on it.

~Evan


body:
Hi!

> Much of recent development and administration has focused on caching,
> clustering, failover, load balancing, and so on.

This is more part of architecture, than of software used.

> It seems to me that
> the decision to use a ready-made application server like JBoss, Resin
> or Zope (or WebSphere if you want proprietary) or a different database
> server would make a greater difference for long term deployment of a
> very large scale wiki farm like Wikimedia than the choice of a
> particular programming language (though of course one may imply the
> other).

I'm not aware of any huge-scale environments, that would be running
on Jboss, Resin or Zope (or Websphere).
Application servers with all the integration magic are required
mostly for complex applications that have hundreds of thousands of
developers ;)

Regarding databases - here again, architecture imposes what you use.
Right now our architecture consists of:

a) Small replicated core database sets (per-language)
b) Pools of replicated text storage nodes
c) Pool of in-memory hash lossy store nodes

Probably we might be adding a

d) Pool of fully clustered storage, for session objects.

What we can introduce - different storage paradigms for different
objects, and here we choose software that works and is easy to maintain.

> That being said, from the rough numbers I've seen about similarly
> sized sites like eBay or Amazon.com, which typically use such
> application server architectures, we are running on a ridiculously

I'm not totally compatible with all enterprise software, but at least
Amazon is using pretty lightweight setup with most of stuff being
routed to 'services' around, SOAP, WSDL, yadda yadda. I'm not sure if
they need full-blown app server for this at the front.

> Nevertheless, it seems clear that our "roll your own" approach, while
> more intensive in developer work, can save significantly on hardware.
> It's also interesting to compare Flickr's technological evolution,
> which is quite similar to our own:
> http://www.ludicorp.com/flickr/zend-talk.ppt

I'm not sure it takes us longer to roll our own stuff, than it would
take to leverage all the other solutions.

> Is similar information available about Yahoo!'s setup?

They're quite similar to us, it is just that they have more
redundancy over multiple datacenters (and have practice of serving
from multiple datacenters at the same time too).

> with new languages, and even MediaWiki itself comes with an OCaml
> extension. :-) It's certainly a rich learning environment.

Well, yes, we even have direct PHP extensions written in C++/C, and
there's various outside-of-mediawiki code in boo, python, C#, perl
too ;-)

--
Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]


from_name: Oldak Quill

body:
On 28/07/06, Jonathan Leybovich <jleybov at yahoo.com> wrote:
> All-
>
> I hereby propose for your consideration Wikicat, a
> project to create an open, bibliographic catalog.  The
> purpose of Wikicat is to both lay the groundwork for a
> scholarly apparatus to be used within Wikipedia as
> well as create a unique and valuable information
> resource in its own right.  In particular, Wikicat
> will:
>
> * facilitate the process of citation by automatically
> fetching bibliographic data based upon unique keys
> such as ISBN, ISSN, and LCCN
> * allow users to more easily navigate between
> information resources by grouping them in a
> functionally significant manner (in particular,
> according to the principles of [[w:FRBR]]) so that,
> for example, different editions, translations, etc.
> are all joined together
> * apply Wikipedia's collaborative content creation
> model to bibliographic data, resulting in a catalog of
> unprecedented detail
>
> In terms of implementation, Wikicat will be defined
> like any other [[m:Wikidata]] dataset and will
> integrate with other datasets such as WiktionaryZ to
> share common entities and perhaps someday support
> something along the lines of a Semantic Mediawiki.  As
> Wikidata is currently not code complete, though,
> Wikicat will be deployed in stages, during the first
> of which it will exist as a read-only database that
> populates itself on an as-needed/"as-cited" basis by
> importing data from the open catalog servers of such
> institutions as the Library of Congress, the
> University of California library system, the U.S.
> National Library of Medicine, etc.
>
> Details about the project, in increasing technical
> detail, are available on the following pages:
>
> http://meta.wikimedia.org/wiki/Proposals_for_new_projects#Wikicat
> http://meta.wikimedia.org/wiki/Wikicat
> http://meta.wikimedia.org/wiki/Wikicat_Technical_Design
>
> Coding of the first stage of the project is nearly
> complete and a list of its operational requirements
> will soon be forthcoming.  Here is a demo of Wikicat
> integration with the Cite/<ref> extension:
>
> http://meta.wikimedia.org/wiki/Image:Wikicat_Cite_screenshoot.png
>
> Thank you for your time and I look forward to your
> comments.

I'm normally against the creation of new projects, but this sounds
like a pretty good idea. Presumably, it'll be a little like Commons
but instead of images, would handle citations. I suppose other
Wikimedia projects will make use of this, do you hope to allow
non-WikiMedia projects to use it?

The project will aim to catalogue books, news, journals, what else? Film?

How will different referencing styles be handled?
--
Oldak Quill (oldakquill at gmail.com)


subject: [Wikitech-l] Happy Sysadmin Day!!!

body:
Hi,

I'd just like to greet all sysadmins with such a nice* fest!

--
Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]

* http://sysadminday.com/


body:
On 7/28/06, Steve Bennett <stevagewp at gmail.com> wrote:
>
> On 7/28/06, Mark Wagner <carnildo at gmail.com> wrote:
> > On 7/27/06, MacGyverMagic/Mgm <macgyvermagic at gmail.com> wrote:
> > > We shouldn't rely on the completely clueless when determining rules
> and
> > > actions with regard to copyright.
> >
> > We shouldn't?  Then why do we give everyone an upload button and
> > encourage them to use it?
>
> +1 insightful
>
> Steve
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

I'm still not sure why that is. Personally, I find doing that is a bad idea.

Mgm


subject: [WikiEN-l] giving medical advice

body:
Perhaps not quoted, but a few good sources to back it up can't hurt.

Mgm

On 7/28/06, mboverload <mboverload at gmail.com> wrote:
>
> Yes, anything as utterly important as the Heimlich Manoeuvre needs to be
> directly quoted from a medical source.  We are talking people's immediate
> safety.
>
> mboverload
>
> On 7/27/06, zero 0000 <nought_0000 at yahoo.com> wrote:
> >
> > Sorry if this has been discussed before.  I just noticed
> > that [[Abdominal thrusts]] gives detailed advice on how to
> > perform a medical procedure.  Maybe there are other such
> > articles too.  Given the fashionable practice of filing
> > suit whenever a medical procedure fails to work, it seems
> > to me that this is rather dangerous for Wikipedia.
> > Wouldn't it be legally safer (and more likely to be
> > medically correct) if the actual procedure in such articles
> > was presented as a direct quotation from a named medical
> > authority?   With permission, of course.  Maybe there should
> > also be a disclaimer.
> >
> > Zero.
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> > _______________________________________________
> > 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: Jay R. Ashworth

body:
On Fri, Jul 28, 2006 at 10:46:36AM +0300, Domas Mituzas wrote:
> Do I have still time to suggest ObjectPerlthonasskelisp++#.net?

That's sorta like the language name version of Chriskwaanzukkah, right?

> Python (parts of Google?)

And this is the dog that didn't bark; I was a bit surprised that we
didn't hear any more comments about Python as a possibility.

Ok, second question: how much leverage would we *lose* if we weren't in
PHP?  (Isn't some of our caching PHP-specific?)

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	Fanfic: read enough, and you'll loose your mind.  --me


body:
On 7/28/06, Ivan Krstic <krstic at solarsail.hcs.harvard.edu> wrote:
> FWIW, after reaching the second to last stage of Nat Torkington's 'Seven
> stages of a Perl programmer,' and using Perl as a primary language for
> more years than I care to count, I've personally found Zen in Python.

I googled this and found references to a seven stages by Tom Christiansen...

http://prometheus.frii.com/~gnat/yapc/2000-stages/slide1.html

According to that, you have not yet rewritten major parts of the
compiler, or become on first-name terms with Larry's wife.

Steve


from_name: Ilmari Karonen

body:
mboverload wrote:
> On 7/27/06, Ilmari Karonen <nospam at vyznev.net> wrote:
>>
>>We still seem to be getting edits from some AOL proxies, at least in the
>>195.93.21.*, 152.163.100.* and 207.200.116.* ranges.  Maybe some of the
>>proxies are still not providing the headers, or perhaps they're missing
>>from our trusted XFF list?
>>
>>Given that the XFF setup doesn't seem to work perfectly, the question
>>remains whether we should apply anon-only range blocks to those proxies.
>
> If you look at my history of me and AOL users...I think AOL is a shithole
> that should be banned from accessing any website.
>
> However, it's much easier to ban an IP address for vandalism than a
> username.  People get bitchy.  No one cares about blocking IP users, and I
> want to keep it that way for ease of blocking.

...

Except this is AOL: for all practical purposes, AOL proxy IPs *can't* be
effectively blocked, not unless you block the entire range.  And if you
don't make the block anon-only, you get heavy collateral damage, which
*does* cause serious bitching; we've just gotten so used to it we don't
really notice the constant complaints any more.

To repeat my argument earlier in this thread, an anon-only range block
of the AOL proxies would actually reduce the annoyance, since it would
override autoblocks, allowing registered users to edit without being hit
by them.  And, of course, once the XFF setup starts working fully, the
range blocks will cease to have any effect.

--
Ilmari Karonen