subject: [WikiEN-l] Wikipedia mirror (Unblock request)

body:
Just thought I would mention that Krishna doesn't appear to be
subscribed to the list, so any replies should probably copy him/her
directly.

Steve

On 6/25/06, Krishna Pagadala <krishnaact at yahoo.com> wrote:
> All,
>  I am planning on building a computer which is a copy of en.wikipedia (including portals), en.wikitonary, en.wikibooks, species.wikimedia along with the pictures. The computer will be sent to India to be used in educational settings, and will probably be copied and shared.
>  I have already built a text only mirror of en.wikipedia at http://freeknowledge.dyndns.org/wikipedia/index.php/Main_Page
>  Any suggestions/advice on how to go about and pitfalls that I will likely encounter is greatly appreciated.
> -Krishna
>
>
>
>
> =====================================
> Misinterpreting Copyright by Richard Stallman
> "Die Gedanken Sind Frei": Free Software and the Struggle for Free Thought by Eben Moglen mp3 ogg
> Free Knowledge blog
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> .
>
> ---------------------------------
> Do you Yahoo!?
>  Everyone is raving about the  all-new Yahoo! Mail Beta.
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


list: wikitech-l

source: pipermail-mbox

from_name: Jay R. Ashworth

subject: [Wikitech-l] Poem extension on Wikisource

body:
On Sun, Jun 25, 2006 at 04:33:24PM -0600, Chad Perrin wrote:
> I've already pointed out that a "does exactly what we want for thirty
> things, but is named for only one, necessitating the creation of
> twenty-nine more duplicates on the off-chance we'll change it later"
> approach can be avoided for ease of differentiation later by separating
> semantics from presentation, and merely linking the two together.  Brion
> commented with an explanation of what's going on that sounds like it
> might actually be taking the approach I favored, and only the initial
> statements' description of what the <poem> tags do created a contrary
> impression.  You seem to think that the behavior assumed in that
> contrary impression is a better way to do things, however, and somehow
> have chosen to avoid addressing my statements about the manner in which
> the same positive effects can be had without the weighty negatives.

Naw, Chad; we're all in violent agreement.

*How* the poem tag does what it does is precisely the way you, I, and
everyone else who I've seen post thinks it ought to: by leveraging CSS.

Now, Steve, on the other hand, has raised a good question: what happens
when people *do* want the <recipe> tag?  :-)

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?


from_name: Brion Vibber

subject: [Wikitech-l] Static content Wikipedia/Wikimedia

body:
Krzysztof Jasiutowicz wrote:
> Hi,
>
> I am writing to this list to inquire about possibility of setting up
> and maintaining up-to-date static HTML content of major
> Wikipedia/Wikimedia sites (for example
> http://download.wikimedia.org/static/).
>
> I'd like to invite people from Wikimedia tech team to cooperate with
> the static content subcommittee of Special Projects Committee on
> technical aspects of its tasks. We need your help.

I would be happy to assign a server for conversion duties. Originally srv31
(which hosts static.wikimedia.org) mostly did this; though it's been kind of
taken over for additional things they can be moved.

-- 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/20060626/4b4988fd/attachment.pgp>


from_name: Jeremy Dunck

subject: [Wikitech-l] Some statistics I wish I had...

body:
On 6/26/06, Felipe Ortega <glimmer_phoenix at yahoo.es> wrote:
> In the past few weeks I' ve read a bunch of mail messages talking about what is precisely my first goal: extracting behavioral conclusions from a quantitative analysis of wikipedia database dumps in all languages.
>
> But, despite all my efforts, and some mails offering myself as contributor I have received no answer from Wikipedia Community. I only wanted to contribute in a very interesting area (I think) and I hope it could lead me to build an interesting thesis about this topic. I'm currently developing some scripts in Phyton that analyze database dumps.
>
> I wrote a paper with some preliminar results, if you may take a glance to it. I only ask for some collaboration from anyone involved with the project, because otherwise maybe I should simply think that all my efforts don' t bother anyone.
>

Felipe,
  I'm a bachelor student at University of Texas at Dallas, also
working on what I'm calling fine-grained statistics for Wikipedia,
using python to interpret text from database dumps.  :)

  I've been working on it off and on for almost a year.  The big
problems for me has been disk space and wikitext parsing.  After
fiddling for quite a while trying to make my own parser, I have
finally broken down to using the HTML as rendered by MediaWiki, then
using that as the basis for the rest.

  My basic goal is to provide statistics for things such as "how many
revisions has this piece of text survived" and similar, then render
that information onto a reader's wikipedia browser page.  As a second
goal, it'd be nice to find some combination of stats that suggest
which bits of a page a more likely trustworthy.

  How far have you gotten, and does it sound like we're on the same track?

  Cheers,
    Jeremy


from_name: Rob Church

body:
On 26/06/06, habj <sweetadelaide at gmail.com> wrote:
> May I ask for a more precise description of why it should not be used for
> other kind of texts than poems? It is not me you need to convince, I ask you
> for some good things to say to those who want to use it for other stuff, and
> style it accordingly.

The main argument boils down to semantics. The output is wrapped in
<div class="poem">, meaning that people can opt to see poems formatted
in a specific manner. This formatting might not need to be applied to
non-poem texts, or it might be otherwise undesirable. In short, it
comes down to "don't mark up non poems as poems".

It would be somewhat trivial to expand the extension to allow
customising the class output according to the tag used; if another use
case pops up, we can add another tag and class combination.

Rob Church


list: wikien-l

from_name: maru dubshinki

subject: [WikiEN-l] Offline submissions?

body:
On 6/26/06, Steve Bennett <stevagewp at gmail.com> wrote:
> On 6/26/06, maru dubshinki <marudubshinki at gmail.com> wrote:
>
> > Y'know, Google used to offer such a service- they'd reply with a link
> > to a cached and compressed copy on their servers.
>
> A link? What's the point?
>
> Steve

The idea was that certain people could not afford to spend all the
time on their crappy dialups to actually run a manual web search,
checking out the various links and such; so they composed a search
query offline as an email, then set up their software to briefly
connect online and fire off the query. A while later, Google would
send an email back with the results, and instead of connecting to the
actual servers for the various links, the user would connect to
Google's servers, which compressed and filtered the web page concerned
so that far less information had to be actually transmitted. I don't
know if it was very popular; I only heard of it once, and years ago.

~maru


from_name: Ray Saintonge

subject: [WikiEN-l] A very interesting recent "fair use" case ruling

body:
Fastfission wrote:

>On 6/21/06, James <user_jamesday at myrealbox.com> wrote:
>
>
>>This aspect applies to almost all uses in articles in the work called
>>Wikipedia by its authors. Whether it's a baseball card, poster, album
>>cover, book cover, mural, painting or postcard, it's not an
>>encyclopedia article and the use is in one is transformative and
>>strongly favors fair use.
>>
>>
>The one problem I have with this is that I don't know where the line
>between "moving contexts is transformative" starts and where one gets
>away from things like the Seinfeld case, where the context is
>definitely different (TV show to trivia book) but it was found to be
>infringement because it cut into the copyright holder's ability to
>make a trivia book in the future. Obvious one case does not simply
>trump another case, but in any event this is a nice assurement that
>"encyclopedic use" has plausibility as transformative.
>
I haven't read the Seinfeld case, but I would expect that the line here
would be that a trivia book devoted exclusively to a single TV seriew
could be viewed as a derivative work, but this would not be the case if
a handful of questions about the program were part of a broader context.

I don't expect that there will ever be a simple demarcation line for
what is safe to use.  In any event, a safe harbor is always available in
cases of uncertainty.

>>You don't need to have specific justification for each image use -
>>readers know from the context that you're illustrating your point (but
>>we should still say so in the fair use explanation, because it's
>>prudent to do so and remove doubt about our intentions).
>>
>>
>Additionally having a fair use justification is also meant to scare
>off cheap trouble by making our case look strong from the beginning
>and demonstrating an awareness of the legal issues involved.
>
Demonstrating awareness is key if any of these are to go any further.

Ec


from_name: habj

body:
On 6/24/06, Timwi <timwi at gmx.net> wrote:

> Please don't use it for something else, even if it seems somewhat useful
> for another purpose. It is _designed_ for poems, and it is supposed to
> mark up only poems. If you find another use, a new tag can be introduced
> that behaves in a very similar way.

May I ask for a more precise description of why it should not be used for
other kind of texts than poems? It is not me you need to convince, I ask you
for some good things to say to those who want to use it for other stuff, and
style it accordingly.

// habj


list: foundation-l

from_name: Gianluigi Gamba

subject: [Foundation-l] Vicenza, Italy

body:
Wikimedia Italia just finished a long 4-day weekend of presentation of
Wikipedia and Wikimedia projects to the thousands of visitors of
"FestAmbiente", held in a park of Vicenza, in northern Italy.
Wikipedians gathered from half of the country (and from the Italian-speaking
area of Switzerland as well).
Frieda had also a question time on Sunday afternoon with the public.

Details (in Italian only, for the moment, sorry) and photos at
http://it.wikipedia.org/wiki/Wikipedia:Raduni/Vicenza_2006

Bye all,
G. (aka Paginazero)


list: wikimedia-l

subject: [Foundation-l] Vicenza, Italy


from_name: Chad Perrin

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> <e7p9d0$skr$1@sea.gmane.org>

body:
On Mon, Jun 26, 2006 at 07:35:00PM +0100, Timwi wrote:
>
> Seriously, security flaws need to be pointed out. *Especially* in
> open-source software.

One of the big problems I have with a lot of proprietary software is the
unwillingness of its vendor to admit flaws and tell us, the users, that
there's a problem of which we should be aware.  I tend to view open and
frank, helpful discussion of security issues to be a net win when I'm
evaluating software to determine whether I want to use it, and ominous
silences as a sign that if a vulnerability arises, I won't find out
until it's too late.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Ben Franklin: "As we enjoy great Advantages from the Inventions of
others we should be glad of an Opportunity to serve others by any
Invention of ours, and this we should do freely and generously."


from_name: Andrew Gray

subject: [WikiEN-l] Offline submissions?

body:
On 26/06/06, Steve Bennett <stevagewp at gmail.com> wrote:
> 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.

Yeah, that's one of the issues I've thought woul be a problem -
figuring out what to ask for. It's almost easier in languages with
little or no coverage, where we still have real demand for first-level
or second-level topics like "history of music" or "Fishing", and the
potential for conflict is less.

If you're going to do this in English, a good and near-inexhaustible
target would be biographies of locally-significant historical figures,
or local history generally, I guess, but then you run into notability
or verifiability issues.

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


from_name: abu hamza

subject:
[WikiEN-l] Offline submissions?how to address the limited range
	of participa

body:
hi, I am not sure the current wikipedia administrative system is geared
towards addressing this
"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."
"

If you go to the muslim guild on wikipedia
http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Islam:The_Muslim_Guild
and you look at all the entrents, everyone is currently under threat of an
indefinate ban or idefinately banned. I think the idea of having a greater
participation is lip service.

>From: mboverload <mboverload at gmail.com>
>Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
>To: "English Wikipedia" <wikien-l at wikipedia.org>
>Subject: Re: [WikiEN-l] Offline submissions?
>Date: Sun, 25 Jun 2006 18:14:08 -0700
>
>Maybe I'm the only one here, but I say "Who cares?"
>
>If they don't have a computer they don't have the time to write an
>encyclopedia.  They are trying to hold up two jobs and feed their kids.
>There's a reason they don't edit:  they don't care enough and I don't blame
>them.
>
>mboverload
>
>On 6/25/06, Anthere <Anthere9 at yahoo.com> wrote:
> >
> > 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.
> > >
> >
> > _______________________________________________
> > WikiEN-l mailing list
> > WikiEN-l at Wikipedia.org
> > To unsubscribe from this mailing list, visit:
> > http://mail.wikipedia.org/mailman/listinfo/wikien-l
> >
>_______________________________________________
>WikiEN-l mailing list
>WikiEN-l at Wikipedia.org
>To unsubscribe from this mailing list, visit:
>http://mail.wikipedia.org/mailman/listinfo/wikien-l

_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters!
http://www.msn.co.uk/newsletters


from_name: Steve Bennett

body:
On 6/26/06, Rob Church <robchur at gmail.com> wrote:
> It would be somewhat trivial to expand the extension to allow
> customising the class output according to the tag used; if another use
> case pops up, we can add another tag and class combination.

That seems to be the strongest argument for making a generic tag
wrapped in a template to set the class. Currently, if a user at fooboo
wiki wants to get the behaviour of <poem> for something that isn't a
poem, their choices are:

1) Wrap it in <poem> anyway, defeating the whole point of semantic mark up.
2) Attempt to imitate it by implementing something that doesn't quite
work as well with templates.
3) Attempt to hack the mediawiki source code to copy <poem>, making
something nonportable.
4) Attempt to convince the MediaWiki developers of the validity of
their "use case" and wait for it to get implemented.
5) Wrap <poem> in a <div class="foo">, store that in a template, carry
out step 4) and reimplement the template with a clean new tag.

Have I missed any?

Steve


subject: [WikiEN-l] Offline submissions?

body:
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
  andrew.gray at dunelm.org.uk


body:
On 26/06/06, Nick Jenkins <nickpj at gmail.com> wrote:
> Don't worry about it, it's an extremely easy thing to miss. It's also partially the name of the variable, $ip, and its implications,
> as we expect IP addresses to be things like "12.34.56.32", and we simply don't expect an IP address to contain things like
> '"><script>'.

No, I should know better; what caused it was damn confusion over the
bloody wfMsg* functions. I forgot that wfMsgWikiHtml() doesn't escape
parameters.

Rob Church


from_name: Mark Gallagher

subject: [WikiEN-l] popular POV not NPOV?

body:
G'day Fred,

[rm top-posted thing]

>>On Sat, 24 Jun 2006, Philip Welch wrote:
>>
>>>I think we should replace "neutral point of view" (which is
>>>abbreviated to the misunderstood acronym NPOV) to
>>>"neutrality" (which, like "verifiability", is easier to understand).
>
> We already have trouble with editors who try to use neutral washed
> out language rather than allowing opposing points of view to be fully
> expressed.

Thank goodness for WikInfo!

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: Anthere

subject: [Foundation-l] Vicenza, Italy

body:
Gianluigi Gamba wrote:
> Wikimedia Italia just finished a long 4-day weekend of presentation of
> Wikipedia and Wikimedia projects to the thousands of visitors of
> "FestAmbiente", held in a park of Vicenza, in northern Italy.
> Wikipedians gathered from half of the country (and from the Italian-speaking
> area of Switzerland as well).
> Frieda had also a question time on Sunday afternoon with the public.
>
> Details (in Italian only, for the moment, sorry) and photos at
> http://it.wikipedia.org/wiki/Wikipedia:Raduni/Vicenza_2006
>
> Bye all,
> G. (aka Paginazero)

It's cool !

Why don't you put labels under the pictures so that we can put names on
faces ?

Ant


subject: [Foundation-l] Vicenza, Italy


from_name: Eric Astor

body:
On this note, would it be possible to get a public pointer to the full
skins, modifications, and so forth used in creating the latest static dumps
(as at http://static.wikipedia.org)? Several projects I know of (including
the OEPC project I'm working on) are looking for ways to create good static
exports, and the November dumps come out looking excellent.

If it's more complicated than that, I'd be happy to contribute in any way I
can to publicizing the export techniques. I would hope that this process
would simplify the process of maintaining up-to-date static HTML dumps.

Thanks very much,
Eric

> -----Original Message-----
> From: wikitech-l-bounces at wikimedia.org [mailto:wikitech-l-
> bounces at wikimedia.org] On Behalf Of Krzysztof Jasiutowicz
> Sent: Monday, June 26, 2006 1:44 PM
> To: wikitech-l at wikimedia.org
> Subject: [Wikitech-l] Static content Wikipedia/Wikimedia
>
> Hi,
>
> I am writing to this list to inquire about possibility of setting up
> and maintaining up-to-date static HTML content of major
> Wikipedia/Wikimedia sites (for example
> http://download.wikimedia.org/static/).
>
> I'd like to invite people from Wikimedia tech team to cooperate with
> the static content subcommittee of Special Projects Committee on
> technical aspects of its tasks. We need your help.
>
> Please see:
> http://meta.wikimedia.org/wiki/Special_projects_committee
> http://meta.wikimedia.org/wiki/Static_content_subcommittee
>
> Best regards,
> Kpjas
> --
> Wikipedia - World's Greatest http://www.wikipedia.org
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.9.4/375 - Release Date: 6/25/2006
>

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.4/375 - Release Date: 6/25/2006


from_name: Frieda Brioschi

subject: [Foundation-l] Vicenza, Italy

body:
2006/6/26, Anthere <Anthere9 at yahoo.com>:

> Why don't you put labels under the pictures so that we can put names on
> faces ?
>
> Ant

Done, here http://it.wikipedia.org/wiki/Wikipedia:Raduni/Vicenza_2006#Foto

;-)

Ciao,
Frieda
___________________________________________
http://it.wikipedia.org/wiki/Utente:Frieda


subject: [Foundation-l] Vicenza, Italy


from_name: Nathan Carter

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

body:
Angela wrote:
> 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.
>
>
>
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.
Cheers,
Nathan.


from_name: Mark Wagner

subject: [WikiEN-l] Spoiler Boilerplates

body:
On 6/25/06, Garion1000 <garion1000 at gmail.com> wrote:
> On 6/25/06, Steve Bennett <stevagewp at gmail.com> wrote:
> >
> > I have to admit to a sense of irony that we warn users of excessively
> > technical language, and we warn them if the title of the page isn't
> > quite right. We even warn them that the article uses unicode
> > characters. But we refuse to warn them that they may witness seriously
> > obscene material or have their enjoyment of a work of fiction totally
> > spoilt.
>
>
> 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',
> or when a reader looks up a movie, he shouldn't  be surprised to find a plot
> summary there. To me a warning in those cases seems unnecessary.

When I look up a movie, I'm usually looking for something other than
the plot, and in that case, I expect any spoiler sections to be noted
-- odds are, I haven't seen the movie yet, and I don't want the ending
to be spoiled.

--
Mark
[[User:Carnildo]]


body:
> -----Original Message-----
> From: wikitech-l-bounces at wikimedia.org [mailto:wikitech-l-
> bounces at wikimedia.org] On Behalf Of Mathias Schindler
> Sent: Monday, June 26, 2006 2:17 PM
> To: Wikimedia developers
> Subject: Re: [Wikitech-l] Static content Wikipedia/Wikimedia
>
> Shouldn't it be included in the sources?
>
> http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/maintenance/dumpHTM
> L.php?revision=12476&view=markup

Not quite... I've done a dump, and the format comes out differently - not
really appropriate for a static dump, since among other things, the Search
button is present but fails. I suspect it's just a skin difference or
something similarly small, but it'd be good to have a public statement of
what's necessary to get the same format as the November static HTML dumps.

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.4/375 - Release Date: 6/25/2006


from_name: Mathias Schindler

body:
On 6/26/06, Brad Patrick <bradp.wmf at gmail.com> wrote:

> 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.

Hi Brad,

thanks to you and Brion for testing it. I would welcome it if it
proves to be usable for our needs. In the meantime, take 5 minutes to
read about the Bitkeeper fiasco if you haven't heard about it already.

As Wikimedia Deutschland e.V faces the same task, I would be happy to
see us share this information and experiences.

Good luck,
Mathias


from_name: mboverload

subject: [WikiEN-l] New York Times article

body:
Yes, I feel so bad for the people who don't want to spend one minute
registering to edit. Semiprotection is used on so few articles I fail to see
how it could have any impact.

mboverload

On 6/26/06, Ben Yates <bluephonic at gmail.com> wrote:
>
> 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
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Magnus Manske

subject:
[Foundation-l] [Wikipedia-l] moving forward on article
	validation

body:
I have made some new toys that might be of interest:

Instead of waiting for the next database dump and downloading the whole
thing, you can now get a XML dump for all articles in a category and its
subcategories:

http://tools.wikimedia.de/~magnus/cat2xml.php?category=History_Version_0.5_articles

Sadly, the toolserver is somewhat broken for use on en, so it doesn't
even know "Category:Wikipedia Version 0.5", but that is someone else's
problem (since ages, I might add). So until this is fixed, you can't get
the complete article texts for 0.5 in one swift motion, but then! ;-)

I have also found a web server (Server2Go) which runs directly from CD
(or the main directory of any drive, including USB sticks). I have
managed to integrate MediaWiki into it. While a MySQL variant is
available, I went for a new MediaWiki database type supporting
plain-text files (read-only at the moment). Back to the roots, I guess ;-)

Anyway, I have created what I hope is a standalone, zero-install
"History Wikipedia 0.5" bundle, currently consisting of a pityful 19
articles. This was done by converting the above mentioned
custom-XML-dump into plain-text articles using a script from my wiki2xml
toy.

Categories don't work, and I was too lazy to set up interlanguage links.
No images either.

Still interested? Try
http://tools.wikimedia.de/~magnus/history05.zip   (23MB)

Best to burn the whole thing to a CD, as it /has/ to be in the root
directory. I *did* mention that it's currently Windows-only, right?

Magnus

-------------- 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/20060626/f75a94ab/attachment.pgp


body:
I have made some new toys that might be of interest:

Instead of waiting for the next database dump and downloading the whole
thing, you can now get a XML dump for all articles in a category and its
subcategories:

http://tools.wikimedia.de/~magnus/cat2xml.php?category=History_Version_0.5_articles

Sadly, the toolserver is somewhat broken for use on en, so it doesn't
even know "Category:Wikipedia Version 0.5", but that is someone else's
problem (since ages, I might add). So until this is fixed, you can't get
the complete article texts for 0.5 in one swift motion, but then! ;-)

I have also found a web server (Server2Go) which runs directly from CD
(or the main directory of any drive, including USB sticks). I have
managed to integrate MediaWiki into it. While a MySQL variant is
available, I went for a new MediaWiki database type supporting
plain-text files (read-only at the moment). Back to the roots, I guess ;-)

Anyway, I have created what I hope is a standalone, zero-install
"History Wikipedia 0.5" bundle, currently consisting of a pityful 19
articles. This was done by converting the above mentioned
custom-XML-dump into plain-text articles using a script from my wiki2xml
toy.

Categories don't work, and I was too lazy to set up interlanguage links.
No images either.

Still interested? Try
http://tools.wikimedia.de/~magnus/history05.zip   (23MB)

Best to burn the whole thing to a CD, as it /has/ to be in the root
directory. I *did* mention that it's currently Windows-only, right?

Magnus

-------------- 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/20060626/f75a94ab/attachment-0001.pgp


body:
I have made some new toys that might be of interest:

Instead of waiting for the next database dump and downloading the whole
thing, you can now get a XML dump for all articles in a category and its
subcategories:

http://tools.wikimedia.de/~magnus/cat2xml.php?category=History_Version_0.5_articles

Sadly, the toolserver is somewhat broken for use on en, so it doesn't
even know "Category:Wikipedia Version 0.5", but that is someone else's
problem (since ages, I might add). So until this is fixed, you can't get
the complete article texts for 0.5 in one swift motion, but then! ;-)

I have also found a web server (Server2Go) which runs directly from CD
(or the main directory of any drive, including USB sticks). I have
managed to integrate MediaWiki into it. While a MySQL variant is
available, I went for a new MediaWiki database type supporting
plain-text files (read-only at the moment). Back to the roots, I guess ;-)

Anyway, I have created what I hope is a standalone, zero-install
"History Wikipedia 0.5" bundle, currently consisting of a pityful 19
articles. This was done by converting the above mentioned
custom-XML-dump into plain-text articles using a script from my wiki2xml
toy.

Categories don't work, and I was too lazy to set up interlanguage links.
No images either.

Still interested? Try
http://tools.wikimedia.de/~magnus/history05.zip   (23MB)

Best to burn the whole thing to a CD, as it /has/ to be in the root
directory. I *did* mention that it's currently Windows-only, right?

Magnus

-------------- 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/20060626/f75a94ab/attachment.pgp>


body:
I have made some new toys that might be of interest:

Instead of waiting for the next database dump and downloading the whole
thing, you can now get a XML dump for all articles in a category and its
subcategories:

http://tools.wikimedia.de/~magnus/cat2xml.php?category=History_Version_0.5_articles

Sadly, the toolserver is somewhat broken for use on en, so it doesn't
even know "Category:Wikipedia Version 0.5", but that is someone else's
problem (since ages, I might add). So until this is fixed, you can't get
the complete article texts for 0.5 in one swift motion, but then! ;-)

I have also found a web server (Server2Go) which runs directly from CD
(or the main directory of any drive, including USB sticks). I have
managed to integrate MediaWiki into it. While a MySQL variant is
available, I went for a new MediaWiki database type supporting
plain-text files (read-only at the moment). Back to the roots, I guess ;-)

Anyway, I have created what I hope is a standalone, zero-install
"History Wikipedia 0.5" bundle, currently consisting of a pityful 19
articles. This was done by converting the above mentioned
custom-XML-dump into plain-text articles using a script from my wiki2xml
toy.

Categories don't work, and I was too lazy to set up interlanguage links.
No images either.

Still interested? Try
http://tools.wikimedia.de/~magnus/history05.zip   (23MB)

Best to burn the whole thing to a CD, as it /has/ to be in the root
directory. I *did* mention that it's currently Windows-only, right?

Magnus

-------------- 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/20060626/f75a94ab/attachment-0001.pgp>


list: wikipedia-l

subject:
[Wikipedia-l] [Foundation-l] moving forward on article
	validation

body:
I have made some new toys that might be of interest:

Instead of waiting for the next database dump and downloading the whole
thing, you can now get a XML dump for all articles in a category and its
subcategories:

http://tools.wikimedia.de/~magnus/cat2xml.php?category=History_Version_0.5_articles

Sadly, the toolserver is somewhat broken for use on en, so it doesn't
even know "Category:Wikipedia Version 0.5", but that is someone else's
problem (since ages, I might add). So until this is fixed, you can't get
the complete article texts for 0.5 in one swift motion, but then! ;-)

I have also found a web server (Server2Go) which runs directly from CD
(or the main directory of any drive, including USB sticks). I have
managed to integrate MediaWiki into it. While a MySQL variant is
available, I went for a new MediaWiki database type supporting
plain-text files (read-only at the moment). Back to the roots, I guess ;-)

Anyway, I have created what I hope is a standalone, zero-install
"History Wikipedia 0.5" bundle, currently consisting of a pityful 19
articles. This was done by converting the above mentioned
custom-XML-dump into plain-text articles using a script from my wiki2xml
toy.

Categories don't work, and I was too lazy to set up interlanguage links.
No images either.

Still interested? Try
http://tools.wikimedia.de/~magnus/history05.zip   (23MB)

Best to burn the whole thing to a CD, as it /has/ to be in the root
directory. I *did* mention that it's currently Windows-only, right?

Magnus

-------------- 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/wikipedia-l/attachments/20060626/f75a94ab/attachment.pgp


subject: [WikiEN-l] Offline submissions?

body:
On 6/26/06, Alphax (Wikipedia email) <alphasigmax at gmail.com> wrote:
>
> mboverload wrote:
> > Maybe I'm the only one here, but I say "Who cares?"
> >
> > If they don't have a computer they don't have the time to write an
> > encyclopedia.
>
> Wow, that says a *lot* about your attitude.
>
> Do even contribute to Wikipedia, or are you just another troll?
>
> --
> Alphax - http://en.wikipedia.org/wiki/User:Alphax
> Contributor to Wikipedia, the Free Encyclopedia
> "We make the internet not suck" - Jimbo Wales
> Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP
>

Thank you for the kind words.  I'll be sure to censor any thoughts that
don't conform to your views in the future.

mboverload


from_name: Nick Jenkins

body:
[Brion Vibber wrote]:
> As I understand it, this was fixed a few hours ago, and was present for just a
> few hours before that; so if you updated from SVN trunk in the last day, make
> sure you update again. :)

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.

Looking back at what happened, the timeline roughly went like this:

2006-06-23 13:15:59: Bug accidentally introduced by small change.
2006-06-23 19:30:00: Current SVN checked out by me.
2006-06-23 19:45:00: Test script started, and after a few minutes reports unexpected results.
2006-06-23 20:55:00: Me narrowing down the problem.
2006-06-23 20:05:00: Details sent by me to devs.
2006-06-23 20:13:57: Bug fixed and checked into SVN.

So within 7 hours it was accidentally introduced, found, reported, and fixed - which I think is an amazingly quick cycle ... and of
these steps, the slowest part of all was me! ;-)

[Tim Starling wrote]:
> This sort of thing really doesn't need to be reported to wikitech-l.

Whoa! Time out for a reality check.

Let me say this very simply: YOU DON'T GET TO MAKE THAT DECISION. The ONLY person who gets to choose how a bug is reported is THE
PERSON WHO FINDS IT.

If I find a bug, then I, and only I, get to choose what to do with that information.

Now, there are a very wide variety of responses to finding bugs.

Some of them include:
1) Do nothing. I could find a bug, and just sit on it. I don't have to tell anybody. (For example, I never bother reporting bugs to
Microsoft any more).
2) Report it to bugzilla.
3) Report it to the developers directly via email.
4) Report it to a technical mailing list about that product, with very limited or no details.
5) Report it to a technical mailing list about that product, with Proof-of-Concept code.
6) Mail it straight it to bugtraq, together with Proof-of-Concept code.
7) Post it anonymously on a script-kiddies bulletin-board.
8) Sit on it, and store up exploits until there is critical number (e.g. 10), and then combine them into some kind of MediaWiki-worm
that knows how to attack all 10 exploits + change a few words / numbers in random articles, and then release it anonymously without
warning at 3 PM on a Wednesday afternoon at peak server load, and then sit back and watch the resulting car crash.

That's 8 possible responses, from the nice to the incredibly antisocial, from the indifferent through to the illegal. There are more
responses, and of course some of the responses can be combined. But all of those responses have one thing in common: None of those
decisions are made by you.

Now, as a general rule I choose to do option 3 (mail the devs) for non-security related bugs, and option 3 + option 4 (mail the devs
+ mail a heads up to wikitech-l) for security bugs that have a working Proof-of-Concept attack.

I choose to do this because I think it is most positive and constructive thing to do with that information. It gives those with the
capacity to fix the problem the details they need in order to know how to fix it; and it gives those who may be affected by the
problem the information to know that they will probably want to update shortly and to be wary of exploits, whilst not giving
attackers the details they need to be harmful. In particular, I think mailing wikitech-l a quick email with details of which
version(s) are affected, the general category of the security bug, but no specific details, is useful. The reason it is useful is
because if someone chooses to run a particular tree (in spite of suggestions that they shouldn't), they will know that there is a
particular type of security issue, and then they can update to keep themselves protected; Also the users of those sites can be aware
of potential exploits until the problem is resolved. Last but not least, if _I_ was running an affected MediaWiki install, then I
would want to know: so telling people this to me is a case of treating others how you would have them treat you.

Now, if you or anyone else doesn't like those heads-up notices, then there's a simple answer: Don't read them! I don't know about
you, but I get hundreds of spam emails per day, and I'm quite capable of completely ignoring them, and not reading them. So if
heads-up notices about security issues in software you're involved with bother you, then don't read them. That's YOUR response,
which YOU GET TO CHOOSE.

Of course, in my personal opinion, the best response is probably sending a reply like this to wikitech-l:
-------------------------------------
Thank you for your MediaWiki bug report. We believe the issue that you reported has now been fixed in SVN revision 14990
 http://mail.wikipedia.org/pipermail/mediawiki-cvs/2006-June/015970.html ).

Updated releases of the stable tree are released periodically as tarballs, and release announcements are sent to the
MediaWiki-announce mailing list. Current snapshots of the development tree can be grabbed by doing an svn checkout/update of the
current development source code.

Thank you for your report and for helping us to make MediaWiki even better.
-------------------------------------

Sending that to wikitech-l in response to a security heads-up on the same list gets you several things:
1) It acknowledges that you got the original bug report.
2) It confirms that there was a problem.
3) It tells everyone that the problem is now fixed.
4) It sends the clear message that "this software is well maintained and we respond promptly to security issues".
5) It tells any affected site admins which release / version they need to update to order to be protected from the problem.
6) It thanks the reporter - because although you mightn't realise it, finding these types of problems can be hard work, and a little
thanks never goes astray.

[Tim Starling wrote]:
> Further to that, I would appreciate it if Nick would commit his testing
> scripts to SVN, and document them fully. It would be easier if we could do
> this testing before we commit, rather than go through all this rigmarole.

I shall be happy to email yourself and Brion an updated version of the script that I'm using (you'll have to check it in, as I don't
have commit privileges). I'll endeavour to get it you today, but failing that some time this week. As with all software I'm sure it
can be improved, but it's probably better to have something more current checked in to the tree than the old version that is there
currently.

Please note however that the script mightn't be quite what you think it is: For example, I didn't have a test for this specific
IpBlockList problem ready to go just waiting for this exact problem. Rather I had a script that generates tests, runs those tests,
and if it fails keeps the tests. So I ran it for a few minutes, it generated a specific IpBlockList test that failed, and then I
took a closer look at the generated test that failed, and said "Oh, that's interesting". So it's a test generator and runner and
result-checker, not a set of predefined static tests.

As such, as a constructive suggestion, one possibility might be to add a cronjob similar to how parserTests gets run nightly and the
results are mailed to wikitech-l. Currently the script runs until stopped with CTRL-C, and it prints out progress information as it
goes. So as a possibility, you could perhaps update it to accept some command line parameters (such as adding a silent mode that
only prints out real errors to make it less chatty, and adding something so that you could specify to run for a specific amount of
time [e.g. 1 hour] instead of indefinitely, and maybe also a maximum number of errors to report). Then the resulting nightly output
could be emailed to wikitech-l, or you could set up a separate private mail alias if you wanted (I'd be happy to be included on
this, as it may or may not require some explaining at first about what it's upset about, and it might require a bit of tweaking to
get the right level of information from the script). That way you'd get an additional different and complementary type of continuous
nightly testing to help catch any regressions or other problems.

All the best,
Nick.


subject: [WikiEN-l] New York Times article

body:
Oh yes, true.  You got me there, I'll admit.

mboverload

On 6/26/06, Steve Bennett <stevagewp at gmail.com> wrote:
>
> On 6/26/06, mboverload <mboverload at gmail.com> wrote:
> > Yes, I feel so bad for the people who don't want to spend one minute
> > registering to edit. Semiprotection is used on so few articles I fail to
> see
> > how it could have any impact.
>
> Remember, semiprotection blocks new users, not just unregistered users.
>
> Steve
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Tim Starling

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

body:
Nick Jenkins wrote:
> [Tim Starling wrote]:
>> This sort of thing really doesn't need to be reported to wikitech-l.
>
> Whoa! Time out for a reality check.
>
> Let me say this very simply: YOU DON'T GET TO MAKE THAT DECISION. The ONLY person who gets to choose how a bug is reported is THE
> PERSON WHO FINDS IT.

No shit, Sherlock. You have the ability to choose how you behave. You can
throw rocks through windows or cry when you don't get your way, or whatever
you feel like doing. I'm only suggesting that you have some consideration
when you choose your path.

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.

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.

Now as you rightly point out, you are free to make these posts. But that
doesn't mean you're going to make any friends by doing it. Yes, you are free
to annoy as many people as you like, but I think you will find that to be a
bitter and unfulfilling path to take in life.

> I shall be happy to email yourself and Brion an updated version of the script that I'm using (you'll have to check it in, as I don't
> have commit privileges). I'll endeavour to get it you today, but failing that some time this week. As with all software I'm sure it
> can be improved, but it's probably better to have something more current checked in to the tree than the old version that is there
> currently.

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

-- Tim Starling


from_name: stevertigo

subject: [WikiEN-l] Ugly == "edit this page (read only)"

body:
Somebody please put it back.
Its like instruction creep for global tabs.

Svertigo

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


from_name: Theresa Knott

body:
On 6/26/06, abu hamza <abuhamza1970 at hotmail.com> wrote:

> If you go to the muslim guild on wikipedia
> http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Islam:The_Muslim_Guild
> and you look at all the entrents, everyone is currently under threat of an
> indefinate ban or idefinately banned. I think the idea of having a greater
> participation is lip service.

That would be terrible if it were true. However a quick glance down
this list of 27 active members makes me suspect that you are over
exaggerating here. Do you have any evidence to back such a claim up?

Theresa


from_name: Kurt Jansson

body:
Hi Brad!

> 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.

I haven't had the time to take a look at them, but in their latest open source
study the German Fraunhofer Society mentioned - besides SugarCRM - the packages
http://www.opencrx.org/ and http://www.wice.de/ as the only open source CRM
software that can compete with its proprietary competitors.

The German computer magazine c't tested some open source CRM packages (but not
wice) and drew the conclusion, that only SugarCRM and it's spin-off Vtiger are
really usable at the moment. OpenCRX has an impressing feature set but would
lack intuitive usability.
http://www.heise.de/open/artikel/73338

Kurt


subject: [WikiEN-l] Offline submissions?

body:
On 6/26/06, maru dubshinki <marudubshinki at gmail.com> wrote:

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

A link? What's the point?

Steve


from_name: Ray Saintonge

body:
Steve Bennett wrote:

>On 6/26/06, Rob Church <robchur at gmail.com> wrote:
>
>
>>It would be somewhat trivial to expand the extension to allow
>>customising the class output according to the tag used; if another use
>>case pops up, we can add another tag and class combination.
>>
>>
>That seems to be the strongest argument for making a generic tag
>wrapped in a template to set the class. Currently, if a user at fooboo
>wiki wants to get the behaviour of <poem> for something that isn't a
>poem, their choices are:
>
>1) Wrap it in <poem> anyway, defeating the whole point of semantic mark up.
>2) Attempt to imitate it by implementing something that doesn't quite
>work as well with templates.
>3) Attempt to hack the mediawiki source code to copy <poem>, making
>something nonportable.
>4) Attempt to convince the MediaWiki developers of the validity of
>their "use case" and wait for it to get implemented.
>5) Wrap <poem> in a <div class="foo">, store that in a template, carry
>out step 4) and reimplement the template with a clean new tag.
>
Speaking as a general non-technical user I would have no compunctions
about using the <poem> tag wherever it works, including recipes and
other non-poetic circumstances.

The average user is intersted in what works, not just the satisfaction
of the arcane technical aesthetics of IT specialists.

Ec


subject:
[Wikipedia-l] [Foundation-l] moving forward
	on	article	validation

body:
Alphax (Wikipedia email) schrieb:
> Magnus Manske wrote:
>
>> I have made some new toys that might be of interest:
>>
>> Instead of waiting for the next database dump and downloading the whole
>> thing, you can now get a XML dump for all articles in a category and its
>> subcategories:
>>
>> http://tools.wikimedia.de/~magnus/cat2xml.php?category=History_Version_0.5_articles
>>
>> Sadly, the toolserver is somewhat broken for use on en, so it doesn't
>> even know "Category:Wikipedia Version 0.5", but that is someone else's
>> problem (since ages, I might add). So until this is fixed, you can't get
>> the complete article texts for 0.5 in one swift motion, but then! ;-)
>>
>>
>>
>> I have also found a web server (Server2Go) which runs directly from CD
>> (or the main directory of any drive, including USB sticks). I have
>> managed to integrate MediaWiki into it. While a MySQL variant is
>> available, I went for a new MediaWiki database type supporting
>> plain-text files (read-only at the moment). Back to the roots, I guess ;-)
>>
>> Anyway, I have created what I hope is a standalone, zero-install
>> "History Wikipedia 0.5" bundle, currently consisting of a pityful 19
>> articles. This was done by converting the above mentioned
>> custom-XML-dump into plain-text articles using a script from my wiki2xml
>> toy.
>>
>> Categories don't work, and I was too lazy to set up interlanguage links.
>> No images either.
>>
>> Still interested? Try
>> http://tools.wikimedia.de/~magnus/history05.zip   (23MB)
>>
>> Best to burn the whole thing to a CD, as it /has/ to be in the root
>> directory. I *did* mention that it's currently Windows-only, right?
>>
>>
>
> How big is it unpacked? Would it be small enough to fit on a cheap USB
> drive?
>

78 MB for the software, plus the (currently uncompressed) text. I'm sure
I could cut off some size if need arises, but for now I'm just happy it
works :-)

Magnus

-------------- 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/wikipedia-l/attachments/20060626/2a42fb9b/attachment.pgp


from_name: Alphax (Wikipedia email)

subject: [WikiEN-l] Offline submissions?

body:
mboverload wrote:
> Maybe I'm the only one here, but I say "Who cares?"
>
> If they don't have a computer they don't have the time to write an
> encyclopedia.

Wow, that says a *lot* about your attitude.

Do even contribute to Wikipedia, or are you just another troll?

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

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


subject: [WikiEN-l] Offline submissions?

body:
Theresa Knott wrote:
> 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?
>

Being able to retrieve articles via email would be nice...

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

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


subject: [Wikitech-l] Zwinger down

body:
Brion Vibber wrote:

>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 )
>
If the illness proves fatal a moment of silence at Wikimania may be in
order. :-(

Ec


from_name: Ilmari Karonen

subject: [Wikitech-l] Mass open proxy blocking

body:
Sui Min wrote:
>
> Is there a way to share blocked open proxy infomation over projects
> like spam blacklist?

'''Support'''. :)  This would be a very useful feature.  We have a lot
of good solutions for detecting and blocking open proxies, but they all
suffer from having to duplicate each others' efforts.

The only question is how to implement it.  Perhaps we could make it so
that any IPs blocked on Meta are blocked on all the Wikimedia wikis as
well.  That'd be a SMOP, and would avoid the need for a new blocking
interface with its associated access control issues.

Alternatively, shifting the effort to the front end, we could set up our
_own_ DNSBL and create some kind of an admin interface to it.  Then we
could use the existing "SORBS" code (which really ought to be renamed)
to do the back end work.

I suppose an implementation similar to the current spam blacklist could
also work, and would be really simple to set up.  I doubt it'd scale as
well, though.

--
Ilmari Karonen


body:
Whoa, that's cool. lol, I don't know why I thought that the configuration of
the interface couldn't be in the wiki too =D

mboverload

On 6/26/06, xaosflux <xaosflux at gmail.com> wrote:
>
> This has been fixed:
>
> http://en.wikipedia.org/w/index.php?title=MediaWiki%3AViewsource&diff=60747575&oldid=60725522
>
> ----- Original Message -----
> From: "stevertigo" <vertigosteve at yahoo.com>
> To: "English Wikipedia" <wikien-l at Wikipedia.org>
> Sent: Monday, June 26, 2006 7:02 PM
> Subject: [WikiEN-l] Ugly == "edit this page (read only)"
>
>
> > Somebody please put it back.
> > Its like instruction creep for global tabs.
> >
> > Svertigo
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> > _______________________________________________
> > WikiEN-l mailing list
> > WikiEN-l at Wikipedia.org
> > To unsubscribe from this mailing list, visit:
> > http://mail.wikipedia.org/mailman/listinfo/wikien-l
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Felipe Ortega

body:
Hello Erik.

My name' s Felipe Ortega, Ph.D. student at the Rey Juan Carlos University (Madrid, Spain). I' m currently working on my thesis, trying to build a quantitative analysis model for Wikipedia. I' ve carefully studied all your efforts as Wikipedia admins and application contributors in this field.

In the past few weeks I' ve read a bunch of mail messages talking about what is precisely my first goal: extracting behavioral conclusions from a quantitative analysis of wikipedia database dumps in all languages.

But, despite all my efforts, and some mails offering myself as contributor I have received no answer from Wikipedia Community. I only wanted to contribute in a very interesting area (I think) and I hope it could lead me to build an interesting thesis about this topic. I'm currently developing some scripts in Phyton that analyze database dumps.

I wrote a paper with some preliminar results, if you may take a glance to it. I only ask for some collaboration from anyone involved with the project, because otherwise maybe I should simply think that all my efforts don' t bother anyone.

Thanks.

Felipe Ortega.

Erik Zachte <erikzachte at infodisiac.com> escribi?: Jimbo:
> It would be nice to track that number over time... are we becoming
"younger" as a community, "older" as a community?
> Staying about the same?  Are old-timers sticking around longer than they
used to, or jumping ship faster?
> There are also a whole set of related questions.

You know I was just thinking to do something similar for mailling lists. Are
people active on a certain list for a long time etc.

I will put the above questions on my wikistats todo list.
First need to focus on unicode update for EasyTimeline which has been in the
queue for way too long.

Erik Zachte

_______________________________________________
Wikitech-l mailing list
Wikitech-l at wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/wikitech-l

---------------------------------

LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y m?viles desde 1 c?ntimo por minuto.
http://es.voice.yahoo.com


from_name: DaB.

subject: [Wikitech-l] Zwinger down

body:
Hello,
Am Sonntag, den 25.06.2006, 22:44 -0700 schrieb Brion Vibber:
> 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.

over zwinger runs the sql-tunnels from zedler to the databases (adler
and ariel). Can someone please create the user pppuser with the same
ssh-public key on the new server?

>
> -- brion vibber (brion @ pobox.com)

Sincerly,
DaB.
--
Blog: http://www.wp-blog.de | PGP: 2D3EE2D42B255885


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

body:
Steve Bennett wrote:
>
> But in any case, I don't think the syntax/meaning of space indentation
> is likely to change, so this is a bit moot.

Indeed.  To put this in historical perspective, I believe the use of
indentation for source code (and preformatted text in general) can be
traced back to Cunningham's original WikiWikiWeb.  He may have got the
idea from POD, which was introduced with about six months earlier with
Perl 5.  I'm not sure where the idea came from before that -- I suppose
it's possible it was invented by Larry Wall, but it's also possible that
he got the idea from some other markup language.

--
Ilmari Karonen


from_name: Steve Bennett

subject: [WikiEN-l] Offline submissions?

body:
On 6/26/06, stevertigo <vertigosteve at yahoo.com> wrote:
> 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.

Why not the talk page? In the beginning at least, it seems quite
feasible simply to append tags like:

==Incoming email 26/6/06==
From: <some mangling of email address>
<text.............>

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?
> 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.

Steve


from_name: Timwi

body:
Tim Starling wrote:
>
> No shit, Sherlock. [...] I'm only suggesting that you have some consideration
> when you choose your path.

If you read his posting in its entirety, you will notice that he has
actually put a heck of a lot of consideration into this particular
decision, *and* he has even gone for the trouble of writing it all up
for *your* benefit. You are being very ungrateful in my opinion.

> 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.

OMFG my holy and sacred MediaWiki! It is the most secure and stable in
the universe and anyone who doubts it is a heretic and must be burnt at
the stake!

Seriously, security flaws need to be pointed out. *Especially* in
open-source software.

Timwi


from_name: Krzysztof Jasiutowicz

body:
Hi,

I am writing to this list to inquire about possibility of setting up
and maintaining up-to-date static HTML content of major
Wikipedia/Wikimedia sites (for example
http://download.wikimedia.org/static/).

I'd like to invite people from Wikimedia tech team to cooperate with
the static content subcommittee of Special Projects Committee on
technical aspects of its tasks. We need your help.

Please see:
http://meta.wikimedia.org/wiki/Special_projects_committee
http://meta.wikimedia.org/wiki/Static_content_subcommittee

Best regards,
Kpjas
--
Wikipedia - World's Greatest http://www.wikipedia.org


from_name: Jay R. Ashworth

references:
<NABBJGECPILFNLFEAPIKGENDIFAA.nickpj@gmail.com>
	<NABBJGECPILFNLFEAPIKOEPJIFAA.nickpj@gmail.com>
	<e7nrtv$t4i$1@sea.gmane.org> <e7p9d0$skr$1@sea.gmane.org>
	<20060626190942.GA10332@apotheon.com>

body:
On Mon, Jun 26, 2006 at 01:09:42PM -0600, Chad Perrin wrote:
> On Mon, Jun 26, 2006 at 07:35:00PM +0100, Timwi wrote:
> > Seriously, security flaws need to be pointed out. *Especially* in
> > open-source software.
>
> One of the big problems I have with a lot of proprietary software is the
> unwillingness of its vendor to admit flaws and tell us, the users, that
> there's a problem of which we should be aware.  I tend to view open and
> frank, helpful discussion of security issues to be a net win when I'm
> evaluating software to determine whether I want to use it, and ominous
> silences as a sign that if a vulnerability arises, I won't find out
> until it's too late.

And, FWIW, while I think there's a whole lot of overreaction on this
thread, on both sides, I come down a bit right of center as well: I
believe that it would be useful to have it documented in the archives
that there *was* such a problem, at timestamp X, such that if someone
is using SVN and happened to pull that particular rev, they have the
opportunity to know.

Remember: while running SVN revs in production is not the recommended
approach, there are people who do it.

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?


from_name: Mathias Schindler

body:
On 6/26/06, Eric Astor <eastor1 at swarthmore.edu> wrote:
> On this note, would it be possible to get a public pointer to the full
> skins, modifications, and so forth used in creating the latest static dumps
> (as at http://static.wikipedia.org)? Several projects I know of (including
> the OEPC project I'm working on) are looking for ways to create good static
> exports, and the November dumps come out looking excellent.

Shouldn't it be included in the sources?

http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/maintenance/dumpHTML.php?revision=12476&view=markup

Greetings,
Mathias (who played around with dumpHTML.php a few months ago without
getting into the details)


from_name: xaosflux

body:
This has been fixed:
http://en.wikipedia.org/w/index.php?title=MediaWiki%3AViewsource&diff=60747575&oldid=60725522

----- Original Message -----
From: "stevertigo" <vertigosteve at yahoo.com>
To: "English Wikipedia" <wikien-l at Wikipedia.org>
Sent: Monday, June 26, 2006 7:02 PM
Subject: [WikiEN-l] Ugly == "edit this page (read only)"

> Somebody please put it back.
> Its like instruction creep for global tabs.
>
> Svertigo
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l


from_name: amgine at saewyc.net

subject: [Foundation-l] Vicenza, Italy

body:
> Wikimedia Italia just finished a long 4-day weekend of presentation of
> Wikipedia and Wikimedia projects to the thousands of visitors of
> "FestAmbiente", held in a park of Vicenza, in northern Italy.
> Wikipedians gathered from half of the country (and from the
> Italian-speaking
> area of Switzerland as well).
> Frieda had also a question time on Sunday afternoon with the public.
>
> Details (in Italian only, for the moment, sorry) and photos at
> http://it.wikipedia.org/wiki/Wikipedia:Raduni/Vicenza_2006
>
> Bye all,
> G. (aka Paginazero)

WooHoo! Congratulations Wikimedia Italia! This looks wonderful (and
exhausting!) The pictures are especially nice; you show us some of the
many things Wikimedians must do besides editing. <grin>

Many congratulations, and thank you for the link!

Amgine


subject: [Foundation-l] Vicenza, Italy


body:
On Mon, Jun 26, 2006 at 04:53:45PM -0700, Ray Saintonge wrote:
> Speaking as a general non-technical user I would have no compunctions
> about using the <poem> tag wherever it works, including recipes and
> other non-poetic circumstances.
>
> The average user is intersted in what works, not just the satisfaction
> of the arcane technical aesthetics of IT specialists.

For sufficiently small values of "works".

This is why Doing Things Right is so damned difficult.

<rant>
It's not aesthetic, it's not technical, and it's not arcane.

Recipes aren't poems.
</rant>

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?


from_name: Pedro Sanchez

subject: [WikiEN-l] Exit Interview -- Jon Awbrey

body:
On 6/23/06, Jon Awbrey <jawbrey at att.net> wrote:
> o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
>
> Jesse W wrote:
> >
> > Oh, [[Truth]]!
> > One of the articles-which-are-nearly-all-the-time-in-a-
> > state- of-total-complete-insane-edit-war/massive-blather!
> > It's a highly subtle concept, that *everyone* thinks they
> > know a vast amount about, that there are very few clear,
> > uncontroversial facts about.  That's enough to make the
> > devil jump with joy at all the craziness that can be
> > created there.  I'm sorry you got sucked in, but
> > it's one of the worst tar pits on the wiki!
> >
> > Jesse Weinstein
>
> ''now'' you tell me ...
>
> fly in amber,
>
> ja
>
> o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
> inquiry e-lab: http://stderr.org/pipermail/inquiry/
> wiki: http://en.wikipedia.org/wiki/user:Jon_Awbrey
> o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

TELL ME THE TRUTH!!!!

(sorry I couldn't resist)


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

body:
On 6/25/06, Steve Bennett <stevagewp at gmail.com> wrote:
> 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.

* The punishment is only banning for 24 hours.
: Yes, but some people, after discovering wikipedia, think a temporary
block amounts to censorship, violating rights, constitutions stuff
blah blah blah. I've seen it even for 1-3 hours blocking.

:So,  can't edit wikipedia for a few hours? What a terrible thing!!
but live with it and move on.


subject: [WikiEN-l] What is "spam?"

body:
On 6/22/06, Daniel P. B. Smith <wikipedia2006 at dpbsmith.com> wrote:
> > From: "Alphax (Wikipedia email)" <alphasigmax at gmail.com>
> >
> > Nathan wrote:
> >> I remember having an imposter with a weird unicode version of the
> >> first
> >> "N" in my username. In fact, it's my only imposter.
> >>
> >> I think such usernames should be blocked too.
> >>
> >> - Nathan (nathanrdotcom)
> >>
> >
> > I think *your* username is innappropriate since you're spamming
> > your URL
> > in it.
>
> Yeesh. Give him a break.
>
> It's unobtrusive. It's a username, so it never appears in the main
> namespace. It's not a link, so it won't affect his site's pagerank.
>
> And if you look at that site, _it's just a personal website,_ no
> different in kind from a Wikipedia user page.
>
> On the spectrum from where co-opting Wikipedia for commercial gain is
> a ten and obnoxious self-promotion is a one, this is a zero. It's
> about as objectionable as using a username that happens to resemble
> one's email address.
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

Yes cut him ome slack. However " _it's just a personal website,_ no
different in kind from a Wikipedia user page." is precisely the
mindset that has led to such tiemwasting poinltess arguments in the
past months. No. your userpage is not your personal webpage. You
cannot write whatever you want, and anyone can touch it, you cannot
cry foul if someone else edits it. It's not for furthering points of
view, political agendas, etc.

Wikipedia's userpages are to organize your wikiwork. Period.


from_name: Nick Jenkins

body:
> 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.

Some keyword hits: mediawiki security analysis, personal independent mediawiki security summary.

Dear future google reader:

Before you judge too quickly, please let me say this: Mediawiki seems pretty secure to me. Finding security bugs in the MediaWiki
software is hard. Every bug I have found, I have reported (over 50 at last count, only a proportion of which were security related,
and of those only 4 were confirmed exploitable). However you should not be alarmed by these numbers, because I am actively trying to
break this software in whacky ways, and you won't be. When I report bugs to the developers, they fix security bugs usually within
the hour, and they fix general bugs usually within a few days. This is very quick, and it indicates this software is actively being
maintained and improved. I am happy to use this software myself for my personal website, and I would not be afraid to use MediaWiki
as a general knowledge & collaboration repository on the Internet or an intranet. However, I would suggest not using it to store
your bank details or credit card details or suchlike. Later versions always seem more robust than earlier versions to me, so you
should try to run the latest stable version if you can. Do not use the development version in subversion unless you are willing to
keep up-to-date, because it is always under active development.

Overall, as a potential user, you should feel good about the fact that someone has tried to break this software. It's a definite
plus. That might seem paradoxical, because you may feel concerned that bugs may be found. However, that's the wrong attitude: Good
software (such as OpenSSH, Linux, apache) has had people systematically trying to break it, and developers actively fixing the stuff
they find. For best results, both ingredients are required (breakers & fixers). This software has that. Understand that all software
has bugs. Anyone who says otherwise is probably trying to sell you something. But every bug that gets found and fixed is one less
bug that you have to worry about. In my opinion, you should be wary of software that has not gone through such a process, because
it's probably less secure that it first appears, whilst software that has gone through this process is more secure than it first
appears. Bugs generally persist until removed: the only question is whether someone has gone looking for them.

> 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?

That sounds fine, and I happily agree. It seems a reasonable balance to me.

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

Don't worry about it, it's an extremely easy thing to miss. It's also partially the name of the variable, $ip, and its implications,
as we expect IP addresses to be things like "12.34.56.32", and we simply don't expect an IP address to contain things like
'"><script>'.

All the best,
Nick.


from_name: Dirk Riehle

body:
I recommend you also look at a full-blown ERP package like Compiere,
www.compiere.org, whether its CRM package fulfills your needs.

The advantage of Compiere is that it has been around for a while, is
likely to spare you future integration and extension hassles, and did
not have an incident like the SugarCRM vs VTiger shootout yet.

Dirk

At 25.06.2006, Angela wrote:
>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.
>_______________________________________________
>foundation-l mailing list
>foundation-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/foundation-l


from_name: Rob Church

subject: [Wikitech-l] Mass open proxy blocking

body:
On 26/06/06, Platonides <Platonides at gmail.com> wrote:
>
> Blocking could be checked against two tables (or even a table array). The
> first one would be per-wiki, while the second one would be shared between
> wikis.

Let's stop talking about global blocking/permissions/etc. until single
sign-on is complete. Then we can bolt things onto it. Without
centralised user identification and authentication, we can do absolute
Jack about global blocks.

Rob Church


subject:
[Wikipedia-l] [Foundation-l] moving forward on
	article	validation

body:
Magnus Manske wrote:
> I have made some new toys that might be of interest:
>
> Instead of waiting for the next database dump and downloading the whole
> thing, you can now get a XML dump for all articles in a category and its
> subcategories:
>
> http://tools.wikimedia.de/~magnus/cat2xml.php?category=History_Version_0.5_articles
>
> Sadly, the toolserver is somewhat broken for use on en, so it doesn't
> even know "Category:Wikipedia Version 0.5", but that is someone else's
> problem (since ages, I might add). So until this is fixed, you can't get
> the complete article texts for 0.5 in one swift motion, but then! ;-)
>
>
>
> I have also found a web server (Server2Go) which runs directly from CD
> (or the main directory of any drive, including USB sticks). I have
> managed to integrate MediaWiki into it. While a MySQL variant is
> available, I went for a new MediaWiki database type supporting
> plain-text files (read-only at the moment). Back to the roots, I guess ;-)
>
> Anyway, I have created what I hope is a standalone, zero-install
> "History Wikipedia 0.5" bundle, currently consisting of a pityful 19
> articles. This was done by converting the above mentioned
> custom-XML-dump into plain-text articles using a script from my wiki2xml
> toy.
>
> Categories don't work, and I was too lazy to set up interlanguage links.
> No images either.
>
> Still interested? Try
> http://tools.wikimedia.de/~magnus/history05.zip   (23MB)
>
> Best to burn the whole thing to a CD, as it /has/ to be in the root
> directory. I *did* mention that it's currently Windows-only, right?
>

How big is it unpacked? Would it be small enough to fit on a cheap USB
drive?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 564 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20060627/6092121e/attachment.pgp


subject: [WikiEN-l] New York Times article

body:
On 6/26/06, mboverload <mboverload at gmail.com> wrote:
> Yes, I feel so bad for the people who don't want to spend one minute
> registering to edit. Semiprotection is used on so few articles I fail to see
> how it could have any impact.

Remember, semiprotection blocks new users, not just unregistered users.

Steve


from_name: brion at pobox.com

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

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!


from_name: Platonides

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

body:
You're doing a good work, Nick. Bug exploiting is not an easy way, and
you've caught quite a lot for the time you've being hunting them.
Personally, i *do* like knowing that. It would be much worse if i knew them
on option 8! I personally understand you wanting to be on such security-risk
mail list ;-)
If i tried to figure out from your reports here where the security hole was,
it'd probably be fixed when i could begin to _see_ it.

"Nick Jenkins" wrote:
> [Brion Vibber wrote]:
>> As I understand it, this was fixed a few hours ago, and was present for
>> just a
>> few hours before that; so if you updated from SVN trunk in the last day,
>> make
>> sure you update again. :)
>
> 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.
>
> Looking back at what happened, the timeline roughly went like this:
>
> 2006-06-23 13:15:59: Bug accidentally introduced by small change.
> 2006-06-23 19:30:00: Current SVN checked out by me.
> 2006-06-23 19:45:00: Test script started, and after a few minutes reports
> unexpected results.
> 2006-06-23 20:55:00: Me narrowing down the problem.
> 2006-06-23 20:05:00: Details sent by me to devs.
> 2006-06-23 20:13:57: Bug fixed and checked into SVN.
>
> So within 7 hours it was accidentally introduced, found, reported, and
> fixed - which I think is an amazingly quick cycle ... and of
> these steps, the slowest part of all was me! ;-)
>
> [Tim Starling wrote]:
>> This sort of thing really doesn't need to be reported to wikitech-l.
>
> Whoa! Time out for a reality check.
>
> Let me say this very simply: YOU DON'T GET TO MAKE THAT DECISION. The ONLY
> person who gets to choose how a bug is reported is THE
> PERSON WHO FINDS IT.
>
> If I find a bug, then I, and only I, get to choose what to do with that
> information.
>
> Now, there are a very wide variety of responses to finding bugs.
>
> Some of them include:
> 1) Do nothing. I could find a bug, and just sit on it. I don't have to
> tell anybody. (For example, I never bother reporting bugs to
> Microsoft any more).
> 2) Report it to bugzilla.
> 3) Report it to the developers directly via email.
> 4) Report it to a technical mailing list about that product, with very
> limited or no details.
> 5) Report it to a technical mailing list about that product, with
> Proof-of-Concept code.
> 6) Mail it straight it to bugtraq, together with Proof-of-Concept code.
> 7) Post it anonymously on a script-kiddies bulletin-board.
> 8) Sit on it, and store up exploits until there is critical number (e.g.
> 10), and then combine them into some kind of MediaWiki-worm
> that knows how to attack all 10 exploits + change a few words / numbers in
> random articles, and then release it anonymously without
> warning at 3 PM on a Wednesday afternoon at peak server load, and then sit
> back and watch the resulting car crash.
>
> That's 8 possible responses, from the nice to the incredibly antisocial,
> from the indifferent through to the illegal. There are more
> responses, and of course some of the responses can be combined. But all of
> those responses have one thing in common: None of those
> decisions are made by you.
>
> Now, as a general rule I choose to do option 3 (mail the devs) for
> non-security related bugs, and option 3 + option 4 (mail the devs
> + mail a heads up to wikitech-l) for security bugs that have a working
> Proof-of-Concept attack.
>
> I choose to do this because I think it is most positive and constructive
> thing to do with that information. It gives those with the
> capacity to fix the problem the details they need in order to know how to
> fix it; and it gives those who may be affected by the
> problem the information to know that they will probably want to update
> shortly and to be wary of exploits, whilst not giving
> attackers the details they need to be harmful. In particular, I think
> mailing wikitech-l a quick email with details of which
> version(s) are affected, the general category of the security bug, but no
> specific details, is useful. The reason it is useful is
> because if someone chooses to run a particular tree (in spite of
> suggestions that they shouldn't), they will know that there is a
> particular type of security issue, and then they can update to keep
> themselves protected; Also the users of those sites can be aware
> of potential exploits until the problem is resolved. Last but not least,
> if _I_ was running an affected MediaWiki install, then I
> would want to know: so telling people this to me is a case of treating
> others how you would have them treat you.
>
> Now, if you or anyone else doesn't like those heads-up notices, then
> there's a simple answer: Don't read them! I don't know about
> you, but I get hundreds of spam emails per day, and I'm quite capable of
> completely ignoring them, and not reading them. So if
> heads-up notices about security issues in software you're involved with
> bother you, then don't read them. That's YOUR response,
> which YOU GET TO CHOOSE.
>
> Of course, in my personal opinion, the best response is probably sending a
> reply like this to wikitech-l:
> -------------------------------------
> Thank you for your MediaWiki bug report. We believe the issue that you
> reported has now been fixed in SVN revision 14990
> http://mail.wikipedia.org/pipermail/mediawiki-cvs/2006-June/015970.html ).
>
> Updated releases of the stable tree are released periodically as tarballs,
> and release announcements are sent to the
> MediaWiki-announce mailing list. Current snapshots of the development tree
> can be grabbed by doing an svn checkout/update of the
> current development source code.
>
> Thank you for your report and for helping us to make MediaWiki even
> better.
> -------------------------------------
>
> Sending that to wikitech-l in response to a security heads-up on the same
> list gets you several things:
> 1) It acknowledges that you got the original bug report.
> 2) It confirms that there was a problem.
> 3) It tells everyone that the problem is now fixed.
> 4) It sends the clear message that "this software is well maintained and
> we respond promptly to security issues".
> 5) It tells any affected site admins which release / version they need to
> update to order to be protected from the problem.
> 6) It thanks the reporter - because although you mightn't realise it,
> finding these types of problems can be hard work, and a little
> thanks never goes astray.
>
> [Tim Starling wrote]:
>> Further to that, I would appreciate it if Nick would commit his testing
>> scripts to SVN, and document them fully. It would be easier if we could
>> do
>> this testing before we commit, rather than go through all this rigmarole.
>
> I shall be happy to email yourself and Brion an updated version of the
> script that I'm using (you'll have to check it in, as I don't
> have commit privileges). I'll endeavour to get it you today, but failing
> that some time this week. As with all software I'm sure it
> can be improved, but it's probably better to have something more current
> checked in to the tree than the old version that is there
> currently.
>
> Please note however that the script mightn't be quite what you think it
> is: For example, I didn't have a test for this specific
> IpBlockList problem ready to go just waiting for this exact problem.
> Rather I had a script that generates tests, runs those tests,
> and if it fails keeps the tests. So I ran it for a few minutes, it
> generated a specific IpBlockList test that failed, and then I
> took a closer look at the generated test that failed, and said "Oh, that's
> interesting". So it's a test generator and runner and
> result-checker, not a set of predefined static tests.
>
> As such, as a constructive suggestion, one possibility might be to add a
> cronjob similar to how parserTests gets run nightly and the
> results are mailed to wikitech-l. Currently the script runs until stopped
> with CTRL-C, and it prints out progress information as it
> goes. So as a possibility, you could perhaps update it to accept some
> command line parameters (such as adding a silent mode that
> only prints out real errors to make it less chatty, and adding something
> so that you could specify to run for a specific amount of
> time [e.g. 1 hour] instead of indefinitely, and maybe also a maximum
> number of errors to report). Then the resulting nightly output
> could be emailed to wikitech-l, or you could set up a separate private
> mail alias if you wanted (I'd be happy to be included on
> this, as it may or may not require some explaining at first about what
> it's upset about, and it might require a bit of tweaking to
> get the right level of information from the script). That way you'd get an
> additional different and complementary type of continuous
> nightly testing to help catch any regressions or other problems.
>
> All the best,
> Nick.


subject: [Wikitech-l] Mass open proxy blocking

body:
Blocking could be checked against two tables (or even a table array). The
first one would be per-wiki, while the second one would be shared between
wikis.

Then, how would it be configured?
*Should any wikipedia admin be able to (un)block anyone?
*Should it be only done via meta / stewards?
*How would global-blocking be locally handled? Should local project have a
local-whitelist?
*An special page for it or integrated in the specialblock (a new checkmark
for example)?
*If we have blocks on both tables, with different expire time, which should
apply?


from_name: Erik Moeller

subject: [Foundation-l] Vicenza, Italy

body:
On 6/26/06, Gianluigi Gamba <gigamb at tin.it> wrote:
> Wikimedia Italia just finished a long 4-day weekend of presentation of
> Wikipedia and Wikimedia projects to the thousands of visitors of
> "FestAmbiente", held in a park of Vicenza, in northern Italy.

Excellent! It's nice to see the chapter structure emerging and doing
good work like this in more and more countries.

Erik


subject: [Foundation-l] Vicenza, Italy