Our Wikipedian friends from China Mainland just confirmed that users from
most provinces of China could visit zh.wp directly.
Originally they could only visit by "climbing the wall".
Most of us guess the lift of the ban is brought by the Olympic Game which is
going to be held next week.
Though the lift might end after the Game finishes, I still want to share
this news with you.
Yeah, they block and then they unblock, back and forth, many times. This is
Support the Wikimedia Foundation: http://donate.wikimedia.org
As you know, we recently announced a restructuring of the Board of
Trustees, which added two new avenues for selecting board members. One
of these is the two seats to be selected by the chapters; the other is
the use of a Nominating Committee to assist the community
representatives in identifying needed expertise to fill out the board.
This note is about the formation of the Nominating Committee. (The
chapters are actively discussing their selection process, and we'll have
more information about that once it is finalized.)
The job of the Nominating Committee is to identify, research and
pre-screen potential candidates for the appointed board positions
involving "specific expertise". There are four of those seats in total;
two are currently vacant, and the others are filled by Jan-Bart de
Vreede and Stuart West. The Nominating Committee will not itself
determine who takes those seats. Its job is to make recommendations to
the community members on the board, who will make the final decision.
(The appointed board members will not vote in these decisions, since it
affects them personally.)
The Nominating Committee will include the following:
* Two members of the current Board of Trustees
* Two members of the volunteer community
* One member of our Advisory Board
* Sue Gardner, our Executive Director
Here's how we expect the nomination process will work:
* First, the board will brief the Nominating Committee regarding its
role, the restructuring, and the board's assessment of its own strengths
and skills gaps. That briefing will result in a set of criteria for
potential board candidates.
* Then, the Nominating Committee will generate a list of possible board
members. All community members should feel free to contribute to this
list by sending names to any member of the Nominating Committee at any
time. Names will also be generated by the Nominating Committee's own
research, as well as recommendations solicited from other friends and
supporters of Wikimedia.
* Once the Nominating Committee has generated a full and rich list of
possibilities, it will begin a research and screening phase. At that
point, it will research the names which have been put forward, and
assess their fit against the selection criteria developed earlier. This
will result in a shortlist of candidates.
* Once the shortlist has been developed, the Nominating Committee will
begin contacting candidates to assess their level of interest in us.
* At that point, the Nominating Committee will deliver to the board a
final list of interested candidates who fit the criteria for the
"specific expertise" roles. The goal will be to give the board a full
briefing on the top eight candidates for the four "expertise" seats,
along with a recommendation for the four who the Nominating Committee
thinks would be the best fit.
* Then the community board members (currently myself, Kat, Frieda,
Domas, Ting, and Jimmy) will vote to determine who will fill the four seats.
The goal is to have the four seats filled by January. The appointed
board members' terms end in December, and this process would be repeated
Of course the Nominating Committee, once established, is free to adjust
and refine this process if it wants to. For example, if a current
appointed board member should be retained for continuity, that may be
handled more simply, although we also anticipate that these seats will
bring in fresh voices from time to time. But at any rate, we imagine the
nominating process will work more-or-less as described here.
So the purpose of this message is both to describe the process for
filling those seats, and to ask for volunteers to fill the two
"volunteer community" spots on the Nominating Committee. If you are
interested in helping us by serving on the Nominating Committee, please
send a note to me, or Sue, or any board member. We would like to hear
from anyone who has the time and the interest to participate, and
especially if you have any experience in non-profit management or
governance, or in hiring. If you're interested, please let us know
within the next week.
-----BEGIN PGP SIGNED MESSAGE-----
I am pleased to welcome Tomasz Finc as a new full-time software
developer. Tomasz will start officially next week on August 4 in our
San Francisco office.
Tomasz is a systems and software engineer with more than 7 years of
experience. He joins us from Amazon.com, where he administered and
supported the Amazon.com A9 search engine, optimized production
performance, developed automation tools, implemented C/C++ changes in
the core search engine code, trained new hires, and fulfilled other
duties. Tomasz is fluent speaker of both Polish and English.
Tomasz will report to me and will work on general MediaWiki
development, code review, systems and administration tools, and
optimization. He will also initially help to support the San Francisco
I am delighted that Tomasz is joining our team; please join me in
welcoming him to the Wikimedia Foundation staff.
- -- brion vibber (brion @ wikimedia.org)
CTO, Wikimedia Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
> I'm also curious how the problem can run in both directions. I can
> understand that one license would be more restrictive than the
> other, such
> that material from project A couldn't be freely used in project B.
> But the
> nuances of the license requirements must be subtle indeed if the
> incompatability runs both ways. Not being a license terms
> aficionado, I'd
> appreciate a layman's explanation of the issues.
Keep in mind that this is unexplored territory even for me, but I can
give you my impressions of the problems I see with the three licensing
options Knol offers.
1) With regard to CC-BY:
It's not a question of one license's being more restrictive than the
other, exactly. It's that the Share Alike (SA) requirement, which
makes the content truly copyleft, can't be added or subtracted in any
straightforward way that I can see. (Note that for purposes of
simplicity I am lumping together GFDL -- Wikipedia's current licensing
standard -- and CC-BY-SA. Their requirements are substantively mostly
the same although formally different.)
How could you add SA, for example, without being the original
licensor, for importing to Wikipedia? How could you subtract it
without being the original licensor(s), for importing to Knol?
2) With regard to CC-NC:
That content flatly can't be added to Wikipedia, which expressly
allows commercial reuse and derivative use. And, with regard to
importing to Knol, how could you add the NC requirement without being
the original licensor? Indeed, how could you add it at all if you've
already granted, in effect, a commercial license by contributing the
content to Wikipedia?
3) With regard to "All Rights Reserved," I think the problem of
importing and exporting to and from Knol from Wikipedia is obvious.
> Can/should the issues be addressed by discussion with Knol before the
> problem grows more serious over time?
Well, the question here is whether Knol's backers are intending the
results of their licensing options. I see no reason to think they
don't intend those results.
Perhaps I'm wrong about this. If so, I think it might be worthwhile
for someone to raise publicly the question of whether Knol's licensing
options are intentionally incompatible with Wikipedia's. I don't
think it's optimal for the Foundation itself to do this -- it would
sound like we're trying to impose our own paradigm on Google, which is
not our aim.
A little news, Chinese Wikipedia just hits the milestone of 200000 articles.
Zh.wp hit the number just after several hours of the unblock.
Support the Wikimedia Foundation: http://donate.wikimedia.org
David Gerard writes:
> We can and should (and, AFAIK, do) heartily support the CC-BY default
> license. Because that's free content, and supporting that wherever it
> springs up and making proper free content licenses the *expected
> default* for reference works is 100% in line with WMF's mission.
> Without us having to do the actual work!
I think it's proper to say we don't oppose CC-BY, but that it's
inconsistent with the licensing schemes we've embraced (GFDL and CC-BY-
SA), because it's non-viral -- it doesn't require that derivative
content be issued under the same free license under which it was
I can't see how content distributed under the licenses Knol offers can
be reproduced in WMF projects, and I can't see how content produced
under WMF's licensing options can be reproduced in Knol. To me, that
raises a serious problem.
I'm very pleased to point out this announcement from the Mozilla project:
"Mozilla is committing to include native support for OGG video and
audio in its next release that includes support for the video element
This is an announcement that Mozilla will be supporting the WhatWG
HTML5 multimedia tags as well as including Xiph's unencumbered media
codecs as part of Firefox.
The WHATWG HTML5 <video/> and <audio/> tags allow supporting browsers
to naively display multimedia content just as they display still
images: without the need for plugins or extensions and with full
integration. Mozilla's commitment to including a set of reasonably
performing and unencumbered codecs as a baseline means that web
developers and users have an opportunity to have multimedia that Just
Works without licensing obligations adding friction to the free flow
of knowledge. Together the native multimedia support and the baseline
inclusion of unencumbered multimedia codecs are an essential step
forward in preserving the open and unrestricted qualities of the web
which are so important to our mission.
The Wikimedia projects have long had a strong commitment to free media
formats, and Wikimedia Commons is probably the largest repository of
videos in Ogg Theora on the web. But our commitment has, at times,
been a costly one: As an early adopter of free media technology we've
suffered from more than our share of complications and incompatibilities.
After years of effort driving adoption and our own work improving the
state of the art for free media formats we're now seeing the beginnings
of a true mainstream adoption which will allow these multimedia formats
to be truly costless for producers and consumers of knowledge. I know
from my own involvement that Wikimedia's adherence to free formats has
been essential in moving things this far, and everyone who has worked
on multimedia within the Wikimedia projects should be proud of our
collective contribution here.
This could never make it into the mainstream without the groups
developing and promoting these free codecs -- particularly Xiph.org,
spreadopenmedia.org, and the FSF's PlayOGG campaign. The W3C's policy
of only accepting royalty-free technology has played an essential
role by not allowing encumbered codecs as part of the standard, but
there has been a stalemate in the adoption of a useful, royalty free
baseline codec set. Because of this, I'd like to personally extend
thanks to the Mozilla Foundation for joining our leadership in this
important area of web standards. Without their help Web Video would
have no hope of escaping the environment of incompatible, proprietary,
"de facto standards" with their related costs.
The Wikimedia projects have had integrated video playback support
for some time now via the OggHandler extension. OggHandler supports a
multitude of playback methods (such as a Java player using Cortado, and
the VLC browser extension) in an effort to get unencumbered multimedia
format support working for as many people as possible. OggHandler has
been a great success, already working for a vast majority of readers, but
the native support in a popular browser will make OggHandler even better
(smoother performance, zero install or an easy upgrade to FireFox, etc).
The new <video/> tag in Firefox has been supported as a playback method
in OggHandler since day zero so the new Firefox builds will automatically
use their native playback ability on the Wikimedia sites.
The code for native support for Ogg Theora and Vorbis
was checked into the Mozilla mainline last night and is
already available in nightly builds marked 3.1a2pre or later
The support is new and pretty raw: There are obvious outstanding issues
with things like timing and audio access on some platforms (such as many
GNU/Linux distros). Once the known bugs are fixed I'll be soliciting
Wikimedians to check for bugs in both our own player code as well as
the Firefox test releases.
Now would be a good time to start building up some material on commons
to showcase this support for Firefox's official release. Although
we've had video on our projects for a long time it's still largely a
new and unexplored territory for us. There are many opportunities to
make important contributions and to have a lot of fun.
> I still don't understand why we should reject the copyleft
> philosophy and
> change to an attribution license. I think that our mission is not
> only to
> provide free information and knowledge, but also to be sure that it
> will be
> kept free.
> I don't think that we should change our licensing policies in order
> to be
> published on Google Knol: why we should do it? If Knols wants to
> allow its
> users to publish Wikipedia-derivative content they should change their
> terms, IMHO.
FWIW, this is my view as well. I'm disappointed with Knol's licensing
options, which strike me as far too conservative.