Wikimedia-l May 2010

wikimedia-l@lists.wikimedia.org

162 participants
148 discussions

Re: [Foundation-l] Wikidata
by Joan Goma 29 May '10

29 May '10

I see the highest interest in statistical data that can be automatically updated from official sources. > Date: Fri, 28 May 2010 16:51:27 +1000 > From: John Vandenberg <jayvdb(a)gmail.com> > Subject: [Foundation-l] Wikidata > To: Wikimedia Foundation Mailing List > <foundation-l(a)lists.wikimedia.org> > Cc: peter017(a)gmail.com, Wikimedia Commons Discussion List > <commons-l(a)lists.wikimedia.org> > Message-ID: > <AANLkTikQ7kmy4D9Hvkb3HiA51zRs3hmvLrxUmnCnaWEA(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > It looks like a solution to bug 4547 is on the horizon. > > https://bugzilla.wikimedia.org/show_bug.cgi?id=4547 > > See also [Wikitech-l] Reasonably efficient interwiki transclusion > http://www.gossamer-threads.com/lists/wiki/wikitech/197322 > > This will be very useful for templates which Commons has developed, > especially language related templates, however I am concerned that > people are also planning on using Commons as a repo for Wikipedia > infoboxes, and including the *data* on Commons rather than just the > template code. e.g. > > http://www.mediawiki.org/wiki/User:Peter17/GSoc_2010#Interest > > This centralisation of data makes sense on many levels, however using > Commons as the host of this data will result in many edit wars moving > to the Commons project, involving people from many languages. Even > the infobox structure can be the cause of edit wars. > > I think it is undesirable to have these Wikipedia problems added to > Commons existing problems. ;-) > > Tying Wikipedia and Commons closer together is also problematic when > we consider the differing audience and scope of each project, > especially in light of the recent media problems. If the core > templates and data used by Wikipedia are hosted/modified on Commons, > it will be more difficult to justify why Commons accepts content which > isn't appropriate on Wikipedia. > > A centralised data wiki has been proposed previously, many times: > > http://meta.wikimedia.org/wiki/Wikidata/historical > http://meta.wikimedia.org/wiki/Wikidata > http://meta.wikimedia.org/wiki/Wikidata_%282%29 > http://meta.wikimedia.org/wiki/WikiDatabank > > Non-WMF projects, such as freebase, dbpedia, etc., have been exploring > this space. > > Isn't it time that we started a new project!? ;-) > > A wikidata project could use semantic mediawiki from the outset, and > be seeded with data from dbpedia. > > A lot of existing & proposed projects would benefit from a centralised > wikidata project. e.g. a genealogy wiki could use the relationships > stored on the wikidata project. wikisource and commons could use the > central data wiki for their Author and Creator details. > > -- > John Vandenberg > > ********************************************* >

9 10

Re: [Foundation-l] foundation-l Digest, Vol 74, Issue 129
by James Heilman 29 May '10

29 May '10

Re: Participation of intellectual professions I see a number of issues holding professionals back from contributing: 1) Some do not realize that it is possible to edit Wikipedia ( I hear this at work when people ask me how I became an editor ). Maybe we should advertise the fact that yes you too can edit Wikipedia. 2) Many are just not interested. In medicine we have had issues with getting physicians to do continuing medical education. Many just want to do their job and that is it. Contributing to Wikipedia is work. However students are required to do work and I think this is one of the populations which would be easiest to attract. McGill University may have started a Wikipedia club. Promoting these may be useful. 3) A great deal of competition to Wikipedia has sprung up such as Radiopeadia ( which does not allow commercial use of images ), Medpedia ( which only allow professionals to contribute ), and Wikidocs ( which has more technical content ). Each addressing some perceived drawback in Wikipedia. None however has received the viewership of Wikipedia but of course cuts into the pool of available volunteers. Medpedia has partnered with a number of very respected Universities. I think we could learn something for each of these formats such as clarification around image copyright and that CC does not mean you lose the rights to it, greater exposure of the professionals who already contribute, etc. 4) Wikipedia has received negative press in professional publications. We need to address these negativities most of which are false. Currently a number of us at WikiProject Med are writing a paper for publication promoting Wikipedia as a health care information resource. Other subject areas should do the same. BTW do we have a WikiProject to address the issue of recruiting editors? I now we have the usability project. James Heilman

1 0

[Foundation-l] Renaming "Flagged Protections" to "Pending Changes"
by Rob Lanphier 29 May '10

29 May '10

Hi everyone, After much debate, we've settled on a name for the English Wikipedia implementation of FlaggedRevs: "Pending Changes". This is a slight variation on one of the finalists ("Pending Revisions") which has the benefit of using the less jargony term "changes" instead of "revisions". The MediaWiki extension will continue to be named "FlaggedRevs", but the greatly simplified subset of functionality that editors and readers on en.wikipedia.org will see will be referred to as "Pending Changes" in the user interface, help documentation, and other places that we'll talk about this feature for non-developers working on English Wikipedia. Thanks everyone for weighing in! We'll be updating the message strings on flaggedrevs.labs to reflect the new name: http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Message_updates Rob On Wed, May 26, 2010 at 3:27 PM, Rob Lanphier <robla(a)wikimedia.org> wrote: > Hi everyone, > > It looks like the discussion on the name is dying down, so I'd like to > summarize what I think we've heard here: > 1. There's no clear favorite out there. In addition to the two ideas we > put forward ("Pending Revisions" and "Double Check"), there's been quite a > bit of discussion around alternatives, for example: "Revision Review" and > "Pending Edits". > 2. There's are still some that aren't comfortable changing the name away > from "Flagged Protection", but that doesn't appear to be a widely held view. > 3. Some people like "Double Check", but some people dislike it a lot. The > people who like it seem to be comfortable with the colloquial use of it, > whereas the people that dislike it don't like the lack of precision and the > possible confusion created by the use of the word "double". > 4. "Pending Revisions" seems to be something most people would settle for. > It's probably not the hands down favorite of too many people, but it > doesn't seem to provoke the same dislike that "Double Check" does. > 5. "Pending Edits" is a simplification of "Pending Revisions" that seems > to have some support, as it replaces the jargony "Revision" with the easier > "Edits" > 6. "Hyperion Frobnosticating Endoswitch" seems to have gathered a cult > following. Yes, we have a sense of humor. No, we're not going there. :-) > > A little background as to where we're at. "Double Check" had an > enthusiastic following at the WMF office, but we're not inclined to push > that one if it's going to be a fight (it's far from the unanimous choice at > WMF anyway). "Revision Review" seems to be heading a bit too far into > jargon land for our comfort. "Pending Revisions" is the compromise that > seems to stand up to scrutiny. A variation such as "Pending Edits" or > "Pending Changes" also seems acceptable to us. > > That's where we stand now. If you haven't spoken up yet, now is the time, > since we're only a couple of days from making a final decision on this. > Please weigh in here: > > http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolle… > > Thanks > Rob > >

1 0

[Foundation-l] Wikidata
by José Emilio Mori Recio 28 May '10

28 May '10

Hello. I've just joined the list, as soon as I've known about the Wikidata subject. I've been thinking about a Wikidata project even before I knew about the ideas proposed at Meta. I've explained it to several people in Spanish wikipedia, and there I've begun work on "Wikidata-compliant" population data templates, which are also found in en.wiki and de.wiki. Obviously Wikidata seems almost "a must" for me, not only for providing up-to-date data once for all the wikis, but also for providing global solutions to show it (graphics, tables...), and many other ideas. But the proposals at Meta don't seem to advance, and the Wikidata mailing list (!) is inactive from 2007. Recently I asked in IRC, and Gerard talked to me about Omegawiki; currently used for dictionaries, but could possibly expand to Wikidata. On the other hand, the "global templates" or "Commons-like" solution for Wikidata would need no "extra interface" as Omegawiki does (so, faster implementation and adaptation) and there could be useful global templates not related to data. But that wouldn't be a real database to interact with (from Toolserver, for example). Anyway, it seems clear to me that Wikidata is necessary, and that it should be an independent Wikimedia project, whichever the way it is implemented. I hope it can be "pushed" from here, and I'm ready to help with the work when appropiate. Looking forward to more ideas... José Emilio Mori Recio, -jem- in the projects

1 0

[Foundation-l] Wikidata
by John Vandenberg 28 May '10

28 May '10

It looks like a solution to bug 4547 is on the horizon. https://bugzilla.wikimedia.org/show_bug.cgi?id=4547 See also [Wikitech-l] Reasonably efficient interwiki transclusion http://www.gossamer-threads.com/lists/wiki/wikitech/197322 This will be very useful for templates which Commons has developed, especially language related templates, however I am concerned that people are also planning on using Commons as a repo for Wikipedia infoboxes, and including the *data* on Commons rather than just the template code. e.g. http://www.mediawiki.org/wiki/User:Peter17/GSoc_2010#Interest This centralisation of data makes sense on many levels, however using Commons as the host of this data will result in many edit wars moving to the Commons project, involving people from many languages. Even the infobox structure can be the cause of edit wars. I think it is undesirable to have these Wikipedia problems added to Commons existing problems. ;-) Tying Wikipedia and Commons closer together is also problematic when we consider the differing audience and scope of each project, especially in light of the recent media problems. If the core templates and data used by Wikipedia are hosted/modified on Commons, it will be more difficult to justify why Commons accepts content which isn't appropriate on Wikipedia. A centralised data wiki has been proposed previously, many times: http://meta.wikimedia.org/wiki/Wikidata/historical http://meta.wikimedia.org/wiki/Wikidata http://meta.wikimedia.org/wiki/Wikidata_%282%29 http://meta.wikimedia.org/wiki/WikiDatabank Non-WMF projects, such as freebase, dbpedia, etc., have been exploring this space. Isn't it time that we started a new project!? ;-) A wikidata project could use semantic mediawiki from the outset, and be seeded with data from dbpedia. A lot of existing & proposed projects would benefit from a centralised wikidata project. e.g. a genealogy wiki could use the relationships stored on the wikidata project. wikisource and commons could use the central data wiki for their Author and Creator details. -- John Vandenberg

1 0

[Foundation-l] Flagged Protection update for May 27
by William Pietri 28 May '10

28 May '10

As requested, here's the weekly Flagged Protection update. The loose-end tidying and rollout prep proceeds apace. This week's rollout prep includes preparing for an emergency rollback, something that we don't expect will be necessary but for which we nonetheless need to be ready. We've been working diligently on the text, which is a key component of the user interface. You can see the enwiki-specific parts of that here: http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Message_updates As part of that text work, we are also, as readers of these lists know, considering changing the name of the English Wikipedia deployment from Flagged Protection to something more easily comprehended by the general public. If you'd like to weigh in on the many options, here's the place: http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolle… The main thing standing between us and being able to give a release date is some trouble with part of the UI. If you're a HTML & CSS guru, we could use your help: http://lists.wikimedia.org/pipermail/wikitech-l/2010-May/047916.html We also fixed a bug this week. Thanks to Sonia, who found and reported that bug. Want to emulate her? Start here: http://flaggedrevs.labs.wikimedia.org/wiki/Main_Page To see the upcoming work, it's listed in our tracker, under Current and Backlog: http://www.pivotaltracker.com/projects/46157 We expect to release to labs again next week, and each week thereafter until this goes live on the English Wikipedia. William

1 0

[Foundation-l] Which pages to apply Flagged Protection to (Re: Renaming "Flagged Protections)
by Rob Lanphier 28 May '10

28 May '10

On Thu, May 27, 2010 at 11:39 AM, James Heilman <jmh649(a)gmail.com> wrote: > I think the best way of rolling this out if it is possible would be to > replace all semi protected articles with flagged protected or"double check" > protected. If it works well we could than either add more pages or apply > it > to all pages. > Hi James, I think it'd be good to have a conversation on this talk page about the subject of where to roll this out to: http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolle… There's already been a little bit of discussion there, and should probably be more. Note that this page: http://en.wikipedia.org/wiki/Wikipedia:Flagged_protection_and_patrolled_rev… ...has a section titled "Initial article count limits". We're planning on putting an upper bound of 2000 articles, so putting all semi-protected articles under the new regime is probably off the table. Just speaking for myself as a community member, it seems smart to limit this to pages that would qualify for semi-protection. It would be very appropriate to add a policy sec Speaking as a member of WMF, we think it's really important that the community has policies ready when this rolls out, so thank you for (re)starting the conversation. Rob

1 0

Re: [Foundation-l] Renaming "Flagged Protections
by James Heilman 27 May '10

27 May '10

I think the best way of rolling this out if it is possible would be to replace all semi protected articles with flagged protected or"double check" protected. If it works well we could than either add more pages or apply it to all pages. This would make it more seamless, draw less potentially negative media attention, and allow all those who will be dealing with these edits to figure out how the system works. We do not want to end up like the baggage terminal at that new terminal in London. -- James Heilman MD, CCFP-EM, B.Sc.

2 1

[Foundation-l] Renaming "Flagged Protections"
by Rob Lanphier 27 May '10

27 May '10

Hi everyone, As William alluded to, a bunch of us have been studying the user interface for Flagged Protections and figuring out how to make it more intuitive. In trying to solve the user interface problems as well as generally figuring out how we're going to talk about this feature to the world at large, it became clear that the name "Flagged Protections" doesn't adequately describe the technology as it looks to readers and editors. It's a tough name to work with. This iteration of the technology is very different from the German implementation, and there's no "flagging" in the proposed configuration. Additionally, "protection" in our world implies "no editing" whereas this feature actually opens up pages currently protected so that everyone can edit. So, we would like to make a change to the name of the "Flagged Protections" feature prior to deploying it to en.wikipedia.org. Under the hood, we would still be using the "FlaggedRevs" extension (no change there), but the name that we talk about in the user-visible portions of the site and documentation would be something new. Here were some criteria we're using to find a name: - Must not introduce obsolete terminology (e.g. there's no "flagging" in our proposed deployment) - Terminology should be consistent with terms we want to use in the user interface - Must not make too strong of a statement of quality/consensus or terms that make us out as publishers approving content from the mountaintop - Should not imply we're creating an elite new classes of users - Should not convey a strong sense of restriction. The feature, as proposed for the trial [1], is less restrictive than semi-protection - Should not be too geeky/too technical/too jargony - Should not be too slick/too cutesy. We're not doing this in the name of creating glossy brochures with pictures of a conference room full of people in formal business attire nodding with approval at a projection of a pie chart - we just want a name that won't be confusing. It turns out that filters out quite a few names (including "Flagged Protection" among other things). Here's the alternatives that made the cut: - "Pending Revisions" - this name is very consistent with what everyone will see in many parts of the user interface, and what it will be used for (i.e. providing a queue of pending revisions) - "Double Check" - this was a late entrant, but has the distinct advantage of clearly communicating what we envision this feature will be used for (i.e. enforcing a double check from a very broad community). A protracted debate on the name will likely delay the eventual launch on the feature, so we're hoping we can have a quick, respectful discussion on the merits of the different proposals so that we can make the change quickly and move on. We really need to have a name fully locked down no later than Friday, May 28. Please let us know your thoughts here: http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolle… We're in the process of working on a lot of terminology tweaks in the user interface in anticipation of the launch. If you're interested in that detail work, I'll post more information about that on wikitech-l (hopefully by end-of-day Monday), as well as on the talk page above. Rob [1] - See the proposed configuration for trial phase: http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolle…

24 52

[Foundation-l] Renaming "Flagged Protections"
by Erik Zachte 25 May '10

25 May '10

I don't believe we should aim at a completely meaningless name out of concern that some people may not get the finer details of what we try to convey. If we make that a rule for all features yet to be named we will again have made our world a bit more impenetrable. Remember how our 100+ acronyms are often cited as big hurdle for outsiders? Revision Review (or any similar term) clearly signals this is a human process, which IMHO gets it 80% right already. If Mediawiki had been named Mediawiki Engine, and Wikimedia had been named Wikimedia Organization, part of the current confusion for outsiders would already have gone. They may not understand from the name what kind of engine, of what kind of organization, but they will have less trouble to tell these terms apart. Erik Zachte

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Wikimedia-l May 2010