Hey All-
If you have the time and energy, take a look at this site notice here:
http://dev.donate.wikimedia.org/index.php/Donate/Notice8a/en
I'm looking for a few different/better ideas of what text should go on
the left side (in place of the 250 million visitors/11 million
articles). Right now there is strictly a data/numerical piece, but it
can better.
If you have an idea, please send to me at rand(a)wikimedia.org.
Thanks.
-Rand
--
Rand Montoya
Head of Community Giving
Wikimedia Foundation
www.wikimedia.org
Email: rand(a)wikimedia.org
Phone: 415.839.6885 x615
Fax: 415.882.0495
Cell: 510.685.7030
“At some future time, I hope to have something witty,
intelligent, or funny in this space.”
I'm pleased to announce that the Wikimedia Foundation is hiring Naoko
Komura as Program Manager for the Stanton Foundation Usability
Project. She will begin work on January 2, 2009, and her employment
contract with us will end on April 1, 2010.
Naoko has worked for us in the past three months as a contractor
shepherding two important projects: the reader/contributor survey,
which was successfully launched and received tens of thousands of
responses, and the Wikimania 2008 postmortem analysis. She's also
project managed the fundraiser translation work, the development of
the Stanton Foundation grant proposal, and another grant proposal
we're actively working on.
Naoko has worked as a Senior Program Manger and Project Manager for
Yahoo! Mail, Postini, and Cygnus Solutions. She has an MA in
International Development Policy from Stanford University and an MS in
Economics from Kobe University in Japan. She's a native speaker of
Japanese.
I'm very pleased that Naoko has agreed to lead this important
initiative. Please join me in welcoming her!
--
Erik Möller
Deputy Director, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
As per Michael's earlier e-mail:
http://wikimediafoundation.org/wiki/Press_releases/Wikipedia_to_become_more…
We're very grateful to the Stanton Foundation for this important
investment in Wikipedia's user-friendliness. We're aware of the UNICEF
research as well and we'll survey the existing improvements as part of
this project. A few points beyond the press release:
'''When will this project begin, and when will it finish?'''
The project will begin in January 2009. It will wrap up April 2010.
'''What is its overall scope?'''
The project scope will include the following:
* user testing designed to identify the most common barriers to entry
for first-time writers, and
* a series of improvements to the MediaWiki interface, including
improvements to issues identified through user testing and a focus on
hiding complex elements of the user interface from people who don't
use them. (Specifically, we'll focus on complex syntax like templates,
references, tables, etc.)
'''What does the Wikimedia Foundation consider to be wrong with the
editing interface right now?'''
When it was first developed, MediaWiki was considered reasonably
user-friendly. At that time, software wasn't as flexible and
user-focused as it is today. It's logical that by today's standards,
MediaWiki may not seem to be as streamlined or user-friendly as other
software.
We have never systematically examined the editing interface to examine
what kinds of challenges new contributors face, but we do know of
certain common problems. For example, many people have difficulty
creating new articles, uploading images, and editing templates,
footnotes, and tables. We hope to make improvements in those areas.
'''Who are the new contributors you are hoping to attract?'''
We are hoping to attract new contributors who are just as smart and
knowledgeable as the people who have always written for Wikipedia and
its sister projects, but who -to date- have been unable or reluctant
to participate because of the barriers posed by the interface. There
are countless individuals who read Wikipedia and would be great
writers/editors, but are daunted by complex wiki syntax. They may not
even realize that they can edit Wikipedia. They are the people we are
targeting with this project.
'''What is the nature of the interface improvements that will be made
in this project?'''
In phase 1 (until late summer 2009), we will focus on reducing or
eliminating common, simple barriers to entry. A possible example
would be, "making the edit button more visible." These will be
identified through systematic user testing, but also by surveying
existing research. In phase 2 (until early 2010), we will shift our
attention to identifying complex pieces of "wiki code" (the formatting
language used to write Wikipedia articles) and making them less
visible to first-time contributors and/or helping them achieve the
respective functionality (such as adding tables) more easily.
'''When can we expect to see the first changes to the Wikipedia interface?'''
We hope to demonstrate a first series of improvements by mid-2009,
with production deployment following shortly thereafter.
'''How can the Wikimedia volunteer community be involved in this project?'''
The project will be open and participatory throughout. Every major
report will be publicly shared, and all code will be developed through
our existing, public version control system. Volunteer developers and
testers will be encouraged to contribute throughout the process.
'''Are the positions created for this project just temporary?'''
We will allocate at least two existing, budgeted developer positions
to this project, and additional hires will be employed for the
duration of the grant.
'''Why don't these funds count towards your overall fundraising goals?'''
The majority of the funding for this project will go towards costs not
included in our 2008-09 budget. While we anticipate that the project
will offset some of our operating costs, we also want to retain
flexibility to reallocate funding inside the project budget as
required.
'''Are you going to localize these changes in all the languages of
Wikipedia and the other projects?'''
All code will be ready for internationalization.
'''Are you going to be looking at the entire editing/contribution
process or just the software?'''
This project focuses on technical solutions, but the user testing will
aim to capture problems experienced throughout the editing process.
--
Erik Möller
Deputy Director, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
On Mon, Dec 1, 2008 at 9:39 AM, Gerard Meijssen
<gerard.meijssen(a)gmail.com> wrote:
> Hoi,
> The software has been tested but not all extensions are considered ready for
> WMF production. I am establishing contacts with, among others, people at
> UNICEF to make sure that we identify the outstanding issues carefully and
> fix them efficiently. Given that the CreatePage extension requires changes
> to the skin, it may make sense to consider using a superset of monobook (I
> do not know how feasible this is).
>
> Given that the software is already being localised at Betawiki, we do not
> need to restrict ourselves to English. I understand that UNICEF uses some of
> their software in Swahili :) I would love to consider Swahili for this ...
> Kennisnet is interested in this functionality, that would make Dutch an
> option. It needs to be clear that it is not only Wikipedia projects that
> will benefit.
>
> The benefits from a more useable interface have little to do with a "simple"
> approach. Newbies are not able to contribute. Our need for more contributors
> and content is most dire in our smallest projects. Personally I am not that
> interested in using "simple" as a test environment. From my perspective, it
> should be there for all the projects that want it. Obviously, when this
> extension is localised first, it will be more effective.
>
> When we are to test this in a Wikimedia Wiki, we need to get involvement
> from Brion. It would help a lot when the WMF actively takes part in this
> collaboration and make usability a priority.
> Thanks,
> GerardM
Thinking about this... (and catching up in thread...)
There are two levels of failure with new pages on enwiki now.
Level one is technical - UNICEF study pointed that out, your
extensions are approaching that problem.
Level two is more conceptual. Does a person who wants to create a
page understand all that a "well done" page in Wikipedia should have?
Can they explain what the idea is, and why it should have a page? Do
they understand references and think about how to provide some?
To be really useful, a toolset that structures a "create page" button
response should address some or all of these questions.
Have the output be not just a page, but a series of pages, which
provide short inputs and do some useful things with them. Perhaps,
for example:
"Wikipedia is an encyclopedia. It exists to collect useful general
information about all topics and make it freely available. But there
are lots of things which don't belong in encyclopedias. Are you sure
that the topic / article you want to create is really an encyclopedia
article? Is it a word definition instead (link to Wictionary), or an
image of some sort (link to commons), or (fill in some more). If your
idea for an article is really an encyclopedia entry, click 'Yes' below
to continue."
"Can you explain what this page / article will be about? What's the
topic? Where did you learn about it? Please fill in the text box
below with your idea of what this new article is about. This will be
posted on the article's talk page to explain the purpose of the
article."
"Wikipedia relies on outside references to verify information people
post here. Can you provide the titles of some books or magazine
articles, website URLs, or other sources which confirm what you are
saying in the new article, in the text box below?"
"Wikipedia would like to have articles about all important and useful
topics, but some topics (normal people, most small businesses, etc)
just aren't important enough. Is your article something which people
in other states or countries will find interesting and useful?
Wikipedia has some policies on what we recommend as being notable
enough for articles (link to policies). If you think this article
idea is notable enough, please click 'Yes' below to continue."
"Wikipedia likes to have links from article to article. Are there
other existing articles which you think this new article should
connect to? List them below if you know of any."
"Wikipedia article start with a short introduction, then more details.
Can you summarize what this article is about in one to three
sentences, to start the article's introduction? Think about it and
then fill in the introduction below if you can. Then click on
'Continue'."
"Ok, now let's create the actual article contents.... " (filled in
template article, with introduction section inserted, and slightly
textually processed references and see also sections).
And the final step drops the article rationale entry into the talk
page as well, on article creation.
Does this process make sense?
--
-george william herbert
george.herbert(a)gmail.com
Responding to Jesse Plamondon-Willard's points:
>The current draft still as a few issues:
>* It allows wikis for languages that have no written form.
This is not an "issue". The Wikimedia Foundation itself has in
the past advertised meeting its goal of spreading knowledge
by providing a platform for languages without fixed written forms
(especially native-American languages) to express themselves and
develop both their written forms and materials in them. So yes,
the proposal is quite clear in allowing them. Since interface
is a requirement, no such wiki will be created under the proposed
policy until an acceptable written form has been agreed upon.
> * It allows every type of language except fictional, including
languages nobody uses for communication. For example, it allows wikis
is extinct languages, so long as some people learn to write or speak
it fluently. Even fictional languages are only excluded due to
"substantial opposition in the community", with no rational
explanation for the distinction between fluently-spoken artificial and
fluently-spoken extinct languages.
Classical languages are not "extinct" languages by any means.
Yes, the policy clearly allows them because of the many educated
people who can express themselves in them fluently and want to do
so. This is not an "issue", but a matter on which the community
(as reflected in the draft) clearly disagrees with the language
committee. Is the Language Committee accountable to community
will or not? If any disagreement is an "issue" and there is no
accountability to community will, then perhaps both the role and
the very existence of the language committee should be reconsidered.
As far as fictional languages, you are correct that there is no
rational explanation other than "community opposition." Exactly.
I personally having nothing against fictional languages either, but
*this* policy draft ultimately derives its legitimacy from community
collaboration and compromise. It reflects community will.
Does the current policy do that?
> * The new requirements are vague and arbitrary, and essentially let
the subcommittee decide requests based on personal preference. They
exclude far less languages, but only because they're not concrete or
measurable.
Everything is completely measurable: How many participants are there
who can express themselves fluently who are building the test
project? Has the localization been completed?
>The community draft is promising, but I don't think implementing it
while these issues are unaddressed would be beneficial.
All the issues *have* been addressed. Perhaps you disagree with
*how* they have been addressed. It seems strange to me that,
if you think things have not been addressed, that you are raising
your issues here rather than at the proposal's talk page over the
past several months.
Thanks,
Dovi
The community was invited to collaborate on a new draft proposal for policy on the creation
of wikis in new languages. Over the past several months quite a few people participated in
the formulation of the new draft proposal, and there was extensive discussion of every
aspect. Attention was paid to every phrase.
http://meta.wikimedia.org/wiki/Meta:Language_proposal_policy/Community_draft
On some things there were compromises: Regarding localization requirements, for
instance, I personally oppose the translation of the interface as a prerequisite for the
creation of a wiki, particularly when it means huge numbers of messages: currently nearly
500 for the first wiki in a language, and well over 3000 (!) messages for subsequent wikis.
Nevertheless, I understand the arguments of others, and given the fact that this huge requirement exists in the current policy anyways it is really no loss even given my position.
The rest of the draft, however, is a huge improvement in many ways. There are
compromises in everything, and the current draft is a good compromise.
In short, the draft is excellent. It is a good reflection of community opinion, and a strong
example of community collaboration and compromise. Language committee members have
participated in its formulation to a significant extent, along with the non-members who
began the draft and did most of the work on it. Overall, its spirit is similar to the current
policy, but with some significant differences in both style and content.
This excellent proposal should be ratified and made policy. Beyond the policy itself, doing
so would strengthen the Language Committee itself by showing clearly that it works in
tandem with the community and addresses community concerns.
Dovi
----- Forwarded Message ----
From: Leigh Babbage <gladysthegroovymule(a)yahoo.co.uk>
To: foundation-l(a)lists.wikimedia.org; langcom-l(a)list.wikimedia.org
Sent: Tuesday, November 18, 2008 2:07:47 PM
Subject: [Foundation-l] Why we should use the community draft of the language proposal policy
Some Wikimedia users (and I am
certainly part of this group) thought it unfair that, whilst
artificial languages such as Esperanto and Volupak were allowed by
this policy to have Wikipedias, classical languages such as Latin and
Ancient Greek were not, on the grounds that, since they have no
native speakers, they do not serve a community and are therefore at
odds with the foundation's mission statement. This seems like both a
contradiction and a questionable interpretation of the foundation's
mission statement. With this in mind, one of the requisites for
eligibility in the current policy:
“The proposal has a sufficient
number of living native speakers to form a viable community and
audience. (Wikisource wikis are allowed in languages with no native
speakers, although these should be on a wiki for the modern form of
the language if possible.)
If the proposal is for an
artificial language such as Esperanto,
it must have a reasonable degree of recognition as determined by
discussion (this requirement is being discussed by the language
subcommittee).”
Has been changed to this in the community draft:
“The proposal has a sufficient worldwide number of people able to
express themselves at a fluent level, in the written, spoken or
signed form, to form a viable community and audience.
If the proposal is for a
language without native speakers, it will need to be demonstrated
that it is well attested in written texts, and is in current use as
a special, auxiliary, engineered, classical or learned language.”
The community draft's requisite
reflects the fact that a viable community and audience does not need
native speakers,
>>>>>>>>>>>>>>>>>>>>>>
In fact, for cultural purpose, the native condition is not determinant. More important is the language prestigious.
<<<<<<<<<<<<<<<<<<<<<<
The community draft also specifies
how much of the interface has to be translated before final approval
for both first projects in a language and projects in languages that
already have projects. By requiring the 500 most-used messages to be
translated for a first project, the policy sets a goal that is tough
but reasonable. Requiring too many messages to be translated before
the creation of the project would be likely to tire-out a smaller
community (which would, of course, grow once the project was
actually created). Not requiring any would make it easier for
languages without much real support to slip through the net (I think
that this part of the process should be used not only to make sure
that the language has an interface, but also as another part of the
test to see whether a language is suitable for the project). By
requiring 500 messages to be translated we can ensure that people
are serious about the project and have enough motivation, that the
language (if it is classical) is capable of expressing modern
concepts and that potential editors are not *too*
over-worked during what is (let's be honest) the most boring part of
the process. It is more sensible to require a grater number of
messages to be translated before the creation of another project in
a language because a language that already has at least one
Wikimedia project should have a bigger community.
______________________________________________
>>>>>>>>>>>>>>>>>>>>>
I agree, minimal localisation proves the ability of the languages expressing technical concepts
it is unbelievable that langcom doesn't yet endorse the community draft. It's excellent.
C.m..l.
Hello,
I was trying to find out what is the difference between an article and page
in wiki's terminology?
I found this article which talks about article -
http://en.wikipedia.org/wiki/Wikipedia:ARTICLE
However, there is not such descriptive article about what a page means in
wikipedia.
Can somebody please help me differentiate them?
I suspect that both article and page mean same. They are used
interchangeably. Is my understanding correct?
Hoi,
Regularly I hear people say that Wikipedia is failing. When you then listen,
there are all kinds of good reasons why Wikipedia is failing. Quality is
low, issues with living persons, pov pushers a long litany of woes are all
grounds to predict the imminent demise of Wikipedia. While all these issues
may be grounds for concern, it is hardly indicative of failure. To me they
are indicative of a wildly successful project coping with everything that is
a consequence of success. I am of the opinion that most of our projects
would love to have the same problems, the same issues, the same success as
the few project that do well.
For most of our projects a lack of content, a lack of community ensure that
the project is irrelevant. No growth, no interest is more killing then all
the woes that our big projects suffer from. At Wikimania 2008 a presentation
was given by developers from UNICEF who had done proper usability studies.
They found that 100% of their newbie testsubjects were not able to create a
new article.
This is serious. This explains why so many of our projects fail. We do not
invite collaboration because people do not know how to. They do not know how
to EVEN when they are explicitly invited to create a new article as they
were in this research.
At the Wikimedia Conference Nederland, Jan-Bart de Vreede indicated in his
speech that Kennisnet is interested in implementing the UNICEF extensions.
These extensions are now localisable in any language at Betawiki. At
ExtensionTesting, all the extensions have been tested against stable
releases. Bugs were identified and some bugs were fixed. As a consequence it
is likely that some more MediaWiki installations will benefit from research.
It seems obvious to people who deal with small projects that usability is
one of the big issue when it comes to the moribunt status of our small
projects. The question I put to you, what are we going to do to first agree
that this is an issue and then to deal with this issue. Do we care that 80%
of our projects are failing?
Thanks,
GerardM