body:
I won't comment on the specific question, but on the underlying
Wikimedia policy issue.

The Board can decide the policy for software use by the Foundation.
What would a sensible policy look like? I think an a priori "open
source[*] only" policy is problematic since there are of course areas
where open source software cannot (yet) compete.  For instance, I'm
not aware of a professional open source optical character recognition
(OCR) solution, which is crucial for digitization.

However, we do need to be aware of the risks of proprietary software:
vendor lock-in, company bankruptcy, no code availability for security
auditing, and so on. Aside from that, supporting open source is an
important matter of outside perception for the Foundation.

How about a policy that states:
- when no adequate (as determined by its prospective users) 100% free
software solution for a task can be found, a proprietary solution may
be used.
- such use needs to be reported and documented in a list of
proprietary software used by the Foundation, so that the decision can
be debated and challenged by the community.
- in such cases, a partially proprietary solution is preferable to a
fully proprietary one.
- a migration plan should be made as soon as a realistic fully open
source alternative emerges.
- the Foundation should, within its budget, support the development of
such an alternative.

Does that make sense?

Best,
Erik

[*] Apologies to those who prefer "free software"; I use the terms
interchangeably.


list: wikimedia-l

source: pipermail-mbox

from_name: Erik Moeller

subject: [Foundation-l] Open source CRM needed for Wikimedia


list: commons-l

from_name: Platonides

subject:
[Commons-l] An interactive copyright tutorial as
	arequirementfor uploading?

body:
>> >*There's too much work for admins
>> We're talking of adding a 'can upload' permission. Also add an can review
>> permission, automatically got after N uploads and no copyright problem.
>> Admins could always add/remove this permission.
>
> Do you mean 'we' as in the people on this list, or 'we' as in the
> developers? If it's the dev's then I'm very glad to hear it (so that
> we can block people from uploading only). But to my knowledge
> MediaWiki is not set up for this kind of thing, is it? B'crats can
> add/remove bot flags.

We as people in this list, people of commons. Sorry.

>> Another problem would be people creating new accounts to bypass this
>> limit
>> system.
>
> Yeah, but I think we'll just have to wear that (not much we can do
> about it, and hopefully not too much of a problem).

It's not a problem now, but if we set continuous upload more difficult, who
knows?

> Brianna

Platonides


list: wikitech-l

from_name: Steve Bennett

subject: [Wikitech-l] Wikimarkup request: -- to em-dash

body:
On 6/25/06, Ilmari Karonen <nospam at vyznev.net> wrote:
> Steve Bennett wrote:
> >
> > Thanks for this explanation. I don't quite follow the logical step
> > that was made between "one common and important use" and "the way this
> > should work", but, hey. In practice, in Wikipedia, this "common and
> > important" use is basically never used - we certainly don't want ASCII
> > art in our articles.
>
> We do, however, quite often want source code in our articles.

And it would probably be appropriate to have a good way of doing that.
Source code doesn't necessarily demand lack of line wrapping. Perhaps
a proper <source> tag would be the way to go.

Steve


list: wikien-l

subject: [WikiEN-l] Spoiler Boilerplates

body:
On 6/25/06, Zero <megamanzero521 at yahoo.com> wrote:
>  And we will get there, I'm positive. But we have quite a way to go. The  most glaring dissapointment I have with the spoiler tag is it wasn't  developed with an encyclopedia in mind. Many users claim the offense of  "Oh but its nice and it will help not to spoil them". This isn't that  kind of website.Wikipedia is an uncensored, pure callaboration of  knowledge unhindered by what other social websites may do.

The spoiler tag, as well as any "warning, this page contains
pornographic images" tags, are totally unrelated to censorship.
Really. And I don't see what either of these tags has to do with
"other social websites" - we don't imitate, we make our own decisions
based on what seems reasonable.

>  You say" "well it doesn't help the wikipedia, but the reader in a way  similar to usenet". This is wrong. Anything promoting such external  social ideals lacking in edvidence to improve the encyclopedia itself  should of course be deleted on sight. -

I didn't mention usenet. And I'm afraid I don't understand your point
here. It seems to me that we are both using the ideal that "Wikipedia
is an encyclopaedia" to support opposing viewpoints. Maybe Wikipedia
should stop claiming to "be an encyclopaedia", and instead define
precisely what it wants to be, and where it wants to draw its limits.
Not all encyclopaedias are the same, so just claiming to be in that
general class of works isn't enough anymore.

Steve


subject: [WikiEN-l] 3RR policy proposal: No "Gotcha" rule

body:
On 6/24/06, fireislandparadise <fireislandparadise at gmail.com> wrote:
> My problem is that not requiring a warning encourages gaming by making it
> easier for a more savvy edit warrior to take advantage of another editor and
> play "gotcha". This is particularly the case as most editors aren't aware of
> the new "unrelated reverts" interpretation. If someone is savvy enough to
> complain on ANI/3RR they should be capable of giving someone a warning
> first, especially if they are a participant in the edit war.

Is "gotcha" a big problem? Let's see:
* You can only do it once, ever, to a single editor
* You can only do it when the person has reverted 3 times in a single
day, something we wish to discourage
* The punishment is only banning for 24 hours.

Sure, it could happen. But it's probably not worth worrying about.

Steve


list: foundation-l

from_name: Ray Saintonge

subject: [Foundation-l] Re : Where we are headed

body:
Birgitte SB wrote:

>--- James Hare <messedrocker at gmail.com> wrote:
>
>
>>Another problem with communication is all the pages
>>it spans. I maintained
>>several user and user talk pages, but I only need
>>two of them. Although the
>>normal MediaWiki software can maintain the status
>>quo, Wikimedia's should be
>>designed a bit differently: the projects can have
>>the mainspace, the portal
>>space, and the project space, but a central wiki
>>(Meta, anyone?) would have
>>the help pages and the user/user talk pages. Surely
>>this has been discussed before?
>>
>>
>Centralizing the help pages is  a bad idea.  There are
>technical differences between projects.  For example
>en.WS has subpages enabled and therefore uses relative
>linking which does not work on other projects.  There
>once was a bot that went through and imported on the
>Meta Help pages into en.WS (even overwrting some of
>local copies!)  It was not useful and they were all
>run through deletion.  They too detailed, too much
>information. Local help pages need be very simple and
>deal with just the common issues, and then link to
>Meta for advanced help.
>
I completely agree with you and Robert on this.  Wiktionary faced the
same problem from the same bot.  The changes included warnings that it
was pointless to freely edit these because the edits would be
overwritten with the next update of the Meta pages.  Even if the
information were all valid, a simple link to the corresponding Meta page
would have been enough.

Ec


subject: [Foundation-l] Re : Where we are headed


from_name: Ed Peschko

subject:
[Foundation-l] Opinions/suggestions for "outside" members of
	the board?

body:
On Mon, Jun 19, 2006 at 01:07:40PM +0200, Jimmy Wales wrote:
>
> To continue the ongoing board development conversation....
>
> The board is considering adding some prominent person from outside the
> core Wikipedia community to the board and seeks brainstorming ideas of
> what type of person could be good, as well as mentions of names who we
> might want to approach.
>
> Larry Lessig - head of Creative Commons
>
> Mitch Kapor - head of Mozilla Foundation (Firefox), founder of EFF, and
> extremely passionate about the Wikipedia mission (and he edits
> Wikipedia, and he is absolutely fascinated by and supportive of our
> community model)
>
> Richard Stallman - needs no introduction
>
> Eben Moglen - main legal mastermind of the FSF
>
> Comments on these names are welcome... as are further ideas of course!

Just to throw in my two cents -  I'd go for Larry Lessig over the others.
I've seen several of his talks and he seems to 'get' the point behind
fair use in conjunction w/copyright law in both ideological and practical
perspectives.

He also is better known than most of the others on your list, with the exception
of Richard Stallman, who tends to IMO be divisive and pedantic in a way that Larry
is not. He also brings a lot of pragmatic legal expertise to the table. He would
also be an engaging proponent for Wikipedia in general.

Again, just my IMO,

Ed


from_name: Andrew Dunbar

body:
On 6/23/06, Jay R. Ashworth <jra at baylink.com> wrote:
> On Thu, Jun 22, 2006 at 12:21:28PM -0600, Chad Perrin wrote:
> > Would requiring spaces on either side of the double dash before
> > converting it into an emdash improve the parsing behavior any?
>
> Please don't.
>
> <snob type=typography>
> Em dashes are properly set in English text without spacing on either
> side, though the ASCIIography of this usage is much less picky.

Can you provide a reference for this? Also can you be
sure this is the only style and that it doesn't vary by
style guide, by publisher, by country, by newspaper vs
novels, etc.
The reason I ask is that I've been studying casually how
they are typeset in books as part of my thinking about
an XML format for e-texts. I have seen so many cases
both with and without spaces that I've been pondering
whether it would best be handled as a style issue.

Andrew Dunbar (hippietrail)

> If someone decides that it needs to be " -- " that's mapped, at least
> take the spaces out when setting the glyph?
> </snob>
>
> 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
>
>     A: Because it messes up the order in which people normally read text.
>     Q: Why is top-posting such a bad thing?
>
>     A: Top-posting.
>     Q: What is the most annoying thing on Usenet and in e-mail?
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>

--
http://linguaphile.sf.net


subject: [Foundation-l] Re : Where we are headed

body:
Gerard Meijssen wrote:

>James Hare wrote:
>
>
>>To respond to Jimmy's e-mail,
>>
>>Another problem with communication is all the pages it spans. I maintained
>>several user and user talk pages, but I only need two of them. Although the
>>normal MediaWiki software can maintain the status quo, Wikimedia's should be
>>designed a bit differently: the projects can have the mainspace, the portal
>>space, and the project space, but a central wiki (Meta, anyone?) would have
>>the help pages and the user/user talk pages. Surely this has been discussed
>>before?
>>
>>
>Hoi,
>Yes, it has. There are people, myself included who present themselves
>slightly different depending on the project. For instance what is the
>relevance to the Wiktionary crowd that I have written about the fish
>that swim in the Dutch sweet waters?? Some information is of value never
>mind the project eg the language proficiency that can be found in the
>Babel templates. However, this is only of relevance to the projects
>where someone is active.
>
I think that the term which you intend is "fresh waters", as opposed to
"salt waters".  My first (unresearched) impression was that "sweet
water" would refer to run-off from farmers' fields that had been
sweetened by the activity of cattle in that field. ;-)

I agree that having separate user and user talk pages on different
projects is a necessary evil.  This avoids having to guess what project
the person with a message is talking about.

Ec


subject: [Foundation-l] Re : Where we are headed


from_name: Mark Gallagher

body:
G'day Warren,

>>WP:3RR was changed (without there first being consensus) back in April so
>>that reverts count towards the 3RR even if they are unrelated. This has
>>resulted in some editors playing "gotcha" by invoking the 3RR without first
>>giving a warning.

I suspect --- though I could very well be wrong --- that this was in
response to an ArbCom ruling.  ArbCom have clarified 3RR in response to
wiki-lawyering a couple of times now (even going so far as to define "a
revert", because certain individuals were trying to twist the English
language until they could argue they'd done nothing wrong).

> I'd like to propose the following exception to the 3RR policy:
>
> Exception:
>
> Lack of warning
>
> A 3RR ban cannot be imposed against an editor who has not been warned that
> he or she is in danger of violating the 3RR. A ban can only be imposed when
> an editor violates the 3RR after receiving a warning even if he or she has
> already tecnically violated the 3RR prior to receiving a warning.

Good grief, no.

I agree that the 3RR should not be used as a "gotcha".  Users who were
not aware of 3RR should not be severely punished for their ignorance.  I
try to avoid blocking "for the 3RR" in the first place --- we use blocks
to put a halt to edit wars, and this may be done whether 3RR comes into
play or not.

New users can't be expected to know about 3RR, but they sure as hell
ought to know how not to be a dick, and that includes not edit-warring.
  A *short* "time out" block and a note that there's a page at
[[WP:3RR]] which prescribes the absolute maximum number --- but remember
a 3RR violation is sufficient but not necessary for a block --- of
reverts per day works fine, for editors normally willing to play nicely
with others. who just got carried away and went too far in one instance.

I don't like the practice of "aha!  3RR!  Now you'll be blocked!"  I
don't like blocking without warning.   I don't like revert warring.  I
don't like obnoxious editing practices.  Believe it or not, there's a
manner in which an admin can behave without any of these things I ---
and I assume you --- dislike being allowed to occur.  It's called *using
his damn brain*.

If an admin is making poor decisions, then that admin needs to be
counselled on how to be a better admin (or, if worst comes to worst,
de-sysopped).  Don't remove the flexibility of current Wikipedia
practices and inflict even more complex and unnecessary rules on all
editors and admins for the sake of a couple who don't know what they're
doing --- teach the ones who are wrong, instead.

We *do not* need *more* policy.

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


from_name: Brion Vibber

body:
Nathan Carter wrote:
> The fact of the matter is what is the foundation's procurement policy?
> IMHO WMF should look at open-source stuff first but if it is not
> suitable then look at proprietary stuff.
> Did you look at sourceforge? I am sure there is some CRM software there.

Such as: http://sourceforge.net/projects/sugarcrm ?

For this conversation to progress usefully, we need to know the answer to this
question:

What does the proprietary version of SugarCRM Professional support that:
a) the open-source version does not
*and*
b) we actually need
?

If there's something specific, we might have a hope of actually comparing
alternatives. As it is, we've got an experimental internal installation of the
*open-source* SugarCRM for those who would be using it to figure out whether
they can make it do what they need.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/foundation-l/attachments/20060625/158822a4/attachment.pgp


body:
Nathan Carter wrote:
> The fact of the matter is what is the foundation's procurement policy?
> IMHO WMF should look at open-source stuff first but if it is not
> suitable then look at proprietary stuff.
> Did you look at sourceforge? I am sure there is some CRM software there.

Such as: http://sourceforge.net/projects/sugarcrm ?

For this conversation to progress usefully, we need to know the answer to this
question:

What does the proprietary version of SugarCRM Professional support that:
a) the open-source version does not
*and*
b) we actually need
?

If there's something specific, we might have a hope of actually comparing
alternatives. As it is, we've got an experimental internal installation of the
*open-source* SugarCRM for those who would be using it to figure out whether
they can make it do what they need.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/foundation-l/attachments/20060625/158822a4/attachment-0001.pgp


body:
Nathan Carter wrote:
> The fact of the matter is what is the foundation's procurement policy?
> IMHO WMF should look at open-source stuff first but if it is not
> suitable then look at proprietary stuff.
> Did you look at sourceforge? I am sure there is some CRM software there.

Such as: http://sourceforge.net/projects/sugarcrm ?

For this conversation to progress usefully, we need to know the answer to this
question:

What does the proprietary version of SugarCRM Professional support that:
a) the open-source version does not
*and*
b) we actually need
?

If there's something specific, we might have a hope of actually comparing
alternatives. As it is, we've got an experimental internal installation of the
*open-source* SugarCRM for those who would be using it to figure out whether
they can make it do what they need.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikimedia-l/attachments/20060625/158822a4/attachment.pgp>


body:
Nathan Carter wrote:
> The fact of the matter is what is the foundation's procurement policy?
> IMHO WMF should look at open-source stuff first but if it is not
> suitable then look at proprietary stuff.
> Did you look at sourceforge? I am sure there is some CRM software there.

Such as: http://sourceforge.net/projects/sugarcrm ?

For this conversation to progress usefully, we need to know the answer to this
question:

What does the proprietary version of SugarCRM Professional support that:
a) the open-source version does not
*and*
b) we actually need
?

If there's something specific, we might have a hope of actually comparing
alternatives. As it is, we've got an experimental internal installation of the
*open-source* SugarCRM for those who would be using it to figure out whether
they can make it do what they need.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikimedia-l/attachments/20060625/158822a4/attachment-0001.pgp>


body:
On 6/25/06, Jay R. Ashworth <jra at baylink.com> wrote:
> On Sun, Jun 25, 2006 at 07:22:53PM +0200, Steve Bennett wrote:
> > > We do, however, quite often want source code in our articles.
> >
> > And it would probably be appropriate to have a good way of doing that.
> > Source code doesn't necessarily demand lack of line wrapping.
>
> It doesn't?
>
> Certainly there are languages in which wrapping a line breaks the
> syntax; the Bourne Shell is only the first one that comes to mind...

I vaguelly recall that this conversation started with the comment that
-- should not be converted to em-dash for C source code.

Anyway, any time you don't want wrapping, there's <nobr> for that.
But in any case, I don't think the syntax/meaning of space indentation
is likely to change, so this is a bit moot.

Steve


body:
On 6/25/06, Jay R. Ashworth <jra at baylink.com> wrote:
> It's a topic I'm close to, because my instinct is to want to render
> standard typesetting as closely as possible in ASCII, but I just can't
> bring myself to set ASCII em dashes--you know, these things--without
> the surrounding spaces -- even though that's how I see them set in
> type.

Weird, I tend to use hyphens with spaces - like this - to achieve that effect.

Steve


subject: [WikiEN-l] Spoiler Boilerplates

body:
On 6/25/06, Zero <megamanzero521 at yahoo.com> wrote:
>  To whom's decision...? It is censorship. It thrives upon the ideal of a  person perhaps not engaging in the action by merit of another group  selectively in the belief they think it might be "cover-worthy", which  is never the case in any encyclopedia.

You're totally losing me. Not only are templates that give the reader
a way of opting out of some content "censorship", but encyclopaedias
are never selective about their content?

>  In view of "not all encyclopedias are the same", you lost me there.  That's an interesting comparison. I suppose you'll say then that the  implementation of a template derived from the ideal of a networking  site is appropriate in any encyclopedia. There's no need to  differientiate; encyclopedias may focus on

And apparently also I think that any template derived from a
myspace.com-like site would be appropriate at Wikipedia?

>doesn't  change the spirit. An encyclopedia's definition is
universal- to give
>information and leave the responsibility of "handeling dangerous
information" to
>the reader. When one embarks upon the knowledge   pot known as an

I don't think that's true. Encyclopaedias have editors, who make all
kinds of "editorial decisions". They're certainly not open-slather
"all information is good information" repositories.

>encyclopedia (wherever or however it may be) those lads  take it upon
themselves
>to make the decision to  enlighten  themselves in  any capacity. As neutral
>editors, I don't see how  that decision become  our concern. We build an
>encyclopedia, not  selctively dictate who might or might not view it
on a personal
>whim. -  Zero

How a spoiler or porn-warning template amounts to "dictating who might
or might not" read our encyclopaedia is beyond me. In all likelihood,
by including obscene material, we are more likely to be cutting off
whole classes of readers for whom the material is too risky - school
classrooms, for instance. The same applies, to a lesser extent, for
spoilers - the very people most likely to read our articles on books
or movies are those likely to avoid doing so out of fear of being
"spoilt".

Your arguments about censorship just seem totally misplaced here.

Steve


subject: [WikiEN-l] New York Times article

body:
G'day Conrad,

> * Kat Walsh wrote:
>>On 6/17/06, geni <geniice at gmail.com> wrote:
>>>since when have admins had "authority to exercise editorial control"?
>>
>>I'm particularly disappointed by that statement, considering I spent a
>>fair bit of effort in the interview explaining how and why they don't.
>
> In my opinion this is slowly becoming little more than a fiction we tell
> ourselves. Recently an admin labeled a user changing his wording of, "Some
> conspiracy theorists disagree..." to "Some disagree..." as "vandalism" and
> placed a 48 hour block after edit warring with the user (and others) over
> this phrase.

Admins *don't* have the authority to exercise editorial control (with
the caveat that we won't call preventing someone from replacing the text
with "poop", "exercising editorial control"), or at least, to exercise
more control than any other editor.  The admin you cite was, on the face
of it, exceeding his authority.

Of course, we don't know the full story.  It could be the editor was an
obnoxious so-and-so who'd been cutting a swathe through Wikipedia,
vandalising and POV-pushing, and when he seemed to be about to re-write
our article on New World Order to make all those loony right-wing
Americans seem less loony, the camel gave one hell of a scream as it
felt its long-suffering back finally break.  Or perhaps not.

It seems to me we have two equally obnoxious sides to the "bad admin"
question.  One takes the view that admins can do no wrong, and resists
any push --- within the admin community or without --- to help those of
us who need to clean up our acts to do so.  This is obviously Harmful,
with a capital 'H', no less.  This side never refers to admins by name,
doesn't want to embarrass anyone.  Doesn't try to improve the conduct of
individual admins, because then the trolls will win.

The other side sits on the sidelines and laughs at us.  This side never
refers to admins by name, either: if those few admins who misbehaved
were encouraged to improve (or even de-sysopped), then this side would
no longer have anything to criticise.  This side enjoys criticising the
status quo so much that it would never *dream* of actually doing
anything likely to make things better for Wikipedia, or the community
that supports it.

Now, it's obvious to anyone that refusing to accept criticism, refusing
to change in the face of clear evidence that we're wrong, etc., is a
terrible way to conduct our affairs.  It's not quite so obvious that
pointing to unspecified inappropriate behaviour and the unnamed admins
who encourage it and saying "tut, tut" without making any effort to do
anything about the problem is also pretty terrible.

<snip />

> So what do you suppose came of it?
>
> When the user put the 'unblock' template on their page it was denied by
> another admin who was involved in the same edit war and then the user's
> talk page was protected by yet another admin to prevent them from
> requesting unblock again. And when his objection was raised at AN/I? Yet
> more admins lined up to say that the action was entirely proper. All this
> against a user who has been on Wikipedia for nine months (~350 edits) and
> never been blocked or cited as a 'troublemaker' before.

I see.  Do you have a link?

> We SAY that admins do not have authority to exercise editorial control,
> but, given the fact that we don't enforce it, the reality is quite different.
>
> I think the blocking admin's message to the user illustrates how far lost
> the 'no editorial control' concept has become;
>
> "If unblocked and you revert me one more time, I'm going to block you for
> a week."
>
> Those are words that NO admin would ever be able to utter if the principle
> you cite above had ANY meaning. But the fact is that a dozen other admins
> looked on and said that it was just fine.

And what did you do about it?  Did you say "no, this is not appropriate.
  This was plain-jane edit warring, and should be treated as such.
Admins should never use their admin powers in an edit war, nor should
they call non-vandalism edits 'vandalism' to justify a block."  Did you
say anything at all?  If you piped up at all, was it to make a comment
like my suggested one, or did you make one more of the sort you've
become famous for --- like the one in your email to the list?

We have damn near a thousand admins now.  Some of them are becoming
admins without even knowing what adminship is all about.  Others have
become too caught up in the tougher admin jobs, and become jaded.  A
couple (and this one irritates me) feel they have the support of ArbCom
regardless of what they do (whether ArbCom agrees or not is a different
story), and feel they have no reason not to do as they please.  Overall,
considering the sheer number of admins involved, I think we can be
pleased that very, very few of them are bad admins.  But when we come
across an example of an admin misbehaving, we should be either trying to
improve their behaviour, or stripping them of adminship until we can
trust them with the extra tools and the inevitable (but unfortunate)
increase in status.  Clucking that everything's broken isn't going to
improve the lot of Wikipedia's admins, nor that of the Wikipedians who
are forced to put up with them.

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


body:
On 6/25/06, Jay R. Ashworth <jra at baylink.com> wrote:
> On Sun, Jun 25, 2006 at 08:47:37PM +0200, Andrew Dunbar wrote:
> > > <snob type=typography>
> > > Em dashes are properly set in English text without spacing on either
> > > side, though the ASCIIography of this usage is much less picky.
> >
> > Can you provide a reference for this? Also can you be
> > sure this is the only style and that it doesn't vary by
> > style guide, by publisher, by country, by newspaper vs
> > novels, etc.
>
> A formal reference?
>
> No; not off hand.
>
> Just personal experience from 35 years or so of reading American
> typesetting, and at least 15 years of paying professional attention
> thereto.

I ask for a reference because I've seen people say that
serial commas (also known as Harvard commas or
Oxford commas) are correct or incorrect whereas in that
case it does turn out to depend on region, publisher, etc.
but people wrongly assume there is a global rule.

> > The reason I ask is that I've been studying casually how
> > they are typeset in books as part of my thinking about
> > an XML format for e-texts. I have seen so many cases
> > both with and without spaces that I've been pondering
> > whether it would best be handled as a style issue.
>
> You've seen commercial typesetting (that is, typesetting done by
> typographers, not computer scientists :-) that put full spaces around
> em-dashes?

I can't say for sure whether they were full spaces or half
spaces. I do have books from several countries, several
eras, and several languages nearby though so I'll try to
look through some in the coming days for you.

> I'd be interested in references myself, if you could lay hands on any.
>
> It's a topic I'm close to, because my instinct is to want to render
> standard typesetting as closely as possible in ASCII, but I just can't
> bring myself to set ASCII em dashes--you know, these things--without
> the surrounding spaces -- even though that's how I see them set in
> type.

I'm interesting in typesetting variations like these so that I
can normalize e-books to be parsable by machine etc
and then perhaps come up with a simple xml dtd that
takes as many typing variations existing in plaintext files
and turns them into a single standard markup or declaration
leaving presentation to styles where it belongs.

Andrew Dunbar (hippietrail)

> 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
>
>     A: Because it messes up the order in which people normally read text.
>     Q: Why is top-posting such a bad thing?
>
>     A: Top-posting.
>     Q: What is the most annoying thing on Usenet and in e-mail?
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>

--
http://linguaphile.sf.net


subject: [WikiEN-l] semi-stuff (was Re: New York Times article)

body:
G'day Steve,

> Maybe others see things differently, but I do not feel a massive
> influx in people contributing raw, valuable text to our encyclopaedia,
> which is something we're quite short of. We have lots of people
> joining us to help delete, categorise, clean, or write about their own
> pet topic - but do we really have so many helping to expand on our
> existing topics?

I agree.  Heck, in some cases I see the same *name* (singular) editing
an area of the encyclopaedia with me.

There's also the issue that an editor's "own pet topic" tends also to be
the "own pet topic" of thousands of other people.  There's very few
people who are fascinated by the mating habits of gibbons and *also*
want to spend hours working on Wikipedia, but there's an imperial
truckload (that's more than a metric truckload, for those wondering) of
people who want to talk about trains.  Not all pet topics are equal.

Cheers,

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


subject: [WikiEN-l] Oversight log

body:
G'day Mark R,

> But that is beside the point. It still hasn't been explained why the
> Arbitrators were selected as the main repositories of these powers.
> Does the removal of revisions crop up frequently in arbitrations
> undertaken by the ArbCom? Or has the ArbCom somehow morphed into
> something more than an Arbitration Committee, to be some sort of
> Content Management Committee?
>
> The Concise Oxford English Dictionary defines 'arbitrator' as "an
> independent person or body officially appointed to settle a dispute".

I suspect it was at least partly because of the precedent of checkuser
being given to the more technically-minded arbitres.  As such, it would
be a classic case of always-logical steps which nonetheless lead us away
from our original intent.

I think we should keep limits on the power of ArbCom, not least for the
peace of mind of the arbitres themselves.  They --- I assume --- don't
want to end up being the go-to guys any time someone is required to
exercise power on Wikipedia.  If this goes on, it could lead to arbitres
being required to accept an awesome amount of responsibility --- more
than they currently hold, and more than they signed up for.

But one could ask "if not them, then who?"  Well, in the specific case
of Oversight, why not bureaucrats?  After all, it's harder to become a
bureaucrat than it is to serve on ArbCom, which should give some
indication of the level of community trust held there.  It's also often
been pointed out that, given the difficulty in becoming a bureaucrat,
the actual difference between a B and an admin is very little.

Cheers,

--
Mark Gallagher
"I was neat, clean, shaved and sober, and I didn't care who knew it."
(Raymond Chandler, /The Big Sleep/)


subject: [WikiEN-l] Oversight -- Really new or not?

body:
G'day Michael N,

> On 6/23/06, Michael Bimmler <mbimmler at gmail.com> wrote:
>
>>On 6/23/06, Lord Voldemort <lordbishopvoldemort at gmail.com> wrote:
>>
>>>Yet. To quote Saw2 "Oh yes, there will be blood."  (But not really,
>>>desysopping won't physically harm anybody...
>>
>>Sure. But desysopping somebody needs less time/skills than preparing a
>>legal action against him ;-) (and it's something against which he
>>cannot file an appeal)
>
> You're wrong there; our villain will be able to file an appeal with ArbCom;
> they'll laugh at him, but he will be able to appeal.
>
> Actually, that's an interesting question; presuming we ever identify the
> Wikitruth admin(s), will it stop at summary desysopping, or do we expect
> that they will also be community banned?

De-sysopping for certs: we have no need for untrustworthy admins.  As
for community banning, well; wouldn't it be more interesting to find out
what upset this person in the first place?  Assuming they aren't a mole
out to prove how easy it is to become an admin (this has been planned
many times), they presumably aren't your standard Wikitruth "I went
there and made a dick of myself and they objected for some reason"
troll.  It would be nice to know what happened to this person that they
betrayed us, partly to prevent anyone else doing the same, but mostly
because improving the experience of anyone editing Wikipedia in good
faith is a Good Thing to aim for.

Cheers,

--
Mark Gallagher
"But the visibility was very poor, and you yourself admit that you were
being struck by thunderbolts all the time, which must have distracted
your attention, so it is more than probable you were mistaken."
- Esmond Haddock, /The Mating Season/


from_name: Andrew Gray

subject: [WikiEN-l] Offline submissions?

body:
According to the WikiProject Countering Systemic Bias, "The average
Wikipedian on English Wikipedia (1) is male, (2) is
technically-inclined, (3) is formally educated, (4) speaks English to
an extent, (5) is White , (6) is aged 15-49, (7) is from a
predominantly Christian country, (8) is from an industrialized nation,
and (9) is more likely to be employed in intellectual pursuits than in
practical skills or physical labor."

The problem with this is the unfortunate gap in coverage that results
from a lack of interest from the typical demographic of Wikipedians
described above. While this demographic is definitely interested in
contributing to a free, online encyclopedia, that doesn't mean the
others aren't. One particular problem is that in order to contribute
to Wikipedia, you'll need to use a computer. There are others who
would probably be interested in contributing to our global effort,
too, but don't understand technology. We need to allow them to
contribute.

For that purpose, I would like to start a project where people without
access to computers (or people who voluntarily choose not to use them)
can -write- their own Wikipedia entries and mail them in. The first
phase of this plan, of course, would be spreading the word. The least
expensive way would probably be distributing fliers in frequented
areas. People could then write their own articles, and mail them in to
the Wikimedia Office. Someone at the office (maybe Monica?) could open
the letters, scan them in, and email them to an offline submissions
mailing list. From there, people interested in the project would
transcribe the article into Wikipedia (if applicable, see below) and
mail back a corresponding letter featuring a print-out of the new
article. Very simple process, plus it would allow people from
non-typical-of-Wikipedia-editor backgrounds to put in their word.

What if their entry is redundant? Not to worry. If the written
submission has content the Wikipedia article doesn't, we add it in. If
it doesn't, that's okay. We don't necessarily have to tell them what
made it in and what didn't, but either way, a reply will be sent to
the writer with a print-out of the article.

----

I'm passing the above on for en:User:Messedrocker, since he's not
subscribed to the list. My thoughts:

a) This has certainly been done before on a local level with minor
languages - was it in West Africa somewhere? My mind is failing me,
but I've certainly seen it mentioned on wikipedia-l before - the
writing was done by a local elder, transcribed and put online by a
volunteer.

b) It might well work, but would probably require careful thought and
planning - who are we targeting? what sort of articles are we
targeting them for? how do we deal with unwanted and inappropriate
submissions without causing more badwill than we started with?

c) Copyrights. This might get fun.

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


subject: [WikiEN-l] Oversight log

body:
G'day jayjg,

> On 6/23/06, Mark Ryan <ultrablue at gmail.com> wrote:
 >
>>22:17, 23 June 2006 Jimbo Wales removed a revision (ID #123456789).
>>Reason given was: "Personally identifiable information"
>>
>>Any reason why that is unacceptable?
>
> Of what benefit would that information be, and to whom?  What would
> the subsequent action be, some editor saying "why did Jimbo remove
> that revision on June 23"?  He's already said why, Personal
> Information.  This suggestion would just turn the log into a fishing
> expedition for distrustful editors.

If Jimbo is using the Oversight power ten times more often than any
other person with Oversight privs, that's something I'd like to know.

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


subject: [Wikitech-l] Zwinger down

body:
Our old central workhorse server Zwinger developed disk errors tonight and is
now offline awaiting repair or replacement.

The only user-visible disruption that I'm aware of is that our Ganglia
load-reporting graphs are temporarily offline. DNS failover appears to have
worked fine, and another server has been pulled over for that duty.

Though various services have been spun off over time, Zwinger's been a central
part of our cluster for nearly two and a half years. Let's all wish him luck for
his surgery.

(Zwinger was named for http://en.wikipedia.org/wiki/Theodor_Zwinger )

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20060625/cf58fa19/attachment.pgp>


subject:
[WikiEN-l] Category:<Subjective-pejorative>, weak consensus,
 and ! NPOV

body:
G'day Steve,

> --- Mark Gallagher
> <m.g.gallagher at student.canberra.edu.au> wrote:
>
>>WP:POINT doesn't trump WP:NPOV, and I never said it
>>did.  One is a core
>>principle, the other is a page which, like many of
>>our policies, acts
>>only to restate "don't be a dick" in more socially
>>acceptable language.
>>Now, there are multiple ways of making a point.
>>Some of them involve
>>being a dick.  You appear to be choosing one of
>>those ways, as WP:POINT
>>makes clear.  It would be nice if you could restrain
>>yourself.
>
> No, WP:DBAD uses unsuitably dickish language itself
> and thus had to be removed to meta. In the hierarchy

Well, that's one interpretation.

> its probably lower than {{proposed}}, though the
> typically dickish citing of it would leave newbies to
> believe otherwise. Please dont mistake casual
> terseness for dickishness. I certainly dont.

It's an easy mistake to make.  In any case, a campaign to add a category
you know is inappropriate to certain articles is hardly "casual
terseness"; it's disrupting Wikipedia to make a point, and being a dick
besides.

<snip: okay/>

>>You think the category is incompatible with NPOV.  I
>>think you're right.
>>  There are those, however, who do not (or who have
>>not considered the
>>issue, and gone along with the cat because it's
>>there). There are two
>>ways for you to get your way: you can either
>>convince them you're right,
>>or you can grind their faces into dust.  Now, you're
>>not in much of a
>>position these days to do any face-grinding, so
>>we're just left with the
>>former option.
>
> Dont make this personal. This seems to be a rarer

Fair enough.  It wasn't really called for, was it?  Bit childish of me,
there.

> case, and this is why I brought it to the list. The
> basic point is that "consensus" only works if its
> overwhelmingly in one direction or another, and (as I
> think Cobb was alluding to) AFD doesnt always work as

What Cobb was alluding to --- always and only --- is his inability to
get all fancruft deleted immediately.

> a discussion forum. Where there are sharp divides
> between actual consensus and NPOV, speaks to a deeper
> issue of leadership with regard to NPOV, and this
> relates to the problem of newbie indoctrination.

Fair enough.

>>The traditional approach taken when trying to change
>>someone else's mind
>>is, "your opinion differs from mine.  How can I best
>>state my message to
>>convince you I'm right?"  The approach *you* are
>>taking is, "your
>>opinion differs from mine.  How can you be *so
>>stupid* as to disagree
>>with me?  Can't you idiots see the bleeding obvious?
>> I'm disgusted with
>>the lot of you!"
>
> I was simply stating my case in a clear and
> incontrovertible way. I dont see the need to make an
> argument weak just for sake of endless discussion with
> those who hold to a relativist position, or to appease
> those, who fail AGF and assume dickishness where there
> is none. I dropped a note, to bring some attn to it.

What you see as "making an argument weak" I see as trying not to get
those you're trying to convince off-side.

Of course, I'm guilty of the same thing, here.  I see someone say "why
are you too STUPID to disagree with me?", and I reply "that's obviously
a counter-productive approach.  Why are you too STUPID to listen to my
alternative?"

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


subject: [WikiEN-l] "Good authors"

body:
On 6/22/06, Jimmy Wales <jwales at wikia.com> wrote:
> The Germans have it right, in my opinion, on their homepage:
> "Gute Autorinnen und Autoren sind stets willkommen."
>
> "Good authors are always welcome."

The opposite of a good author is a bad author. What kind of person
regards themselves as a bad author _and_ will happily accept an
introduction like this as a good reason not to participate? I don't
think it's the bad authors, school children and trolls we have to deal
with on a regular basis. I think it's more likely to be people who
lack self-worth and confidence, and who will be turned away, and will
never try editing Wikipedia for fear of being shouted at. Many of
these people could become excellent contributors: not all areas of
Wikipedia require a thick skin.

If an _actual_ bad author is going to be turned away by a message like
that, I think they are likely to be the kind of person we could
reform, and turn to areas of Wikipedia where they could be productive.
After all, they have listened to reason.

We have a history of being welcoming to _everyone_, and to then
examine their track record, to assist them in improving their
contributions, or to remove them from the project. I also believe that
becoming a "good author" on Wikipedia takes a lot of learning of both
the social and the technical dimension of the project. It's not
something which you _are_ when you visit the site for the first time.
A knowledgeable person might be completely incapable of reaching
consensus, and a dyslexic might be well aware of their problem, and
focus on pictures or policies.

Jimmy, I may be wrong, but I suspect the notion above reflects your
desire for Wikipedia to be seen (correctly) as elitist by the media,
rather than a free-for-all. As you said in an interview with the
Christian Science Monitor, "I think Wikipedia is extremely elitist.
We're a bunch of snobs. But it's an elitism of productive work, it's
an elitism of results."

These were very wise words. However, an elitism of results is not in
conflict with being welcoming to everyone we don't know yet. Indeed,
it requires it.

Erik


from_name: Rob Church

subject: [Wikitech-l] Mass open proxy blocking

body:
On 25/06/06, Simetrical <Simetrical+wikitech at gmail.com> wrote:
> Clever.  Stewards were always able to combine the flags, it's just
> Rob's MakeBot that imposed the additional restriction, but of course
> that has no control over whether the standard bureaucrat extension can
> add sysop to any user at all.

No, but a future improved version of MakeSysop (or preferably a better
user rights management extension) might ensure the reverse. :)

> Well, there my knowledge of the situation ends, so I'll leave that to
> the devs.  I couldn't find a feature request at
> http://bugs.wikimedia.org/, which is where they generally go, but I
> could easily have missed it.

We have support for blocking open proxies and stuff according to the
SORBS DNSBL. Whether we want to re-enable it is another matter.

Rob Church


from_name: daniwo59 at aol.com

body:
I have to agree with much of what Erik is saying here as well. The key
statement for me is "there are of course areas where open source software  cannot
(yet) compete." In response the software package being examined is the  most
open of those available which meets the Foundation's specific needs.

For those who are not in the know, these needs are threefold: 1) donor
management, 2) press management, and 3) volunteer management (i.e., building a
database of volunteers with specific skills and circumstances, who can respond
to specific tasks, such as a request to interview someone who specializes in
classical music, or someone who has a flatbed scanner at home). Other needs
will  likely be identified over time as well. We need a package that can handle
all of  the above--the package being examined can do that--and it is generally
open  source. In fact, the propritary part is the privacy component, which
means  that confidential information about donors and volunteers will not be
accessible  to anyone with an internet connection.

I do not think it lies within the scope of our mission to provide financial
support for the development of free software alternatives, but I  generally
accept Erik's other points, particularly that a partially  proprietary solution
is preferable to a fully proprietary one. I would add,  however, that we
should not compromise on the quality of our solutions.

Danny

In a message dated 6/25/2006 12:58:29 PM Eastern Daylight Time,
eloquence at gmail.com writes:

I won't  comment on the specific question, but on the underlying
Wikimedia policy  issue.

The Board can decide the policy for software use by the  Foundation.
What would a sensible policy look like? I think an a priori  "open
source[*] only" policy is problematic since there are of course  areas
where open source software cannot (yet) compete.  For instance,  I'm
not aware of a professional open source optical character  recognition
(OCR) solution, which is crucial for  digitization.

However, we do need to be aware of the risks of  proprietary software:
vendor lock-in, company bankruptcy, no code  availability for security
auditing, and so on. Aside from that, supporting  open source is an
important matter of outside perception for the  Foundation.

How about a policy that states:
- when no adequate (as  determined by its prospective users) 100% free
software solution for a task  can be found, a proprietary solution may
be used.
- such use needs to be  reported and documented in a list of
proprietary software used by the  Foundation, so that the decision can
be debated and challenged by the  community.
- in such cases, a partially proprietary solution is preferable  to a
fully proprietary one.
- a migration plan should be made as soon as  a realistic fully open
source alternative emerges.
- the Foundation  should, within its budget, support the development of
such an  alternative.

Does that make sense?


subject: [Wikitech-l] Poem extension on Wikisource

body:
I'm just going to play devil's advocate one last time here then shut up.

On 6/25/06, Brion Vibber <brion at pobox.com> wrote:
> Let me summarize what <poem> does, how, and why. <poem> does two things:
>
> 1) It *modifies the behavior* of wiki syntax within its borders to preserve line
> breaks and initial whitespace in a different way from general text.

That sounds like a useful thing in many situations other than poetry.
I'll stipulate a <preserveformatting> tag.

> 2) It *marks* the contents with a distinct style class ('poem') which allows
> distinct styling to be applied to all <poem>s via the global style sheet.

...which could be wrapped in a <div class="poem"> tag via a {{poem}} template.

The one thing I notice is we don't have a good way with dealing with
blocks of text. {{temp-start}} / {{temp-end}} templates are apparently
deprecated, and {{temp|huge block of text that covers several lines
and includes tables, templates and all manner of crud}} templates have
limitations. Does this mean that the only way to create new block
elements  (like poems, recipes, source code...) is by defining new
elements in the Wiki-markup language itself? That seems like a pity.

Steve


subject: [WikiEN-l] "Good authors"

body:
On 6/25/06, Erik Moeller <eloquence at gmail.com> wrote:
> On 6/22/06, Jimmy Wales <jwales at wikia.com> wrote:
> > The Germans have it right, in my opinion, on their homepage:
> > "Gute Autorinnen und Autoren sind stets willkommen."
> >
> > "Good authors are always welcome."
>
> The opposite of a good author is a bad author. What kind of person
> regards themselves as a bad author _and_ will happily accept an
> introduction like this as a good reason not to participate? I don't
> think it's the bad authors, school children and trolls we have to deal
> with on a regular basis. I think it's more likely to be people who
> lack self-worth and confidence, and who will be turned away, and will
> never try editing Wikipedia for fear of being shouted at. Many of
> these people could become excellent contributors: not all areas of
> Wikipedia require a thick skin.

How about "New editors always welcome!" - then, the assumption is that
we will give *anyone* a *chance* (as opposed to implying that we will
let anyone edit, no matter how destructive they are).

> We have a history of being welcoming to _everyone_, and to then
> examine their track record, to assist them in improving their
> contributions, or to remove them from the project. I also believe that
> becoming a "good author" on Wikipedia takes a lot of learning of both
> the social and the technical dimension of the project. It's not

IMHO being a "good author" is irrelevant. Perhaps it comes from the
German translation, but one's "authoring" skills aren't really
important, if one is adding images, reordering categories, performing
any manner of maintenance etc. Hell, even a "bad author" who is adding
useful information is useful - we have copyeditors to clean up
afterwards.

> Jimmy, I may be wrong, but I suspect the notion above reflects your
> desire for Wikipedia to be seen (correctly) as elitist by the media,
> rather than a free-for-all. As you said in an interview with the
> Christian Science Monitor, "I think Wikipedia is extremely elitist.
> We're a bunch of snobs. But it's an elitism of productive work, it's
> an elitism of results."

We're not elitist at all. The tone of most of our articles is very
folksy and approachable, and our massive predilection for pop culture,
over history or literature should put paid to that theory. It's rare
to see two academics arguing over a substantitive issue on a difficult
topic. Most of the arguments are emotional or territorial.

Steve


from_name: James Hare

body:
Mr. Wool,

I don't care if you use AOL, but such a database would be the best thing
ever. This way, we have people within the foundation that are easily
contactable in the event the Wikimedia Foundations needs... say... a
60-year-old privacy activist. For the record, I have a flatbed scanner that
also functions as a photocopier (color and b&w) and a printer.

On 6/25/06, daniwo59 at aol.com <daniwo59 at aol.com> wrote:
>
>
> I have to agree with much of what Erik is saying here as well. The key
> statement for me is "there are of course areas where open source
> software  cannot
> (yet) compete." In response the software package being examined is
> the  most
> open of those available which meets the Foundation's specific needs.
>
> For those who are not in the know, these needs are threefold: 1) donor
> management, 2) press management, and 3) volunteer management (i.e.,
> building a
> database of volunteers with specific skills and circumstances, who can
> respond
> to specific tasks, such as a request to interview someone who specializes
> in
> classical music, or someone who has a flatbed scanner at home). Other
> needs
> will  likely be identified over time as well. We need a package that can
> handle
> all of  the above--the package being examined can do that--and it is
> generally
> open  source. In fact, the propritary part is the privacy component, which
> means  that confidential information about donors and volunteers will not
> be
> accessible  to anyone with an internet connection.
>
> I do not think it lies within the scope of our mission to provide
> financial
> support for the development of free software alternatives, but
> I  generally
> accept Erik's other points, particularly that a partially  proprietary
> solution
> is preferable to a fully proprietary one. I would add,  however, that we
> should not compromise on the quality of our solutions.
>
> Danny
>
> In a message dated 6/25/2006 12:58:29 PM Eastern Daylight Time,
> eloquence at gmail.com writes:
>
> I won't  comment on the specific question, but on the underlying
> Wikimedia policy  issue.
>
> The Board can decide the policy for software use by the  Foundation.
> What would a sensible policy look like? I think an a priori  "open
> source[*] only" policy is problematic since there are of course  areas
> where open source software cannot (yet) compete.  For instance,  I'm
> not aware of a professional open source optical character  recognition
> (OCR) solution, which is crucial for  digitization.
>
> However, we do need to be aware of the risks of  proprietary software:
> vendor lock-in, company bankruptcy, no code  availability for security
> auditing, and so on. Aside from that, supporting  open source is an
> important matter of outside perception for the  Foundation.
>
> How about a policy that states:
> - when no adequate (as  determined by its prospective users) 100% free
> software solution for a task  can be found, a proprietary solution may
> be used.
> - such use needs to be  reported and documented in a list of
> proprietary software used by the  Foundation, so that the decision can
> be debated and challenged by the  community.
> - in such cases, a partially proprietary solution is preferable  to a
> fully proprietary one.
> - a migration plan should be made as soon as  a realistic fully open
> source alternative emerges.
> - the Foundation  should, within its budget, support the development of
> such an  alternative.
>
> Does that make sense?
>
>
>
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>


from_name: Sabine Cretella

subject: [Wikitech-l] '' again ...

body:
Well, up to some days ago a link like the following worked:

[[Categoria:Storia d#&39;#&39;e canzone napulitane]]

Now it does not work anymore ...

Was there something changed in the software?

I need that double '' in some way ...

Thanks, Sabine
Chiacchiera con i tuoi amici in tempo reale!
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com


subject: [Wikitech-l] [Fwd: '' again ...]

body:
Sorry, my fault ... it works - of course it must be '

Ciao, Sabine

-------- Original-Nachricht --------
Betreff: 	'' again ...
Datum: 	Mon, 26 Jun 2006 00:05:38 +0200
Von: 	Sabine Cretella <sabine_cretella at yahoo.it>
An: 	Wikimedia developers <wikitech-l at wikimedia.org>

Well, up to some days ago a link like the following worked:

[[Categoria:Storia d#&39;#&39;e canzone napulitane]]

Now it does not work anymore ...

Was there something changed in the software?

I need that double '' in some way ...

Thanks, Sabine

Chiacchiera con i tuoi amici in tempo reale!
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com


subject: [WikiEN-l] Offline submissions?

body:
On 6/25/06, Andrew Gray <shimgray at gmail.com> wrote:
> For that purpose, I would like to start a project where people without
> access to computers (or people who voluntarily choose not to use them)
> can -write- their own Wikipedia entries and mail them in. The first
> phase of this plan, of course, would be spreading the word. The least

IMHO, there are so many people out there with so much to contribute
who fall outside our other key demographics but *do* have access to
email that deliberately targeting the most difficult hurdle for us is
just making extra work. Simply targeting the right people (retired
academics stand out as ideal: intelligent, educated, experts in
obscure fields, and with time on their hands) and motivating them to
write an article would already reap benefits. Why pick out the few
people left who have zero access to the internet (not even 10 minutes
a week, not even sending an email on their grandkid's computer)? And
how is such a person going to write an article anyway? Writing it by
hand? On a typewriter? It seems a little bit fanciful...

I know I sound like a wet blanket, but I really do believe in
expanding our reach, and deliberately advertising for new
contributors. Aiming for those without email access sounds like making
life difficult for ourselves though.

Steve


from_name: brion at pobox.com

subject: [Wikitech-l] MediaWiki automated test run failure 2006-06-26

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 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 Language converter: output gets cut off unexpectedly (bug 5757)... 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!

Passed 394 of 407 tests (96.81%) FAILED!


subject: [WikiEN-l] "Good authors"

body:
On 6/25/06, Steve Bennett <stevagewp at gmail.com> wrote:
> How about "New editors always welcome!" - then, the assumption is that
> we will give *anyone* a *chance* (as opposed to implying that we will
> let anyone edit, no matter how destructive they are).

I agree in principle that the slogan "the free encyclopedia that
anyone can edit" is overly simplistic. It reminds me of the famous
saying, "I would never want to belong to any club that would have
someone like me for a member." It's more of a technical definition
than one of principles and goals -- and can easily be confused with
the latter.

I believe that we need to highlight the mission of providing a great,
free encyclopedia, along with the core principle _how_ we want to
accomplish it. And the single most important principle I can think of
here is not "anyone can edit". It's not even NPOV or any other policy.
It's "WikiLove" -- of which our commitment to openness is only an
expression. We share a love of knowledge, and we treat everyone who
shares the same love with respect and goodwill. (That's the idea, at
least.)

If I wanted a three word slogan for Wikipedia, it would be something
like "Love in Knowledge": emphasizing the core principle of WikiLove
as well as the overarching goal to collect the sum of all human
knowledge. Come to think of it, "Love in Knowledge" might be a nice
slogan for the Wikimedia Foundation. Or is it too kitschy?

> We're not elitist at all. The tone of most of our articles is very
> folksy and approachable

I'm not sure about "folksy," but of course an encyclopedia should be
approachable. My idea of the perfect Wikipedia article is one which
presupposes very little, and allows me to zoom into any level of
detail which I require (following links and references to primary and
secondary sources if Wikipedia itself is exhausted). Naturally, by
"presupposing little", I don't mean that every concept needs to be
explained in every article: that's what links are for.

"Elitism of results", as Jimmy put it, doesn't mean to me that we
already believe that we've created the best encyclopedia in history.
It only means that we believe that we should, and more importantly,
that we can. And I think that these beliefs are firmly rooted in
Wikipedia's culture.

Erik


from_name: Anthere

subject: [WikiEN-l] Offline submissions?

body:
Andrew Gray wrote:
> According to the WikiProject Countering Systemic Bias, "The average
> Wikipedian on English Wikipedia (1) is male, (2) is
> technically-inclined, (3) is formally educated, (4) speaks English to
> an extent, (5) is White , (6) is aged 15-49, (7) is from a
> predominantly Christian country, (8) is from an industrialized nation,
> and (9) is more likely to be employed in intellectual pursuits than in
> practical skills or physical labor."
>
> The problem with this is the unfortunate gap in coverage that results
> from a lack of interest from the typical demographic of Wikipedians
> described above. While this demographic is definitely interested in
> contributing to a free, online encyclopedia, that doesn't mean the
> others aren't. One particular problem is that in order to contribute
> to Wikipedia, you'll need to use a computer. There are others who
> would probably be interested in contributing to our global effort,
> too, but don't understand technology. We need to allow them to
> contribute.
>
> For that purpose, I would like to start a project where people without
> access to computers (or people who voluntarily choose not to use them)
> can -write- their own Wikipedia entries and mail them in. The first
> phase of this plan, of course, would be spreading the word. The least
> expensive way would probably be distributing fliers in frequented
> areas. People could then write their own articles, and mail them in to
> the Wikimedia Office. Someone at the office (maybe Monica?) could open
> the letters, scan them in, and email them to an offline submissions
> mailing list.

Hello,

Just for the record, Monica is no more working for us. That let's Danny
to open the letters and scan the content. Then an automatic machine
could change it at least partially to electronic format. And others will
have the fix what should be fixed.

I am a bit perplex you call this the least expensive way...
Of course, Danny frankly has no time to do this at all. I suppose we
would have to hire students to be the interface... in all honesty, I
think it is very unpractical, in particular in a language where there is
already so much content. Most of the time, the article would have
changed and the new content would need to be integrated to the online
version. This would be very unpractical.

It has much more chance to work locally, in a rather little developped
language. Yes, your memory is good, it has been done, by Guaka, in
Bambara, a bit over a year ago. Guaka directly visited some elders and
picked up notes.

One of the reasons the editing system works is that it is very simple
and very quick.

  From there, people interested in the project would
> transcribe the article into Wikipedia (if applicable, see below) and
> mail back a corresponding letter featuring a print-out of the new
> article. Very simple process, plus it would allow people from
> non-typical-of-Wikipedia-editor backgrounds to put in their word.
>
> What if their entry is redundant? Not to worry. If the written
> submission has content the Wikipedia article doesn't, we add it in. If
> it doesn't, that's okay. We don't necessarily have to tell them what
> made it in and what didn't, but either way, a reply will be sent to
> the writer with a print-out of the article.

Additional costs. Who would support that ?

> ----
>
> I'm passing the above on for en:User:Messedrocker, since he's not
> subscribed to the list. My thoughts:
>
> a) This has certainly been done before on a local level with minor
> languages - was it in West Africa somewhere? My mind is failing me,
> but I've certainly seen it mentioned on wikipedia-l before - the
> writing was done by a local elder, transcribed and put online by a
> volunteer.

Yes. Btw, Guaka will be at Wikimania in Boston. If you go, you may
discuss this experience with him.

> b) It might well work, but would probably require careful thought and
> planning - who are we targeting? what sort of articles are we
> targeting them for? how do we deal with unwanted and inappropriate
> submissions without causing more badwill than we started with?
>
> c) Copyrights. This might get fun.
>


body:
G'day Cobb,

>>Mark Gallagher wrote:
>>Oh, yes?  I assume you have an example at the ready, because surely no-one
>>would have the gall to pull a statement like that out of their arse with
>>no proof of it being true.
>
> Proof about being wiki-stalked and hassled by organised groups?
>
> Are you actually stupid, or being deliberately stupid, or have you just
> woken up
> and don't know about the Wikiedia Review fiasco? Interested parties would
> like
> to know.

The people targetted by Wikipedia Review posters and Daniel Brandt were
not new editors who came across a part of Wikipedia where editorial
standards were lax and attempted to improve matters.  They also weren't
wiki-stalked or blocked for vandalism.  Do you actually know what the
big deal about WR *was*?  The offending Wikipedia Review members are not
the long-standing, representative Wikipedians you were talking about in
your last post.

If you're going to make mocking replies, please do so under less
fraudulent circumstances.  I have no doubt there are plenty of times
when you or any other poster here could attempt to trip me up; however,
if you're going to attempt such a thing, you can at least do so after
accurately representing the actual discussion, rather than brazenly
changing tack and then using insults to try to cover it.  That's a hack
trick, and a clumsy one.

> Do you think WR are alone, or just the most high-profile?

Wikipedia Review are definitely not alone.  This is in part a
consequence of our size and influence on the Internet (we attract the
less stable elements of society), but also partly because of the way we
treat some users (disaffected users attracted by the chance to discuss
"what's wrong with Wikipedia").  However, they and their ilk (Brandt's
"people who I think were mean to me" Hive Mind project and "people I
want to be mean to" Hive2; WikiTruth) are definitely not relevant to
what you were talking about, and you know it.

>>As for knowledge of the Wikipedia rules, that's rot, too.  Knowing how to
>>behave appropriately in a collaborative environment is useful (hint: don't
>>be a dick), and having respect for our core principles, like neutrality
>>and respect for copyright, even more so.  Wikipedia has too many rules,
>>true, but you can get by quite happily without them if you just use common
>>sense and keep in mind our principles.
>
> Lovely sentiments. It's just a shame they don't have anything to do with
> the actual reality of Wikipedia for a newbie editor.

I suppose it's theoretically possible you're right here, in that I'm not
a newbie editor at the moment.  But I was, once, and at that time "don't
be a dick", "be objective" (I didn't know about NPOV, but objectivity
sounded like an obvious goal for this sort of project), and "don't
violate copyrights" (again, not stealing is hardly an unusual
philosophy) worked just fine, as it has for thousands of other editors.

>>I suspect, from what (admittedly little) I've seen from you, that you
>>have neither the backing of policy nor common sense when you
>>ride out on your high horse desperate to delete someone else's hard work.
>
> Well, of course you don't dear... but what does this have to do with
> anything?

I assume you think "dear" is meant to impress upon me your intellectual
superiority.  Well, it impresses upon me your wish to impress upon me
your intellectual superiority, which will have to suffice.

What this has to do "with anything" is quite simple: you complain about
the treatment of newbies, when the only experience of such treatment
you've bothered to offer us as evidence so far are your attempts to
delete others' hard work and how you reacted when they objected.

>>Despite this minor issue, which others would consider crippling, you still
>
> insist on
>
>>stamping your foot and complaining that you never get your own way.  And
>>as for "consensus building", well, it's a beautiful dream, but you
>>actually have to talk to people (as opposed to ranting at them for being
>>too stupid to agree with you).
>
> As opposed to long, patronising lectures full of misrepresentations from
> blowhards like you?

At last, an argumentative gambit that isn't completely fatuous!
Certainly, you're still a long way from convincing anyone that anything
you have to say is remotely credible, but --- at least you've said
something that can't be easily countered.  What does one say to "you're
a blowhard?"  "I'm not" lacks style, and is hardly convincing.  Any
attempt to mount a convincing argument that one is *not* a blowhard, of
course, merely cements the idea further.

Frankly, it's still argument-by-insult, but at least it's a reasonably
well-thought-out insult, as opposed to your "stupid" --- which you
worked so hard to disingenously insert --- above.

>>As for the time it takes to run a checkuser, well, there are certain
>>people who consider privacy important.  Crazy, I know.  What, do they have
>>something to hide?  All right-thinking, red-blooded human beings owe it to
>>themselves --- and us, damn it! --- to look under the beds of these people
>>immediately, in case a Commie is hiding there.
>
> Your IP address is all over the internet; so is your user agent string
> (operating
> system and browser). You are talking a complete a total load of old bollocks
> - and that doesn't come as a surprise given some of your other confused
> messages on this list.

You point to *my user agent string* as proof that I don't care about
privacy --- a classic case of missing the forest for trees.  My *real
name* and *university* are sent out in *every single message I post to
this list*!  When did I say I jealously guarded *my* privacy?

All I said was that there were certain people who considered privacy
important.  Guess what?  Some of them edit Wikipedia.  Guess what?  I
don't want to see them forced to leave when we have no reason to do so
other than Cobb being concerned that he can't Checkuser whomever he wants.

<snip/>

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


from_name: Tim Starling

subject: [Wikitech-l] SVG blankness problem hopefully resolved

body:
Brion Vibber wrote:
> I believe I've got the SVG blanking problem resolved.
>
> Some files may still have blank renderings left over; use ?action=purge on the
> image description page (on Commons if it's a Commons image) to rerender them.
>
>
> The new batch of machines set up a few weeks ago ended up with a broken version
> of libxml2 that ships by default with Fedora Core 4, which is unable to handle
> an odd but legal XML construct in SVG files exported from Adobe Illustrator.
>
> We'd worked around this problem on the other servers by upgrading libxml2 to the
> then-latest version which handles it, but apparently this didn't make it into
> the setup scripts (or else didn't get installed properly by them) on the newest
> machines.
>

Don't forget to fix the setup scripts this time. I think
/home/wikipedia/src/packages/install-librsvg is the one you're looking for.
This will just keep happening with every new or reinstalled server until the
setup scripts are fixed. I've been trying to make setup-apache and
setup-general entirely rerunnable, that is, to make them work as upgrade
scripts as well as setup scripts. So you can test them out by just updating
them and running them on some machines.

-- Tim Starling


from_name: xaosflux

subject: [WikiEN-l] Offline submissions?

body:
Baby steps!
This is quite a proposal, but the worst part is that it signifigantly
increases the ammount of work required to get something done.  I think a
better first step would be to set up a method to have emailed in articles
added, perhaps automagically to a queue.

xaosflux

----- Original Message -----
From: "Andrew Gray" <shimgray at gmail.com>
To: "English Wikipedia" <wikien-l at wikipedia.org>
Sent: Sunday, June 25, 2006 5:31 PM
Subject: [WikiEN-l] Offline submissions?

> According to the WikiProject Countering Systemic Bias, "The average
> Wikipedian on English Wikipedia (1) is male, (2) is
> technically-inclined, (3) is formally educated, (4) speaks English to
> an extent, (5) is White , (6) is aged 15-49, (7) is from a
> predominantly Christian country, (8) is from an industrialized nation,
> and (9) is more likely to be employed in intellectual pursuits than in
> practical skills or physical labor."
>
> The problem with this is the unfortunate gap in coverage that results
> from a lack of interest from the typical demographic of Wikipedians
> described above. While this demographic is definitely interested in
> contributing to a free, online encyclopedia, that doesn't mean the
> others aren't. One particular problem is that in order to contribute
> to Wikipedia, you'll need to use a computer. There are others who
> would probably be interested in contributing to our global effort,
> too, but don't understand technology. We need to allow them to
> contribute.
>
> For that purpose, I would like to start a project where people without
> access to computers (or people who voluntarily choose not to use them)
> can -write- their own Wikipedia entries and mail them in. The first
> phase of this plan, of course, would be spreading the word. The least
> expensive way would probably be distributing fliers in frequented
> areas. People could then write their own articles, and mail them in to
> the Wikimedia Office. Someone at the office (maybe Monica?) could open
> the letters, scan them in, and email them to an offline submissions
> mailing list. From there, people interested in the project would
> transcribe the article into Wikipedia (if applicable, see below) and
> mail back a corresponding letter featuring a print-out of the new
> article. Very simple process, plus it would allow people from
> non-typical-of-Wikipedia-editor backgrounds to put in their word.
>
> What if their entry is redundant? Not to worry. If the written
> submission has content the Wikipedia article doesn't, we add it in. If
> it doesn't, that's okay. We don't necessarily have to tell them what
> made it in and what didn't, but either way, a reply will be sent to
> the writer with a print-out of the article.
>
> ----
>
> I'm passing the above on for en:User:Messedrocker, since he's not
> subscribed to the list. My thoughts:
>
> a) This has certainly been done before on a local level with minor
> languages - was it in West Africa somewhere? My mind is failing me,
> but I've certainly seen it mentioned on wikipedia-l before - the
> writing was done by a local elder, transcribed and put online by a
> volunteer.
>
> b) It might well work, but would probably require careful thought and
> planning - who are we targeting? what sort of articles are we
> targeting them for? how do we deal with unwanted and inappropriate
> submissions without causing more badwill than we started with?
>
> c) Copyrights. This might get fun.
>
> --
> - Andrew Gray
>  andrew.gray at dunelm.org.uk
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l


subject: [WikiEN-l] Spoiler Boilerplates

body:
On 6/25/06, Steve Bennett <stevagewp at gmail.com> wrote:
>
> On 6/25/06, Garion1000 <garion1000 at gmail.com> wrote:
> > It makes sense to me. When an article is bad (or not complete enough,
> too
> > technical, whatever), a reader should be warned. But when a reader looks
> up
> > something 'obscene', he shouldn't be surprised to see something
> 'obscene',
>
> I would be very much surprised to see explicit pornography if I looked
> up "hard-core pornography". We're an encyclopaedia, after all - not
> normally the sort of place one expects to find porn.

I had to check out that article. It's only a stub. But actually I wouldn''t
mind an example of hardcore pornogaphy on the article on hardcore
pornography. Not a gallery or something, but just a small picture...sure. I
also don't think it's that important though. No need to update your
watchlists. :)

> Seems to be a common problem that "spoiler" is confused with "plot
> summary". Consider a movie review in the paper. You'll usually get a
> decent plot summary of the first two-thirds of the film. You would
> never see anything like the surprise twist at the end revealed. Now, I
> think we can go a little further than that, but when it comes to
> revealing that twist, we should be careful to respect our readers, who
> may be reading the article in order to decide whether the film is
> worth seeing or not.

But wikipedia is indeed different than a review. For a review I would go to
rottentomatoes or for more info to IMDB. But for more in depth information I
would go to wikipedia. And then I would expect spoilers.

Garion


from_name: Angela

body:
I'm not buying into the arguments Brad and his friends are putting
forward for Wikimedia to turn away from it's reliance on open source
software. Especially when that decision is being taken by some unknown
group of people with no community or Board consultation about possible
alternatives.

So, I'm asking if people can suggest to Brad some open source (fully
open source, not "can be open source if you don't need the security
package") CRM software
(http://en.wikipedia.org/wiki/Customer_relationship_management). I've
no doubt that people on this list have contacts in the free/OS
software world, so I'm hoping you can now use those contacts to help
with this.

Angela.


from_name: Tony Sidaway

body:
On 6/24/06, fireislandparadise <fireislandparadise at gmail.com> wrote:
> My problem is that not requiring a warning encourages gaming by making it
> easier for a more savvy edit warrior to take advantage of another editor and
> play "gotcha". This is particularly the case as most editors aren't aware of
> the new "unrelated reverts" interpretation. If someone is savvy enough to
> complain on ANI/3RR they should be capable of giving someone a warning
> first, especially if they are a participant in the edit war.
>

The "unrelated reverts" interpretation isn't new (see my own edits on
the 3RR talk page, circa February, 2005).  If you need it spelled out
to you, here it is:

Don't engage in edit warring on any page. Ever.


from_name: Brad Patrick

body:
Fascinating.  I'm reminded of the phrase "speak now or forever hold your
peace."  Must be wedding season.

Other than the handwringing of "there must be something", I haven't received
a single suggestion of a single bit of actual software from anyone, except
one very kind person who humbly suggested another open source package which
was (in her estimation) "most likely inappropriate" but "worth a look?!?".

To restate the issue (just in case anyone wasn't following along)...if you
are aware of an open source / free CRM package that has functionality that
is enterprise-worthy, email me.  The proprietary package to beat, in the
non-profit case at least, is The Raiser's Edge from Blackbaud.  If you have
the link to a package I should be looking at,  email me.

I think it should not surprise anyone that there are *not* dozens of
alternatives which have the capabilities we need.  When it comes to the
simple question "this is the proprietary solution - does anything in the
open source space compare?" and you have pressing business needs that must
be attended to, you do what you have to do.  The fact that a product which
is not perfect but is probably close enough even exists is fantastic.  And,
on philosophical grounds if you are willing to forego the proprietary
solution which actually *does* work to do what you want out of the box, and
consider the  more-open-than-any-other-solution, I would think that would be
seen as a sign of strength and commitment to pushing back, not a sellout of
an (at presently) unattainable ideal.

We just began our testing of the system, which Brion got up and running late
last week (in a matter of a few hours, btw, thx Brion).   We haven't
committed to it at this point, but it is the system to beat, pending our
testing, gap analysis, and fuller discussion with Sugar about the
Professional package offerings.

-B


from_name: Gerard Meijssen

subject:
[Foundation-l] Opinions/suggestions for "outside" members of
 the board?

body:
Fred Bauder wrote:
> On Jun 25, 2006, at 12:45 AM, Gerard Meijssen wrote:
>
>
>> We could have some servers in Africa... There is some reluctance of
>> the
>> developers to overcome.. We could hope that the project of the Vrije
>> Universiteit bears fruit.. and help it where we can. With this project
>> successful, it would mean a peer to peer MediaWiki whereby content is
>> near the people that want it.
>>
>
> Ok, Vrije Universiteit is in the Netherlands. What project do they
> have which relates to Africa?
>
> Fred
Hoi,
They are building an application that allows the hosting of Wikipedia
content in a peer to peer basis. When successful it means that people
can opt to run a Wikipedia peer on their hardware. This peer network
would know what information is in demand and distribute it accordingly..
So when a certain topic is in the news .. the network would react by
bringing more copies of the data to where it is in demand. This would
overcome among other things the current problems with peering agreements
between ISP's.

They are at the stage where they need real life (anonomised) traffic
details to test the distribution of traffic in a big private GRID network.
Thanks,
    GerardM


from_name: Theresa Knott

subject: [WikiEN-l] Offline submissions?

body:
On 6/26/06, xaosflux <xaosflux at gmail.com> wrote:
> Baby steps!
> This is quite a proposal, but the worst part is that it signifigantly
> increases the ammount of work required to get something done.  I think a
> better first step would be to set up a method to have emailed in articles
> added, perhaps automagically to a queue.

If they don't have access to the web, how will they know what the
current article says in order to email in their modifications?

Theresa
--

http://theresaknott.googlepages.com/home
http://en.wikipedia.org/wiki/User:Theresa_knott


subject:
[Wikitech-l] Cross-Site-Scripting arbitrary JavaScript
	execution and HTML insertion vulnerability in the live Wikipedia.

references:
<NABBJGECPILFNLFEAPIKGENDIFAA.nickpj@gmail.com>
	<NABBJGECPILFNLFEAPIKOEPJIFAA.nickpj@gmail.com>
	<e7nrtv$t4i$1@sea.gmane.org>

body:
On 26/06/06, Tim Starling <t.starling at physics.unimelb.edu.au> wrote:
> Whenvever you post one of these "OMFG security flaw" posts to a public
> mailing list, it damages the reputation of MediaWiki as a secure and stable
> wiki engine. These posts will be archived and available in the search
> engines forever. Some people are going to search for "mediawiki security" on
> google and judge it by what they find.

*cough* And people are going to spot these arguments in the public
archive, too. Who was it who asked us all to be decent to people;
those we knew, and those we didn't? Common sense, to me.

> What we would like is for MediaWiki to be judged by the reliability of its
> release versions, not whatever happens to be at the head of the trunk in any
> particular second.

I'd tend to agree, although since we're using Subversion trunk in
production on a popular web site, it is, of course, prudent for us to
keep it secure against known issues. :)

Might I suggest that Nick continues to (very kindly) advise us in
advance of security issues, as he has been doing, via the private
channels (emailing two or three of us, or using the security at wikimedia
alias; whatever), but holds back on announcing stuff to wikitech-l for
an hour or so, and doesn't bother announcing bugs in Subversion trunk
that are fixed up?

This means that:

* we still get fair warning of stuff we need to fix
* people aren't alerted and panicked and misled when there's little
cause for alarm
* people *are* given fair notice of problems in the "stable" branch

> I'm sure we can arrange commit access for you.

Sounds like a sensible idea to me; he's not going to go off breaking
stuff, we can sorta guess that, and we'll benefit from having a bit
more testing stuff. :)

Rob Church


body:
On 26/06/06, Nick Jenkins <nickpj at gmail.com> wrote:
> Yes, I hadn't looked at the code at all until after it was fixed, and I want to say thanks and kudos most especially to Rob Church for getting the fix in so quickly.

I suppose it's time to cough to the fact that I was at fault in the
first place? :(

Rob Church


references:
<NABBJGECPILFNLFEAPIKGENDIFAA.nickpj@gmail.com>
	<NABBJGECPILFNLFEAPIKOEPJIFAA.nickpj@gmail.com>
	<e92136380606252326u36ad4c30uc09949c32fb03726@mail.gmail.com>
	<CD377722-F68B-4655-81A3-AC6AAFD03F1D@gmail.com>

body:
On 26/06/06, Domas Mituzas <midom.lists at gmail.com> wrote:
> > I suppose it's time to cough to the fact that I was at fault in the
> > first place? :(
>
> You were not at fault. You were the fault!

*sob* I blame it on E numbers and Doctor Who! Damn those TARDISes and
their oh-so-alluring world without htmlspecialchars().

I must rush to the nearest blog and spend a whole hour composing four
sentences, PACKED with emo!!!11!one.

Rob Church


from_name: Ben Yates

subject: [WikiEN-l] New York Times article

body:
Even if the restrictions are minor, any level of separation between
anons and regular users does have social consequences: it's a barrier,
if a permeable one, and it will effect how many people join wikipedia
(and what types of people), how users treat outsiders, etc.
Semiprotection is necessary, but we shouldn't pretend it's
inconsequential.  (Hey, maybe those consequences are /good/, like
encouraging people to create accounts and become invested in the
project.  And maybe they're not.)

On 6/25/06, mboverload <mboverload at gmail.com> wrote:
> On 6/22/06, Steve Bennett <stevagewp at gmail.com> wrote:
>
> > Anyway, the more I consider the facts, the less convinced I am. The
> > problem is in the interpretation of "anyone can edit". Does it mean
> > "anyone who wants to edit, can", or does it mean "anyone at all can
> > edit". Normally this wouldn't matter, but it's critical if we're
> > attempting to measure "anyone-can-edit-ness" (ACEN).
>
>
> Anyone can drive on the public roads.  Of course you need a licence and need
> to know the rules of the road.  It's just common sense, we don't need to
> fine-tune it.
>
> The problem is that semi-protection lasts longer
> > than full protection, as a rule, so that in general this comparison is
> > far from true.
>
>
> What, they can't wait 4 days to edit an article that's a huge source of
> vandalism - yet they can still edit the other 99.999% of articles? Boohoo.
>
> mboverload
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

--
Ben Yates
Wikipedia blog - http://wikip.blogspot.com


from_name: Steve Bennett

subject: [WikiEN-l] Offline submissions?

body:
On 6/26/06, Theresa Knott <theresaknott at gmail.com> wrote:
>
> If they don't have access to the web, how will they know what the
> current article says in order to email in their modifications?

I think the suggestion only applied to brand new articles.

Steve


from_name: Sui Min

subject: [Wikitech-l] Mass open proxy blocking

body:
hi

2006/6/26, Simetrical <Simetrical+wikitech at gmail.com>:
> On enwiki, this is solved by the simple expedient of using indefinite
> blocks.  These can be lifted by request if it's judged that the proxy
> is no longer open.  (See
> http://meta.wikimedia.org/wiki/Meta:No_open_proxies.)  Thus, no
> clogging the blocklists.

Is there a way to share blocked open proxy infomation over projects
like spam blacklist?

Many of open proxies can use worldwide/everywhere.
but we blocke it by earch project.
That's a kind of nonsense.

We (jawiki) use open proxy checker (developed ba a sysop) and
block open proxy one by one too.
but there's many *indivixual* proxies including tor,
so thers's no end with this way.

Don't you think so?

suisui
suisui at gmail.com


from_name: Domas Mituzas

references:
<NABBJGECPILFNLFEAPIKGENDIFAA.nickpj@gmail.com>
	<NABBJGECPILFNLFEAPIKOEPJIFAA.nickpj@gmail.com>
	<e92136380606252326u36ad4c30uc09949c32fb03726@mail.gmail.com>

body:
> I suppose it's time to cough to the fact that I was at fault in the
> first place? :(

You were not at fault. You were the fault!

Domas


from_name: stevertigo

subject: [WikiEN-l] Offline submissions?

body:
I havent much read on this thread, but I think I like
the idea of being able to shoot simple notes (via
email, or various messaging protocols) to articles. I
dont know what form that would take but, suffice it to
say it shouldnt be appended to the article itself. And
probably not the talk page either.

It would be easy to envision it as a kind of ticket
system, where in addition to talk pages, articles have
an associated list of "tickets" which are like
extended comments not attached to a particular edit.
By 'simple notes' I mean a quick means to push off
that we think about including in a particular article
but dont have time to actually dig in and work it in
ourselves.

The ticket would show up in a list, and based on the
actual content, editors can choose to stick it
wherever it is they like to stick such things.
Maybe just appending to the bottom of the talk would
be a first incarnation, but it might get out of hand,
and we want talk comments to be responsive to previous
comments.

Accreditation in history would be a problem if the one
who submitted the ticket wants credit. Some may not
though. I imagine this being clicking on the ticket,
and the script opens up the edit window and appends
the ticket text to the article. In the edit comment
field, the ticket poster's name will show up as the
source. In the edit window, its a simple matter of
just shoving things around artfully and calling it
"good writing." (The onus for accuracy is on the
ticket sender ;)

-Svertigo

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


subject: [WikiEN-l] "Good authors"

body:
On 6/26/06, Erik Moeller <eloquence at gmail.com> wrote:
> If I wanted a three word slogan for Wikipedia, it would be something
> like "Love in Knowledge": emphasizing the core principle of WikiLove
> as well as the overarching goal to collect the sum of all human
> knowledge. Come to think of it, "Love in Knowledge" might be a nice
> slogan for the Wikimedia Foundation. Or is it too kitschy?

Funny, you know the etymology of "philosophy" right?

Steve


subject: [WikiEN-l] "Good authors"

body:
--- George Chriss <GChriss at psu.edu> wrote:
> If I had to give Wikimedia projects a new, more
> accurate slogan, it would be "organizing knowledge
> by open editing".  Perhaps the Foundation proper
> should adopt "for people that love sharing
> knowledge"?

Too syllogistic. "Free information, come and get it"
would be better.

A better slogan: "Every day [we] write the book."
Elvis might have some objection though.

-S

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


from_name: Jimmy Wales

body:
daniwo59 at aol.com wrote:
> How about a policy that states:
> - when no adequate (as  determined by its prospective users) 100% free
> software solution for a task  can be found, a proprietary solution may
> be used.
> - such use needs to be  reported and documented in a list of
> proprietary software used by the  Foundation, so that the decision can
> be debated and challenged by the  community.
> - in such cases, a partially proprietary solution is preferable  to a
> fully proprietary one.
> - a migration plan should be made as soon as  a realistic fully open
> source alternative emerges.
> - the Foundation  should, within its budget, support the development of
> such an  alternative.

The one thing I would add to this is that in terms of running the actual
website, delivering the actual work to the end user, we should never run
anything other than fully free software.

Running back office operations may in some cases require a tradeoff...
in the case in question, as I understand it so far, SugarCRM is free
software except that the module for security is proprietary.  I have not
done any analysis yet to fully understand the status, so I am just
speaking here of the hypothetical case.

--Jimbo

--
#######################################################################
#    Office: 1-727-231-0101       |  Free Culture and  Free Knowledge #
#    http://www.wikipedia.org     |     Building a free world         #
#######################################################################


subject: [WikiEN-l] Offline submissions?

body:
--- Steve Bennett <stevagewp at gmail.com> wrote:
> Why not the talk page? In the beginning at least, it
> seems quite
> feasible simply to append tags like:
...
> Then people could deal with that text in the normal
> ways, adding comments as to whether they think it's
> worth including etc. What's the downside?

IMHO its just not the place to put discrete chunks of
material which are designed for inclusion in the
article. Plus, talk pages can get overloaded with
nonsense or offtopic comments this way that have to be
pruned by hand. Using a ticket system will let people
use them, ignore them, otherwise file them to
/dev/null.

> > Accreditation in history would be a problem if the
> one
> > who submitted the ticket wants credit. Some may
> not
>
> True. Maybe at first simply deny them that
> opportunity? Or you know,
> in the edit summary you could always put the source
> so it's not *totally* lost.

WP is at the point where things are done only when
they are and no sooner by the brilliant people who
know how to do this stuff. It would be best left to
them to decide what minimum specific level of
sophistication is required. Wikidata seems like it was
on this track IIRC, and this might be just repeating a
part of that idea.

-S

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


from_name: maru dubshinki

subject: [WikiEN-l] Offline submissions?

body:
On 6/26/06, Andrew Gray <shimgray at gmail.com> wrote:
> On 26/06/06, Alphax (Wikipedia email) <alphasigmax at gmail.com> wrote:
>
> > > If they don't have access to the web, how will they know what the
> > > current article says in order to email in their modifications?
> >
> > Being able to retrieve articles via email would be nice...
>
> There is someone who offers such a service - directed at the .za
> market, I believe, but don't quote me on that. It seems to be quite
> popular, certainly popular enough we had to make sure his
> page-retrieval software didn't get blocked.
>
> --
> - Andrew Gray

Y'know, Google used to offer such a service- they'd reply with a link
to a cached and compressed copy on their servers.

~maru