It is an honor to announce that the Affiliations Committee has resolved
 recognizing the Wikimedia User Group China as a Wikimedia User
Group; their main focus areas are getting more chinese people know and
use Wikipedia, encouraging people to become contributors to the
different Wikimedia projects, and maintain the community healthy and
growing. Let's welcome the newest member of the family of affiliates
-and the fourth from the Sinosphere!
"*Jülüjain wane mmakat* ein kapülain tü alijunakalirua jee wayuukanairua
junain ekerolaa alümüin supüshuwayale etijaanaka. Ayatashi waya junain."
Carlos M. Colina
Vicepresidente, A.C. Wikimedia Venezuela | RIF J-40129321-2 |
Chair, Wikimedia Foundation Affiliations Committee
This is a personal note to clarify a some questions that recently came up,
specifically in the context of my role as the incoming ED.
My partner Wil and I are partners in our private lives. We have always both
been extremely independent, and we respect that in each other. That said we
have different roles: I am the Executive Director with responsibilities
towards the Foundation and the movement, and he is an independent community
member with his own voice.
I make my decisions using my own professional judgement in conjunction with
input from the community and staff. I don’t consult Wil on these matters,
ask him to do anything on my behalf or monitor his engagements with the
community. When I speak here, it is in my capacity as an ED.
Wil, on the other hand, has a very strong personal interest in the
community and agreat deal of curiosity about how the Wikimedia
projectswork. It is very important to him that he remains an
able to speak with his own voice and ask his own questions. He does not
take direction from me. He will not work for the WMF or engage with the WMF
I hope this addresses some of the questions and draws distinction between
my role as ED and Wil’s participation as an independent member. If you have
any questions for Wil you can reach him directly. If you have any questions
for me or the WMF, you can get a hold of me by email or on my talk page.
We are the Finance Fellows, a multicultural team consisting of 4 young
professionals. We are happy to introduce a 6-month movement-wide project
that focuses on the consistency of how we operate, which is explained
further in this announcement.
*But here's some information about us*:
Arda [User:Melmas_(WMF)] <https://meta.wikimedia.org/wiki/User:Melmas_(WMF)> is
from Turkey. He holds a BA in Economics.
<https://meta.wikimedia.org/wiki/User:Lgillis_(WMF)> is from Belgium. She
holds a Master's degree in Applied Economics and a Master's degree in
<https://meta.wikimedia.org/wiki/User:Oolukoya_(WMF)> is from Nigeria. She
holds a Master's in International Business and a BSc in Economics.
<https://meta.wikimedia.org/wiki/User:Wagsegura_(WMF)> is from Nicaragua.
He holds a BA in Applied Economics.
*About the project "Movement-wide financial report"*
Driven by the Wikimedia Foundation's guiding principles of transparency and
accountability, our goal is to gather data and develop systematic metrics
in order to provide a better understanding of financial statements. The aim
is to help make financial data and statements more consistent and
comparable across all Wikimedia Chapters, Thematic Organizations, and the
Wikimedia Foundation, to the benefit of the whole movement.
The idea of this project comes from the WMF Board of Trustee's Audit
Committee and is supported by the Wikimedia Foundation. An initial quantitative
analysis of Wikimedia Chapters and Thematic Organizations
at Wikimania 2013 by Michal Buczyński (User:Aegis Maelstrom)
<https://en.wikipedia.org/wiki/User:Aegis_Maelstrom>, highlighted the
importance of meaningful, obtainable and unified data.
The Finance Fellows have been formed by WMF to spearhead this project. The
intention of this project is to enable Wikimedia Chapters and Thematic
Organizations to benchmark activities and costs in a consistent way. We
will begin by gathering comparable quantitative financial data about
Wikimedia Chapters and Thematic Organizations. Our findings will later be
released movement-wide, on Meta-Wiki.
Please note that this is not an audit process. We are simply collecting the
data and developing global metrics. The metric is an objective measurement
that will enable data to be consistent, meaningful and comparable among the
Wikimedia Chapters, Thematic Organizations, and the Wikimedia Foundation.
We will build on existing data sets and reach out to Chapters and Thematic
Organizations if further information is required. After processing the
gathered information, we will confirm the data with each organization.
In the long run, we envision that this project could be replicated
annually. In this attempt to enable Wikimedia Chapters, Thematic
Organizations, and the Wikimedia Foundation to help make the movement's
financial data more consistent, we rely on the data provided by the
organizations. We believe that there is enough data available to make a new
attempt on capturing the movement's finances as a whole.
A meta page <https://meta.wikimedia.org/wiki/Movement-wide_Financial_Report>
created for the project, in order to make the information accessible to
everyone and create a space for discussion and/or suggestions. We strongly
encourage you to share with us what types of additional information is
And of course: This is all an experiment! If it does not work, we will try
to apply a modified 'agile' process by iterating, repeating, and trying
again based on the feedback we are getting. If this does not seem right, or
if it appears we are missing something obvious, please let us know!
WMF Finance Fellows (User:WMF Finance Fellows)
This is a response to Martin's note here:
.. and also a more general update on the next steps regarding disputes
about deployments. As you may have seen, Lila has also posted an
update to her talk page, here:
I want to use this opportunity to respond to Martin's and other
people's criticisms, and to talk about next steps from WMF’s
perspective following discussions with Lila and the team. I’m also
sending a copy of this note to all the stewards, to better involve
them in the process going forward.
I am -- genuinely -- sorry that this escalation occurred. We would
have preferred to avoid it.
I would like to recap how we find ourselves in this situation: As
early as July, we stated that the Wikimedia Foundation reserves the
right to determine the final configuration of the MediaViewer feature,
and we explicitly included MediaWiki: namespace hacks in that
statement.  When an admin implemented a hack to disable
MediaViewer, another local admin reverted the edit. The original admin
reinstated it. We then reverted it with a clear warning that we may
limit editability of the page.  The original admin reinstated the
hack. This is when we protected the page.
Because all admins have equal access to the MediaWiki: namespace,
short of desysopping, there are few mechanisms to actually prevent
edit wars about the user experience for millions of readers.
Desysopping actions could have gotten just as messy -- and we felt
that waiting for a "better hack" to come along (the likeliest eventual
outcome of doing nothing) or disabling the feature ourselves would not
be any better, either from a process or outcome standpoint.
Our processes clearly need to be improved to avoid these situations in
the future. We recognize that simply rejecting a community request
rather than resolving a conflict together is not the right answer.
We’ve been listening to feedback, and we’ve come to the following
- We intend to undertake a review of our present processes immediately
and propose a new approach that allows for feedback at more critical
and relevant junctures in the next 90 days. This will be a transparent
process that includes your voices.
- As the WMF, we need to improve the process for managing changes that
impact all users. That includes the MediaWiki: namespace. For WMF to
fulfill its role of leading consistent improvements to the user
experience across Wikimedia projects, we need to be able to review
code and manage deployments. This can be done in partnership with
trusted volunteers, but WMF needs to be able to make an ultimate
determination after receiving community feedback regarding production
changes that impact all users.
- We are prepared to unprotect MediaWiki:Common.js on German Wikipedia
and enter constructive, open-ended conversations about the way
forward, provided we can mutually agree to do so on the basis of the
current consistent configuration -- for now. We would like to request
a moratorium on any attempts to disable the feature during this
conflict resolution process. The goal would be to make a final,
cross-wiki determination regarding this specific feature, in
partnership with the community, within at most 90 days.
With regard to the German Wikipedia situation, we’d like to know if
stewards want to at all be involved in this process: In a situation
like this, it can be helpful to have a third party support the
conversation. Stewards are accountable to "valid community consensus
within the bounds of the Foundation's goals" , which seems to be
precisely the intersection of concerns at issue here. We would like to
suggest an IRC meeting with stewards ASAP to talk about the specific
question of stewards’ involvement, if any. If stewards prefer not to
be involved, we understand, but it's probably a good idea to have a
sync-up conversation regardless.
I hope we can move forward in good faith from here, and find better
ways to work together. As Lila has expressed, we believe there is a
need for a clear understanding of our role. It is as follows:
Managing software development, site configuration and deployment is a
core WMF responsibility. The community leads in the development of
content; the Wikimedia Foundation leads in the development of
Because these processes are deeply interdependent, we need to develop
better protocols for timely feedback and resolution of disagreements.
At the same time Lila’s and the Board’s statements make it very clear
that the WMF will not accept RfCs or votes as the sole determining
factor in global software deployments.
This means that technology and UX changes should not be decided by
vote or poll and then disabled at-will: where we disagree, we need to
talk to each other (and yes, that means a more judicious application
of RESOLVED WONTFIX on our end, as well!). We need to ensure a
process where the community voice is heard earlier at critical
junctions in the product development. All of this is consistent with
the principle of "shared power" articulated in the Guiding Principles
 approved by the Board of Trustees.
At the same time, as noted above and earlier, the superprotection
feature should be replaced with a better mechanism for code review and
deployment in the MediaWiki: namespace. This is discussed in  and
ideas and suggestions are welcome. Let’s be upfront about control
structures for production changes to avoid misunderstandings and
ambiguity in the future.
We are exploring options on how to improve dispute resolution
mechanisms -- whether it’s e.g. a standing working group or a better
protocol for responding to RfCs and engaging in discussions. We've
started a brainstorming page, here, which we hope will usefully inform
the process of conflict resolution regarding German Wikipedia, as
well, so we can arrive at a more concrete conflict resolution process
soon. Your thoughts/suggestions are welcome, so we can (in NPOV style)
look at different possibilities (e.g. workgroups, committees, votes,
surveys) that have been discussed in the past:
We’re absolutely not saying that WMF simply wants to be able to
enforce its decisions: we completely understand there need to be
mechanisms for the community to influence decisions and outcomes at
all stages of the development and release of software. We need to
arrive at this process together.
Again, we are sorry that this escalation occurred - and we hope we can
move forward constructively from here.
VP of Engineering and Product Development, Wikimedia Foundation
Don't worry, we indeed have a lot of time till the next elections, but as
this issue had been raised during the last elections - and we decided that
we can't change the rules few weeks before the elections, now I want to
raise the discussion enough time before.
According to the current rules , in order to influence and vote in the
elections, you need to be active editor, developer or WMF staff/contractor.
Last year this issue concern some of us. The foundation is not small
organizations as it been before, and by comparison, the number of people
participating in the elections every year is not high.
For example, last elections there were 1809 valid votes. By comparison, the
number of WMF staff this days is 218, what makes there voting power 12% of
the total voters last year. This consider to be a great amount of power
when we are talking about elections (In the last election you would have
around 650 votes in order to be elected...)
Wikimedia thematic organizations staff and contractors for example don't
have the same privilege to vote only because they are employees of the
movement, only if they are editors as well. The question - what make the
WMF staff different, and if this is not a little bit problematic that the
staff have such power to decide on their direct board, but in general - the
board of the whole movement.
Do we need to give the same privilege also to all the staff in our
Should we limited the elections to staff (both WMF and chapters) that are
active editors or developers as additional to their work in the movement?
I'll be happy to hear yours input.
Chairperson, Wikimedia Israel
+972-(0)-54-5878078 | http://www.wikimedia.org.il
Imagine a world in which every single human being can freely share in the
sum of all knowledge. That's our commitment!
1. Where can I find a response from either the WMF board or WMF
funding/finance to the criticisms of a lack of transparency or the
apparent failure of the project to deliver value for the donor's money
as raised in this blog post?
2. Where can I read an officially recognized report for the outcomes
of this project in terms of value for Wikimedia projects? Obviously we
do not want to rely on second-hand analysis when reports to the WMF
are a requirement for such projects.
We know NSA wants Wikipedia data, as Wikipedia is listed in one of the
That slide is about HTTP, and the tech staff are moving the
user/reader base to HTTPS.
As we learn more about the NSA programs, we need to consider vectors
other than HTTP for the NSA to obtain the data they want. And the
userbase needs to be aware of the current risks.
One question from the "Dells are backdored"[sic] thread that is worth
separate consideration is:
Are the Wikimedia transit links encrypted, especially for database replication?
MySQL has replication over SSL, so I assume the answer is Yes.
If not, is this necessary or useful, and feasible ?
However we also need to consider that SSL and other encryption may be
useless against NSA/etc, which means replicating non-public data
should be avoided wherever possible, as it becomes a single point of
Given how public our system is, we don't have a lot of non-public
data, so we might be able to design the architecture so that
information isnt replicated, and also ensure it isnt accessed over
insecure links. I think the only parts of the dataset that are
private & valuable are
* passwords/login cookies,
* checkuser info - IPs and useragents,
* WMF analytics, which includes readers iirc, and
* hidden/deleted edits
* private wikis and mailing lists
Have I missed any?
Are passwords and/or checkuser info replicated?
Is there a data policy on WMF analytics data which prevents it flowing
over insecure links, and limits what is collected and ensures
destruction of the data within reasonable timeframes? i.e. how about
not using cookies to track analytics of readers who are on HTTP
instead of HTTPS?
The private wikis can be restricted to https, depending on the value
of the data on those wikis in the wrong hands. The private mailing
lists will be harder to secure, and at least the English Wikipedia
arbcom list contain a lot of valuable data about contributors.
Regarding hidden/deleted edits, the replication isnt the only source
of this data. All edits are also exposed via Recent Changes
(https/api/etc) as they occur, and the value of these edits is
determined by the fact they are hidden afterwards (e.g. don't appear
in dumps). Is there any way to control who is effectively capturing
all edits via Recent Changes?
For some months, Twitter have been blocking most URLs in their direct
messages (DMs), supposedly as an anti-spam measure.
Do we have someone who has a contact there, who could ask them to
whitelist Wikimedia project URLs in DMs?
On Thu, Oct 9, 2014 at 10:26 AM, Pine W <wiki.pine(a)gmail.com> wrote:
> I'm sure a Board member, Lila, or Erik will correct me if I am mistaken,
> but my understanding is that there is internal agreement at Board level
> that the Product side of the org needs some systemic changes, that Lila was
> chosen with the goal of making those changes, and that some changes are
> already happening.
There's agreement at all levels that we want to continue down the path
set by Sue back in 2012  for WMF to truly understand itself as a
technology and grantmaking organization. That path led to where we are
1) As part of the ED transition, Sue recommended (and the Board
accepted the recommendation) to seek an ED with a strong
technology/product background, and we hired Lila Tretikov as Sue's
successor who matches those requirements.
2) In November 2012, I recommended that we prepare for building out
new functions for UX and Analytics, and prepare for dedicated
leadership for Engineering and Product. Sue accepted this
recommendation. I hired Directors for UX and Analytics in 2013,
followed by Community Engagement in 2014, and finally we hired a VP
Engineering last week to complete the process.
3) To better account for the need to learn quickly and adjust course
as appropriate, we introduced quarterly reviews in December 2012 
and increasingly reduced the specificity of Annual Plan level
commitments while increasing the focus on metrics and accountability
in the reviews.
4) On the technology and product front, many improvements to process
and support infrastructure have been implemented in the last couple of
years, including but not limited to:
- Development of MediaWiki Vagrant as a standardized dev environment,
to reduce failure cases due to developer environment inconsistencies
- Improvements to continuous integration infrastructure for PHP unit
nearly enough yet) on automated tests, especially for newly developed
- Introduction and continued improvement of BetaLabs as a staging
environment for all commits, increased use of automated end-to-end
browser tests and QA testing by humans to catch bugs and regressions
prior to production rollouts
- Introduction and use of various tools for measuring the impact of
features, including EventLogging as a standard instrumentation
framework for measuring feature usage, dashboards for visualizing
usage, WikiMetrics for analyzing editor cohort behavior, Editor
Engagement Vital Signs for understanding system-wide user behavior,
analysis of pageview data using Hadoop (just rolled out), etc.
- Highly specialized automated testing frameworks for specific
projects, e.g. Parsoid round-trip testing and visual diffing (!) to
detect dirty diffs or output problems
- Introduction of design research as a discipline in the UX team
(through hiring of Abbey Ripstra as User Research Lead) and
incorporation of user studies in a much more systematic way across
- Community liaisons dedicated to key products, responding to user
feedback and helping Product Managers understand more complex
- Continued shortening of release/deployment cycles; significant
improvements to deployment tooling, rewriting our legacy "scap" tools
to increase the ability to monitor and reason about deployments;
introduction of daily "SWAT" deploys to quickly release fixes, etc.
- Introduction of various infrastructure tools that help us better
analyze/profile issues, including logstash for log analysis, increased
use of graphite for performance metrics collection and various
front-ends for visualizing those metrics
- Shift towards loosely coupled services, addressing the difficulty of
maintaining and improving our highly monolithic codebase (examples
include Parsoid, Citoid, Mathoid, and the new Content API in
- Introduction of Beta Features framework to stage features for early adopters
5) The changes Lila has pushed for since we started include:
- Greater focus on quarterly prioritization and a "rolling roadmap"
rather than a fiscal year view of the world
- Increased emphasis on understanding the needs of different user
personas at all cycles of software development, including through use
of qualitative and quantitative methods
- Reducing velocity of user-facing changes (esp. on desktop) to
increase focus on foundations (platform/process improvements) that
ultimately will enable us to move faster and more effectively
- Documenting product development methodology on-wiki and establishing
a clearer social contract (to reduce the reliance on RFCs/votes
regarding feature configurations)
- Surveying the needs of current users to more systematically balance
projects that serve future/new users vs. projects that serve the users
we have today
- Improved communication channels for community engagement to make it
easier to understand what major projects are currently in development
and how to provide feedback
This already means, effectively, that the commitments in the Annual
Plan developed during Sue's time should be taken with a big block of
salt at this point in time -- we're slowing down the deployment (not
development) of big user-facing features like Flow and VE as much as
needed to ensure that we incorporate user feedback, data and
qualitative research into the product development process
appropriately and spend sufficient time on the technical foundations
for these projects.
The quarterly prioritization alone has been, IMO, a huge improvement
that's already paying off. In the "Annual Plan" view of the world,
it's unlikely that we would have prioritized a project like HHVM the
way we did, because we were generally stuck on the priorities set for
the whole year. But it was very clear that this project would provide
huge benefits to our users, and I'm glad we were able to call it out
as _the_ top priority for Q1 and give the team the space to really
focus on getting it done (almost there now, starting to serve reader
Our draft Q2 top priorities (not yet posted on-wiki, but discussed in
the metrics meeting last week) are consistent with the above, with the
main user-facing push being on mobile web/apps and editing
performance, while the other priorities are more
platform/process-related. Once again, we're continuing to work on VE /
Flow, but focusing more on fundamentals (performance, architecture,
testing, use case analysis, etc.) than accelerating deployments.
My focus over the coming days is to flesh out the details for the Q2
priorities, and then shift to putting more effort in documenting and
refining product development methodologies and processes on-wiki. On
the engineering side, there's plenty of process/infrastructure
improvement to do as well. From my point of view, continued
improvement to test coverage and CI/testing infrastructure, developer
tools, profiling/instrumentation, staged roll-out support and
strengthening of architectural leadership are the big pieces for
coming months, but I'll let Damon speak to his focus areas as he gets
the lay of the land.
VP of Product & Strategy, Wikimedia Foundation