from_name: David Strauss

subject: [Foundation-l] Wikitext isn't a programming language, but...

body:
#loop is a problem. If this template language is Turing-complete, it can
be used to run infinitely long programs. That is a huge avenue for abuse.

Then again, there could be an execution limit to the parsing of a template.

Virgil Ierubino wrote:
> The introduction of ParserFunctions was reluctant, but look how it's taken
> off. Reluctance against programming-language-style extensions is many-fold,
> but primarily is this concern: Wikitext is not a programming language. It's
> a markup to simplify formatting in articles. So complicating it with
> parameters and arguments and functions is just wrong wrong wrong. I agree.
>
> The problem is, users of Wikitext *want* to program. But not in articles, in
> templates.
>
> It's simply true that the way templates are used is not entirely as they
> were originally intended. Originally they were very simple transclusion
> devices. Now they are complex ways of organising and structuring data in an
> easy and efficient way - the point being that users (without technical
> know-how) can include templates in their articles with simple code (e.g.
> {{template|a|b|c}} ) and receive a specially generated result tailored to
> the applicable article by the template code. This is obviously a massively
> useful way of allowing articles to have better information better presented,
> and allowing non-tech-savvy users (or even the tech-savvy ones) to very
> quickly and easily and intuitively insert complex formatting like
> a (dynamic) infobox into their articles.
>
> So the way I see this, it's only really in *templates* that the advanced,
> programming-like features are required, and the reason is that, simply due
> to evolution, templates are being used like subroutines or functions. And
> for good reason. That's a very very *very* useful thing for them to be able
> to do. Which is why they are all doing it. That kind of functionality makes
> MediaWiki an extremely powerful wiki engine - it's extendible from within.
>
> But if these "functions" are being written in Wikitext, that makes Wikitext
> more than just markup, which is confusing - so scrap them. And yet, software
> support for such "functions" is incredibly useful - so keep them!
>
> There's a solution here. How about we introduce another language ****that is
> only available in the Template namespace****, specifically for this
> function? Call it Wikisyntax. Wikisyntax is a pure (and simple) programming
> language, with no markup. Wikitext is a pure and simple markup language,
> with no code.
>
> Normal users (who can use Wikitext fairly easily) rarely ever look at the
> template namespace anyway. It's a simple fact that your average user of
> MediaWiki has no idea what a template is, and will never create or edit one
> until he or she is quite advanced and has got a strong understanding of the
> system. Thus it is not objectionable on usability grounds alone to expand
> the code for the template namespace. In fact, usability is a *reason* to
> support the idea of Wikisyntax: templates *are* being used like this because
> it's an extremely fruitful feature, so it would make things easier, but it
> would keep the complexity seperate and hidden away from normal markup and
> articles. Of course, users can still write templates with just Wikitext, but
> the Wikisyntax option is there.
>
> Crucial is the point that the Wikisyntax code is only parsed when written in
> the template namespace. This allows Wikitext to remain a pure markup for use
> in articles by normal users, without confusion. But the Template +
> Wikisyntax idea is, essentially, a way of allowing a wiki to have *custom
> subroutines* that **aid** those normal users in normal articles. No other
> Wiki engine has that kind of power.
>
> Would this idea be difficult to implement? I don't think so at all.
> Wikisyntax can be a seperate file, say, SyntaxParser.php, called only when
> necessary. Its contents can simply be (mildly altered, although not much) a
> copy-and-paste of the ParserFunctions extension that is already written, and
> any others we'd like to include, e.g. StringFunctions and VariablesExtension
> (discuss later). We *already have the code* (pretty much) for this new
> template language!
>
> I have made a page on Meta for this suggestion:
> http://meta.wikimedia.org/wiki/Wikisyntax , please leave your comments
> either here or there. Thanks.
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/foundation-l

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


list: wikimedia-l

source: pipermail-mbox

body:
#loop is a problem. If this template language is Turing-complete, it can
be used to run infinitely long programs. That is a huge avenue for abuse.

Then again, there could be an execution limit to the parsing of a template.

Virgil Ierubino wrote:
> The introduction of ParserFunctions was reluctant, but look how it's taken
> off. Reluctance against programming-language-style extensions is many-fold,
> but primarily is this concern: Wikitext is not a programming language. It's
> a markup to simplify formatting in articles. So complicating it with
> parameters and arguments and functions is just wrong wrong wrong. I agree.
>
> The problem is, users of Wikitext *want* to program. But not in articles, in
> templates.
>
> It's simply true that the way templates are used is not entirely as they
> were originally intended. Originally they were very simple transclusion
> devices. Now they are complex ways of organising and structuring data in an
> easy and efficient way - the point being that users (without technical
> know-how) can include templates in their articles with simple code (e.g.
> {{template|a|b|c}} ) and receive a specially generated result tailored to
> the applicable article by the template code. This is obviously a massively
> useful way of allowing articles to have better information better presented,
> and allowing non-tech-savvy users (or even the tech-savvy ones) to very
> quickly and easily and intuitively insert complex formatting like
> a (dynamic) infobox into their articles.
>
> So the way I see this, it's only really in *templates* that the advanced,
> programming-like features are required, and the reason is that, simply due
> to evolution, templates are being used like subroutines or functions. And
> for good reason. That's a very very *very* useful thing for them to be able
> to do. Which is why they are all doing it. That kind of functionality makes
> MediaWiki an extremely powerful wiki engine - it's extendible from within.
>
> But if these "functions" are being written in Wikitext, that makes Wikitext
> more than just markup, which is confusing - so scrap them. And yet, software
> support for such "functions" is incredibly useful - so keep them!
>
> There's a solution here. How about we introduce another language ****that is
> only available in the Template namespace****, specifically for this
> function? Call it Wikisyntax. Wikisyntax is a pure (and simple) programming
> language, with no markup. Wikitext is a pure and simple markup language,
> with no code.
>
> Normal users (who can use Wikitext fairly easily) rarely ever look at the
> template namespace anyway. It's a simple fact that your average user of
> MediaWiki has no idea what a template is, and will never create or edit one
> until he or she is quite advanced and has got a strong understanding of the
> system. Thus it is not objectionable on usability grounds alone to expand
> the code for the template namespace. In fact, usability is a *reason* to
> support the idea of Wikisyntax: templates *are* being used like this because
> it's an extremely fruitful feature, so it would make things easier, but it
> would keep the complexity seperate and hidden away from normal markup and
> articles. Of course, users can still write templates with just Wikitext, but
> the Wikisyntax option is there.
>
> Crucial is the point that the Wikisyntax code is only parsed when written in
> the template namespace. This allows Wikitext to remain a pure markup for use
> in articles by normal users, without confusion. But the Template +
> Wikisyntax idea is, essentially, a way of allowing a wiki to have *custom
> subroutines* that **aid** those normal users in normal articles. No other
> Wiki engine has that kind of power.
>
> Would this idea be difficult to implement? I don't think so at all.
> Wikisyntax can be a seperate file, say, SyntaxParser.php, called only when
> necessary. Its contents can simply be (mildly altered, although not much) a
> copy-and-paste of the ParserFunctions extension that is already written, and
> any others we'd like to include, e.g. StringFunctions and VariablesExtension
> (discuss later). We *already have the code* (pretty much) for this new
> template language!
>
> I have made a page on Meta for this suggestion:
> http://meta.wikimedia.org/wiki/Wikisyntax , please leave your comments
> either here or there. Thanks.
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/foundation-l

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


body:
#loop is a problem. If this template language is Turing-complete, it can
be used to run infinitely long programs. That is a huge avenue for abuse.

Then again, there could be an execution limit to the parsing of a template.

Virgil Ierubino wrote:
> The introduction of ParserFunctions was reluctant, but look how it's taken
> off. Reluctance against programming-language-style extensions is many-fold,
> but primarily is this concern: Wikitext is not a programming language. It's
> a markup to simplify formatting in articles. So complicating it with
> parameters and arguments and functions is just wrong wrong wrong. I agree.
>
> The problem is, users of Wikitext *want* to program. But not in articles, in
> templates.
>
> It's simply true that the way templates are used is not entirely as they
> were originally intended. Originally they were very simple transclusion
> devices. Now they are complex ways of organising and structuring data in an
> easy and efficient way - the point being that users (without technical
> know-how) can include templates in their articles with simple code (e.g.
> {{template|a|b|c}} ) and receive a specially generated result tailored to
> the applicable article by the template code. This is obviously a massively
> useful way of allowing articles to have better information better presented,
> and allowing non-tech-savvy users (or even the tech-savvy ones) to very
> quickly and easily and intuitively insert complex formatting like
> a (dynamic) infobox into their articles.
>
> So the way I see this, it's only really in *templates* that the advanced,
> programming-like features are required, and the reason is that, simply due
> to evolution, templates are being used like subroutines or functions. And
> for good reason. That's a very very *very* useful thing for them to be able
> to do. Which is why they are all doing it. That kind of functionality makes
> MediaWiki an extremely powerful wiki engine - it's extendible from within.
>
> But if these "functions" are being written in Wikitext, that makes Wikitext
> more than just markup, which is confusing - so scrap them. And yet, software
> support for such "functions" is incredibly useful - so keep them!
>
> There's a solution here. How about we introduce another language ****that is
> only available in the Template namespace****, specifically for this
> function? Call it Wikisyntax. Wikisyntax is a pure (and simple) programming
> language, with no markup. Wikitext is a pure and simple markup language,
> with no code.
>
> Normal users (who can use Wikitext fairly easily) rarely ever look at the
> template namespace anyway. It's a simple fact that your average user of
> MediaWiki has no idea what a template is, and will never create or edit one
> until he or she is quite advanced and has got a strong understanding of the
> system. Thus it is not objectionable on usability grounds alone to expand
> the code for the template namespace. In fact, usability is a *reason* to
> support the idea of Wikisyntax: templates *are* being used like this because
> it's an extremely fruitful feature, so it would make things easier, but it
> would keep the complexity seperate and hidden away from normal markup and
> articles. Of course, users can still write templates with just Wikitext, but
> the Wikisyntax option is there.
>
> Crucial is the point that the Wikisyntax code is only parsed when written in
> the template namespace. This allows Wikitext to remain a pure markup for use
> in articles by normal users, without confusion. But the Template +
> Wikisyntax idea is, essentially, a way of allowing a wiki to have *custom
> subroutines* that **aid** those normal users in normal articles. No other
> Wiki engine has that kind of power.
>
> Would this idea be difficult to implement? I don't think so at all.
> Wikisyntax can be a seperate file, say, SyntaxParser.php, called only when
> necessary. Its contents can simply be (mildly altered, although not much) a
> copy-and-paste of the ParserFunctions extension that is already written, and
> any others we'd like to include, e.g. StringFunctions and VariablesExtension
> (discuss later). We *already have the code* (pretty much) for this new
> template language!
>
> I have made a page on Meta for this suggestion:
> http://meta.wikimedia.org/wiki/Wikisyntax , please leave your comments
> either here or there. Thanks.
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/foundation-l

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


list: foundation-l

body:
I'm certainly no expert for the MediaWiki parser, but you could take a
microtime() from the start of parsing and periodically check time
elapsed. With anything beyond the allotted parsing time, the template
would return either nothing or a warning.

David Gerard wrote:
> On 19/01/07, David Strauss <david at fourkitchens.com> wrote:
>
>> #loop is a problem. If this template language is Turing-complete, it can
>> be used to run infinitely long programs. That is a huge avenue for abuse.
>> Then again, there could be an execution limit to the parsing of a template.
>
>
> We have one real-life example of this, of course, in the recent
> template on es: Wikipedia that took 20 seconds to run and caused some
> annoyance on wikitech-l ... how feasible are execution time limits in
> practice, what's a reasonable limit (knowing people are going to push
> as close to it as they can) and what's a reasonable failure mode
> (knowing people are going to push as close to it as they can)?
>
>
> - d.
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/foundation-l

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


body:
I'm certainly no expert for the MediaWiki parser, but you could take a
microtime() from the start of parsing and periodically check time
elapsed. With anything beyond the allotted parsing time, the template
would return either nothing or a warning.

David Gerard wrote:
> On 19/01/07, David Strauss <david at fourkitchens.com> wrote:
>
>> #loop is a problem. If this template language is Turing-complete, it can
>> be used to run infinitely long programs. That is a huge avenue for abuse.
>> Then again, there could be an execution limit to the parsing of a template.
>
>
> We have one real-life example of this, of course, in the recent
> template on es: Wikipedia that took 20 seconds to run and caused some
> annoyance on wikitech-l ... how feasible are execution time limits in
> practice, what's a reasonable limit (knowing people are going to push
> as close to it as they can) and what's a reasonable failure mode
> (knowing people are going to push as close to it as they can)?
>
>
> - d.
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/foundation-l

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


body:
I'm certainly no expert for the MediaWiki parser, but you could take a
microtime() from the start of parsing and periodically check time
elapsed. With anything beyond the allotted parsing time, the template
would return either nothing or a warning.

David Gerard wrote:
> On 19/01/07, David Strauss <david at fourkitchens.com> wrote:
>
>> #loop is a problem. If this template language is Turing-complete, it can
>> be used to run infinitely long programs. That is a huge avenue for abuse.
>> Then again, there could be an execution limit to the parsing of a template.
>
>
> We have one real-life example of this, of course, in the recent
> template on es: Wikipedia that took 20 seconds to run and caused some
> annoyance on wikitech-l ... how feasible are execution time limits in
> practice, what's a reasonable limit (knowing people are going to push
> as close to it as they can) and what's a reasonable failure mode
> (knowing people are going to push as close to it as they can)?
>
>
> - d.
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/foundation-l

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


list: wikien-l

from_name: Oskar Sigvardsson

subject: [WikiEN-l] My own Livejournal

body:
On 1/19/07, Steve Summit <scs at eskimo.com> wrote:
<snip>
> Though I suppose you get a few more points for brazen chutzpah
> for having somehow convinced the moderators to let messages from
> your new account through; I can't imagine how you managed that.)

It's like this: all of the moderators are in the cabal with the rest
of us, so they cleverly made up a plan where they let his messages
through and then bribed us so that we wouldn't take him seriously, and
thus brake his spirit.

You see, it's all part of the conspiracy!


list: wikitech-l

from_name: Alai

subject: [Wikitech-l] PDA browsing and large pages

body:
Alphax (Wikipedia email <alphasigmax at ...> writes:
> Something similar was coded back in November:
>
> http://www.mediawiki.org/wiki/Labeled_Section_Transclusion

Interesting.  I can see how that would be potentially helpful in some cases,
such as the aforementioned stub types list.  But as it requires markup of the
pages being 'sliced', and of the sectionated pages transcluding on that basis,
it's not as general a fix as I was hoping for.  The link that Manuel Schneider
posted (http://en.wikipedia.7val.com/) is much closer to what I had in mind,
though it's obviously bundling together a number of things:  stripping out CSS,
fiddling with width formats, etc, as well as the per-section rendering.  An
ideal solution would make those orthogonal -- as well as serving same from
Wikipedia itself.

Slan,
Alai.


from_name: Anthony

subject: [Foundation-l] In defence of Google

body:
On 1/18/07, Gerard Meijssen <gerard.meijssen at gmail.com> wrote:
> Hoi,
> Recently there has been a lot of traffic about search engines. The tone
> of these discussions have been hostile towards Google. I want to remind
> you all that it is because of the value Google attaches to our content
> that we became the number 10 or whatever in the Alexa rankings.

So Google is to blame for that?  You say it as though it is
necessarily a good thing.

> When
> Google were to drop the value it attaches to Wikipedia in favour of for
> instance Citizendium, it will become clear how important Google is for
> the dissemination of our Free content.

When STDs and pregnancy can be prevented by an inexpensive, safe and
effective once a day pill, those people distributing free condoms will
be out of business.

If Citizendium becomes the next great thing as a fork, then
Citizendium will be disseminating "your" Free content.  If not, then
there's little reason to believe Google would drop Wikipedia, just
move it down to number two.

> When Citizendium finally gets its
> act together, and does a better job that we do, it will make sense to
> Google to change its preference. We should not sit on our laurels but
> innovate. Frankly we can use some competition.
>
> The point that I am making is NOT that we might not consider dabbling in
> search technology. When we are to do this, we will find a well written
> proposal in Meta to consider. My point is that Google did a world of
> good to the Open Content movement. It is relevant that we acknowledge
> this. They are not like Microsoft who gives us a low ratings because of
> us competing with their product. Google did good, Google does good.
>
A large portion of Wikipedia contributors found the site through
Google.  Of course, a large portion of them also use the Windows
operating system.  I have as hard of a time imagining a Wikipedia
without Microsoft as I do one without Google.  In either case some
other company would have to take up the slack.

Google and Microsoft are for-profit corporations.  Their purpose for
existence is to make a profit.  The wonderful thing about capitalism
is that a corporation can do a lot of good for the world while
pursuing the goal of making money.  But there's really no reason to
acknowledge this.

I'd love to see Google torn down and replaced with an open source
collaborative search engine run democratically by the world.  I'd love
to have access to a search engine as good as Google, with a truly open
API (i.e. sans http://code.google.com/apis/soapsearch/api_terms.html),
and with all the results being released under an open content license.
 Is Wikimedia the one to do that?  It's arguable whether it'd be
within the scope of the Foundation's mission.  And in any case, I
haven't seen a reasonable proposal of how to do it.  So I guess when
it comes to that point, we're both in agreement.  And yeah.  Google
did good.  Google does good.  But Google did bad, too.  Google does
bad, too.  And Microsoft also did/does good/bad.

Anthony


subject: [Foundation-l] In defence of Google


subject: [WikiEN-l] My own Livejournal

body:
On 1/18/07, Oskar Sigvardsson <oskarsigvardsson at gmail.com> wrote:
> On 1/19/07, Steve Summit <scs at eskimo.com> wrote:
> <snip>
> > Though I suppose you get a few more points for brazen chutzpah
> > for having somehow convinced the moderators to let messages from
> > your new account through; I can't imagine how you managed that.)
>
> It's like this: all of the moderators are in the cabal with the rest
> of us, so they cleverly made up a plan where they let his messages
> through and then bribed us so that we wouldn't take him seriously, and
> thus brake his spirit.
>
> You see, it's all part of the conspiracy!
>
Actually, his messages aren't going through at all.  The moderation
cabal has set up a system which produces automated fake responses to
his posts that are only sent to him and others on moderation.  This
post is one of the only real ones, as the cabal has decided to place
me into the so called "Troll Honeypot" for similarly unfounded
reasons.

Anthony


from_name: Rob Church

subject: [Wikitech-l] special page listing pages with broken links?

body:
On 18/01/07, Travis Derouin <travis at wikihow.com> wrote:
> That page seems to pick up pages in the user and talk namespaces as
> well. Is there much value in adding a special page to the list of
> extensions that lists main namespace pages that have links to articles
> that don't exist in the main namespace? I know we'll use it, but we
> have a different flow of creating pages and dealing with broken links
> than Wikipedia.

The four questions I usually ask myself before committing an extension are:

1. Is it well written, secure (to my knowledge), etc?
2. Do I want to release the code for this?
3. Is someone else going to find it useful?
4. Has it been done better in the repo?

I like to think that #1 is always a "yes", and #2 is usually a "yes"
as well, so generally what I go for is satisfying #3 and #4.

In your case, I think you'd be satisfying both of those; I don't see
why someone else wouldn't find it useful, and I don't believe there's
anything like it in the repository to date.

Rob Church


from_name: Birgitte SB

subject: [Foundation-l] Mail archives

body:
I wanted to look up the detailed report that was
posted to the list after the Frankfurt retreat.  I
have entually found it but in the process had some
troubles because not realizing that Anthere has been
using two different email addresses caused me to miss
seeing it when searching by "Author".  If any of you
are familiar with using our archives, you realize how
frustrating it can be to find (or not find) a message
you half remember.

The thing that I realized while looking for this
information is that everyone is relying much to
heavily on these archives.  I knew that that all the
links from the past list summaries had been scrambled.
 I went to the WMF website hoping to find the
information there after my failure in the archives.  I
found that the WMF website also uses links to the
archives. [1]  All of these links have been scrambled
in the past week and the archive is gernerally not
something that can be expected to be stable.

I ask you to consider making an effort to mirror any
offcial messages or detailed reports either on the WMF
or Meta instead of simply repairing the existing
links.  These messages become rather hard to find once
the links go bad.  If this is decided to be a bad idea
for some reason; then please consider using a
standardized subject for such messages.  Everyone
should think twice about linking to the archive in
general.  If you expect people to be reading what
write in six months, I would encourage you to quote
the message instead of linking.

Birgitte SB

[1] http://wikimediafoundation.org/wiki/Home
(See: "Wikimedia Board reorganization" read more link)

____________________________________________________________________________________
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091


subject: [Foundation-l] Mail archives


subject: [Wikitech-l] Install Question - GD Library

body:
On 18/01/07, Jon Anunson <janunson at design-plus.com> wrote:
> I have PHP 5.0 installed, acording to http://se.php.net/gd, GD is bundled
> into the PHP install.  When i'm running the Mediawiki install, though, under
> Checking invironments it says "Couldn't find GD library or ImageMagick; image
> thumbnailing disabled."  Is there a certain version of GD required, or maybe
> i havn't gotten PHP installed properly (?)

What platform?

GD is bundled with the Windows binaries, although it needs to be
enabled in the PHP configuration, and Unix or Linux distributions may
require it to be compiled in or added as an extension. For instance,
under FreeBSD, you either compile it in or install
/usr/ports/graphics/php5-gd.

Rob Church


from_name: Nina Stratton

subject: [WikiEN-l] Troubling news on Citizendium

body:
On 1/18/07, Alphax (Wikipedia email) <alphasigmax at gmail.com> wrote:
>
> Nina Stratton wrote:
> > I'm a 40 (almost) year old black woman who dropped out of high school
> and
> > never finished college. I'm also fundamentally opposed to "experts"
> running
> > anything I have to do with. I can read, I can write, and I can learn.
> That's
> > all I need and all I will ever need.
> >
>
> You're either incredibly na?ve, or the best troll I've seen in a long
> time.
>
> --
> 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

I'm from the Midwest, so I think I fall into the "incredibly naive"
category. Having said that...on reflection I better not say much else.:)

On a side note, I've been invited by my would-have-been alma mater to tour
the high school and discuss my life with the principal as "an inspiration to
the students". I must be doing something right.

Nina

_______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>
>
>
>

--
Sincerely,

Nina
"Look at the sky. We are not alone. The whole universe is friendly to us and
conspires only to give the best to those who dream and work." - Abdul Kalam


from_name: Brion Vibber

subject: [Wikitech-l] Database problem post-mortem

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

== Summary ==

Full disk on the database master for non-en.wikipedia.org made most of
our wikis uneditable for about 2.5 hours, during Europe midday / US morning.

Immediate problem is repaired; some minor further cleanup needed;
procedural changes recommended.

== Disruption and data loss ==

The last edits to make it to the slave servers were at:
2007-01-19 11:50:29 UTC

A few more made it through on samuel before it stopped accepting more
data up to:
2007-01-19 11:51:03
(23 broken edits on de.wikipedia.)

After that point the database didn't accept more writes, leaving a
read-only state which didn't allow any further consistency problems to
develop.

There _may_ be some minor problems related to caching of revision data
where ID numbers overlap from the old server, but this is unclear.

== Inspection and repair ==

I was woken up around 13:50 to take a look, informed that samuel
(non-enwiki master) was out of disk space and wikis were read-only.

After a few minutes to check that the slaves were consistent and that
there wasn't _too_ bad a lag between them and the master, I decided to
go ahead with a master switch to adler, leaving samuel out of service
until it gets re-cloned.

By 14:26 the master switch was done, and read-write service restored.

== Further work: immediate ==

If really desired, we may be able to clone the small number of 'lost'
edits from samuel.

Once we no longer need samuel's data, it should have its database
re-cloned from one of the slaves consistent with the new state, and it
can be restored to slave service.

== Further work: long-term ==

Our procedure for monitoring disk space and cleaning up binlogs is terrible.

Low-disk warnings from Nagios are routinely ignored, in part because the
thresholds seem much too high.

Binlog cleanup appears to be entirely manual and ad-hoc; there is no set
schedule or assignment to do this.

The good news is this task is easy to automate.

Recommendation:
* automate cleanup of binlogs on the db masters.
* make low-disk warnings more reasonable and visible for the masters
specifically (where it really, really matters)

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

iD8DBQFFsOS1wRnhpk1wk44RAjujAKDLga9UHrs9Z5o0E6DM24puZvkSMwCeO9N0
/TIoWOSKKdUMOO3Lu5Bdn0M=
=R6SD
-----END PGP SIGNATURE-----


subject: [WikiEN-l] Expertaphobia

body:
On 1/19/07, Thomas Dalton <thomas.dalton at gmail.com> wrote:
>
> > The problem with expertise on Wikipedia is how to judge whether or
> > not someone is an expert.
>
> Exactly. And short of the foundation phoning people's universities and
> confirming degrees, it always will be. (And that only works for
> subjects where it's possible to get a degree... I don't think there is
> any easy way to confirm other kinds of qualifications (experience, for
> example).)
>
> _______________________________________________
> Really, it comes down to the edits and verifiability. If a person is
> adding content that's appropriately referenced, all it takes is checking a
> book out of the library to see whether that person's full of shit or not.
> The cheesesteak reference is a good one. The answer to that is (drumroll
> please), were either one of the statements sourced well?

If one can't find a source for their controversial statement, then it
doesn't belong in a Wikipedia article in the first place. That's the problem
right now - Wikipedia has this "write then cite" thing going on it's
tutorials, but it really should be the other way around. It would quell a
lot of the rampant deletionism going on right now if that were done.

Nina

If you can't find a source, then you're statement doesn't belong on
> Wikipedia anyway. I'm always encouraging people to source first (which runs
> a bit counter to current Wikipedia instructions, but could do away with a
> lot of the rampant deletionism).
>

--
Sincerely,

Nina
"Look at the sky. We are not alone. The whole universe is friendly to us and
conspires only to give the best to those who dream and work." - Abdul Kalam


from_name: Parker Peters

subject: [WikiEN-l] My own Livejournal

body:
I've been nothing but civil, but I'm the one being put on moderation.

That shows what the groupthink is like around here. Do you all drink the
same kool-aid too?

Parker

On 1/18/07, Mark Ryan <ultrablue at gmail.com> wrote:
>
> Please stop this. Civility is a two-way street, and we should afford
> even those who are critical of us some basic courtesy (that is the
> case even if they do not show the same courtesy in response).
>
> I have put Parker Peters' new email address onto moderation, and that,
> I hope, is the end of the matter. If he/she wants to continue to
> contribute to the mailing list in a civil fashion, he or she is more
> than welcome to do so, via the moderation queue.
>
> ~Mark Ryan
>
> On 19/01/07, Sean Barrett <sean at epoptic.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Parker Peters stated for the record:
> > > Everything I sent was unedited and exactly as I was seeing it come in
> to my
> > > account.
> > >
> > > Whether you choose to believe the truth or not is your own choice,
> though it
> > > saddens me that you choose not to.
> > >
> > > Parker
> >
> > Will it make you so sad that in your despair you give up trying to lie
> > to us and just go away?
> >
> > - --
> >  Sean Barrett     | Fac futuaris et caballus
> >  sean at epoptic.com | in quo huc equitasti.
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.2 (MingW32)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFFsD+O/SVOiq2uhHMRAhn5AKCciF0HIfaBdqfHumxxXRIGUF+17gCfTCii
> > YN+TfEVhAqIX3oeR0+UvZRY=
> > =yY9R
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > WikiEN-l mailing list
> > WikiEN-l at lists.wikimedia.org
> > To unsubscribe from this mailing list, visit:
> > http://lists.wikimedia.org/mailman/listinfo/wikien-l
> >
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>


body:
On 1/19/07, Thomas Dalton <thomas.dalton at gmail.com> wrote:
>
> > Problem is that applies to almost any given subject. People do no say
> > "I am not a chemist" even though I can probably find an exception to
> > almost any stamtent about chemisty made by someone without a degree.
>
> Try listening to secondary (high) school Chemistry teachers... they
> have degrees and still teach complete rubbish most of the time. I can
> understand teaching things slightly simplified, but teaching something
> which is actually outright wrong in the name of simplicity is just
> crazy.
>
> A good lawyer is only as good as their ability or inclination to stay
abreast of current precedent. The same goes for any teacher or "expert".
They can't rest on their credentials and expect to know what they're talking
about.

Ultimately, that's the problem I have. At least in America, we have an
"expert" beauracracy set up that rewards past effort while failing to
acknowledge that any "expert" needs to be a life-long learner. A lot
"experts" wouldn't last a day in the private sector, because they simply
wouldn't have competitive knowledge.

Nina

--
Sincerely,

Nina
"Look at the sky. We are not alone. The whole universe is friendly to us and
conspires only to give the best to those who dream and work." - Abdul Kalam


subject:
[WikiEN-l] Citizendium trying out not being a fork of Wikipedia
	for a while

body:
On 1/19/07, David Gerard <dgerard at gmail.com> wrote:
>
> On 19/01/07, Steve Block <steve.block at myrealbox.com> wrote:
>
> > Still, not really a huge amount of sense discussing citizendium here.
>
>
> It's a relevant and interesting related project, so is relevant to
> discuss insofar as it informs what Wikipedia does and how it does it.
>
>
> - d.
>
>
> The day Wikipedia requires you to put your resume on your userpage to
edit, is the day I am outta there.

Of course I looked into Citizendium - a lot of us have. It made me feel
small and somewhat worthless as a potential contributor. I simply don't need
that in my life, so I didn't apply. Until they invite me to participate
(like they invited several "experts"), I see no need to be involved.

Nina

--
Sincerely,

Nina
"Look at the sky. We are not alone. The whole universe is friendly to us and
conspires only to give the best to those who dream and work." - Abdul Kalam


subject: [WikiEN-l] What is an "expert"?

body:
On 1/19/07, Marc Riddell <michaeldavid86 at comcast.net> wrote:
>
> Hello all,
>
> I believe there is something we should ask at this point. This question is
> for everyone participating in this Mailing List:
>
> What is your definition of an "expert"?
>
> Please, for now, try to resist responding to the others' answers, simply
> state your own.
>
> Marc Riddell
>
> _______________________________________________
> Someone who is passionately interested in and committed to learning
> everything (from anyone) about their field. This person would be a life-long
> learner who stays abreast of current events in their field, and can explain
> their field to anyone. For example, Albert Einstein was an expert. So was
> Carl Sagan. The "Brief History of Time" guy in the wheelchair (I'm blanking
> on his name) is an expert. Bill Gates is not an expert, but Steve Jobs might
> be one. Annie Sprinkle is an expert. bell hooks is an expert. For gemstones,
> I'm an expert.
>

I said 'their field' three times in one post. I either haven't had enough
coffee or  I've had too much.

--
Sincerely,

Nina
"Look at the sky. We are not alone. The whole universe is friendly to us and
conspires only to give the best to those who dream and work." - Abdul Kalam


from_name: christoph.huesler at css.ch

subject: [Wikitech-l] Antwort: Re:  WikiDump Parsing

body:
Alai wrote:
> Note that one also needs to cope with leading and trailing spaces, and
the
> "Category" is case-insensitive.  So probably something more like:
>
> \[\[ *[Cc][Aa][Tt][Ee][Gg][Oo][Rr][Yy] *: * ...

Or just use an "ignore case" option like /i (in pcre)...

-- chris


body:
On 1/19/07, Steve Block <steve.block at myrealbox.com> wrote:
> Guettarda wrote:
> > On 1/18/07, Steve Block <steve.block at myrealbox.com> wrote:
> >> Matt R wrote:
> >>> As per the subject, excerpts from:
> >>>
> >>>
> >> https://lists.purdue.edu/pipermail/citizendium-l/2007-January/000863.html
> >>> Larry Sanger writes,
> >>>
> >>>   "After seeing the widespread support for the suggestion
> >>> that we try *not* forking Wikipedia--i.e., that we delete all articles
> >> that
> >>> are not marked "CZ Live"--I am about to instruct our tech team to go
> >> ahead
> >>> and make the deletion...
> >> I'm a bit clueless, but does this mean they haven't used any Wikipedia
> >> content, or that they have but they're hiding it?  I mean, all the
> >> articles that are marked "CZ Live", are they based on Wikipedia content?
> >>   And if they are, doesn't that mean they *have* to license under GFDL?
> >>   Which, unless I got confused in another thread, they aren't planning
> >> to do?
> >>
> >> Steve block
> >
> >
> > Steve - if you poke around the Citizendium forum (there's a link to it in
> > Matt's email) a lot of your questions may be answered.
>
> I looked at Citizendium a while back but couldn't for the life of me
> work out how I was supposed to become a contributor so I gave up looking
> at it.
>
> > Apparently their first "approved" article, Biology, was a complete re-write
> > - the Wikipedia article was blanked.  Other people have modified existing
> > articles.  As I understand it, the CZ Live stuff is stuff that people are
> > working on.
> >
> > Obviously they can't release work based on WP articles under a more
> > restrictive license.  New material could be - it seems to me that there's a
> > debate between people who want the whole project to by cc-by-nc and those
> > who want it to stay GFDL.
>
> I can't see how you can ringfence certain articles.  If information is
> moved from one GFDL article to another, a cc by nc, then the new article
> must be both GFDL and cc by nc, no?  And aren't they incompatible?
>
CC-by-NC isn't a copyleft license, so the compatibility would be
really strange.  A derivative of a GFDL article (which wasn't an
aggregate) would have to be GFDL.  But a derivative of a CC-by-NC
article doesn't have to be CC-by-NC.  However, the original work would
still be under CC-by-NC, so unless the original authors gave [you]
other permissions, you'd still have to follow CC-by-NC for any
derivatives.  As for a work entirely released under *both* GFDL *and*
CC-by-NC, that'd be kind of cool.  You could use the work under the
GFDL, complete with all its obnoxious requirements, *or* you could use
the work under CC-by-NC, without all the GFDL's obnoxious
requirements, but only if you do so for noncommercial purposes.

Anyway, I think the idea was that different articles would have
different licenses.

Anthony


from_name: effe iets anders

subject: [Foundation-l] Board meeting in Rotterdam later this week

body:
Not true. *if* we would allow NC, I bet it will be possible to persue a lot
of institutions to give their images, paintings, texts etc away under the
NC. So it does have a huge potential, also for pictures with on the short
term no free equivalent. But that is not what this discussion should be
about imho. I dont think we should be talking about what images we would
like to use, i think we should talk about what we are *allowed* (legally) to
use. And as I said already quite a while before, that is mostly a case for
license-experts, copyright-experts, the foundation and their willingness to
face a potential sue, and maybe as well the free software foundtaion, the
writer of the GNU Free Documentation License.
*If* it would be allowed by all those, it is time for us as community or
maybe as every community by itself, to choose what licenses we *want* to
use, taking into account what the possible consequenses are and what the
costs to our ideals are.
The first is more a fact, that we have to find out, and let some people do
research to, the second is more an opinion. For the first I would suggest to
ask experts to find this out, to ask the foundation to take a stand on this
issue, to ask the FSF advice, and see whether it is _allowed_ or not.
For the second question I would suggest to have a more structured and broad
discussion, possibly on meta, where the discussion could be split into
different topics, and the arguments can be collected in a way that one can
keep oversight. Because who exactly is benefitting from this very
discussion? We have very great texts here, but the problem is that probably
only a small group reads this (due to the amount of text) and those in this
group already took a stand, and wont be persuaded anymore. It makes little
sense that way :) Please let someone set up a structured discussion on meta,
so it will be easier to follow, and it will less be making people to quit
foundation-l due to the amount of messages in their inbox (not everybody has
gmail). I myself would prefer first _*at least*_ a guideline of the
foundation, stating what the boundaries are within which we can move.

Lodewijk

2007/1/19, geni <geniice op gmail.com>:
>
> On 1/19/07, rfrangi op libero.it <rfrangi op libero.it> wrote:
>
> > Same applies to NC images.
> >
> > Roberto (Snowdog)
>
>
> There arew very few NC images for which a free equiv is not posible.
>
> --
> geni
>
> _______________________________________________
> foundation-l mailing list
> foundation-l op lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/foundation-l
>


body:
Not true. *if* we would allow NC, I bet it will be possible to persue a lot
of institutions to give their images, paintings, texts etc away under the
NC. So it does have a huge potential, also for pictures with on the short
term no free equivalent. But that is not what this discussion should be
about imho. I dont think we should be talking about what images we would
like to use, i think we should talk about what we are *allowed* (legally) to
use. And as I said already quite a while before, that is mostly a case for
license-experts, copyright-experts, the foundation and their willingness to
face a potential sue, and maybe as well the free software foundtaion, the
writer of the GNU Free Documentation License.
*If* it would be allowed by all those, it is time for us as community or
maybe as every community by itself, to choose what licenses we *want* to
use, taking into account what the possible consequenses are and what the
costs to our ideals are.
The first is more a fact, that we have to find out, and let some people do
research to, the second is more an opinion. For the first I would suggest to
ask experts to find this out, to ask the foundation to take a stand on this
issue, to ask the FSF advice, and see whether it is _allowed_ or not.
For the second question I would suggest to have a more structured and broad
discussion, possibly on meta, where the discussion could be split into
different topics, and the arguments can be collected in a way that one can
keep oversight. Because who exactly is benefitting from this very
discussion? We have very great texts here, but the problem is that probably
only a small group reads this (due to the amount of text) and those in this
group already took a stand, and wont be persuaded anymore. It makes little
sense that way :) Please let someone set up a structured discussion on meta,
so it will be easier to follow, and it will less be making people to quit
foundation-l due to the amount of messages in their inbox (not everybody has
gmail). I myself would prefer first _*at least*_ a guideline of the
foundation, stating what the boundaries are within which we can move.

Lodewijk

2007/1/19, geni <geniice at gmail.com>:
>
> On 1/19/07, rfrangi at libero.it <rfrangi at libero.it> wrote:
>
> > Same applies to NC images.
> >
> > Roberto (Snowdog)
>
>
> There arew very few NC images for which a free equiv is not posible.
>
> --
> geni
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/foundation-l
>


from_name: Brad Patrick

subject: [Foundation-l] Fundraising drive closed

body:
In simple terms, we are still going to be struggling to keep up with our
hardware purchases if our traffic remains on its trajectory.  We are not
going to be able to hire for all of the positions we would like to, and we
don't have an operating cushion which is appropriate for our size and
requirements.

In other words we can keep the wolves at bay, but not eliminate them, given
this effort.

On 1/19/07, David Gerard <dgerard at gmail.com> wrote:
>
> On 19/01/07, Erik Moeller <erik at wikimedia.org> wrote:
>
> > The Virgin Unite donation is not accounted for yet (should happen in
> > the next few days). Overall, the fundraiser has been a success, and
> > some exciting new possibilities are being discussed on the
> > Board-level.
>
>
> So how hurt are we by making $1M rather than the hoped-for $1.5M?
>
>
> - d.
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/foundation-l
>

--
Brad Patrick
General Counsel & Interim Executive Director
Wikimedia Foundation, Inc.
bradp.wmf at gmail.com
727-231-0101


subject: [Foundation-l] Fundraising drive closed


from_name: Marc Riddell

subject: [WikiEN-l] What is an "expert"?

body:
Hello all,

I believe there is something we should ask at this point. This question is
for everyone participating in this Mailing List:

What is your definition of an "expert"?

Please, for now, try to resist responding to the others' answers, simply
state your own.

Marc Riddell


from_name: Rob Smith

subject: [WikiEN-l] What is an "expert"?

body:
On 1/19/07, David Gerard <dgerard at gmail.com> wrote:

>  Someone who knows
> their given field and can show they are regarded as someone who knows
> said field.

By this definition "expert" and "recognized expert" are mutually the same,
i.e. mutual backlslapping is the key.

nobs


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

Brad Patrick wrote:
> Is there a latent hardware solution necessary?; that is, was the problem a
> function of size as well as cleanup, or just the cleanup?

Just cleanup. Binlogs had been accumulating since September 30 on
samuel, totaling about 65 GB. Had they been cleaned up more regularly
there would have been no disk shortage.

(Incidentally I removed the earliest 10GB during emergency cleanup to
free up some work space on the drive.)

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

iD8DBQFFsPrHwRnhpk1wk44RAgvyAKCDijMh4yO8RQiuK3ysNgZst2T6PgCfTA5Y
mtWmsMlJzfiCw5pXLk9fq4s=
=NDvw
-----END PGP SIGNATURE-----


from_name: Virgil Ierubino

body:
The introduction of ParserFunctions was reluctant, but look how it's taken
off. Reluctance against programming-language-style extensions is many-fold,
but primarily is this concern: Wikitext is not a programming language. It's
a markup to simplify formatting in articles. So complicating it with
parameters and arguments and functions is just wrong wrong wrong. I agree.

The problem is, users of Wikitext *want* to program. But not in articles, in
templates.

It's simply true that the way templates are used is not entirely as they
were originally intended. Originally they were very simple transclusion
devices. Now they are complex ways of organising and structuring data in an
easy and efficient way - the point being that users (without technical
know-how) can include templates in their articles with simple code (e.g.
{{template|a|b|c}} ) and receive a specially generated result tailored to
the applicable article by the template code. This is obviously a massively
useful way of allowing articles to have better information better presented,
and allowing non-tech-savvy users (or even the tech-savvy ones) to very
quickly and easily and intuitively insert complex formatting like
a (dynamic) infobox into their articles.

So the way I see this, it's only really in *templates* that the advanced,
programming-like features are required, and the reason is that, simply due
to evolution, templates are being used like subroutines or functions. And
for good reason. That's a very very *very* useful thing for them to be able
to do. Which is why they are all doing it. That kind of functionality makes
MediaWiki an extremely powerful wiki engine - it's extendible from within.

But if these "functions" are being written in Wikitext, that makes Wikitext
more than just markup, which is confusing - so scrap them. And yet, software
support for such "functions" is incredibly useful - so keep them!

There's a solution here. How about we introduce another language ****that is
only available in the Template namespace****, specifically for this
function? Call it Wikisyntax. Wikisyntax is a pure (and simple) programming
language, with no markup. Wikitext is a pure and simple markup language,
with no code.

Normal users (who can use Wikitext fairly easily) rarely ever look at the
template namespace anyway. It's a simple fact that your average user of
MediaWiki has no idea what a template is, and will never create or edit one
until he or she is quite advanced and has got a strong understanding of the
system. Thus it is not objectionable on usability grounds alone to expand
the code for the template namespace. In fact, usability is a *reason* to
support the idea of Wikisyntax: templates *are* being used like this because
it's an extremely fruitful feature, so it would make things easier, but it
would keep the complexity seperate and hidden away from normal markup and
articles. Of course, users can still write templates with just Wikitext, but
the Wikisyntax option is there.

Crucial is the point that the Wikisyntax code is only parsed when written in
the template namespace. This allows Wikitext to remain a pure markup for use
in articles by normal users, without confusion. But the Template +
Wikisyntax idea is, essentially, a way of allowing a wiki to have *custom
subroutines* that **aid** those normal users in normal articles. No other
Wiki engine has that kind of power.

Would this idea be difficult to implement? I don't think so at all.
Wikisyntax can be a seperate file, say, SyntaxParser.php, called only when
necessary. Its contents can simply be (mildly altered, although not much) a
copy-and-paste of the ParserFunctions extension that is already written, and
any others we'd like to include, e.g. StringFunctions and VariablesExtension
(discuss later). We *already have the code* (pretty much) for this new
template language!

I have made a page on Meta for this suggestion:
http://meta.wikimedia.org/wiki/Wikisyntax , please leave your comments
either here or there. Thanks.


subject: [Wikitech-l] eAccelerator and memcached use

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

Mike O wrote:
> Is there any advantage or deteriment to using both eAccelerator AND
> memcached on the same single server Wikipedia mirror on a relatively
> low traffic site? The reason I ask is that eAccelerator is installed
> as a PHP plugin and memcached is also installed. MediaWiki is set to
> use memcached for caching, however eAccelerator picks up on the PHP
> script and caches them too. So I'm wondering if that's a good idea
> (possibly redudant) or should I disabled eAccel in favor of
> memcached? Far as I know memcached is set to use 128MB of RAM at the
> moment. eAccelerator appears to be set to use 32MB, if that matters
> for answering the question.

Well, try it both ways and see which way gives you better performance... :)

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

iD8DBQFFsPuqwRnhpk1wk44RAhSeAKDEbtBh4Ix2LMZdNuKAapizSuOX8gCfTaZa
/nKgAYK92/+MZwqqGC1Jw3E=
=Kxk4
-----END PGP SIGNATURE-----


from_name: David Gerard

body:
On 19/01/07, David Strauss <david at fourkitchens.com> wrote:

> #loop is a problem. If this template language is Turing-complete, it can
> be used to run infinitely long programs. That is a huge avenue for abuse.
> Then again, there could be an execution limit to the parsing of a template.

We have one real-life example of this, of course, in the recent
template on es: Wikipedia that took 20 seconds to run and caused some
annoyance on wikitech-l ... how feasible are execution time limits in
practice, what's a reasonable limit (knowing people are going to push
as close to it as they can) and what's a reasonable failure mode
(knowing people are going to push as close to it as they can)?

- d.


subject:
[Wikitech-l] [Foundation-l] Wikitext isn't a programming
	language, but...


body:
On 19/01/07, Virgil Ierubino <virgil.ierubino at gmail.com> wrote:

> There's a solution here. How about we introduce another language ****that is
> only available in the Template namespace****, specifically for this
> function? Call it Wikisyntax. Wikisyntax is a pure (and simple) programming
> language, with no markup. Wikitext is a pure and simple markup language,
> with no code.

Oh yes please. Separate data and code!

MediaWiki is one of those really nice bits of technology that lets
geeks get really geeky, *but* is so simple to use that even people who
can't work computers can be fantastically productive with it. (c.f.
Firefox, LiveJournal, Mac OS X.)

It's hard to get across to some of the people pushing MediaWiki markup
to its limits just how intimidating the computer gobbledygook can be
to people who just hit "edit this page" and want to write about
something they know about the subject.

- d.


from_name: Jeff Raymond

subject: [WikiEN-l] What is an "expert"?

body:
Marc Riddell wrote:

> What is your definition of an "expert"?

1) Someone with academic training and/or credentials in a given field.

2) One with significant demonstrated knowledge in a subject.

It's a rather fluid term given the subject matter that's involved, though.
 To be a law "expert," you almost certainly need legal training.  To
become an expert on a specific subject (like, say, a film or a sports
team), it may simply involve having done significant research on it.

-Jeff


from_name: Guy Chapman aka JzG

subject: [WikiEN-l] Reliable sources (Guy Chapman aka JzG)

body:
On Fri, 19 Jan 2007 00:51:33 -0800 (PST), zero 0000
<nought_0000 at yahoo.com> wrote:

>> if there has never been a reputably published biography or profile,
>> then I don't believe we can have an article.

>This would include minor actors and exclude famous scientists.
>Even scientists who have a large number of scientific achievements
>are rarely the subjects of published biographies.  Being famous
>enough to get a mention in newspapers doesn't help either, since
>such articles rarely provide information like place of birth.

Many notable scientists are profiled in pop science and other
journals.  And a fair number of those who have not, really should not
be on Wikipedia.  Take Piotr Blass, for example.  He re-created his
article about ten times before we finally  banned him.

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


from_name: Oskar Sigvardsson

subject: [WikiEN-l] Searching an article history

body:
On 1/19/07, Ray Saintonge <saintonge at telus.net> wrote:
> What helps is a good search strategy.  Batching the diffs into
> successively smaller groups is faster than looking at every one
> individually.
>
> Ec

That's what I do too, a sort of binary diff-search.

--Oskar


subject: [WikiEN-l] Independent article

body:
On 18/01/07, nunh.huh at mac.com <nunh.huh at mac.com> wrote:

> > what do we do when mostly we're right, we're occasionally
> laughably (or harmfully?) wrong

> Well, when the reporter calls, it might be good to follow-up "Wikipedia is not a reliable source" with "and there are no sources which are completely reliable", and point them towards our <http://en.wikipedia.org/wiki/List_of_premature_obituaries>

"Like the print media, Wikipedia is a *pretty good* source, but it's
not of such reliability that you can just accept whatever you see
there without thinking for yourself." How's that?

- d.


body:
On 19/01/07, Alphax (Wikipedia email) <alphasigmax at gmail.com> wrote:

> So it's alright so stick your fingers in your ears and shout "It's
> alright, I have a positive attitude!" as you go around ignoring the
> advice of "experts", and go around doing as much damage as possible?

Er, what damage??

- d.


subject: [WikiEN-l] Searching an article history

body:
On 19/01/07, Oskar Sigvardsson <oskarsigvardsson at gmail.com> wrote:
> On 1/19/07, Ray Saintonge <saintonge at telus.net> wrote:

> > What helps is a good search strategy.  Batching the diffs into
> > successively smaller groups is faster than looking at every one
> > individually.

> That's what I do too, a sort of binary diff-search.

Yep. It's a bit painful, but is generally feasible. Nightmare on a
really heavily edited page, of course.

- d.


from_name: Ryzvel at 3mail.com

subject: [WikiEN-l] Independent article

body:
Sounds a bit like the Brittanica! Tim . . .
On 18/01/07, nunh.huh at mac.com <nunh.huh at mac.com> wrote:

> > what do we do when mostly we're right, we're occasionally
> laughably (or harmfully?) wrong

> Well, when the reporter calls, it might be good to follow-up "Wikipedia is not a reliable source" with "and there are no sources which are completely reliable", and point them towards our <http://en.wikipedia.org/wiki/List_of_premature_obituaries>

"Like the print media, Wikipedia is a *pretty good* source, but it's
not of such reliability that you can just accept whatever you see
there without thinking for yourself." How's that?

- d.

_______________________________________________
WikiEN-l mailing list
WikiEN-l at lists.wikimedia.org
To unsubscribe from this mailing list, visit:
http://lists.wikimedia.org/mailman/listinfo/wikien-l


from_name: Anthere

subject: [Wikitech-l] MediaWiki as a Wikimedia project

body:
David Gerard wrote:
> On 10/01/07, Erik Moeller <erik at wikimedia.org> wrote:
>
>
>>Well, Brion has been the release manager for MediaWiki for years.
>>Since he's on the payroll of WMF, I don't think we're assuming any
>>_new_ responsibilities, but merely clarifying existing
>>responsibilities. And I definitely do agree that the WMF should do a
>>better job at soliciting and coordinating external contributions to
>>MW, but this, like many other things the WMF _should_ be doing, is
>>greatly limited by our ability to spend money on doing so.

For the record, Erik proposed to the board that MediaWiki becomes a
wikimedia project some weeks ago, and I indicated I was not overly
supportive of the idea and asked that he asks their opinion to developers.

I am not very happy with the idea, because to the difference of the
wikimedia project,
Mediawiki is directly used by and developed for the benefit of many
other projects.

Examples: right now, no organisation is "authorized" to host a bit of
the projects. No organisation is "authorized" to put an advertisement on
the project sites. And to take the example of OmegaWiki, no organisation
is authorized to add itself as a "sponsor" or whatever of any of our
projects. Because practically, the projects are financially supported at
99% by the Foundation.

Do you really want that for MediaWiki ?

I agree the term "related" does not describe the current relationship
between MediaWiki and the Foundation. I think Brion gets it right in
saying "Wikimedia projects are the primary customers of the MediaWiki".

I would prefer to make it clear the relation between software and
foundation, but not to qualify it under the same terms than the relation
with the projects.

> OK - what does officially putting MediaWiki under the umbrella of the
> WMF do for MediaWiki that is an improvement on the present situation?
> List with + and -.

I saw no answer to this part. Unless I really missed it entirely. I
would like to see arguments.

The main argument given by Erik was the techsummit. We are planning to
have in the future a big bunch of days dedicated only to mediawiki
development... for its primary customer. It seems a bit odd for an
organisation to give so much to a project that is not even recognise as
one of its project. Hence the suggestion to officially announce
mediawiki as a Foundation project.

Meanwhile, I would like to see a list of pro and con developped before
letting the board participate to such a decision ;-)

ant

> - d.


from_name: Evan Martin

body:
On 1/19/07, Domas Mituzas <midom.lists at gmail.com> wrote:
> > disabled eAccel in favor of memcached? Far as I know memcached is set to use
> > 128MB of RAM at the moment. eAccelerator appears to be set to use 32MB, if
> > that matters for answering the question.
>
> eAccelerator caches bytecode, memcached does not.
> Even then, if eAccelerator is used as bytecode cache, it is 10x faster than
> memcached, because there's no more communication/serialization overhead.

See the "What about shared memory?" section of
http://www.danga.com/memcached/ to get the other side of this.  Since
you (the OP) have a single server this advantage isn't useful, I think
you'd be better off growing the eAccelerator cache to 128+32mb for the
reasons Domas mentioned.


list: commons-l

subject: [Commons-l] good animated GIF artist needed

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

David Gerard wrote:
> Oh, are SVG animations live in MediaWiki on Wikimedia? I thought it
> used a restricted subset of tags to avoid active content dangers. Do
> we have any animated SVGs on Commons as yet?

You can't really use animated SVGs comfortably at this time; SVG images
are rasterized to flat, solid, unmoving PNG images for display inline.

You could of course upload an animated SVG as source if you can convert
it to something else that will actually display inline usefully
(animated GIF? ;)

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

iD8DBQFFsQ9bwRnhpk1wk44RAtTBAJ9rI/Mu4YnKIMvq+Obro5BoLzvd5wCgpqbJ
gngkaAPfOstCzPEBqbmkyyA=
=yd8C
-----END PGP SIGNATURE-----


from_name: Rob Church

subject:
[Wikitech-l] [Foundation-l] Wikitext isn't a
	programminglanguage, but...

body:
On 19/01/07, Andrew Garrett <andrew at epstone.net> wrote:
> implement it in PHP as part of MediaWiki. MediaWiki is a piece
> of software, not an IDE.

Not like DevAnywhere. :P

Rob Church


body:
On 19/01/07, Anthere <Anthere9 at yahoo.com> wrote:
> I agree the term "related" does not describe the current relationship
> between MediaWiki and the Foundation. I think Brion gets it right in
> saying "Wikimedia projects are the primary customers of the MediaWiki".

This being the case, we generally develop functionality with a
semi-defined project scope in mind for MediaWiki; it's a wiki engine,
mostly driven by the Wikimedia interpretation of a wiki.

A *lot* of what goes into MediaWiki (aside from bug fixes) is new
functionality developed *for* use on Wikimedia wikis; a lot of
extensions are developed to facilitate extras for Wikimedia. Having
said that, there *are* things going into development which Wikimedia
might never make use of, but which fall under the general scope of
what MediaWiki is supposed to function as; a lot of additional
extensions and plugins, for instance - stuff like LDAP authentication
and other corporate/academic-used features.

I don't see any real problem with the current interpretation of
things. MediaWiki is as open as Wikipedia - the code is licenced under
the GNU GPL and anyone who really feels strongly about it can fork it
quite happily at any time.

A huge number of organisations can and do take a vested interest in
developing the software to its fullest potential. The superb effort
going into things like Semantic MediaWiki and WiktionaryZ may never
have been on the agenda in 2003, and may not be completely adopted in
all Wikimedia projects, but they're very much in tune with what
MediaWiki is.

What is MediaWiki? It's a free form wiki engine which has a purpose.
That purpose is to make sharing of ideas, information and content easy
for anyone.

How is that counter to any Wikimedia ideology? It's not. I think
MediaWiki development works better when everyone feels they're in a
comfortable environment where they're free to work on their own
portions that interest them. Sure, they have to put up with me
swearing every so often...sure, they have to be careful. But I
personally, and I suspect others, have a nice comfortable feeling of
not having to be accountable to the Wikimedia Board of Trustees. I
like that; I can view all my users as equals.

In case it's not clear; I support the current status quo.

Rob Church


from_name: Ray Saintonge

body:
Gerard Meijssen wrote:

>When it is painful that things are not available in Wikipedia because we
>do not allow for fair use, it will stimulate the debate about the way
>copyright is an offence to bringing information and science to the
>people. By using fair use pictures you allow the status quo to maintain
>it self. The dearth of material about certain subjects makes them even
>less relevant. For the parties like the RIAA it is important to realise
>that without the availability of material like this, many of their
>artists will only be forgotten that much quicker. Not that they are
>likely to care because there is always the next boy band or girlie group
>to hype.
>
This is an interesting perspective.  There is still a need to
differentiate between how existing copyright law relates to Wikimedia
projects, and what, if anything, we should be doing to promote changes
to copyright law.  Both are important, and both require a high degree of
individual acceptance of responsibility.

In regards to the former highly compliant policies that attempt to avoid
the slightest hint of a lawsuit keep the likes of RIAA very happy, and
do nothing to advance the projects.  Overly aggressive policies can be
just as harmful because they will drain the Foundation in unwinnable
lawsuits.  Ironically, if no one so much as takes the first steps in a
legal proceeding that is probably a sign that we are being too timid.
Such proceedings can be an incentive to review the issues involved in
the light of real circumstances, and in most cases we can take the
opportunity to concede before the matter gets out of hand, and to push
forward conservatively in only those cases where vital issues are at
stake.  For the most part the burden of taking these matters further
along the legal paths should rest with the person who has the belief
that some particular text or image is indispensible to the relevant
Wikimedia project.

I think that our mission is more than simply regurgitating material that
is already free.  To me it also involves freeing that which is not yet
free.  With material that is clearly protected this may involve simply
getting permissions which the owner is easily willing to give.
Sometimes the owner is simply not findable, and the material is
orphaned; at other times the person claiming the copyright is making an
invalid claim for any of a number of reasons.  While I strongly support
the continued inclusion of properly defined fair use material, I also
make special note of the fact that there are numerous other provisions
in the law that would succeed as well if not better to substantiate the
free nature of specified texts and images.

Securing change in copyright law is a separate problem.  It requires
caution to insure that our status as a tax-exempt corporation will not
be jeapordized by excessive participation in lobbying or other political
activities.  It does not stop any individual from relating his
experiences as a Wikimedia editor.  It does not stop us from discussing
the directions that we would like legislators around the world to take
in this direction, and arriving at a realistic synthesis that would
balance interests on both sides of the copyright divide.  After all one
of the purposes of such law is to balance divergent interests.  In the
light of our broader mission what is worth more to us: limiting fair use
in places that already have it, or seeking an expansion of fair dealing
in places that apply it too restrictively?

Ec


from_name: Alphax (Wikipedia email)

subject: [WikiEN-l] Independent article

body:
Daniel R. Tobias wrote:
> On 17 Jan 2007 at 12:10, "Abigail Brady" <morwen at evilmagic.org>
> wrote:
>
>> On 1/17/07, David Gerard <dgerard at gmail.com> wrote:
>>> [[Marti Pellow]] had some vandalism that made the media - it said for
>>> five hours on Friday that he was dead. If people could watchlist it,
>>> that would be good (that should be enough for now).
>> Note, same IP claimed that Dec, of Ant and Dec, was dead: and this
>> stayed until yesterday. :(
>
> [[Kellie Pickler]] was listed as dead on her article recently too.
>
>

/me goes to check [[Francisco Franco]]...

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

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


subject:
[WikiEN-l] Citizendium trying out not being a fork of Wikipedia
 for a while

body:
cohesion wrote:
> On 1/18/07, Guettarda <guettarda at gmail.com> wrote:
>>>> Larry Sanger writes,
>>>>
>>>>   "After seeing the widespread support for the suggestion
>>>> that we try *not* forking Wikipedia--i.e., that we delete all articles
>>> that
>>>> are not marked "CZ Live"--I am about to instruct our tech team to go
>>> ahead
>>>> and make the deletion...
>
> So, if they are making new material, will this be free content or not?
>

No. Non-commercial-only is a SEVERE limitation of freedoms. I'm sure the
[[DFSG]] talks about it somewhere... ah, here we go:

6. No discrimination against fields of endeavor, like commercial use

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

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


from_name: Steve Block

subject: [WikiEN-l] My own Livejournal

body:
Mark Ryan wrote:
> Please stop this. Civility is a two-way street, and we should afford
> even those who are critical of us some basic courtesy (that is the
> case even if they do not show the same courtesy in response).
>
> I have put Parker Peters' new email address onto moderation, and that,
> I hope, is the end of the matter. If he/she wants to continue to
> contribute to the mailing list in a civil fashion, he or she is more
> than welcome to do so, via the moderation queue.

Civility is a two way street.  But when people are abusing our good
faith by creating problems on Wikipedia and then assuming differing
identities to create a hostile environment on the mailing list, I think
it's going too far in one direction to keep turning the other cheek.
I'm a little disappointed people who abuse our good faith are offered
such hospitality, but well aware I have the option open to simply ignore
such behaviour from now on.

Steve block

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.0/639 - Release Date: 18/01/07 18:47


body:
Guettarda wrote:
> On 1/18/07, Steve Block <steve.block at myrealbox.com> wrote:
>> Matt R wrote:
>>> As per the subject, excerpts from:
>>>
>>>
>> https://lists.purdue.edu/pipermail/citizendium-l/2007-January/000863.html
>>> Larry Sanger writes,
>>>
>>>   "After seeing the widespread support for the suggestion
>>> that we try *not* forking Wikipedia--i.e., that we delete all articles
>> that
>>> are not marked "CZ Live"--I am about to instruct our tech team to go
>> ahead
>>> and make the deletion...
>> I'm a bit clueless, but does this mean they haven't used any Wikipedia
>> content, or that they have but they're hiding it?  I mean, all the
>> articles that are marked "CZ Live", are they based on Wikipedia content?
>>   And if they are, doesn't that mean they *have* to license under GFDL?
>>   Which, unless I got confused in another thread, they aren't planning
>> to do?
>>
>> Steve block
>
>
> Steve - if you poke around the Citizendium forum (there's a link to it in
> Matt's email) a lot of your questions may be answered.

I looked at Citizendium a while back but couldn't for the life of me
work out how I was supposed to become a contributor so I gave up looking
at it.

> Apparently their first "approved" article, Biology, was a complete re-write
> - the Wikipedia article was blanked.  Other people have modified existing
> articles.  As I understand it, the CZ Live stuff is stuff that people are
> working on.
>
> Obviously they can't release work based on WP articles under a more
> restrictive license.  New material could be - it seems to me that there's a
> debate between people who want the whole project to by cc-by-nc and those
> who want it to stay GFDL.

I can't see how you can ringfence certain articles.  If information is
moved from one GFDL article to another, a cc by nc, then the new article
must be both GFDL and cc by nc, no?  And aren't they incompatible?

Still, not really a huge amount of sense discussing citizendium here.

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.0/639 - Release Date: 18/01/07 18:47


body:
zero 0000 wrote:
>> From: Guy Chapman aka JzG <guy.chapman at spamcop.net>

>> Actually I think this is a good litmus test for whether an individual
>> is encyclopaedically notable.  If there are no sources for basic
>> biographical data other than the individual themselves, in other
>> words
>> if there has never been a reputably published biography or profile,
>> then I don't believe we can have an article.
>
> This would include minor actors and exclude famous scientists.
> Even scientists who have a large number of scientific achievements
> are rarely the subjects of published biographies.  Being famous
> enough to get a mention in newspapers doesn't help either, since
> such articles rarely provide information like place of birth.

Conference and conventions publish biographical data, I know the source
is generally the person, but they should be reputable as sources.
Magazines like New Scientist often profile scientists too, although my
subscription lapsed a few years back.

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.0/639 - Release Date: 18/01/07 18:47


body:
Is there a latent hardware solution necessary?; that is, was the problem a
function of size as well as cleanup, or just the cleanup?

On 1/19/07, Brion Vibber <brion at pobox.com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> == Summary ==
>
> Full disk on the database master for non-en.wikipedia.org made most of
> our wikis uneditable for about 2.5 hours, during Europe midday / US
> morning.
>
> Immediate problem is repaired; some minor further cleanup needed;
> procedural changes recommended.
>
>
> == Disruption and data loss ==
>
> The last edits to make it to the slave servers were at:
> 2007-01-19 11:50:29 UTC
>
> A few more made it through on samuel before it stopped accepting more
> data up to:
> 2007-01-19 11:51:03
> (23 broken edits on de.wikipedia.)
>
> After that point the database didn't accept more writes, leaving a
> read-only state which didn't allow any further consistency problems to
> develop.
>
> There _may_ be some minor problems related to caching of revision data
> where ID numbers overlap from the old server, but this is unclear.
>
>
> == Inspection and repair ==
>
> I was woken up around 13:50 to take a look, informed that samuel
> (non-enwiki master) was out of disk space and wikis were read-only.
>
> After a few minutes to check that the slaves were consistent and that
> there wasn't _too_ bad a lag between them and the master, I decided to
> go ahead with a master switch to adler, leaving samuel out of service
> until it gets re-cloned.
>
> By 14:26 the master switch was done, and read-write service restored.
>
>
> == Further work: immediate ==
>
> If really desired, we may be able to clone the small number of 'lost'
> edits from samuel.
>
> Once we no longer need samuel's data, it should have its database
> re-cloned from one of the slaves consistent with the new state, and it
> can be restored to slave service.
>
>
> == Further work: long-term ==
>
> Our procedure for monitoring disk space and cleaning up binlogs is
> terrible.
>
> Low-disk warnings from Nagios are routinely ignored, in part because the
> thresholds seem much too high.
>
> Binlog cleanup appears to be entirely manual and ad-hoc; there is no set
> schedule or assignment to do this.
>
> The good news is this task is easy to automate.
>
> Recommendation:
> * automate cleanup of binlogs on the db masters.
> * make low-disk warnings more reasonable and visible for the masters
> specifically (where it really, really matters)
>
> - -- brion vibber (brion @ pobox.com)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFsOS1wRnhpk1wk44RAjujAKDLga9UHrs9Z5o0E6DM24puZvkSMwCeO9N0
> /TIoWOSKKdUMOO3Lu5Bdn0M=
> =R6SD
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

--
Brad Patrick
General Counsel & Interim Executive Director
Wikimedia Foundation, Inc.
bradp.wmf at gmail.com
727-231-0101


body:
Ray Saintonge wrote:

> The Renaissance Wikipedian who is not associated with a university has
> to make do with what he can find.  If all he can find is internet
> material it will shape and limit his perceptions.  Fact checking should
> be one of our jobs, but doing that effectively depends on having access
> to information.

I have been meaning to ask this. Has it ever been explored that the
Foundation look at getting some subscriptions to archives and the like
and allowing a reference team access to those subscriptions to do some
fact checking?

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.0/639 - Release Date: 18/01/07 18:47


subject: [WikiEN-l] My own Livejournal

body:
On 19/01/07, Steve Block <steve.block at myrealbox.com> wrote:

> I'm a little disappointed people who abuse our good faith are offered
> such hospitality, but well aware I have the option open to simply ignore
> such behaviour from now on.

I urge all readers to deal with such silliness by ignoring it and
talking about useful and sensible things.

(Although I do acknowledge that there are times when suppressing one's
incredulous reaction requires gritting one's teeth hard enough to
break a molar.)

- d.


subject: [WikiEN-l] My own Livejournal

body:
Parker Peters wrote:
> Guettarda,
>
> I waited over a week after having my account with Gmail fixed following the
> major database corruption. This necessitated the creation of a new Gmail
> account as the old one was beyond recovery.
>

Without some sort of corroborating evidence, why should we believe you?

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

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


body:
On 19/01/07, Steve Block <steve.block at myrealbox.com> wrote:

> Still, not really a huge amount of sense discussing citizendium here.

It's a relevant and interesting related project, so is relevant to
discuss insofar as it informs what Wikipedia does and how it does it.

- d.


from_name: Glen S

subject: [WikiEN-l] Moving the Main Page (sic)

body:
On 1/16/07, Rocky7 Peter <freudianjungianp at hotmail.com> wrote:
>
> Frankly speaking, "Main Page" sounds very foolish.
>
> Apparently "Today's Top Page" or "Today's Page" is better than "Main
> Page".
>
> "Main Page" is, therefore, very harmful to the reliability of all admins
> (except Mgm and someone) and all Wikimedia Projects.
>
> So, I think, "Change it, however difficult, as soon as you can".
>
> Sincerly
>
> Peter Rocky7

Ummm... what?! I think you're entirely missing the point; "reliability of
all admins"? I have no idea how moving it to "Today's Page" will affect my
reliability.

The entire idea of moving the page is absurd.

Glen
http://en.wikipedia.org/wiki/User_talk:Glen_S

On Mon, 15 Jan 2007 13:53:51 -0500, Pilotguy <pilotguy.wikipedia at gmail.com>
> wrote:
> >
> >Indeed. Keep it the way it is now. There's no harm being done anyway.
> >
> >On 1/15/07, Gary Kirk <gary.kirk at gmail.com> wrote:
> > >
> > > Anyway, we can always create these articles as [[Main Page (book)]],
> > > [[Main Page (film)]] and so on. It really is a non-issue - there's no
> > > definite reason to move our Main Page.
> > >
> > > Jm2p...
> > >
> > > On 1/15/07, MacGyverMagic/Mgm <macgyvermagic at gmail.com> wrote:
> > > > It might be just me, but I don't think a movie or book titled "Main
> > > Page"
> > > > would actually get sold to a editor or studio representative. Titles
> are
> > > key
> > > > to drawing in an audience, and when someone came to me with that as
> a
> > > title,
> > > > I'd ask them to change it.
> > > >
> > > > Mgm
> > > >
> > > >
> > > > On 1/14/07, PeruvianLlama <peruvianllama at gmail.com> wrote:
> > > > >
> > > > > Luna wrote:
> > > > > > Right. But since we're obviously going to need such a redirect,
> what
> > > do
> > > > > we
> > > > > > gain from moving Main Page? It's a lot of work for...?
> > > > > >
> > > > > The idea would be that such a redirect would be temporary. The
> problem
> > > > > of having Main_Page in the namespace wouldn't be solved overnight,
> or
> > > > > even in a matter of days. But at least it would be solved a year
> (or 6
> > > > > months, or whatever) down the road. That's a long time, but like I
> > > said,
> > > > > I haven't seen anyone claiming that this is really any kind of an
> > > > > immediate worry. It's just a good idea for the sake of long-term
> > > > > consistency.
> > > > >
> > > > > If we wait until the movie/book/etc. called "Main Page" is made
> and
> > > > > suddenly wants to be in that article page, then we no longer have
> the
> > > > > luxury of doing things at a reasonable pace. Then it really will
> be
> a
> > > > > big issue to update all of our internal links, and to hope that
> > > external
> > > > > links update quickly enough. If we're proactive about this, we
> might
> > > be
> > > > > saving ourselves a headache. At worst, like I said, we're at least
> > > being
> > > > > consistent.
> > > > >
> > > > >
> > > > > MacGyverMagic/Mgm wrote:
> > > > > > And it still doesn't open up the page for any potential films,
> books
> > > or
> > > > > > articles on anything else, because leaving a redirect is what we
> > > need to
> > > > > not
> > > > > > kill incoming links from outside of Wikipedia.
> > > > > > Mgm
> > > > > Not immediately no, but it opens up the possibility of doing so in
> the
> > > > > future. After a year we can drop the redirect, since most/all of
> the
> > > > > external links will have updated. Those that haven't, well, a
> broken
> > > > > link or three isn't going to bring either Wikipedia or the
> internet
> at
> > > > > large to its knees. The reason I posted this idea was because the
> main
> > > > > three objections to moving appeared to be:
> > > > > 1) It will be too big a strain on the servers to move such a big
> page
> > > > > 2) It will be too much of a hassle to update internal links
> > > > > 3) It will be too much of a hassle to update external links
> > > > >
> > > > > I think that if it came to it, we could enlist the help of devs or
> > > other
> > > > > technical wizardry to eliminate the hurdles of objection #1.
> Objection
> > > > > #2 has already been rebutted. I was taking aim at objection #3.
> > > > >
> > > > > There isn't any wildly important reason to move Main_Page
> somewhere
> > > > > else, and I say again, it certainly isn't a terribly
> time-sensitive
> > > > > issue. But on the other hand, there don't seem to be any wildly
> > > > > important reasons to _not_ move Main_Page, other than things being
> too
> > > > > much of a hassle.
> > > > >
> > > > > Cheers,
> > > > > - PeruvianLlama
> > > > >
> > > > > _______________________________________________
> > > > > WikiEN-l mailing list
> > > > > WikiEN-l at lists.wikimedia.org
> > > > > To unsubscribe from this mailing list, visit:
> > > > > http://lists.wikimedia.org/mailman/listinfo/wikien-l
> > > > >
> > > > _______________________________________________
> > > > WikiEN-l mailing list
> > > > WikiEN-l at lists.wikimedia.org
> > > > To unsubscribe from this mailing list, visit:
> > > > http://lists.wikimedia.org/mailman/listinfo/wikien-l
> > > >
> > >
> > >
> > > --
> > > Gary Kirk
> > >
> > > _______________________________________________
> > > WikiEN-l mailing list
> > > WikiEN-l at lists.wikimedia.org
> > > To unsubscribe from this mailing list, visit:
> > > http://lists.wikimedia.org/mailman/listinfo/wikien-l
> > >
> >
> >
> >
> >--
> >Pilotguy
> >pilotguy.wikipedia at gmail.com
> >http://en.wikipedia.org/wiki/User:Pilotguy
> >
> >http://pilotguy.wordpress.com
> >_______________________________________________
> >WikiEN-l mailing list
> >WikiEN-l at lists.wikimedia.org
> >To unsubscribe from this mailing list, visit:
> >http://lists.wikimedia.org/mailman/listinfo/wikien-l
>
> _________________________________________________________________
> Hotmail ????????MSN ????????? http://jp.msn.com/
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>

--
Glen
http://en.wikipedia.org/wiki/User_talk:Glen_S


body:
geni wrote:

>On 1/19/07, effe iets anders <effeietsanders at gmail.com> wrote:
>
>
>>Not true. *if* we would allow NC, I bet it will be possible to persue a lot
>>of institutions to give their images, paintings, texts etc away under the
>>NC. So it does have a huge potential, also for pictures with on the short
>>term no free equivalent. But that is not what this discussion should be
>>about imho. I dont think we should be talking about what images we would
>>like to use, i think we should talk about what we are *allowed* (legally) to
>>use.
>>
>>
>Anything until the foundation gets the takedown notice however that
>approach is unhelpful.
>
Yes, except that I don't see it as unhelpful.  At the same time I do not
believe that we should be posting indisputably protected random material
for the sole purpose of getting a reaction from those we already know
will react adversely.  That would be a wilfull violation.

Talking about the images that we want is the path to talking about what
is allowed.  If we don't want the image in the first place it doesn't
matter if it's allowed.  Talking about what is allowed in an empirical
vacuum is a clear path to unrealistic answers.

>>*If* it would be allowed by all those, it is time for us as community or
>>maybe as every community by itself, to choose what licenses we *want* to
>>use, taking into account what the possible consequenses are and what the
>>costs to our ideals are.
>>
>>
>The foundation has rejected that position in the past. no reason to
>think they will do otherwise in future.
>
>You know I've seen complaints that the foundation pays to much
>attention to en at the expense of other projects. Now I hope you see
>the other side of that.
>
>
Adopting a common license as a basis to build from is a sensible
decision.  (Wikinews already uses a different licence from everyone
else.)  I think that this still allows projects some variation in how
the licence will be interpreted.  In dealing with fair use, AFAIK the
licences themselves are silent on the matter.  Any kind of dominance on
the Board has its downside, whether it's dominance of a language (like
English), or political entity (like the United States or the European
Union).

Ec


from_name: Petr Kadlec

subject: [Wikitech-l] Use binary to represent varchar rather than UTF8

body:
Hi!

On 17/01/07, Brion Vibber <brion at pobox.com> wrote:

> [...] While it is possible as of my testing
> last year to store UTF-16 data in UCS-2 fields by communicating with the
> server using invalid pseudo-UTF-8 which encodes the UTF-16 surrogate
> pair halves as separate UTF-8 characters, this would be very fragile and
> likely to lead to bugs, interoperability problems, and data corruption.)
> [...]

I believe this CESU-8 thing has been discussed before a bit (see
http://lists.wikimedia.org/pipermail/wikitech-l/2005-October/019766.html and
http://lists.wikimedia.org/pipermail/wikitech-l/2005-October/019611.html),
including filing a MySQL bug (see http://bugs.mysql.com/bug.php?id=14052, no
comments since, it seems).

-- [[cs:User:Mormegil | Petr Kadlec]]


from_name: George Chriss

subject: [WikiEN-l] What is an "expert"?

body:
My thoughts, the second comment in one of Sanger's postings:

http://www.dufoundation.org/blog/?p=96

-George / GChriss

On Fri, 19 Jan 2007 08:48:21 -0500  English Wikipedia  wrote:

Hello all,

I believe there is something we should ask at this point. This question is
for everyone participating in this Mailing List:

What is your definition of an "expert"?

Please, for now, try to resist responding to the others' answers, simply
state your own.

Marc Riddell

_______________________________________________
WikiEN-l mailing list
WikiEN-l at lists.wikimedia.org
To unsubscribe from this mailing list, visit:
http://lists.wikimedia.org/mailman/listinfo/wikien-l


body:
effe iets anders wrote:

>And as I said already quite a while before, that is mostly a case for
>license-experts, copyright-experts, the foundation and their willingness to
>face a potential sue, and maybe as well the free software foundtaion, the
>writer of the GNU Free Documentation License.
>
The fact is that there has been no corpus of case law built up relating
to free licences of any kind.  These experts are guessing just as much
as anybody else.  Risk tolerance, and the willingness for the Foundation
to face a law suit is important, but so too is the recognition that
there are numerous steps between where we are now, and a full-blown
lawsuit, and these usually include many opportunities to withdraw.

>I would suggest to have a more structured and broad
>discussion, ..., where the discussion could be split into
>different topics, and the arguments can be collected in a way that one can
>keep oversight.
>
Yes, but that demands an awful lot of focus and concentration from
people. ;-)

>Because who exactly is benefitting from this very
>discussion? We have very great texts here, but the problem is that probably
>only a small group reads this (due to the amount of text) and those in this
>group already took a stand, and wont be persuaded anymore. It makes little
>sense that way :) Please let someone set up a structured discussion on meta,
>so it will be easier to follow, and it will less be making people to quit
>foundation-l due to the amount of messages in their inbox (not everybody has
>gmail). I myself would prefer first _*at least*_ a guideline of the
>foundation, stating what the boundaries are within which we can move.
>
I don't know about meta; I very seldom go there anymore.  Some of us are
more accustomed to going through the mailing lists than watching a
number of separate pages on meta., though I admit that it could be
easier to keep the discussion a little more organized there.

Ec


from_name: Thomas Dalton

subject: [WikiEN-l] My own Livejournal

body:
> We saw you accidentally replying as "Bob" from your
> "onmywayoutser" address, or vice versa; then hand-editing
> a response or two in a clumsy attempt to cover it up; then
> disingeniously claiming that there had been some kind of bizarre
> gmail failure.  (I mean, +1 for creativity in a desperate
> situation, but minus several million for believability.
> Though I suppose you get a few more points for brazen chutzpah
> for having somehow convinced the moderators to let messages from
> your new account through; I can't imagine how you managed that.)

I would give him +10 for creativity - it was a damn good try. I knew
it was rubbish, but I wanted to believe it, I really did...


from_name: Ligulem

subject: [Wikitech-l] Wikitext isn't a programming language, but...

body:
On 19.01.2007 10:10, Virgil Ierubino wrote:
> There's a solution here. How about we introduce another language ****that is
> only available in the Template namespace****, specifically for this
> function? Call it Wikisyntax. Wikisyntax is a pure (and simple) programming
> language, with no markup. Wikitext is a pure and simple markup language,
> with no code.

Just a side note about the history of MediaWiki template syntax:

MediaWiki template syntax got the first stage of a "programming
language" when parameters for templates were introduced ("function call").

The introduction of default parameter values provided parameter
dependent text selection in templates ("if"-construct).


subject: [WikiEN-l] Expertaphobia

body:
> The problem with expertise on Wikipedia is how to judge whether or
> not someone is an expert.

Exactly. And short of the foundation phoning people's universities and
confirming degrees, it always will be. (And that only works for
subjects where it's possible to get a degree... I don't think there is
any easy way to confirm other kinds of qualifications (experience, for
example).)


body:
> I looked at Citizendium a while back but couldn't for the life of me
> work out how I was supposed to become a contributor so I gave up looking
> at it.

It seems it's still a pilot, so you have to email and ask permission
to join. That's too much bother for me, so I'm sticking to Wikipedia.