subject: [WikiEN-l] Process wonkery

body:
On 9/23/06, Stephen Streater <sbstreater at mac.com> wrote:
>
> On 23 Sep 2006, at 19:20, George Herbert wrote:
>
> > On 9/23/06, Stephen Streater <sbstreater at mac.com> wrote:
> >>
> >> On 23 Sep 2006, at 18:36, George Herbert wrote:
> >>
> >>> On 9/23/06, David Gerard <dgerard at gmail.com> wrote:
> >>>> On 23/09/06, Guy Chapman aka JzG <guy.chapman at spamcop.net> wrote:
> >>>>
> >>>>> The problem with the DRV is that the existence of a number of
> >>>>> votes
> >>>>> from obdurate "all schools are inherently notable" types means
> >>>>> that
> >>>>> vote counting gives no consensus, whereas a comparison of
> >>>>> arguments
> >>>>> from policy - specifically verifiability and hence the ability to
> >>>>> cover the subject objectively - shows a clear delete.
> >>>>
> >>>>
> >>>> This is a hardened attitude formed by people on VFD as it was who
> >>>> wanted to delete all schools from Wikipedia below the notability
> >>>> level
> >>>> of Eton. That is: the process was pathological on both sides.
> >>>>
> >>>> So let's assume every school will be in Wikipedia on the same basis
> >>>> that every pissweak or even no-longer-existent hamlet in the US
> >>>> will
> >>>> remain. What can be done then?
> >>>>
> >>>> * Is existence enough? Evidently.
> >>>> * So we need proof of existence and basic verifiable information.
> >>>>
> >>>> There should be enough for a stub at the very least. If you want to
> >>>> turn it into a list entry instead, the redirect needs to be in the
> >>>> appropriate place.
> >>>>
> >>>> If you're bringing this to wikien-l to re-fight the school deletion
> >>>> wars, you're probably not spending your time well.
> >>>>
> >>>>
> >>>> - d.
> >>>> _______________________________________________
> >>>> WikiEN-l mailing list
> >>>> WikiEN-l at Wikipedia.org
> >>>> To unsubscribe from this mailing list, visit:
> >>>> http://mail.wikipedia.org/mailman/listinfo/wikien-l
> >>>
> >>> Just for reference, we're looking at a worst case roughly 124,000
> >>> school stubs ( http://nces.ed.gov/programs/digest/d04/tables/
> >>> dt04_085.asp
> >>> ) for the US.
> >>>
> >>> I understand those that disagree, but I think the categorical
> >>> include
> >>> pseudopolicy for schools makes sense.  They're of immense
> >>> interest to
> >>> most parents, the school system has 72 million odd Americans in it,
> >>> and categorical inclusionism here is not in any way throwing
> >>> Wikipedia
> >>> into disrepute or threatening our server load or diskspace.
> >>
> >> I don't the issue is technological. It's more to
> >> do with the reliability of the information.
> >>
> >> The idea is that a smaller encyclopaedia with
> >> reliable information is better than one twice as
> >> big where (a possibly unknown) half of the
> >> information is unreliable.
> >> _______________________________________________
> >> WikiEN-l mailing list
> >> WikiEN-l at Wikipedia.org
> >> To unsubscribe from this mailing list, visit:
> >> http://mail.wikipedia.org/mailman/listinfo/wikien-l
> >
> > The existence of the school in question has been verified, as I
> > understand it.
> >
> > Nuking the article because one can't verify some other information in
> > the article is nonsense.  If it's not completely verifyable and you
> > have some particular question as to its accuracy, then tagging it with
> > unverified, then editing out the info in extremis, are the established
> > thing to do.
> >
> > This incident worries me.  Nothing personal to you, Guy, or Cyde Weys,
> > but there's an established consensus on schools.  Just because you've
> > been around for a long time and are admins doesn't mean you can game
> > the procedures to delete something which consensus says should stay.
> > Complaining when people kick back and complain about it is ... nice
> > chutzpah?
> >
> > This is part of the problem I had with Tony, back six months ago.
> > It's fine to be bold.  But the limit of being bold has to be when
> > consensus kicks back and complains about what you just did.  If your
> > reaction when consensus kicks back is "process wonkery sucks" then
> > there is a problem.
> >
> > Trying to undo a consensus via admin guerilla warfare, nicking little
> > slices off it here and there, is not a good way to fix things, and
> > particularly not a good way to establish positive admin/general editor
> > populace relations.
>
> Would you be happy with as stub stating the existence
> of the organisation? Is this verifiable from secondary sources?
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l

Happy?  No, it should be a fleshed out, referenced article.  That
would make me happy.

Acceptable?  Leave it as a stub with minimally verifyable information.

Bad?  Leave info in it which is unverifyable and appears suspicious or spurious.

Worse?  Keep it deleted.

All in my personal opinion, of course.

--
-george william herbert
george.herbert at gmail.com


list: foundation-l

source: pipermail-mbox

from_name: George Herbert

subject:
[Foundation-l] Does anyone else think bugzilla is a complete
	failure

body:
On 9/23/06, Brion Vibber <brion at pobox.com> wrote:
> Foundation-L probably isn't the best place to do it, but whatever works. ;)

Perhaps Birgitte SB should subscribe to Mediawiki-L, where the
software is the focus of discussion?

As an aside, is there a publically joinable WMF operations related
list (technical site operations, networking and systems and code)?
These are areas I am interested in possibly contributing in...

--
-george william herbert
george.herbert at gmail.com


list: wikimedia-l


list: wikitech-l

from_name: Nick Jenkins

subject: [Wikitech-l] Tech demo: "Can We Link It?" - Link Suggesting tool

body:
> Something must have gone wrong there - it now turns it into
> [[]]rest-of-Y..., see
> http://en.wikipedia.org/w/index.php?title=2005&diff=77172402&oldid=77148885
> - and look for 'gas cylinder', 'aircraft carrier' or 'sodomy law'.

Thanks for the heads up and sorry about that, silly copy-and-paste error in the last thing I changed, have fixed the tool and the
2005 page now.

> If I understand correctly, "Don't know" actually means "Don't link
> this, but don't let my decision count as a vote against linking in the
> future".

Exactly. It doesn't link it, and doesn't vote for it or against it. Basically it does nothing, and affects no future link
suggestions, until a user explicitly chooses either yes or no, and clicks the "preview with added links" button.

> I had a similar one, [[Second in Command|second in command]] instead
> of [[second-in-command|second in command]] ([[second in command]] is a
> redirect to that second one).

That should hopefully be okay now, I think.

I.e. this test text:
had a similar one, second in command instead of
Now suggests this:
had a similar one, [[Second-in-command|second in command]] instead of

> a suggestion might be to link
> differently if the words in question are in a different style from
> surrounding text (ie italics vs non-italics) or in some kind of
> quotation marks.

Well it won't suggest linking anything enclosed in italics or any other form of wiki text (e.g. {{something linkable}}, [[something
else linkable]], ''something else linkable'', etc are all out).

It's debatable whether italics or bolded text should be linked, but my gut feeling is that if the writer thought there was something
special about that phrase then we should probably assume we should leave it alone.

Adding links for things in quotation marks is possible, although I'm happy to see mostly dubious links just get voted off the
island...

> Can you make it so that changing any of the radio buttons doesn't lose
> their keyboard focus in Firefox? Otherwise it's extremely hard, to the
> point of being impossible, to use this properly.

I'm assuming that you're probably using tab + left-arrow / right-arrow for navigating around the page and changing radio button
choices?

The trade-off is that the up arrow and down arrow keys are currently being used to allow moving the selected/highlighted row up and
down; However Firefox also binds those keys to changing the selected radio button if a radio button has the focus. In other words,
without removing the focus, pressing up arrow and down arrow will both change the current row, AND change the selected radio button
(which is very annoying, and that's why it explicitly drops the focus).

So I can stop fiddling with the focus, if we lose the up-arrow / down-arrow key functionality (or shift it to different keys). Would
that work okay for you?

> preg_replace("/\\[\\[([$linkprefixchars]*)([^]|]+)([$linktrailchars]*)\|$1\]\]/",
> "$1[[$2]]$3", $text), where $linkprefixchars and $linktrailchars are
> grabbed from the appropriate language file.  (Regex is untested and
> might contain typos and/or other errors, but you probably get the
> point: try to use the exact matching technique that MediaWiki itself
> uses.)

Cool, I'll have a look at using this, although to a certain extent it's currently largely independent of MediaWiki (i.e. there may
be no appropriate language file to grab). And if it gets it wrong and suggests [[Aircraft carrier|aircraft carriers]], it's probably
not as good as [[aircraft carrier]]s, but it's not a catastrophe.

> Does it already tag the edit comment with "[via Suggestor]"?

Yes, it supplies a default edit summary of: "Adding a few internal links from a [[User:Nickj/Can We Link It|link suggesting tool]]".

All the best,
Nick.


from_name: Birgitte SB

body:
--- Brion Vibber <brion at pobox.com> wrote:

> Birgitte SB wrote:

> >  Here is the bug which had the
> > most effort invested in it from WS.
> >
> > http://bugzilla.wikimedia.org/show_bug.cgi?id=4375
>
>
> This is "protected sections".
>
> As I recall there is open debate about whether this
> is a desirable feature and,
> if so, whether it should be implemented as in that
> code.
>
> I don't recall anyone pushing for it in many months,
> though, so I assume there
> is no longer any interest in it?
>

I don't see any debate whether this desirable with
contributors from over 15 languages

http://wikisource.org/wiki/Wikisource:Vote_on_enabling_the_ProtectSection_extension

As to whether there is current interest, it depends on
whether "stable versions" will work for us or not.  I
believe "stable versions' will do the trick but some
people want to see a woking model first.  Besides this
possibility, no one has ever found an alternate
solution to "protect section".  Without it we have
been forced to protect the entire page which is very
undesirable.

As to the rest, thanks for your explanation.  I know
there is no easy answer to this.  I did put this out
on foundation-l more to try and see if others are
having the same problems than to goad you.  But I will
not complain if sometthing gets more attention due to
it ;)

Birgitte SB

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


body:
--- David Gerard <dgerard at gmail.com> wrote:

> On 23/09/06, Birgitte SB <birgitte_sb at yahoo.com>
> wrote:
>
> > people are becoming frustrated with this.  It
> seems a
> > great deal of very minor issues are handled for
> en.WP
> > very quickly. They have recently gotten help to
> > rearrange the side bar display of all things.  Yet
> > everyone says the developers are overworked.  So I
> > would think somehow this system of prioritizing
> what
> > gets done (bugzilla) must be broken.
> > Now this is my personal opinion.   I care ten
> times
> > more that the development needs of my community
> are
> > more fairly  addressed, than that the community's
> > voices in the Board Elections are not drowned out
> by
> > en.WP.
>
>
> It's an Americocentric conspiracy to take over
> Wikimedia, and
> absolutely the most effective thing for you to do is
> Assume Bad Faith!
> DOWN WITH EN:WP!!
>
>
> No, actually it's probably because a lot of the devs
> start as editors
> on en:wp and so that tends to be the project they
> hang around on and
> hear the bugs of most. e.g. Rob Church, who has done
> a *remarkable*
> amount of recent work on MediaWiki and can be found
> on en:wp and on
> #wikipedia ... or Tim Starling, who started as a
> contributor, realised
> there was an urgent need for development and
> sysadmin and pretty much
> moved to that.
>
> That is: if your project doesn't get its favourite
> bugs fixed, it's
> not favouritism to en:wp - it's your project not
> contributing to the
> development. These are volunteers, if you recall.
>
>
> - d.

Yes I do realize a big part of issue is that the
people  interested in development are inherently not
interested in Wikisource.  I was just trying to
compare this issue with everyone talking about en.WP
dominating election issues and voting (which everyone
seemed to classify as a "bad thing")  But seriously to
everyone who thinks I am just being unrealistic here,
is nine months to short a time to start complaining?
Seriously what should my expectations be?

Birgitte SB

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


from_name: Anthere

subject:
[Foundation-l] California E. Coli Epidemic Reaches Wikipedia
	Community

body:
I hope your son get through with no bad memories. My thoughts are with you.

Ant

Jeffrey V. Merkey wrote:
> My 2 year old son, Alexej Martin Merkey, was admitted to Primary
> Childrens Hospital in Salt lake City this afternoon in
> Serious condition due to our family (and others in Utah) getting exposed
> to this virulent strain of E. Coli from California
> on contaminated Spinach.   We had some of this crap in our house and
> alexej ate a some of it, as did my wife and I.
> They have 14 cases here at present of children 2 and under, and one of
> them has died (from Idaho).
>
> Alexej's photo is here http://meta.wikimedia.org/wiki/User:Jmerkey if
> folks don't know who he is.
>
> Alexej's platelet count was at 83 which is very high (most of them are
> below 20 due to the damage caused by the toxins from this strain) and
> they feel he will pull through, but his kidneys were having problems
> late this evening and they told me they might have to put him on
> dialasys over the weekend.  He was not feeling too well, and its always
> rough for a 2 year old to have to go through something like this.   They
> tell me the entero-toxins from this virulent strain of E. Coli cause a
> lot of damage and the next two days will be bad for him.
>
> Both my wife and I appear to also have been infected, but since we are
> adults, out systems dealt with it more effectively.
>
> Bottom line, DONT BUY OR EAT ANY SPINACH FROM CALIFORNIA FOR NOW.
>
> All my love.   Hopefully, he will home soon.
>
> Jeff


list: wikien-l

subject: [WikiEN-l] Process wonkery

body:
On 9/23/06, Stephen Streater <sbstreater at mac.com> wrote:
>
> On 23 Sep 2006, at 20:34, George Herbert wrote:
>
> > On 9/23/06, Stephen Streater <sbstreater at mac.com> wrote:
> >>
> >> On 23 Sep 2006, at 19:20, George Herbert wrote:
> >>
> >>> On 9/23/06, Stephen Streater <sbstreater at mac.com> wrote:
> >>>>
> >>>> On 23 Sep 2006, at 18:36, George Herbert wrote:
> >>>
>
> >>> The existence of the school in question has been verified, as I
> >>> understand it.
> >>>
> >>> Nuking the article because one can't verify some other
> >>> information in
> >>> the article is nonsense.  If it's not completely verifyable and you
> >>> have some particular question as to its accuracy, then tagging it
> >>> with
> >>> unverified, then editing out the info in extremis, are the
> >>> established
> >>> thing to do.
> >>>
> >>> This incident worries me.  Nothing personal to you, Guy, or Cyde
> >>> Weys,
> >>> but there's an established consensus on schools.  Just because
> >>> you've
> >>> been around for a long time and are admins doesn't mean you can game
> >>> the procedures to delete something which consensus says should stay.
> >>> Complaining when people kick back and complain about it is ... nice
> >>> chutzpah?
> >>>
> >>> This is part of the problem I had with Tony, back six months ago.
> >>> It's fine to be bold.  But the limit of being bold has to be when
> >>> consensus kicks back and complains about what you just did.  If your
> >>> reaction when consensus kicks back is "process wonkery sucks" then
> >>> there is a problem.
> >>>
> >>> Trying to undo a consensus via admin guerilla warfare, nicking
> >>> little
> >>> slices off it here and there, is not a good way to fix things, and
> >>> particularly not a good way to establish positive admin/general
> >>> editor
> >>> populace relations.
> >>
> >> Would you be happy with as stub stating the existence
> >> of the organisation? Is this verifiable from secondary sources?
> >>
> >> _______________________________________________
> >> WikiEN-l mailing list
> >> WikiEN-l at Wikipedia.org
> >> To unsubscribe from this mailing list, visit:
> >> http://mail.wikipedia.org/mailman/listinfo/wikien-l
> >
> > Happy?  No, it should be a fleshed out, referenced article.  That
> > would make me happy.
> >
> > Acceptable?  Leave it as a stub with minimally verifyable information.
> >
> > Bad?  Leave info in it which is unverifyable and appears suspicious
> > or spurious.
> >
> > Worse?  Keep it deleted.
> >
> > All in my personal opinion, of course.
>
> Would you be happy to convert it to a stub with
> only verifiable information? If so, it may be worth
> saying so on DRV.
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

Happy?  No.  That should have been the first response of the first AFD
nominator.  I am getting tired of cleaning up people's AFD messes this
way.

Willing to?  Yes.

I have so stated on the undelete review discussion.

--
-george william herbert
george.herbert at gmail.com


from_name: Erik Moeller

body:
Jeffrey,

very sorry to hear this. Thinking of you, and hope your son gets well.
--
Peace & Love,
Erik


body:
On 9/23/06, Birgitte SB <birgitte_sb at yahoo.com> wrote:
>
>
> --- David Gerard <dgerard at gmail.com> wrote:
>
> > On 23/09/06, Birgitte SB <birgitte_sb at yahoo.com>
> > wrote:
> >
> > > people are becoming frustrated with this.  It
> > seems a
> > > great deal of very minor issues are handled for
> > en.WP
> > > very quickly. They have recently gotten help to
> > > rearrange the side bar display of all things.  Yet
> > > everyone says the developers are overworked.  So I
> > > would think somehow this system of prioritizing
> > what
> > > gets done (bugzilla) must be broken.
> > > Now this is my personal opinion.   I care ten
> > times
> > > more that the development needs of my community
> > are
> > > more fairly  addressed, than that the community's
> > > voices in the Board Elections are not drowned out
> > by
> > > en.WP.
> >
> >
> > It's an Americocentric conspiracy to take over
> > Wikimedia, and
> > absolutely the most effective thing for you to do is
> > Assume Bad Faith!
> > DOWN WITH EN:WP!!
> >
> >
> > No, actually it's probably because a lot of the devs
> > start as editors
> > on en:wp and so that tends to be the project they
> > hang around on and
> > hear the bugs of most. e.g. Rob Church, who has done
> > a *remarkable*
> > amount of recent work on MediaWiki and can be found
> > on en:wp and on
> > #wikipedia ... or Tim Starling, who started as a
> > contributor, realised
> > there was an urgent need for development and
> > sysadmin and pretty much
> > moved to that.
> >
> > That is: if your project doesn't get its favourite
> > bugs fixed, it's
> > not favouritism to en:wp - it's your project not
> > contributing to the
> > development. These are volunteers, if you recall.
> >
> >
> > - d.
>
> Yes I do realize a big part of issue is that the
> people  interested in development are inherently not
> interested in Wikisource.  I was just trying to
> compare this issue with everyone talking about en.WP
> dominating election issues and voting (which everyone
> seemed to classify as a "bad thing")  But seriously to
> everyone who thinks I am just being unrealistic here,
> is nine months to short a time to start complaining?
> Seriously what should my expectations be?
>
>
> Birgitte SB
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l

I think your expectations should be that:

A. Some methods of promoting enhancements to the code are more
effective than others, and that your series of emails here has
hopefully pointed you to some more effective methods.

B. As with many open source projects, there are probably many
enhancements that would be good, or at worst harmless, that do not
happen because nobody who actually does coding ends up highly
interested in the problem.

The ultimate solution to B is to successfully accomplish A.  If you
don't seem to get leverage there, then you may want to learn PHP and
the MediaWiki codebase...  A lot of enhancements ultimately happen
because one person wants it badly enough to code it, even if the
existing community didn't.

MediWiki is no different from any generic open source project in these regards.

The very best, very large development base projects can have a more
user-requirements-request driven approach, but that only works if you
have enough coders / developers that they have "spare time" beyond the
tasks they see as personal individual must-have or individual interest
drivers.  I'm not sure how many people are working on MediaWiki right
now, but it seems relatively small for a very large userbase project.

--
-george william herbert
george.herbert at gmail.com


from_name: Fastfission

subject: [WikiEN-l] Is Wikipedia a News Portal (among other things)?

body:
On 9/23/06, David Alexander Russell <webmaster at davidarussell.co.uk> wrote:
> Here's an idea. I presume the main problem with scanning them is their
> size (ie they won't fit on an ordinary scanner). Why not just scan them
> in sections and then use 'photo stitching' software (the kind that's
> designed to turn a collection of photos into a panorama) to turn the
> scanned sections into a single image?

It's time consuming and difficult. It is very easy to screw up in
scanning something like this, so all of the parts will fit except for
one (i.e. if something is not scanned at exactly the same elevation or
gets skewed slightly in some other way).

It can be done. It's just not very easy. And it's certainly not fun. I
wouldn't do it for free.

In the end I suspect that most digitization of such things will be
done either by countries which will try to sell access to them (i.e.
ProQuest) or as not-for-profit grants (i.e. a university deciding to
put its PD library online, which looks good on a yearly report even if
it doesn't create any revenue). This sort of dull work is not the sort
of thing that too many volunteers would be interested in doing over
time, IMO. (Maybe I'm wrong! Hopefully!)

FF


list: wikipedia-l

subject: [Wikipedia-l] Wikipedia and the networked society

body:
Berto wrote:
>>Do you know someone who works at a multinational volunteer collective?
>
> Myself. The Dutch Barge Association is organizing the 2009 Black Sea Rally
> (from Ireland to Kiev and back by internal waterways and seas). It's very
> complicated, as it means crossing the Bielorussian border on private boats,
> and passing 200m away from Chernobyl. For the organization we use... a
> closed wiki. Over 200 stubs were needed just to map small needs like gas
> connectors, diesel availability, etc.
>
>
>>Find out what they think the
>>parallels are between their organizations or projects and ours.
>
> 1) DBA has an external goal. Wiki is a means to us. Here the means coincide
> with the end.
> 2) DBA has but 1400 members (some 800 barges, I believe), a clear internal
> hyerarchical structure, periodical mass meetings, a paper magazine. Internet
> is very important to us, but we mostly do our stuff on real water and meet
> in real life. The whole structure was born as a traditional english "user
> group" in the 90's, when a growing number of englishmen started to buy old
> dutch Tjalken and Luxemotors for them to cruise on european inland waters.
> 3) Projects are largely born much in the way they are born here. If anyone
> has enough political ability to collect support for a project, than it will
> eventually become an official thing.
> 4) While we do actively lobby whenever european laws come to touch our
> interests, the only funding we request goes to canal dredging and lock-gates
> maintainance. DBS is fully funded by the 50 quids we pay each every year to
> get our memberships.
> 5) The community is keeping a constant eye on whatever happens, I can hardly
> think of something like META for us. Our village is too small to have
> unknown districts.
> 6) We do have minorities (sailing barges). Yes, I'm into minorities even
> there :) Must be something in my DNA :)
> 7) Vandalizing pages is potentially dangerous for the life of our members
> (all it takes is moving navigational data), so we do not accept anonymous
> contributions. If you are not a member you need a member to grant for you in
> order to be accepted.
> 8) There has been a long discussion before accepting to use a wiki for the
> project. Many people rated wmf as "too chaotic" for them to accept anything
> coming from here. Yet now consensus is that the wiki is useful, and IMHO it
> really is. I forced the decision by setting up the wiki myself and emitting
> the first users. Once it stopped to be a concept and it became "simply a
> tool" all doubts vanished. I expect another major cruising association to
> adopt a closed wiki in the next future.
>
> B?rto

Very interesting. Thnaks for sharing that with us. Ant


from_name: Ray Saintonge

subject: [Foundation-l] Dreams, goals, and milestones (1 of 3)

body:
Brion Vibber wrote:

>Daniel Arnold wrote:
>
>
>>Wikimedia Commons goals are better software which we naturally don't want to
>>demand solely from others but want to be able contributing to with less
>>friction. Some of our goals:
>>* Single login
>>
>>
>Real soon now. ;)
>
>
>>* CheckUsage directly in MediaWiki
>>* CommonsTicker directly in MediaWiki (for example via a defined RSS feed that
>>can be imported in any other Wikimedia or third party wiki: See as
>>well "Instant Commons" idea)
>>* Checked Versions for files in order to review not only negatively ("this
>>file needs to be deleted") but also positively ("this file can be used safely
>>and is useful") our content.
>>
>>
>Would love to these too; bug me about them in October and keep bugging me until
>they happen!
>
Without commenting about specific requests, I never feel right about
being a pain-in-the-ass about getting things done when I'm confident
that the person doing the work is doing as much as he can with the
resources available.

Single login would be nice, as would a more sophisticated search
function, but since I have never even figured out how to use a simple
bot.I really can't make any constructive contributions to those efforts.

Ec


from_name: James Hare

subject:
[Foundation-l] Commons request for a delinker tool running in
	every wiki

body:
If the bot wishes to run on Wikinews, it'll need an admin flag -- due to our
status as a current events site, almost every single mainspace page is
protected.

On 9/23/06, Aphaia <aphaia at gmail.com> wrote:
>
> Super.
>
> In this summer "omg red link!!" case happened on the Foundation wiki
> again about Commons logo. It is wonderful we are deliver from the need
> of manual check and spend the time for more creative works. I fully
> support this proposal of Arnomane.
>
> One question: how does it works on the closed (private) wiki? Or
> partly access restricted one(s), z.B. wikimania2005? (You need
> registration to give a look to Internal namespace, or to pages not
> listed on the whitelist)
>
> Currently those wikis are not covered? Just curious.
>
> On 9/23/06, Daniel Arnold <arnomane at gmx.de> wrote:
> > Am Samstag, 23. September 2006 00:13 schrieb Erik Moeller:
>
> > Given the fact that ensuring of free content policies is one of the *key
> > missions* of the Wikimedia Foundation and CommonsDelinker is something
> that
> > clearly adresses this topic (via a much more efficient copyvio deletion
> with
> > less negative side effects for local wikis at the same time) I think it
> is
> > appropriate calling for a support note.
> >
> > And lets not forget: This tool will touch Foundation affairs too: like
> Meta
> > wiki, Wikimania wikis, Foundation wiki, although the probability that
> this
> > tool will need to remove something there is much lower than in other
> wikis
> > but not zero.
> >
> > By the way: The Foundation wikis need a CommonsTicker. Why? Well you all
> > remember some troubles with random people overwriting logos and such. We
> > Commons admins simply don't have the time watching over every file
> alone.
> > CommonsTicker would enable you being alerted quickly on overwrite,
> suggested
> > deletion and so forth of any logo, image, media file that is important
> to the
> > Foundation directly. You will be surprised how much changes in Commons
> will
> > affect Foundation wikis directly.  Many other Wikimedia wikis can
> confirm
> > this because they got used to CommonsTicker.
> >
> > Wouldn't it be cool to be informed in advance that something needs your
> > attention? It would save us all a lot of frustration:
> >
> > http://meta.wikimedia.org/wiki/User:Duesentrieb/CommonsTicker
> >
> > Cheers, Arnomane
> > _______________________________________________
> > foundation-l mailing list
> > foundation-l at wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/foundation-l
> >
>
>
> --
> Kizu Naoko
>   Wikiquote: http://wikiquote.org
>   * vox populi, vox dei *
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>


from_name: Tim 'avatar' Bartel

subject: [Wikipedia-l] Comparison of Wikipedia Main Pages

body:
Hi,

Mark Clements schrieb am 23.09.2006 02:09:
> "Erik Zachte" <erikzachte at infodisiac.com> wrote in
>>Here is a screenshot of all 230 Wikipedia Main Pages of yesterday, shrunk
[...]
>
> One thing that immediately stands out is the number of interwiki language
> links in the left navigation.  Surely these should all be the same length,
> but compare, for example, the Norwegian and Czech pages (which are next to
> each other)...

This is not so surely. The German speaking Wikipedia perhaps decided to
list the most common used languages and smaller languages which are
spoken in German speaking regions only.

Bye, Tim.

--
http://wikipedistik.de


from_name: Daniel Arnold

body:
Am Samstag, 23. September 2006 00:13 schrieb Erik Moeller:
>
> I don't think the WMF needs to get legally involved in this. Would it
> be reasonable to just run the bot (since it shouldn't have a bot flag
> anyway) and ask communities to block it if they find it unreasonable?

The bot in itself is not a legal issue. We just call for support as this is
something which affects all Wikimedia wikis and is thus of general
importance. And of course it's going to be much more easier if the Foundation
supports this especially given the fact that we all know how wired people can
react sometimes.

Given the fact that ensuring of free content policies is one of the *key
missions* of the Wikimedia Foundation and CommonsDelinker is something that
clearly adresses this topic (via a much more efficient copyvio deletion with
less negative side effects for local wikis at the same time) I think it is
appropriate calling for a support note.

And lets not forget: This tool will touch Foundation affairs too: like Meta
wiki, Wikimania wikis, Foundation wiki, although the probability that this
tool will need to remove something there is much lower than in other wikis
but not zero.

By the way: The Foundation wikis need a CommonsTicker. Why? Well you all
remember some troubles with random people overwriting logos and such. We
Commons admins simply don't have the time watching over every file alone.
CommonsTicker would enable you being alerted quickly on overwrite, suggested
deletion and so forth of any logo, image, media file that is important to the
Foundation directly. You will be surprised how much changes in Commons will
affect Foundation wikis directly.  Many other Wikimedia wikis can confirm
this because they got used to CommonsTicker.

Wouldn't it be cool to be informed in advance that something needs your
attention? It would save us all a lot of frustration:

http://meta.wikimedia.org/wiki/User:Duesentrieb/CommonsTicker

Cheers, Arnomane


body:
Am Freitag, 22. September 2006 03:39 schrieb SJ:
> Questions: what are the most important goals over the next few years
>   a) for Wikipedia,
>   b) for Wiktionary, Wikibooks, Commons and any further media
> repository, Wikisource, Wikinews, Wikiquote, Wikispecies, Wikiversity
> [I would forward to the other lists but for some of them it might
> double their annual list traffic]

Wikimedia Commons goals are better software which we naturally don't want to
demand solely from others but want to be able contributing to with less
friction. Some of our goals:
* Single login
* CheckUsage directly in MediaWiki
* CommonsTicker directly in MediaWiki (for example via a defined RSS feed that
can be imported in any other Wikimedia or third party wiki: See as
well "Instant Commons" idea)
* Checked Versions for files in order to review not only negatively ("this
file needs to be deleted") but also positively ("this file can be used safely
and is useful") our content.
* Wikidata in MediaWiki for uniform and queryable file descriptions. Every
serious media repository in the world uses well defined description fields.

These are some high priority requirements for the visions of Wikimedia Commons
coming true.

Have also a look at the thread on CommonsDelinker, our current pending
solution to yet another software problem, wich adresses as well some
expectations towards the Foundation (which thus has a little bit to do with
the goals of the Foundation, although not the same ;-).

Cheers, Arnomane


subject: [WikiEN-l] Current events and breaking news

body:
Daniel R. Tobias wrote:

>Regarding all the discussion lately about whether Wikipedia ought to
>have coverage of breaking events right as they happen, this sort of
>thing is what brings out both the best and the worst of Wikipedia.
>
...

>On the other hand, such breaking events *also* show the best and the
>worst of the mainstream media.  Look at tapes of the live TV or radio
>coverage of a major past event (the Kennedy assassination, the Reagan
>attempted assassination, the 2000 U.S. presidential election, the
>9/11 attacks, Hurricane Katrina) and you'll see the same sorts of
>missteps and pratfalls you see on Wikipedia (though generally minus
>the outright vandalism).  Announcers report rumors and then retract
>them.  Things are reported as fact that turn out to be false.  James
>Brady is dead... no he isn't!  Bush is projected as the winner... no,
>Gore is projected as the winner... no, Bush... no, it's too close to
>call.  The Pope is dead... no he isn't... OK, *now* he is.
>Announcers sometimes interrupt one another to bring in new bulletins.
>
>So, everybody has some problems dealing with events that flood in too
>rapidly to keep track of.  But at least Wikipedia's coverage
>eventually settles down to a reasonable article.
>
To some extent this question devolves into placing the boundary between
Wikipedia and Wikinews.  The overnight claim that Osama bin Laden had
died of typhoid is apparently unverifiable and traced through a single
source.  See for example
http://news.xinhuanet.com/english/2006-09/24/content_5128781.htm  This
story is not ready for Wikipedia, but Wikinews probably needs to keep
track of it.   Early reports of the 9/11 attacks also suggested attacks
in other places than those that were in fact attacked.  The uncertainty
in the 2000 election was always there; at least the newspapers were able
to avoid the embarassment connected with Dewey's win in 1948.  On the
other hand, it has been 43 years since the Kennedy assasination, and the
conspiracy theories haven't died down at all.

On the other hand Wikipedia is able to bring verifiable background
information far more effectively than any other medium, even while the
breaking aspects of the story are clouded with uncertainty.

Ec


from_name: [LiM] Manop

subject: [Wikipedia-l] Change of namespace: who to contact?

body:
I have another question regard to Thai Wikipedia. Severl months ago, all the
namespaces were changed from English language to Thai language. But it seems
that "Wikipedia" namespace was forgotten. Do I need to re-discuss about this
again or just make a request to the developer directly? Thank you for any
response.

Regards,
Manop

In Thai WP, we need to change the namespace also

On 9/20/06, oscar <oscar.wiki at gmail.com> wrote:
>
> On 9/19/06, Ragib Hasan <ragibhasan at gmail.com> wrote:
> >
> > On 9/19/06, habj <sweetadelaide at gmail.com> wrote:
>
>
> > The recommended way, as I understand it, is to first have a discussion
> on
> > > your wiki to reach a decision and then file a request to have the
> > namespace
> > > renamed at Mediazilla
> > > http://bugzilla.wikimedia.org/
> > > You can also join one of the IRC-channels with tech folks in it and
> ask
> > to
> > > have it done, but you should be able to show a concensus on your wiki
> > first.
> > >
> > > /habj
> >
> > This part is a bit interesting, we do have consensus, but how would
> > someone not able to understand another language or to see Indic fonts
> > be able to understand the consensus page?
>
>
> simply add an english translation of the vital passage(s) to the same
> page.
> when this happens to me as a steward, i usually ask people to translate
> and
> the passage i need to understand into english at that very page, so it
> becomes a bilingual passage. this always works well :-)
>
> oscar
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>


from_name: Guy Chapman aka JzG

subject: [WikiEN-l] Process wonkery

body:
Apologies for the bias and frustration evident here.

At DRV right now is a debate regarding Finger Lakes Christian School.
The sources for this article are: a diary date and a quote form the
principal; and the school website.  The school is a private church
school with 75 students.

The problem with the article itself was established at AfD: absence of
non-trivial coverage in reliable secondary sources.  We cannot verify
anything much other than its existence, so the article contents was a
simple directory entry, but of course [[WP:NOT]] a directory does not
apply to schools.

The problem with the deletion debate is obvious; it has the S-word in
the title so the subject is "inherently notable" (whatever that might
mean, no sources were cited to back this claim).  Obviously if one
were to substitute "company" for "school" in the article title it
would have been snowballed into the bitbucket, with its 75 unique
Googles outside Wikipedia and mirrors.

The problem with the DRV is that the existence of a number of votes
from obdurate "all schools are inherently notable" types means that
vote counting gives no consensus, whereas a comparison of arguments
from policy - specifically verifiability and hence the ability to
cover the subject objectively - shows a clear delete.

The problem with the whole argument is that the quasi-religious belief
that every school article must be kept because all schools are
inherently notable appears to override all concerns of verifiability
and neutrality, to the point where nobody arguing to keep has even
tried to fix the major issue raised at AfD, that the contents of the
article cannot be formally verified per policy.  Folk memory has it
that one outright hoax was nearly kept as a result of this line of
reasoning.

I'm rather hoping that someone on this list will care enough and have
sufficient resources to actually find the reliable sources the article
needs, since I have little doubt that the school inclusionists will
see to it that it is kept one way or another, and the last thing we
need is yet another unverifiable promotional article on a private
Christian school.  I can't find much other than directory entries, and
I find I lose the will to live after reading a certain number of them.

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


from_name: Tim Starling

subject: [Wikitech-l] What comes first: <ref> or #expr: ?

body:
Carlos wrote:
> Hi.
>
> If I set MediaWiki:cite_reference_link to just $3 (so <ref>...</ref>
> will output the plain number), can I do
>
>    {{#expr: <ref/> + <ref/>}}
>
> to get "3"?

It won't work. <ref> is replaced by a random textual placeholder before
template expansion begins, not by the final HTML.

-- Tim Starling


from_name: Brion Vibber

body:
Daniel Arnold wrote:
> Wikimedia Commons goals are better software which we naturally don't want to
> demand solely from others but want to be able contributing to with less
> friction. Some of our goals:
> * Single login

Real soon now. ;)

> * CheckUsage directly in MediaWiki
> * CommonsTicker directly in MediaWiki (for example via a defined RSS feed that
> can be imported in any other Wikimedia or third party wiki: See as
> well "Instant Commons" idea)
> * Checked Versions for files in order to review not only negatively ("this
> file needs to be deleted") but also positively ("this file can be used safely
> and is useful") our content.

Would love to these too; bug me about them in October and keep bugging me until
they happen!

> * Wikidata in MediaWiki for uniform and queryable file descriptions. Every
> serious media repository in the world uses well defined description fields.

That could be some ways off, but useful data that's not wikidata might be
shorter term.

-- brion vibber (brion @ pobox.com)

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


body:
Daniel Arnold wrote:
> Wikimedia Commons goals are better software which we naturally don't want to
> demand solely from others but want to be able contributing to with less
> friction. Some of our goals:
> * Single login

Real soon now. ;)

> * CheckUsage directly in MediaWiki
> * CommonsTicker directly in MediaWiki (for example via a defined RSS feed that
> can be imported in any other Wikimedia or third party wiki: See as
> well "Instant Commons" idea)
> * Checked Versions for files in order to review not only negatively ("this
> file needs to be deleted") but also positively ("this file can be used safely
> and is useful") our content.

Would love to these too; bug me about them in October and keep bugging me until
they happen!

> * Wikidata in MediaWiki for uniform and queryable file descriptions. Every
> serious media repository in the world uses well defined description fields.

That could be some ways off, but useful data that's not wikidata might be
shorter term.

-- brion vibber (brion @ pobox.com)

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


body:
Daniel Arnold wrote:
> Wikimedia Commons goals are better software which we naturally don't want to
> demand solely from others but want to be able contributing to with less
> friction. Some of our goals:
> * Single login

Real soon now. ;)

> * CheckUsage directly in MediaWiki
> * CommonsTicker directly in MediaWiki (for example via a defined RSS feed that
> can be imported in any other Wikimedia or third party wiki: See as
> well "Instant Commons" idea)
> * Checked Versions for files in order to review not only negatively ("this
> file needs to be deleted") but also positively ("this file can be used safely
> and is useful") our content.

Would love to these too; bug me about them in October and keep bugging me until
they happen!

> * Wikidata in MediaWiki for uniform and queryable file descriptions. Every
> serious media repository in the world uses well defined description fields.

That could be some ways off, but useful data that's not wikidata might be
shorter term.

-- brion vibber (brion @ pobox.com)

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


body:
Daniel Arnold wrote:
> Wikimedia Commons goals are better software which we naturally don't want to
> demand solely from others but want to be able contributing to with less
> friction. Some of our goals:
> * Single login

Real soon now. ;)

> * CheckUsage directly in MediaWiki
> * CommonsTicker directly in MediaWiki (for example via a defined RSS feed that
> can be imported in any other Wikimedia or third party wiki: See as
> well "Instant Commons" idea)
> * Checked Versions for files in order to review not only negatively ("this
> file needs to be deleted") but also positively ("this file can be used safely
> and is useful") our content.

Would love to these too; bug me about them in October and keep bugging me until
they happen!

> * Wikidata in MediaWiki for uniform and queryable file descriptions. Every
> serious media repository in the world uses well defined description fields.

That could be some ways off, but useful data that's not wikidata might be
shorter term.

-- brion vibber (brion @ pobox.com)

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


from_name: Anthony

subject: [Foundation-l] Election query

body:
On 9/23/06, Alison Wheeler <wikimedia at alisonwheeler.com> wrote:
> I didn't want to ask this actually while voting was open in case anyone
> got worried, but not that voting has closed I'd like to ask something.
>
> How are our votes actually counted and, more importantly, how can we each
> be certain that the votes we made are actually the ones which are being
> counted?
>
During the first election I asked this and what I got from the
discussion was that this can't be done.  The process used for
encryption generates random padding so that re-encrypting the exact
same message using the same public key will produce a different result
every time.  My "receipt" did not indicate any information about this
random string/padding.

Things might have changed, or maybe I was informed incorrectly about
this the first time.  In any case the message certainly seems to
contain more information than just your vote, as I'm pretty much
certain that someone else voted exactly the same way as me and yet my
encrypted vote is not duplicated in the list of votes.  (Doing a
google search appears to confirm that we all had the same encryption
and signing keys of 0x4E86F78C and 0xA12C1339, respectively.)

> I ask this because of the issues raised in the USA about election fraud
> (http://en.wikipedia.org/wiki/Diebold#Security_Concerns etc.) and wondered
> whether the same could happen with us, After all, the voting isn't being
> carried out on independent servers it is on Wikimedia servers and,
> presumably, a lot of people have access to those who could do things
> without leaving a trace.
>
If you copied your "resulting encrypted version" when you voted, then
you can look at [[Special:Boardvote/dump]] to ensure that it hasn't
been tampered with *since voting*.  Of course this doesn't ensure that
your vote wasn't tampered with *at the time of voting*.  If what I've
said above is correct, the only ways to do that would be to either
decrypt your vote with the private key or to obtain the information
about the random padding from someone who has access to the private
key.  That private key is almost surely not going to be released to
the public, though it could theoretically be used to spot check
certain votes.  As for releasing the random padding information to
anyone who wants to check their own vote, that's probably possible,
assuming there is no information in the raw (padded) unencrypted
message which is sensitive.

Anthony


subject: [Foundation-l] Election query


subject: [Wikitech-l] Memcached layer for revision text extraction

body:
Ivan Krsti? wrote:
> Gregory Maxwell wrote:
>> Has memcached's allocator changed?   I'm somewhat surprised that that
>> widely varying size of the page text isn't causing us fragmentation
>> problems.
>
> As I mentioned during the hacking days, the allocator granularity and
> semantics have been improved (along with a pile of other things) by
> Facebook in what is about to become memcached 1.2.0. If we see
> fragmentation errors, a switch to 1.2 is in order.
>

I don't know what you mean by fragmentation. Memcached's problem is fixed
distribution of memory between size classes, which can lead to one size
class having a very different expiry time to another. I've never heard such
a problem referred to as fragmentation. Allocation and deallocation are
constant-time operations, so fragmentation of memory within a slab is
irrelevant.

I imagine the revision cache would have a similar size distribution to the
parser cache, which was the dominant item previously in terms of size.

-- Tim Starling


from_name: David Gerard

subject: [WikiEN-l] Process wonkery

body:
On 23/09/06, Guy Chapman aka JzG <guy.chapman at spamcop.net> wrote:

> The problem with the DRV is that the existence of a number of votes
> from obdurate "all schools are inherently notable" types means that
> vote counting gives no consensus, whereas a comparison of arguments
> from policy - specifically verifiability and hence the ability to
> cover the subject objectively - shows a clear delete.

This is a hardened attitude formed by people on VFD as it was who
wanted to delete all schools from Wikipedia below the notability level
of Eton. That is: the process was pathological on both sides.

So let's assume every school will be in Wikipedia on the same basis
that every pissweak or even no-longer-existent hamlet in the US will
remain. What can be done then?

* Is existence enough? Evidently.
* So we need proof of existence and basic verifiable information.

There should be enough for a stub at the very least. If you want to
turn it into a list entry instead, the redirect needs to be in the
appropriate place.

If you're bringing this to wikien-l to re-fight the school deletion
wars, you're probably not spending your time well.

- d.


subject:
[Wikitech-l] Fwd: [Foundation-l] Does anyone else think bugzilla is
	a complete failure

body:
---------- Forwarded message ----------
From: Birgitte SB <birgitte_sb at yahoo.com>
Date: 23-Sep-2006 16:38
Subject: [Foundation-l] Does anyone else think bugzilla is a complete failure
To: Wikimedia Foundation Mailing List <foundation-l at wikimedia.org>

The subject line pretty much sums this note up.  I am
frustrated with the continued lack of development
support for anything where the propents are not
actually developers themselves.  I have aware for
sometime that asking for anything without uploading a
"patch" is absolutely useless.  So I accepted people
that don't know what a patch is are just screwed.  But
I have recently realized many of developments which
have never happened *did* have attachments (which I
think are "patches").  The bugzilla system really must
be broken.  Because how can these things just be
ignored for so long?  Here is the bug which had the
most effort invested in it from WS.

http://bugzilla.wikimedia.org/show_bug.cgi?id=4375

This feature was so desired by people Wikisource a
show of support by 15 separte languages was
orchestrated hoping it would have some effect.

http://wikisource.org/wiki/Wikisource:Vote_on_enabling_the_ProtectSection_extension

This was back in January.  Nothing ever happened.  The
underlying problem this feature would solve will now
hopefully be able to be addressed by "Stable version".
 At least I hope "stable versions" will be workable.
But the last email about how de.WP wants a much more
complicated system for this worries me.

There are other technical issues that have projects on
WS at a standstill.

http://bugzilla.wikimedia.org/show_bug.cgi?id=189

http://bugzilla.wikimedia.org/show_bug.cgi?id=5881

I ask people online.   Bugs are filed.  Nothing
happens.  I do not want to make the effort to get all
sub-domains to show support for these new features
when it will have no effect.  I realize that the
developers are volunteers and are able to chose what
interests them and where they would like to work.  But
they do not even give any feedback or even tell us
they will not help us and we should learn to live
without it.  We just wait month upon month hoping it
is on someone's to-do list somewhere.  It is beyond
frustrating.  Has anyone else experienced these
problems?

Birgitte SB

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
foundation-l mailing list
foundation-l at wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/foundation-l


from_name: GerardM

body:
Hoi,
Most of the developers are volunteers. There is certainly too much work in
the first place. It is a stellar performance what so few people do with so
little investment.

Their first priority is to keep the servers operational, combine this with
the growth that we experience this is a big job. There are several big jobs
that have been postponed time and again for many many months (think single
login or the inclusion of software that has been programmed and is waiting
for inclusion in the software).

When you find yourself a developer to program for you, it does not mean that
the software will be accepted; the only thing achieved is that you are
closer to getting it accepted. This is not to say that Bugzilla is busted,
it is that your expectations are not compatible with reality.

PS when you expect developers to reply to your wishes, you have to realise
that that too is work..

Thanks,
       GerardM

On 9/23/06, Birgitte SB <birgitte_sb at yahoo.com> wrote:
>
> The subject line pretty much sums this note up.  I am
> frustrated with the continued lack of development
> support for anything where the propents are not
> actually developers themselves.  I have aware for
> sometime that asking for anything without uploading a
> "patch" is absolutely useless.  So I accepted people
> that don't know what a patch is are just screwed.  But
> I have recently realized many of developments which
> have never happened *did* have attachments (which I
> think are "patches").  The bugzilla system really must
> be broken.  Because how can these things just be
> ignored for so long?  Here is the bug which had the
> most effort invested in it from WS.
>
> http://bugzilla.wikimedia.org/show_bug.cgi?id=4375
>
> This feature was so desired by people Wikisource a
> show of support by 15 separte languages was
> orchestrated hoping it would have some effect.
>
>
> http://wikisource.org/wiki/Wikisource:Vote_on_enabling_the_ProtectSection_extension
>
> This was back in January.  Nothing ever happened.  The
> underlying problem this feature would solve will now
> hopefully be able to be addressed by "Stable version".
> At least I hope "stable versions" will be workable.
> But the last email about how de.WP wants a much more
> complicated system for this worries me.
>
> There are other technical issues that have projects on
> WS at a standstill.
>
> http://bugzilla.wikimedia.org/show_bug.cgi?id=189
>
> http://bugzilla.wikimedia.org/show_bug.cgi?id=5881
>
> I ask people online.   Bugs are filed.  Nothing
> happens.  I do not want to make the effort to get all
> sub-domains to show support for these new features
> when it will have no effect.  I realize that the
> developers are volunteers and are able to chose what
> interests them and where they would like to work.  But
> they do not even give any feedback or even tell us
> they will not help us and we should learn to live
> without it.  We just wait month upon month hoping it
> is on someone's to-do list somewhere.  It is beyond
> frustrating.  Has anyone else experienced these
> problems?
>
>
> Birgitte SB
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>


from_name: Daniel R. Tobias

subject: [WikiEN-l] Schools, notability, inclusionism, deletionism, etc.

body:
There's been some discussion here lately on the desirability of
including or deleting the article for some smallish private school.
Actually, it's my impression that, over the couple of years I've been
involved with the project, Wikipedia has been steadily moving in the
direction of inclusionism in a number of subject areas, including
schools, roads, pop music, and TV episodes.  A while back, something
had to be highly notable to be included in those subjects, but now
there are articles on county roads, middle schools, upcoming as-yet-
unnamed pop albums, etc.

So is this a good thing or a bad thing?  At least in some areas,
where there are bounded categories that are (fairly) well defined
(one can always expect there will be a few edge cases though),
there's some value to aiming for having a complete set of articles,
even if some of them are of marginal notability and don't have all
that much to be said about them.  Some past U.S. vice presidents are
pretty obscure now, but it would be good to have all of them anyway
(do we?)  We've got articles on all the popes (and various antipopes
as well), though some of the early ones have practically no known
facts beyond their regnal names and (sometimes approximate) dates of
office.  We've got all the U.S. census-listed places, thanks to an
early "bot" run, and probably should aim to get similarly complete
coverage of the rest of the world, even including remote villages of
tiny population; it's useful in the aggregate to be able to look up
any place (particularly when this is integrated into applications
where you can click on a spot on a map for more information).

So, should we be just as complete for schools, albums, songs, TV
shows, and so on?  Would that just be duplicating IMDB, etc., or
would it be helping to make Wikipedia a one-stop resource for more in-
depth info (including links where appropriate to other sites like
IMDB) on everything in each of these fields?

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


from_name: Stephen Streater

subject: [WikiEN-l] Process wonkery

body:
On 23 Sep 2006, at 17:46, David Gerard wrote:

> On 23/09/06, Guy Chapman aka JzG <guy.chapman at spamcop.net> wrote:
>
>> The problem with the DRV is that the existence of a number of votes
>> from obdurate "all schools are inherently notable" types means that
>> vote counting gives no consensus, whereas a comparison of arguments
>> from policy - specifically verifiability and hence the ability to
>> cover the subject objectively - shows a clear delete.
>
>
> This is a hardened attitude formed by people on VFD as it was who
> wanted to delete all schools from Wikipedia below the notability level
> of Eton. That is: the process was pathological on both sides.
>
> So let's assume every school will be in Wikipedia on the same basis
> that every pissweak or even no-longer-existent hamlet in the US will
> remain. What can be done then?
>
> * Is existence enough? Evidently.
> * So we need proof of existence and basic verifiable information.
>
> There should be enough for a stub at the very least. If you want to
> turn it into a list entry instead, the redirect needs to be in the
> appropriate place.
>
> If you're bringing this to wikien-l to re-fight the school deletion
> wars, you're probably not spending your time well.

We can still give moral support. If content
cannot be verified, it should be taken out.
The onus is on the people adding the
information to provide verification.


body:
Regarding all the discussion lately about whether Wikipedia ought to
have coverage of breaking events right as they happen, this sort of
thing is what brings out both the best and the worst of Wikipedia.

At its best, Wikipedia has up-to-date information on things of
current interest, placed in historical context, something that no
other medium can do in quite the same way: news media have info on
what just happened now without much context, while printed
encyclopedias have out-of-date information on what happened a long
time ago without recent updates.  The easy updatability of Wikipedia,
combined with its ability to hyperlink things together, give it the
ability to have simultaneous depth, breadth, currency, and history.

You also see it at its worst during times of rapidly-changing events,
though; there's a dizzying succession of edits to any related
articles which include the posting of rumors, hearsay, and
speculation as if it were fact; lots of jumping to conclusions about
what has happened, what effect it will have, and what it all means;
and plenty of cases of outright vandalism.  The high edit volume
makes it an exercise in frustration to make any sort of update, due
to edit conflicts.  Thus, one can see why some would desire that
current events be left out until they have a chance to settle down a
bit.

On the other hand, such breaking events *also* show the best and the
worst of the mainstream media.  Look at tapes of the live TV or radio
coverage of a major past event (the Kennedy assassination, the Reagan
attempted assassination, the 2000 U.S. presidential election, the
9/11 attacks, Hurricane Katrina) and you'll see the same sorts of
missteps and pratfalls you see on Wikipedia (though generally minus
the outright vandalism).  Announcers report rumors and then retract
them.  Things are reported as fact that turn out to be false.  James
Brady is dead... no he isn't!  Bush is projected as the winner... no,
Gore is projected as the winner... no, Bush... no, it's too close to
call.  The Pope is dead... no he isn't... OK, *now* he is.
Announcers sometimes interrupt one another to bring in new bulletins.

So, everybody has some problems dealing with events that flood in too
rapidly to keep track of.  But at least Wikipedia's coverage
eventually settles down to a reasonable article.

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


body:
On 9/23/06, Daniel R. Tobias <dan at tobias.name> wrote:
> So, should we be just as complete for schools, albums, songs, TV
> shows, and so on?  Would that just be duplicating IMDB, etc., or
> would it be helping to make Wikipedia a one-stop resource for more in-
> depth info (including links where appropriate to other sites like
> IMDB) on everything in each of these fields?
>
IMDB is not free content, so I don't think it ever makes sense to
worry about whether or not one is duplicating IMDB.  A duplicate of
IMDB which is free content would be a good thing.

>From a standpoint of practicality, I'd say moving toward being more
inclusive in these areas is fairly inevitable.


from_name: Alison Wheeler

subject: [Foundation-l] Election query

body:
I didn't want to ask this actually while voting was open in case anyone
got worried, but not that voting has closed I'd like to ask something.

How are our votes actually counted and, more importantly, how can we each
be certain that the votes we made are actually the ones which are being
counted?

I ask this because of the issues raised in the USA about election fraud
(http://en.wikipedia.org/wiki/Diebold#Security_Concerns etc.) and wondered
whether the same could happen with us, After all, the voting isn't being
carried out on independent servers it is on Wikimedia servers and,
presumably, a lot of people have access to those who could do things
without leaving a trace.

I am *not* meaning imply that anything has been done, but I would very
much like to know what security voters like myself have that our votes
have been correctly recorded and tallied.

Alison Wheeler


subject: [Foundation-l] Election query


subject: [WikiEN-l] Process wonkery

body:
On 23 Sep 2006, at 18:36, George Herbert wrote:

> On 9/23/06, David Gerard <dgerard at gmail.com> wrote:
>> On 23/09/06, Guy Chapman aka JzG <guy.chapman at spamcop.net> wrote:
>>
>>> The problem with the DRV is that the existence of a number of votes
>>> from obdurate "all schools are inherently notable" types means that
>>> vote counting gives no consensus, whereas a comparison of arguments
>>> from policy - specifically verifiability and hence the ability to
>>> cover the subject objectively - shows a clear delete.
>>
>>
>> This is a hardened attitude formed by people on VFD as it was who
>> wanted to delete all schools from Wikipedia below the notability
>> level
>> of Eton. That is: the process was pathological on both sides.
>>
>> So let's assume every school will be in Wikipedia on the same basis
>> that every pissweak or even no-longer-existent hamlet in the US will
>> remain. What can be done then?
>>
>> * Is existence enough? Evidently.
>> * So we need proof of existence and basic verifiable information.
>>
>> There should be enough for a stub at the very least. If you want to
>> turn it into a list entry instead, the redirect needs to be in the
>> appropriate place.
>>
>> If you're bringing this to wikien-l to re-fight the school deletion
>> wars, you're probably not spending your time well.
>>
>>
>> - d.
>> _______________________________________________
>> WikiEN-l mailing list
>> WikiEN-l at Wikipedia.org
>> To unsubscribe from this mailing list, visit:
>> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>
> Just for reference, we're looking at a worst case roughly 124,000
> school stubs ( http://nces.ed.gov/programs/digest/d04/tables/
> dt04_085.asp
> ) for the US.
>
> I understand those that disagree, but I think the categorical include
> pseudopolicy for schools makes sense.  They're of immense interest to
> most parents, the school system has 72 million odd Americans in it,
> and categorical inclusionism here is not in any way throwing Wikipedia
> into disrepute or threatening our server load or diskspace.

I don't the issue is technological. It's more to
do with the reliability of the information.

The idea is that a smaller encyclopaedia with
reliable information is better than one twice as
big where (a possibly unknown) half of the
information is unreliable.


from_name: Carl Peterson

body:
On 9/23/06, David Gerard <dgerard at gmail.com> wrote:
>
> On 23/09/06, David Alexander Russell <webmaster at davidarussell.co.uk>
> wrote:
> > David Gerard wrote:
>
> > > If it's third-party verifiable, why not?
> > > (note: many people become AFD regulars just to enforce their
> > > disagreement with this notion.)
>
> > Well, now that it seems that it is possible to enforce one's bias simply
> > by overruling your opponents when closing an AFD (rather than convicing
> > others to support your point of view) why do they bother?
>
>
> It's possible to do all sorts of things; whether they do is another
> matter, of course.

About a month and change ago, a few of us in WikiProject Louisville
discussed the inclusion/exclusion argument (citing an essay somewhere that
thoroughly presented all sides of the argument. If I remember right, one of
the things we decided would be appropriate is having several anthology-style
articles for defined groups of schools, especially at the elementary school
level to avoid the creation of 80+ articles where the only thing truly
"notable" about the school is the fact that it exists and who or what its
namesake is. One of the pseudo-implementations of this is in the [[List of
schools in Louisville]], where we have the public schools listed in table
format with the year of founding (if we can find it conclusively) and a
unique fact or two about the school and/or its namesake, again, if we can
find it.

Carl


subject:
[Foundation-l] Wikimedia Foundation Board Election 2006:
	Announcement of result

body:
Word.

On 9/23/06, James Forrester <jdforrester at wikimedia.org> wrote:
>
> We, the Election Officers, hereby give notice of the results of the
> 2006 Board of Trustees election. The winner is Erik M?ller, also known
> as "Eloquence" or "Xirzon". Assuming that the Board endorses the
> result and appoints M?ller, he will replace Angela Beesley, who chose
> to resign [1] earlier this year. The term to which M?ller will be
> appointed will cover the rest of the term for which Beesley was
> elected, and will end with the ordinary 2007 election.
>
> In total, 2347 valid ballots were cast and accepted; the specific
> results are as follows:
>
> 1st - 987 (42%) - Eloquence (Erik M?ller)
> 2nd - 702 (30%) - Mindspillage (Kathleen (Kat) Walsh)
> 3rd - 648 (28%) - Oscar (Oscar van Dillen)
> 4th - 580 (25%) - Arnomane (Daniel Arnold)
> 5th - 492 (21%) - Kim Bruning
> 6th - 423 (18%) - AaronSw (Aaron Swartz)
> 7th - 382 (16%) - Charles Matthews
> 8th - 378 (16%) - Arno Lagrange
> 9th - 375 (16%) - Cimon Avaro (Jussi-Ville Heiskanen)
> 10th - 356 (15%) - Zuirdj (Juan David Ruiz)
> 11th - 349 (15%) - Kelly Martin
> 12th - 346 (15%) - UninvitedCompany (Steve Dunlop)
> 13th - 323 (14%) - Improv (Pat Gunn)
> 14th - 315 (13%) - Linuxbeak (Alex Schenck)
> 15th - 297 (13%) - alex756 (Alex T. Roshuk Esq.)
> 16th - 237 (10%) - Evrik (Bruce Andersen)
> 17th - 109 ( 5%) - Ross.Hedvicek (Ross Hedvicek)
>
> We would like to take this opportunity to give our thanks to all of
> the developers, translators, those people who supported and promoted
> the election, and all others for their support and assistance for the
> election, and especial thanks to Tim Starling.
>
> [1] -
> http://wikimediafoundation.org/wiki/Press_releases/Angela_Beesley_resigns_from_Wikimedia_Foundation_board
>
> Yours,
>
> The Election Officials, Wikimedia Foundation Board Election 2006
>
> Essjay
> James D. Forrester
> Kizu Naoko
> Dariusz Siedlecki
> Jon Harald S?by
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>


from_name: Pat Gunn

subject: [Foundation-l] Candidate statements

body:
habj wrote:
>I am not sure if the translators need appreciation from the candidates. I
>think it would be more appreciated if more of them made their texts more
>easy to translate. Things to avoid are things like puns: "Bored? Board
>Questions for Improv." OK of course I just skipped the pun, but he risked
>getting it translated to something strange in a couple of languages. So do
>the people who write "endowment" rather than "finansial reserve" or
>something similar (if I understood that term correct in context - I am still
>not 100% sure that I did.

My apologies on that front. I assumed that the pun would simply be
translated out by the translators -- I tried to help out in
the translation task for a few languages which I kinda-sorta speak,
and removed the pun in each non-English (I think). I believe I was
the one who first introduced the idea of an endowment -- it's not quite
exactly identical to a financial reserve, in that only interest from
its investment flows into the general coffers of the project. My apologies
if it wasn't exactly clear -- it's a financial-esque term. If you had asked,
I would've explained. I do appreciate the efforts of translators though,
especially those who had to deal with my half-baked Spanish. My thanks
to them and to the election coordinators.

---
Pat Gunn
mod: csna, bmcm, bmco, cooa, cona, clpd, coom
http://dachte.org
Yeah, I totally did the Vulcan nerve pinch on a guy once
and it definitely worked because he said "Ow."
	-- Seen on SomethingAwful


subject: [Foundation-l] Candidate statements


subject: [WikiEN-l] Process wonkery

body:
On 23 Sep 2006, at 19:20, George Herbert wrote:

> On 9/23/06, Stephen Streater <sbstreater at mac.com> wrote:
>>
>> On 23 Sep 2006, at 18:36, George Herbert wrote:
>>
>>> On 9/23/06, David Gerard <dgerard at gmail.com> wrote:
>>>> On 23/09/06, Guy Chapman aka JzG <guy.chapman at spamcop.net> wrote:
>>>>
>>>>> The problem with the DRV is that the existence of a number of
>>>>> votes
>>>>> from obdurate "all schools are inherently notable" types means
>>>>> that
>>>>> vote counting gives no consensus, whereas a comparison of
>>>>> arguments
>>>>> from policy - specifically verifiability and hence the ability to
>>>>> cover the subject objectively - shows a clear delete.
>>>>
>>>>
>>>> This is a hardened attitude formed by people on VFD as it was who
>>>> wanted to delete all schools from Wikipedia below the notability
>>>> level
>>>> of Eton. That is: the process was pathological on both sides.
>>>>
>>>> So let's assume every school will be in Wikipedia on the same basis
>>>> that every pissweak or even no-longer-existent hamlet in the US
>>>> will
>>>> remain. What can be done then?
>>>>
>>>> * Is existence enough? Evidently.
>>>> * So we need proof of existence and basic verifiable information.
>>>>
>>>> There should be enough for a stub at the very least. If you want to
>>>> turn it into a list entry instead, the redirect needs to be in the
>>>> appropriate place.
>>>>
>>>> If you're bringing this to wikien-l to re-fight the school deletion
>>>> wars, you're probably not spending your time well.
>>>>
>>>>
>>>> - d.
>>>> _______________________________________________
>>>> WikiEN-l mailing list
>>>> WikiEN-l at Wikipedia.org
>>>> To unsubscribe from this mailing list, visit:
>>>> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>>>
>>> Just for reference, we're looking at a worst case roughly 124,000
>>> school stubs ( http://nces.ed.gov/programs/digest/d04/tables/
>>> dt04_085.asp
>>> ) for the US.
>>>
>>> I understand those that disagree, but I think the categorical
>>> include
>>> pseudopolicy for schools makes sense.  They're of immense
>>> interest to
>>> most parents, the school system has 72 million odd Americans in it,
>>> and categorical inclusionism here is not in any way throwing
>>> Wikipedia
>>> into disrepute or threatening our server load or diskspace.
>>
>> I don't the issue is technological. It's more to
>> do with the reliability of the information.
>>
>> The idea is that a smaller encyclopaedia with
>> reliable information is better than one twice as
>> big where (a possibly unknown) half of the
>> information is unreliable.
>> _______________________________________________
>> WikiEN-l mailing list
>> WikiEN-l at Wikipedia.org
>> To unsubscribe from this mailing list, visit:
>> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>
> The existence of the school in question has been verified, as I
> understand it.
>
> Nuking the article because one can't verify some other information in
> the article is nonsense.  If it's not completely verifyable and you
> have some particular question as to its accuracy, then tagging it with
> unverified, then editing out the info in extremis, are the established
> thing to do.
>
> This incident worries me.  Nothing personal to you, Guy, or Cyde Weys,
> but there's an established consensus on schools.  Just because you've
> been around for a long time and are admins doesn't mean you can game
> the procedures to delete something which consensus says should stay.
> Complaining when people kick back and complain about it is ... nice
> chutzpah?
>
> This is part of the problem I had with Tony, back six months ago.
> It's fine to be bold.  But the limit of being bold has to be when
> consensus kicks back and complains about what you just did.  If your
> reaction when consensus kicks back is "process wonkery sucks" then
> there is a problem.
>
> Trying to undo a consensus via admin guerilla warfare, nicking little
> slices off it here and there, is not a good way to fix things, and
> particularly not a good way to establish positive admin/general editor
> populace relations.

Would you be happy with as stub stating the existence
of the organisation? Is this verifiable from secondary sources?


from_name: Steve Summit

subject: [WikiEN-l] Hallmark of bad process: guideline vs didacticism

body:
d. the Gerard wrote:
>     ** A lot of people think making things hard policy means people
> will actually follow them. This means editorial guidelines get phrased
> as didactic policy.
>     ** Policy is harsh stuff, and there's a limit to how much people
> will hold in their heads.

Here's another slant:

It's easy to imagine we need lots of reasonably hard rules,
because everyone knows that people are imperfect, and that
asking them to "be reasonable" or to "follow the spirit of the
guidelines" doesn't always work.  So the goal is to remove
imperfect, subjective human judgement from the equation, and
replace it with a complete, cohesive, consistent set of nicely
objective rules, which will ensure magnificently coordinated,
correct behavior.

And that might work, *if* the rules were in fact complete,
cohesive, and consistent.

But they rarely are, even in a real society where there are
armies of paid legislators and civil servants poring over the
legalese.  In an ad-hoc project where anyone can edit anything
(including the guidelines and policy documents), it's a virtual
certainty that the rules will never be complete, cohesive, or
consistent.

But when the rules are incomplete or inconsistent, fallible human
judgment is right back in the center of the equation again, as
various people (both on the doing-things side and the enforcing-
or cleaning-up-things side) try valiantly to decide *which* rule
ought to apply in each situation.

In the worst case, you end up with a lose-lose situation,
in which the rules exact all the costs that rules often do
(in terms of stifling initiative or creativity, taking on a life
of their own, and requiring significant resources to maintain,
thus parasitizing the rest of the enterprise), while delivering
none of the benefits, meaning that the costs of living without
rules -- the dependency on fallible human judgement, and the
eventual chaotic anarchy that may result when people do what they
want and fight over whether they're allowed to -- are also borne.

As always, it's important to take a step back and assess whether
a system -- in this case, a set of rules at a given level of
attempted completeness -- is actually achieving its goals,
and is doing so commensurate with its costs.


from_name: Fl Celloguy

subject:
[Foundation-l] Wikimedia Foundation Board Election 2006:
 Announcement of result

body:
My deepest congratulations to Erik; may he be a successful and wise Board member. Also congratulations to each and every one of the candidates, and great thanks to the elections officials, everyone who helped translate and make the election successful, and everyone who voted.Best of luck, Erik!FlcelloguyFrom Wikipedia, the free encyclopedia.
_________________________________________________________________
Express yourself - download free Windows Live Messenger themes!
http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://imagine-msn.com/themes/vibe/default.aspx?locale=en-us&source=hmtagline


from_name: Brad Patrick

body:
Best wishes and good luck and success to Angela.  She is to be
congratulated for her board service and work in the community.

Erik, welcome aboard!

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


subject: [WikiEN-l] Process wonkery

body:
On 23 Sep 2006, at 20:34, George Herbert wrote:

> On 9/23/06, Stephen Streater <sbstreater at mac.com> wrote:
>>
>> On 23 Sep 2006, at 19:20, George Herbert wrote:
>>
>>> On 9/23/06, Stephen Streater <sbstreater at mac.com> wrote:
>>>>
>>>> On 23 Sep 2006, at 18:36, George Herbert wrote:
>>>

>>> The existence of the school in question has been verified, as I
>>> understand it.
>>>
>>> Nuking the article because one can't verify some other
>>> information in
>>> the article is nonsense.  If it's not completely verifyable and you
>>> have some particular question as to its accuracy, then tagging it
>>> with
>>> unverified, then editing out the info in extremis, are the
>>> established
>>> thing to do.
>>>
>>> This incident worries me.  Nothing personal to you, Guy, or Cyde
>>> Weys,
>>> but there's an established consensus on schools.  Just because
>>> you've
>>> been around for a long time and are admins doesn't mean you can game
>>> the procedures to delete something which consensus says should stay.
>>> Complaining when people kick back and complain about it is ... nice
>>> chutzpah?
>>>
>>> This is part of the problem I had with Tony, back six months ago.
>>> It's fine to be bold.  But the limit of being bold has to be when
>>> consensus kicks back and complains about what you just did.  If your
>>> reaction when consensus kicks back is "process wonkery sucks" then
>>> there is a problem.
>>>
>>> Trying to undo a consensus via admin guerilla warfare, nicking
>>> little
>>> slices off it here and there, is not a good way to fix things, and
>>> particularly not a good way to establish positive admin/general
>>> editor
>>> populace relations.
>>
>> Would you be happy with as stub stating the existence
>> of the organisation? Is this verifiable from secondary sources?
>>
>> _______________________________________________
>> WikiEN-l mailing list
>> WikiEN-l at Wikipedia.org
>> To unsubscribe from this mailing list, visit:
>> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>
> Happy?  No, it should be a fleshed out, referenced article.  That
> would make me happy.
>
> Acceptable?  Leave it as a stub with minimally verifyable information.
>
> Bad?  Leave info in it which is unverifyable and appears suspicious
> or spurious.
>
> Worse?  Keep it deleted.
>
> All in my personal opinion, of course.

Would you be happy to convert it to a stub with
only verifiable information? If so, it may be worth
saying so on DRV.


body:
Congratulations, Erik.  I hope you can be as comprehensive in your
discussions with the community during your term as a board member as
you've been as a candidate, and I mean that without any hint of
sarcasm.  We need to know what's going on with the Foundation - and we
need to know where we can help.


subject:
[Foundation-l] Does anyone else think bugzilla is a complete
	failure

body:
On 23/09/06, Birgitte SB <birgitte_sb at yahoo.com> wrote:

> people are becoming frustrated with this.  It seems a
> great deal of very minor issues are handled for en.WP
> very quickly. They have recently gotten help to
> rearrange the side bar display of all things.  Yet
> everyone says the developers are overworked.  So I
> would think somehow this system of prioritizing what
> gets done (bugzilla) must be broken.
> Now this is my personal opinion.   I care ten times
> more that the development needs of my community are
> more fairly  addressed, than that the community's
> voices in the Board Elections are not drowned out by
> en.WP.

It's an Americocentric conspiracy to take over Wikimedia, and
absolutely the most effective thing for you to do is Assume Bad Faith!
DOWN WITH EN:WP!!

No, actually it's probably because a lot of the devs start as editors
on en:wp and so that tends to be the project they hang around on and
hear the bugs of most. e.g. Rob Church, who has done a *remarkable*
amount of recent work on MediaWiki and can be found on en:wp and on
#wikipedia ... or Tim Starling, who started as a contributor, realised
there was an urgent need for development and sysadmin and pretty much
moved to that.

That is: if your project doesn't get its favourite bugs fixed, it's
not favouritism to en:wp - it's your project not contributing to the
development. These are volunteers, if you recall.

- d.


subject:
[Foundation-l] Does anyone else think bugzilla is a complete
 failure

body:
Birgitte SB wrote:
> The subject line pretty much sums this note up.  I am
> frustrated with the continued lack of development
> support for anything where the propents are not
> actually developers themselves.

The purpose of the bug tracker is to do two things:

* Ensure that bug reports and feature requests are in a central, searchable
place where they will be seen and not be lost

* Ensure that there is at least some tracking of completion of issues.

As long as those are happening (and they are), then Bugzilla is *not* a failure.
If you don't believe me, look in MediaWiki's RELEASE-NOTES file and read the bug
numbers of the fixed/implemented issues per major release.

Please keep in mind what the bug tracking system replaces: a series of dozens of
wiki pages on a dozen separate wikis containing requests and complaints, which
weren't read by anyone and from which things would disappear never to be seen again.

Now, just because someone (or even several people) have requested something
doesn't mean it'll get done, any more than having several people write a letter
to a congressman or send a petition to a corporation will mean that the
government or company will do that thing.

In addition to someone, somewhere wanting it, it also has to fit with the
interests and priorities of the group that would actually effect it.

Some "neat features" may simply have no priority to the group that does the work
and runs the operations of the site. Manpower is limited, and effort goes, in
rough order, to:
1) Things that are really, really important to keep the site running
2) Things that someone writing code things are useful and/or neat

Some bugs are either very difficult to fix or have small enough effects that
someone has to decide to put in the effort to track it down and may not consider
it worth doing immediately.

>  I have aware for
> sometime that asking for anything without uploading a
> "patch" is absolutely useless.

This is false, but I realize it's easy to feel that way if your own request is
not being fulfilled. Take a peak at the thousands of other requests, and you may
notice that there are other things to do.

> I have recently realized many of developments which
> have never happened *did* have attachments (which I
> think are "patches").  The bugzilla system really must
> be broken.  Because how can these things just be
> ignored for so long?

1) Patches have to be looked at, understood, and accepted. As with pieces of
legislation "suggested" by a lobbyist group, legislators might want to take a
look at it before they vote on it.

Some patches are not good code. Some patches would damage the system or destroy
the performance of the entire site if they were simply installed.

Other times it's simply not known whether the feature *is actually desirable*.
Just because someone, somewhere wants it, even if the code *works*, it isn't
necessarily something that *should* be added.

Review may be a community or political issue as well as looking at actual code.

>  Here is the bug which had the
> most effort invested in it from WS.
>
> http://bugzilla.wikimedia.org/show_bug.cgi?id=4375

This is "protected sections".

As I recall there is open debate about whether this is a desirable feature and,
if so, whether it should be implemented as in that code.

I don't recall anyone pushing for it in many months, though, so I assume there
is no longer any interest in it?

> There are other technical issues that have projects on
> WS at a standstill.
>
> http://bugzilla.wikimedia.org/show_bug.cgi?id=189

This is very low priority as there seems to be little active interest in it and
it requires a security review of third-party code which is reputed to be unsafe.
(If that's changed, we'd like to hear about it.)

> http://bugzilla.wikimedia.org/show_bug.cgi?id=5881

There is open debate about how this should work and what it should look like.
I've agreed in principal that we should be able to do something for this for
Wikisource but there is as far as I know no one currently attempting to reach
agreement on implementation.

Without this, having some disputed code doesn't actually mean anything will get
done.

If you're very interested, please keep bugging me about these things.

> I ask people online.   Bugs are filed.  Nothing
> happens.  I do not want to make the effort to get all
> sub-domains to show support for these new features
> when it will have no effect.  I realize that the
> developers are volunteers and are able to chose what
> interests them and where they would like to work.

Many developers are volunteers, but two of us are employed by the Foundation.
Primarily this means we have an extra commitment to site operations issues --
performance, security, etc -- but also it means we should pay more attention to
some of the Foundation's smaller sites.

Since there's a lot to do, it helps to make waves on specific issues to make
sure attention gets paid.

Foundation-L probably isn't the best place to do it, but whatever works. ;)

-- brion vibber (brion @ pobox.com)

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


body:
Birgitte SB wrote:
> The subject line pretty much sums this note up.  I am
> frustrated with the continued lack of development
> support for anything where the propents are not
> actually developers themselves.

The purpose of the bug tracker is to do two things:

* Ensure that bug reports and feature requests are in a central, searchable
place where they will be seen and not be lost

* Ensure that there is at least some tracking of completion of issues.

As long as those are happening (and they are), then Bugzilla is *not* a failure.
If you don't believe me, look in MediaWiki's RELEASE-NOTES file and read the bug
numbers of the fixed/implemented issues per major release.

Please keep in mind what the bug tracking system replaces: a series of dozens of
wiki pages on a dozen separate wikis containing requests and complaints, which
weren't read by anyone and from which things would disappear never to be seen again.

Now, just because someone (or even several people) have requested something
doesn't mean it'll get done, any more than having several people write a letter
to a congressman or send a petition to a corporation will mean that the
government or company will do that thing.

In addition to someone, somewhere wanting it, it also has to fit with the
interests and priorities of the group that would actually effect it.

Some "neat features" may simply have no priority to the group that does the work
and runs the operations of the site. Manpower is limited, and effort goes, in
rough order, to:
1) Things that are really, really important to keep the site running
2) Things that someone writing code things are useful and/or neat

Some bugs are either very difficult to fix or have small enough effects that
someone has to decide to put in the effort to track it down and may not consider
it worth doing immediately.

>  I have aware for
> sometime that asking for anything without uploading a
> "patch" is absolutely useless.

This is false, but I realize it's easy to feel that way if your own request is
not being fulfilled. Take a peak at the thousands of other requests, and you may
notice that there are other things to do.

> I have recently realized many of developments which
> have never happened *did* have attachments (which I
> think are "patches").  The bugzilla system really must
> be broken.  Because how can these things just be
> ignored for so long?

1) Patches have to be looked at, understood, and accepted. As with pieces of
legislation "suggested" by a lobbyist group, legislators might want to take a
look at it before they vote on it.

Some patches are not good code. Some patches would damage the system or destroy
the performance of the entire site if they were simply installed.

Other times it's simply not known whether the feature *is actually desirable*.
Just because someone, somewhere wants it, even if the code *works*, it isn't
necessarily something that *should* be added.

Review may be a community or political issue as well as looking at actual code.

>  Here is the bug which had the
> most effort invested in it from WS.
>
> http://bugzilla.wikimedia.org/show_bug.cgi?id=4375

This is "protected sections".

As I recall there is open debate about whether this is a desirable feature and,
if so, whether it should be implemented as in that code.

I don't recall anyone pushing for it in many months, though, so I assume there
is no longer any interest in it?

> There are other technical issues that have projects on
> WS at a standstill.
>
> http://bugzilla.wikimedia.org/show_bug.cgi?id=189

This is very low priority as there seems to be little active interest in it and
it requires a security review of third-party code which is reputed to be unsafe.
(If that's changed, we'd like to hear about it.)

> http://bugzilla.wikimedia.org/show_bug.cgi?id=5881

There is open debate about how this should work and what it should look like.
I've agreed in principal that we should be able to do something for this for
Wikisource but there is as far as I know no one currently attempting to reach
agreement on implementation.

Without this, having some disputed code doesn't actually mean anything will get
done.

If you're very interested, please keep bugging me about these things.

> I ask people online.   Bugs are filed.  Nothing
> happens.  I do not want to make the effort to get all
> sub-domains to show support for these new features
> when it will have no effect.  I realize that the
> developers are volunteers and are able to chose what
> interests them and where they would like to work.

Many developers are volunteers, but two of us are employed by the Foundation.
Primarily this means we have an extra commitment to site operations issues --
performance, security, etc -- but also it means we should pay more attention to
some of the Foundation's smaller sites.

Since there's a lot to do, it helps to make waves on specific issues to make
sure attention gets paid.

Foundation-L probably isn't the best place to do it, but whatever works. ;)

-- brion vibber (brion @ pobox.com)

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