Thanks again for your responses, Denny. I think it really helps to get a
clearer perspective on things "on the inside", and that informs the kind of
things we need to think and talk about as a company and as a movement.
I know it's a super awkward position to be putting all of you in,
especially at this juncture. I hope we'll all get through this sanely and
we can talk about ways to better align our various structures to our needs
with less immediate stress.
-- brion
On Feb 25, 2016 9:16 AM, "Denny Vrandecic" <dvrandecic(a)wikimedia.org> wrote:
> Thanks to all the answers to my response. I am still reading them, and I
> probably will not be able to answer to all in a timely manner (I have to
> work, after all), but I wanted to make a few things clearer, quickly:
>
> Milos, I indeed do not care about reelection. And if I have to choose
> between truth and political wisdom, I hope to continue to choose the first.
>
> More importantly, Milos, I did a massive error in my formulation, as I know
> realize, which lead to a misunderstanding. I have to apologize for that.
> When I said that the Board has to make a decision in the interest of the
> Foundation when there is a conflict between the Communities and the
> Foundation, I was phrasing myself very badly, I now realize. I actually did
> not mean a direct conflict between a single Community and the Foundation,
> i.e. with these two as being directly opposed to each other and fighting
> over something, but rather the more complicated case of a decision where
> there is a conflict of interests between the Foundation and the
> Movement-at-large, the Board is obliged to decide in the best interest of
> the Foundation.
>
> I do not buy in the mythology of an "evil community" at all. I do not even
> buy into the mythology of a great divide between the communities and the
> foundation. There are plenty of people who are active and constructive in
> both, and who bridge both. The cases where the Foundation and the Movement
> are directly opposed to each other should be extremely rare, and,
> thankfully are. I don't think there was anything even close to that brought
> to the Board in my tenure so far.
>
> More often though is the case that there is a third-party situation, e.g.
> an imminent and considerable legal threat to the Foundation. In that case,
> the interests of the Movement at large has to be secondary for the Board.
>
> I regard the Movement-at-large as much more resilient than any and each of
> its parts. And I am thankful for that, because I think our mission is much
> too important to leave it with a small NGO in the Bay Area. It has to be a
> mission carried by every single one of us, it has to be a mission that is
> inclusive of every one who wants to join in realizing it.
>
> I have overstated my point in my last mail, obviously, and also
> intentionally to make a point (and thanks for everyone to calling me out on
> that). But as many have confirmed, there is truth in this overstatement. I
> don't think that such situations will occur often. But when they occur, and
> that is what I said, they will be painful and frustrating and potentially
> shrouded in confidentiality / secrecy. Therefore it remains my strong
> belief, that reaffirming the current Board as the movement leadership body
> is a bad idea, because the overstated incompatibility that I have described
> remains.
>
> I could imagine with a much smaller Board of Trustees, which itself is a
> constituent of a body representing the whole Movement.
> I could imagine a wholly new body to represent the whole movement.
> I could imagine many, many small new bodies who somehow make local
> decisions on the one side and bubble up to an ineffective, but extremely
> resilient and representative voice.
> I could imagine many other models.
> But I have a hard time to imagine the Board of Trustees of the Wikimedia
> Foundation sincerely filling out the role of the movement leadership, due
> to the inherent constraints and incompatibilities between these roles. As
> rare as they appear, they do appear.
>
> Dariusz, you say that a disengagement from the Foundation by the community
> would increase a specific Foundation versus the rest of the movement
> situation. I don't think that the formal composition of the Board matters
> as much as its role, duties, and obligations.
>
> The German Wikimedia chapter, the one chapter I have a bit experience with,
> is a membership organization. The Board is elected by the members in its
> entirety. I don't see any claim of that Board to lead the German Wikimedia
> communities. I don't see that the German chapter is significantly closer to
> the German Wikimedia communities, or that their relation to the communities
> is considerably less strained, than the Foundation is to the overall
> communities (besides the obvious locality of their relation).
>
> Dan, Brion, James, in particular thanks to you for arguing why my
> overstatement was, well, an overstatement. But I still remain convinced
> that the view of the Board as having the role of leading the movement is
> merely an accident of the fact that we have no other obvious leadership,
> and that the Board is being sucked into that vacuum. It is not designed to
> be so, and, I argue, due to the legal and formal obligations, it shouldn't.
>
> MZMcBride, I currently lack the time to answer to your specific and
> excellent points in particular. Sorry. I hope to come back to it.
>
>
>
>
>
> On Thu, Feb 25, 2016 at 8:24 AM, Dariusz Jemielniak <
> djemielniak(a)wikimedia.org> wrote:
>
> > On Thu, Feb 25, 2016 at 10:43 AM, Milos Rancic <millosh(a)gmail.com>
> wrote:
> >
> > > Thus, not the senate, but assembly is the right form of our
> > > organization: assembly which would select *paid* Board members.
> > > Besides the load, I want Board members to be accountable to
> > > Wikimedians, not to the for-profit or non-profit entities which give
> > > them money.
> > >
> >
> > I am not, and have not been employed by any Wikimedia organization.
> >
> >
> > >
> > > Yes, it's scary to be accountable to people you lead. I completely
> > > understand that.
> > >
> >
> > I have no idea where you get this idea from in my letter. I am not scared
> > to be accountable to people I lead, and I hope I have stated my readiness
> > in this department clearly.
> >
> >
> > >
> > > The costs of having 100 people assembly won't be significant at all.
> > > First of all, the most of the people in such large body would be
> > > anyways mostly consisted of those going to Wikimedia Conference and
> > > Wikimania. If you really care about money, scale the initial body to
> > > 40-50 and ask all chapters that sending three or more people to those
> > > conferences to contribute expenses for one to such body. If you put
> > > that way, the costs could rise up to ~5%, if they raise at all.
> > >
> >
> > If you envisage a large, 100 people assembly during Wikimania or
> Wikimedia
> > Conference, then indeed it is possible to arrange without significant
> > additional cost. However, I believe this is basically an entirely
> different
> > idea than the one Denny described (or at least the one I understood we're
> > discussing). An assembly would be a body who would voice their opinion
> only
> > once a year in practice, most likely. I'm not sure what exactly would it
> > do, but surely it would be difficult for it to agree/vote on situations
> > happening within a span of weeks, rather than months.
> >
> >
> > >
> > > So, please, reconsider your ideas on the line: from speaking about bad
> > > bureaucracy, while in fact increasing inefficient one -- to thinking
> > > about efficient, democratically accountable bureaucracy, with
> > > everybody content by its construction.
> > >
> >
> > I am not convinced if a body of 100 people meeting once a year is an
> > efficient way to reduce bureaucracy. Of course views may differ.
> >
> >
> > >
> > > Said everything above, I have to express that I am pissed off by the
> > > fact that the Board members are constructive as long as they are under
> > > high level of pressure. Whenever you feel a bit more empowered, I hear
> > > just the excuses I've been listening for a decade.
> > >
> >
> > I am saddened you have this perception.
> > https://xkcd.com/552/
> >
> >
> > >
> > > Please, let us know how do you want to talk with us in the way that we
> > > see that the communication is constructive.
> >
> >
> > That is a good topic for a separate thread! Currently, the list we use is
> > limited to 1500 English speakers.
> >
> > An idea that I have been trying to champion for a while was also
> > community-liaisons: community elected people whose responsibility is
> > day-to-day communication with the WMF and back. This would not be a
> > decisive role, and it is independent from whether we have a senate or
> > assembly or not, but could at least increase the reach of communication
> and
> > decision making in some areas.
> >
> > Also, discourse is a platform that perhaps will take off at some point.
> >
> > dj
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > New messages to: Wikimedia-l(a)lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> >
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> New messages to: Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
[x-posted announcement]
Hello,
The next online office hour session of the Wikimedia Language team is
scheduled for next Wednesday, March 2nd 2016 at 14:00 UTC. This session is
going to be an online discussion over Google Hangouts/Youtube with a
simultaneous IRC conversation. Due to the limitation of Google Hangouts,
only a limited number of participation slots are available. Hence, do
please let us know (on the event page
<https://plus.google.com/u/0/events/cbn4a2gubl4m6au3jv0gllh5t0k>) if you
would like to join in the Hangout. The IRC channel #wikimedia-office and
the Q&A channel for the youtube broadcast will be open for interactions
during the session.
Our last online round-table session was held in November 2015. You can
watch the recording here: https://www.youtube.com/watch?v=eYWZ6C4N93Y
Please read below for the event details, including local time and do let us
know if you have any questions.
Thank you
Runa
== Details ==
# Event: Wikimedia Language team's office hour session
# When: March 2nd, 2016 (Wednesday) at 14:00 UTC (check local time
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160302T1400)
# Where: https://plus.google.com/u/0/events/cbn4a2gubl4m6au3jv0gllh5t0k and
on IRC #wikimedia-office (Freenode)
# Agenda: Content Translation updates and Q & A
--
Language Engineering Manager
Outreach and QA Coordinator
Wikimedia Foundation
Greetings,
Wikimedia is a mentoring organization for Outreachy round 12 and the
application period is now open[1]. More details can be found out on the
program page[2].
We have a lot of project ideas in the Possible-Tech-Projects board[3],
where students can look for ideas.
Some of them have a well defined scope with micro-tasks and ready to be
featured, while many others require your love.
Do consider stepping forward and adding yourself as a mentor if you feel
you could help move any of the projects forward, especially in the "
*Discussion*" and "*Missing mentors*" column. A lot of projects in the
"*Missing
mentors*" column have also been recently added, which are Community
wishlist items, and stand a good chance of being featured.
Your comments would be greatly appreciated in shaping these ideas into
featured projects for the students.
Also, if you know of other projects/ideas which could be a good fit for a 3
month GSoC/Outreachy internship, feel free to add them to the board.
[1] - https://outreachy.gnome.org/?q=program_home&prg=6
[2] - https://www.mediawiki.org/wiki/Outreachy/Round_12
[3] - https://phabricator.wikimedia.org/tag/possible-tech-projects/
-Thank You!
-Sumit
-Co-organizer of Outreachy 12 alongwith Tony Thomas
Hi,
we are considering a policy for REST API end point result format
versioning and negotiation. The background and considerations are
spelled out in a task and mw.org page:
https://phabricator.wikimedia.org/T124365https://www.mediawiki.org/wiki/Talk:API_versioning
Based on the discussion so far, have come up with the following
candidate solution:
1) Clearly advise clients to explicitly request the expected mime type
with an Accept header. Support older mime types (with on-the-fly
transformations) until usage has fallen below a very low percentage,
with an explicit sunset announcement.
2) Always return the latest content type if no explicit Accept header
was specified.
We are interested in hearing your thoughts on this.
Once we have reached rough consensus on the way forward, we intend to
apply the newly minted policy to an evolution of the Parsoid HTML
format, which will move the data-mw attribute to a separate metadata
blob.
Gabriel Wicke
Hey all,
TLDR: ORES extension [1] which is an extension that integrates ORES service
[2] with Wikipedia to make fighting vandalism easier and more efficient is
in the progress of deployment. You can test it in
https://mw-revscoring.wmflabs.org (Enable it in your preferences first)
You probably know ORES. It's an API service that gives probably of an edit
being vandalism, it also does other AI-related stuff like guessing the
quality of articles in Wikipedia. We have a nice blog post in Wikimedia
Blog [3] and media paid some attention to it [4]. Thanks to Aaron Halfaker
and others [5] for their work in building this service. There are several
tools using ORES to highlight possibly vandalism edits. Huggle, gadgets
like ScoredRevisions, etc. But an extension does this job much more
efficiently.
The extension which is being developed by Adam Wight, Kunal Mehta and me
highlights unpatrolled edits in recentchanges, watchlists, related changes
and in future, user contributions if ORES score of those edits pass a
certain threshold. GUI design is made by May Galloway. ORES API (
ores.wmflabs.org) only gives you a score between 0 and 1. Zero means it's
not vandalism at all and one means it's vandalism for sure. You can test
its simple GUI in https://ores.wmflabs.org/ui/. It's possible to change the
threshold in your preferences in the recent changes tab (you have options
instead of numbers because we thought numbers are not very intuitive).
Also, we enabled it in a test wiki so you test it:
https://mw-revscoring.wmflabs.org. You need to make an account (use a dummy
password) and then enable it in beta features tab. Note that building AI
tool to detect vandalism in a test wiki sounds a little bit silly ;) so we
set up a dummy model that probability of an edit being vandalism is
backward of the last two digits (e.g. diff id:12345 = score:54%). In a more
technical aspect, we store these scores in ores_classification table so we
can do a lot more analysis with them once the extension is deployed. Fun
use cases such as the average score of a certain page or contributions of a
user or members of a category, etc.
We passed security review and we have consensus to enable it in Persian
Wikipedia. We are only blocked on ORES moving from Labs to production
(T106867 [6]). The next wiki is Wikidata, we are good to go once the
community finishes labeling edits so we can build the "damaging" model. We
can enable it Portuguese and Turkish Wikipedia after March because s2 and
s3 have database storage issues right now. For other Wikis, you need to
check if ORES supports the Wiki and if community finished labeling edits
for ORES (check out the table at [2])
If you want to report bugs or add feature requests you can find it in here
[7].
[1]: https://www.mediawiki.org/wiki/Extension:ORES
[2]: https://meta.wikimedia.org/wiki/Objective_Revision_Evaluation_Service
[3]:
https://blog.wikimedia.org/2015/11/30/artificial-intelligence-x-ray-specs/
[4]:
https://meta.wikimedia.org/wiki/Research:Revision_scoring_as_a_service/Media
[5]:
https://meta.wikimedia.org/wiki/Research:Revision_scoring_as_a_service#Team
[6]: https://phabricator.wikimedia.org/T106867
[7]: https://phabricator.wikimedia.org/tag/mediawiki-extensions-ores/
Best
My apologies for the short notice. Normally we announce these more than one
hour in advance, but I forgot.
In today's RFC meeting, we will discuss the following RFC:
* Standardise on how to access/register JavaScript interfaces
<https://phabricator.wikimedia.org/T108655>
<https://phabricator.wikimedia.org/E144
<https://phabricator.wikimedia.org/E140>>
The meeting will be on the IRC channel #wikimedia-office on
chat.freenode.net at the following time:
* UTC: Wednesday 22:00
* US PST: Wednesday 14:00
* Europe CET: Wednesday 23:00
* Australia AEDT: Thursday 09:00
Roan
https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-02-24
= 2016-02-24 =
== Technology ==
=== Analytics ===
* '''Blocking''': (nobody we know)
* '''Blocked''': (on nothing)
* '''Updates''':
** Upgraded to CDH 5.5, comes with lots of improvements for those using the
Hadoop cluster:
http://www.cloudera.com/documentation/enterprise/latest/topics/cdh_rn_new_i…
** Internally released data that estimates the number of Unique Devices
hitting each of our domains, using the Last Access cookie. This is a major
release, and it's available in the wmf database in hive, in the
last_access_uniques_daily table.
** Fixed handling of uri-encoded page titles in the pageview API
=== Architecture ===
* '''Blocking''':
** ???
* '''Blocked''':
** ???
* '''Updates''':
** ???
=== Performance ===
* '''Blocking''':
** ???
* '''Blocked''':
** ???
* '''Updates''':
** ???
=== Release Engineering ===
* '''Blocking''':
** https://phabricator.wikimedia.org/T111259
** Update train email as to why stalled
* '''Blocked''':
** None
* '''Updates''':
** AQS deployed via Scap3, (hooray \o/ +1) ready for new services w/new
version
** Phabricator updates happened, puppet work continues
** Train (still) not running wmf.14 on testwiki and that's all
=== Research ===
* '''Blocking''':
** nothing we know of
* '''Blocked''':
** blocked on ops for ORES in production
*** also blocks deployment of ORES extension to fawiki and wikidata
*** halfak would like to engage with ops - could someone contact him?
* '''Updates''':
** none
=== Security ===
* '''Blocking''':
** ???
* '''Blocked''':
** ???
* '''Updates''':
** Working through lots of security bugs
** PageViewInfo review in progress
=== Services ===
* '''Blocking''':
** ???
* '''Blocked''':
** ???
* '''Updates''':
** ???
=== Technical Operations ===
* '''Blocking''':
** ???
* '''Blocked''':
** ???
* '''Updates''':
** ???
== Product ==
=== Community Tech ===
* '''Blocking''':
** ???
* '''Blocked''':
** ???
* '''Updates''':
** ???
=== Discovery ===
* '''Blocking''':
** none afaik
* '''Blocked''':
** Would like Ops input for https://phabricator.wikimedia.org/T126730 (caching
model for WDQS)
** Would like Sec review on SVG sanitizer JS lib
** Would like Sec review on Schema validator php lib
* '''Updates''':
** Preparing to switch completion suggester into production (March)
** A number of new interesting graphs at http://discovery.wmflabs.org/ e.g.
http://discovery.wmflabs.org/metrics/#failure_langproj,
http://discovery.wmflabs.org/portal/#browser_breakdown
** Not much new, mostly bugfixes, tweaks and maintenance
==== Graphs ====
** Pageview API graphs getting popular
=== Editing ===
==== Collaboration ====
* '''Blocking''':
** External Store - In progress. Will soon enable External Store on Beta
Cluster as a pre-requisite for this. If you want to look/give feedback on
the Beta change, see https://phabricator.wikimedia.org/T95871
* '''Blocked''':
** Flow dumps on dumps.wikimedia.org:
https://phabricator.wikimedia.org/T119511
** Schema change to make a column NOT NULL in production:
https://phabricator.wikimedia.org/T122111#2050844
* '''Updates''':
** Enabled Echo cross-wiki notifications feature on initial wave of wikis.
Good feedback so far.
** Working on some issues with Flow board moves.
** Also, not a Collaboration team thing, but we've asked for feedback on
some Code of Conduct proposed changes:
https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Suggested_changes
==== Language ====
* '''Blocking''':
** None
* '''Blocked''':
** None
* '''Updates''':
**
==== Multimedia ====
* '''Blocking''':
** ???
* '''Blocked''':
** ???
* '''Updates''':
** ???
==== Parsing ====
* '''Blocking''':
** None?
* '''Blocked''':
** None
* '''Updates''':
** Templatedata based serialization being deployed today (
https://phabricator.wikimedia.org/T111674 and
https://phabricator.wikimedia.org/T104599 )
** Kunal and Ori have been investigating
https://phabricator.wikimedia.org/T124356 ... Ori might have made some
headway there.
*** Filed https://phabricator.wikimedia.org/T127757 to fix getText()
semantics to prevent this kind of sneaky bugs in the future.
** Heads up for release engineering:
https://phabricator.wikimedia.org/T111259 bit us once more recently.
==== VisualEditor ====
* '''Blocking''':
** None known.
* '''Blocked''':
** Waiting on Design Research availability for user testing of Single Edit
Tab integration
* '''Updates''':
** Single Edit Tab went to Hungarian Wikipedia yesterday; now waiting on
user feedback.
** Some improvements to OOUI; note the breaking change for wmf.15+ (no
known issues in gerrit master code).
** Last week we said we'd update on assessing the performance impact of
OOUI on all read pages; this is not firm yet, but appears to be a trivial
additional cost.
=== Fundraising Tech ===
* No blockers/blocking
* Investigating anomalies
* Improving CiviCRM reporting
* Testing backup processor improvements
* Further Latin America processor work
=== Reading ===
==== Android ====
* '''Updates''':
** Nothing to report.
==== Reading Infrastructure ====
* We've been mostly chasing performance issues that people found that touch
stuff SessionManager also touched.
* In the not too distant future, load.php is going to start enforcing the
fact that it's supposed to not depend on the session or the request data.
** See https://phabricator.wikimedia.org/T127233 and subtasks.
** Check your ResourceLoaderModule subclasses and your
'ResourceLoaderGetConfigVars' hook functions to make sure you're not using
$wgUser or $wgLang (or their equivalents via RequestContext). You'll
generally want to use the user and language from the ResourceLoaderContext
or use the 'MakeGlobalVariablesScript' hook instead. Remember that Message
objects will use $wgLang by default.
** Check your parser hooks to make sure you're using
$parserOptions->getUser() or $parser->getTargetLanguage() instead of
$wgUser or $wgLang (or their equivalents via RequestContext), respectively.
Otherwise you're liable to blow things up if your hook gets used in a
message somewhere.
** Timo says he'll send an announcement of some sort once details are
settled.