Dear all,
It is an honor to announce that the Affiliations Committee has resolved
[1] 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!
Regards,
Carlos
1:
https://meta.wikimedia.org/wiki/Affiliations_Committee/Resolutions/Wikimedi…
--
"*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 |
www.wikimedia.org.ve <http://wikimedia.org.ve>
Chair, Wikimedia Foundation Affiliations Committee
Phone: +972-52-4869915
Twitter: @maor_x
Hi all,
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
independent individual
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
employees.
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.
Thanks,
Lila
Hi folks,
This is a response to Martin's note here:
https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073936.html
.. 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:
https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#Working_Together
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. [1] 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. [2] 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
conclusions:
- 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" [3], 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
technology.
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
[4] 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 [5] 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:
https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Process_ideas
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.
Sincerely,
Erik
[1] https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Meinungsbil…
[2] https://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.js&d…
[3] https://meta.wikimedia.org/wiki/Stewards_policy
[4] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles#Sha…
[5] https://bugzilla.wikimedia.org/show_bug.cgi?id=69445
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Re: http://twkozlowski.net/the-pot-and-the-kettle-the-wikimedia-way/
Two questions:
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.
Thanks,
Fae
--
faewik(a)gmail.com https://commons.wikimedia.org/wiki/User:Fae
We know NSA wants Wikipedia data, as Wikipedia is listed in one of the
NSA slides:
https://commons.wikimedia.org/wiki/File:KS8-001.jpg
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
failure.
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?
--
John Vandenberg
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?
--
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk
Hi folks,
to increase accountability and create more opportunities for course
corrections and resourcing adjustments as necessary, Sue's asked me
and Howie Fung to set up a quarterly project evaluation process,
starting with our highest priority initiatives. These are, according
to Sue's narrowing focus recommendations which were approved by the
Board [1]:
- Visual Editor
- Mobile (mobile contributions + Wikipedia Zero)
- Editor Engagement (also known as the E2 and E3 teams)
- Funds Dissemination Committe and expanded grant-making capacity
I'm proposing the following initial schedule:
January:
- Editor Engagement Experiments
February:
- Visual Editor
- Mobile (Contribs + Zero)
March:
- Editor Engagement Features (Echo, Flow projects)
- Funds Dissemination Committee
We’ll try doing this on the same day or adjacent to the monthly
metrics meetings [2], since the team(s) will give a presentation on
their recent progress, which will help set some context that would
otherwise need to be covered in the quarterly review itself. This will
also create open opportunities for feedback and questions.
My goal is to do this in a manner where even though the quarterly
review meetings themselves are internal, the outcomes are captured as
meeting minutes and shared publicly, which is why I'm starting this
discussion on a public list as well. I've created a wiki page here
which we can use to discuss the concept further:
https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r…
The internal review will, at minimum, include:
Sue Gardner
myself
Howie Fung
Team members and relevant director(s)
Designated minute-taker
So for example, for Visual Editor, the review team would be the Visual
Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker.
I imagine the structure of the review roughly as follows, with a
duration of about 2 1/2 hours divided into 25-30 minute blocks:
- Brief team intro and recap of team's activities through the quarter,
compared with goals
- Drill into goals and targets: Did we achieve what we said we would?
- Review of challenges, blockers and successes
- Discussion of proposed changes (e.g. resourcing, targets) and other
action items
- Buffer time, debriefing
Once again, the primary purpose of these reviews is to create improved
structures for internal accountability, escalation points in cases
where serious changes are necessary, and transparency to the world.
In addition to these priority initiatives, my recommendation would be
to conduct quarterly reviews for any activity that requires more than
a set amount of resources (people/dollars). These additional reviews
may however be conducted in a more lightweight manner and internally
to the departments. We’re slowly getting into that habit in
engineering.
As we pilot this process, the format of the high priority reviews can
help inform and support reviews across the organization.
Feedback and questions are appreciated.
All best,
Erik
[1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus
[2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
Hi all,
There are online small business accounting software packages. Do any
thematic orgs have experience with them? Any recommendations? I am thinking
about proposing Quickbooks Online for the Cascadia user group, but as this
Forbes article says, there are competitors:
http://www.forbes.com/sites/quickerbettertech/2014/01/06/why-your-company-m…
Thanks,
Pine
Hi folks,
At the Zurich Hackathon, I met with a couple of folks from WM-CH who
were interested in talking about ways that chapters can get involved
in engineering/product development, similar to WM-DE's work on
Wikidata.
My recommendation to them was to consider working on GLAM-related
tooling. This includes helping improve some of the reporting tools
currently running in Labs (primarily developed by the illustrious and
wonderful Magnus Manske in his spare time), but also meeting other
requirements identified by the GLAM community [1] and potentially
helping with the development of more complex MediaWiki-integrated
tools like the GLAMWiki-Toolset.
There's work that only WMF is well positioned to do (like feeding all
media view data into Hadoop and providing generalized reports and
APIs), but a lot of work in the aforementioned categories could be
done by any chapter and could easily be scaled up from 1 to 2 to 3
FTEs and beyond as warranted. That's because a lot of the tools are
separate from MediaWiki, so code review and integration requirements
are lower, and it's easier for technically proficient folks to help.
In short, I think this could provide a nice on-ramp for a chapter or
chapters to support the work of volunteers in the cultural sector with
appropriate technology. This availability of appropriate technology is
clearly increasingly a distinguishing factor for Wikimedia relative to
more commercial offerings in its appeal to the cultural sector.
At the same time, WMF itself doesn't currently prioritize work with
the cultural sector very highly, which I think is appropriate given
all the other problems we have to solve. So if this kind of work has
to compete for attention with much more basic improvements to say the
uploading pipeline or the editing tools, it's going to lose. Therefore
I think having a "cultural tooling" team or teams in the larger
movement would be appropriate.
I've not heard back from WM-CH yet on this, but I also don't think
it's an exclusive suggestion, so wanted to put the idea in people's
heads in case other organizations in the movement want to help with
it. I do want WMF to solve the larger infrastructure problems, but the
more specialized tooling is likely _not_ going to be high on our
agenda anytime soon.
Thanks,
Erik
[1] https://upload.wikimedia.org/wikipedia/commons/a/a2/Report_on_requirements_…
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
