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
>
> *********************************************
>
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
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
>
>
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
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/historicalhttp://meta.wikimedia.org/wiki/Wikidatahttp://meta.wikimedia.org/wiki/Wikidata_%282%29http://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
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
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
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.
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…
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