Maybe it was this ticket in September?
https://phabricator.wikimedia.org/T146686
I’ll try to get a full stack trace later today when I have access to the wiki again.
DanB
From: Wikitech-l [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Alex Monk
Sent: Monday, December 19, 2016 9:38 AM
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Subject: Re: [Wikitech-l] VisualEditor in 1.28 - fails after upgrade from 1.27
I feel like that sessions error was something we fixed months ago but can't
find details right now. Certainly not the first time I've seen it...
> > BadMethodCallException from line 845 of <...>/w/includes/session/
> SessionManager.php:
> > Sessions are disabled for this entry point
> >
https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-12-14
= 2016-12-14 =
== Product ==
=== Reading ===
==== iOS native app ====
* Last Week
** Finished work on 5.3.2, shipped to beta (Dynamic text size, data layer
update, performance enhancements)
https://phabricator.wikimedia.org/project/view/2281/
* This week
** Monitor 5.3.2 beta & regression testsing, fix any issues, release 5.3.2
on Thursday or Friday
** Start work on 5.4 (Nearby, Login updates)
https://phabricator.wikimedia.org/project/view/2326/
==== Android native app ====
* Last week:
** Bug fixes for new release
** Continuing Q2 goals for Wikidata descriptions
** New prod release v2.4.183
** Initial survey
** Internal test automation discussions; now over 300 unit tests in CI
* Next week (https://phabricator.wikimedia.org/project/view/2352/ ):
** More Q2 goals for Wikidata descriptions (polish)
==== Mobile Content Service (MCS) ====
* Board: https://phabricator.wikimedia.org/project/board/1323/query/open/
* Deployed:
** Updated announcements endpoint to shorten survey for Android app
(getting lots of responses)
** Caching announcement responses
* To be deployed:
** Emitted etags have double quotes now.
https://phabricator.wikimedia.org/T150886
==== Reading Web ====
* Current sprint: https://phabricator.wikimedia.org/project/view/2362/
* Last week:
** Create importable test pages that can be used to test various Reading
Web related changes https://phabricator.wikimedia.org/T137527
** Hovercards rewrite finish up
** Continue working on returning page images from the lead section only
* Until we meet next time:
** Make hovercards preferences available on the settings page
** PagePreviews reading depth
==== Reading Infrastructure ====
* API 18n patches go live this week! announcement:
https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-December/…
* starting work on TemplateStyles
* blocked:
** WMDE on the last i18n patch before we can move to hard deprecation:
https://gerrit.wikimedia.org/r/#/c/321464/
** could use some advice from Performance on dealing with huge JS data
blobs: *https://phabricator.wikimedia.org/T32574#2836570*
<https://phabricator.wikimedia.org/T32574#2836570>
** MediaViewer tests failing, mw.language tests seem to be the cause:
https://phabricator.wikimedia.org/T152476
* not blocking
=== Community Tech ===
* Blockers: None
* Blocked: Nope
* Updates:
** Created a special page report for looking at page assessment data:
https://en.wikipedia.org/wiki/Special:PageAssessments?project=History
*** Note that pagination is broken at the moment and the fix will be
deployed soon
** Converted a bunch more wikis to numeric and uca collation:
https://phabricator.wikimedia.org/T149002
** Continued work on supporting Programs Dashboard
** Bug fixes on CopyPatrol
** Work in progress for deploying Copypatrol for Czech wikipedia
** Community Wishlist Survey ended with 265 proposals and loads of exciting
proposals.
=== Editing ===
==== Collaboration ====
* Updates
** https://www.mediawiki.org/wiki/Collaboration/Deployment_planning
** Edit Review Improvements
*** New RecentChanges filters
*** Drop inconsistent filters
** Echo
*** Fixed unread notification count caching
*** Switched to extension.json
** FlaggedRevs (Collaboration team is taking more active involvement here
in support of deferred changes (
https://en.wikipedia.org/wiki/Wikipedia:Deferred_changes) project)
*** Various fixes
** ORES
*** Various fixes
==== Language ====
* Blocked:
** Performance: https://phabricator.wikimedia.org/T152180 - This is
Unbreak Now for ULS, but need moreinfo on it. Language team can't reproduce
it.
** CI/Jenkins: https://phabricator.wikimedia.org/T153038 -
mwext-qunit-jessie test fails on unrelated change(s).
** In ContentTranslation, there's a significantly larger number of
badtoken errors in saving articles lately. Did anybody notice this for
editing in general?
==== Parsing ====
* Linter extension is now in beta cluster (ex:
https://en.wikipedia.beta.wmflabs.org/wiki/Special:LintErrors )
* Services, VE, and Parsing teams collectively decided to postpone
deployment of splitting data-mw attribute from the HTML for later when it
has higher urgency since Mobile Content Service is already doing this split
on their own and no other Parsoid client wants it, and VE doesn't like it
right now.
* We are still trying to figure out whether we want to use HTML5Depurate
(Java) or a PHP version for our pilot deployment of a Tidy replacement.
* Work ongoing to parse and render language variants in Parsoid (which
includes some fixes to the PHP parser's language variant parsing as well).
Close to being finished.
=== Discovery ===
* No blockers
* Continuing work on crosswiki search and refactoring Special:Search. Load
tests OK, now doing relevancy tests.
* Refactoring query parsing to allow extensions to add search keywords
* Improved handling of characters containing diacritics or accents
* Released tabular and map data namespaces to Commons:
https://www.mediawiki.org/wiki/Help:Tabular_Data and
https://www.mediawiki.org/wiki/Help:Map_Data
* Discovery narrative and roadmap 2016-2017:
https://www.mediawiki.org/wiki/File:Discovery_narrative_FY_2016-17.pdf
== Technology ==
=== Release Engineering ===
* Blocking
** (Language) CI/Jenkins: https://phabricator.wikimedia.org/T153038 -
mwext-qunit-jessie test fails on unrelated change(s).
* Blocked
** Nothing right now
* Updates
** Reminder last week for deployments is this week until Jan 3rd:
https://lists.wikimedia.org/pipermail/wikitech-l/2016-November/086936.html
=== Security ===
* Security Reviews
** Recommendations API
** Sanitarium review
** LoginNotify
** Working on scheduling reviews for Wikidata:
*** Cognate extension: https://phabricator.wikimedia.org/T149082
*** InterwikiSorting Extension: https://phabricator.wikimedia.org/T149083
=== Services ===
* Blockers: none
* Updates:
** Trending service deployed. Some bugs were discovered and still to be
fixed
*** https://en.wikipedia.org/api/rest_v1/#!/Feed/trendingEdits
** Citoid is behind RESTBase now.
*** https://en.wikipedia.org/api/rest_v1/#!/Citation/getCitation
=== Technical Operations ===
* Alex has a conflicting meeting up, will probably make the last 10 minutes
of the meeting though
* '''Blocked'''
** CommunityTech on "Frequent duplicate key errors by page assessments"
https://phabricator.wikimedia.org/T152080
* '''Blocking'''
** None
* '''Updates'''
** API woes ongoing
** Draft goals posted, again if teams have dependencies on ops for next
Quarter, please inform us.
** Labs team is at low capacity, due to severe weather conditions in India
** There is a goal for full precise deprecation next quarter, so expect
anything precise in labs or production to have to either migrate of cease
existing
=== Performance ===
* Not blocked
* Team offsite last week. Redefined our long-term goals and short-term
projects. Cleaned up by backlog (trimmed by 16%).
https://www.mediawiki.org/wiki/Wikimedia_Performance_Team#Focus
* Experimented with Grafana 4 alerts. Available right now, use them!
== Wikidata ==
== Fundraising Tech ==
* added googleweblight to non-JS browser list
** proxy works like opera mini, runs JS server side and renders page down,
sometimes breaking it
** https://phabricator.wikimedia.org/T152602, about to deploy
https://gerrit.wikimedia.org/r/327043
* Eileen published our first real CiviCRM extension to
https://civicrm.org/extensions/unsubscribe-email-data-entry-screen
** existing extensions are all actually Drupal modules, not publicized
except in gerrit
** hope more of our code becomes widely usable
https://www.mediawiki.org/wiki/Fundraising_tech/Free_Software_Citizenship
** Katie is helping push for time in 2017 to further those goals
** If you have contacts at other non-profits that might be interested in
open source payment processing and donor relationship software, please
email fr-tech@
* more work on internal dashboard, including adding a vagrant role
=== Analytics ===
No blockers nor blocked
Updates:
* Hired a new engineer who started this week
* Worked on information architechture of wikistats2.0 with designer
contractor and Erik Z
* Worked on cleaning up our mediawiki history reconstruction scala code
The current format of MediaWiki thumbnail URLs is very ad hoc: it depends
on the media handler, the contents of the file, and a dozen different
configuration settings. As a consequence, it is impossible to guess what a
thumbnail URL will be, given the filename and the desired size; clients
have to request it from the AP and waste hundreds of valuable milliseconds,
or use complicated logic to guess it and accept that sometimes they will
end up with the wrong result.
There is an ongoing discussion about rethinking the URL format so that it
can be used as a proper API. [1] As part of that, I would like to make a
list of clients which try to guess thumbnail URLs on their own, instead of
fetching them from the API - these clients will need to be updated if we
change the URL format. If you know of any, please add them to T153498 [2],
and preferably some information on what they do. Clients can include mobile
apps, user scripts, bots, whatever you can think of.
Thanks!
[1]: https://phabricator.wikimedia.org/T66214
[2]: https://phabricator.wikimedia.org/T153498
+1 to Anna's :)
Good job everyone!
On Fri, Dec 16, 2016 at 8:10 AM, Anna Stillwell <astillwell(a)wikimedia.org>
wrote:
> :)
>
> On Thu, Dec 15, 2016 at 3:09 AM, Pau Giner <pginer(a)wikimedia.org> wrote:
>
>> Hi all,
>>
>> Some months ago we started to define a statement of purpose for design at
>> Wikimedia. We shared our initial iteration and got useful feedback. Based
>> on that feedback, we have updated a new version: https://www.mediawiki
>> .org/wiki/Design/Statement_of_purpose
>>
>> Please, feel free to check the updated version, and provide any
>> suggestion in the talk page.
>>
>> If the statement just sounds as a logical, simple, and obvious
>> description for the purpose of design here, that was the goal. Putting this
>> in writing has been helpful for designers and people working with us to get
>> into the same page, and will be useful in the future to achieve the level
>> of support for design we envision for those areas where we are not there
>> yet.
>>
>> Thanks to everyone that has contributed to the process.
>>
>> --
>> Pau Giner
>> Senior User Experience Designer
>> Wikimedia Foundation
>>
>>
>> _______________________________________________
>> Wmfall mailing list
>> Wmfall(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wmfall
>>
>>
>
>
> --
> "If you have knowledge, let others light their candles in it." - Margaret
> Fuller
>
> Anna Stillwell
> Director of Culture
> Wikimedia Foundation
> 415.806.1536 <(415)%20806-1536>
> *www.wikimediafoundation.org <http://www.wikimediafoundation.org>*
>
>
> _______________________________________________
> Wmfall mailing list
> Wmfall(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wmfall
>
>
Hi.
If I wanted to make a page on the English Wikipedia using wikitext called
"List of United States presidents" that dynamically embeds information
from <https://www.wikidata.org/wiki/Q23> and
<https://www.wikidata.org/wiki/Q11806> and other similar items, is this
currently possible? I consider this to be arbitrary Wikidata querying, but
if that's not the correct term, please let me know what to call it.
A more advanced form of this Wikidata querying would be dynamically
generating a list of presidents of the United States by finding every
Wikidata item where position held includes "President of the United
States". Is this currently possible on-wiki or via wikitext?
If either of these querying capabilities are possible, how do I do them?
I don't understand how to query Wikidata in a useful way and I find this
frustrating. Since 2012, we've been putting a lot of data into Wikidata,
but I want to programmatically extract some of this data and use it in my
Wikipedia editing. How do I do this?
If these querying capabilities are not currently possible, when might they
be? I understand that cache invalidation is difficult and that this will
need a sensible editing user interface, but I don't care about all of
that, I just want to be able to query data out of this large data store.
MZMcBride
Hello!
Recently I've worked on some MediaWiki setups with enabled "img_auth.php". During that work I've noticed a few things that I think can be improved, to make an extension developer's life easier.
I know that this feature is mostly used by private/intranet wikis, so there are only limited resources for future development available at the WMF. Therefore I'd like to volunteer to work on "img_auth.php".
Is this something the Wikimedia dev community is interested in? Can I count on some support by the original maintainers of "img_auth.php"? I'd be happy about any feedback.
Oh, and I've already created a Phabricator task: https://phabricator.wikimedia.org/T153174
--
Robert Vogel
Hello everyone,
The draft goals for the Technology and Product teams at the Wikimedia Foundation have been posted on MediaWiki for FY2016-17, Q3 (January–March) [1]
Goals for this quarter will become final the beginning of January. The Product and Technology teams regularly post draft goals a month before they are final. This email is just a reminder that we do so.
Please feel free to engage with the respective owners identified in each area for feedback or additional information before we finalize our goals. Also teams provide additional information on their respective feature pages as well.
Thank you,
Wes
[1] https://www.mediawiki.org/wiki/Wikimedia_Engineering/2016-17_Q3_Goals
Forwarding Katherine's email because this may also be of interest to
technical audiences and Wikimedia affiliates who don't subscribe to
Wikimedia-l. Also including Research-l because the strategy process
will likely be influenced by existing research, and may involve new
research initiatives.
Pine
---------- Forwarded message ----------
From: Katherine Maher <kmaher(a)wikimedia.org>
Date: Thu, Dec 15, 2016 at 6:42 PM
Subject: [Wikimedia-l] Update on Wikimedia movement strategy process (#1!)
To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org>,
"wmfall(a)lists.wikimedia.org" <wmfall(a)lists.wikimedia.org>
*(Apologies for cross posting)*
Hi all,
Since joining the Wikimedia Foundation and movement in 2014, I have often
heard community members, movement organizations, and staff members speak of
a need for a clear, unifying, and inspirational strategic direction for our
movement. These conversations tend to follow a pattern: they start by
recognizing the incredible work of our movement over the past 15 years,
while seeking clarity on what we do next. What do we want to achieve over
the next 15 years? What role do we want to play in the world? How will we
prioritize our work and resources?
At the June 2016 Board of Trustees meeting, the Board identified[1] the
development of a long-term movement strategy as one of our top priorities
for the coming year. Coming to consensus on a long-term strategic direction
will help us know where we are headed, which path we will take, and how we
will ensure our work is supported.
At the Foundation’s December metrics meeting this morning, Anna Stillwell
and Lisa Gruwell shared a presentation on the work the Foundation has done
since June to prepare for a movement strategy consultation in the coming
year.[2] We have been working to understand past Wikimedia strategy
efforts, estimate future budgets and timelines, and secure resources for
the year to come. In this email, I want to present some additional detail
on this progress, and next steps we can take together.
(*Fair warning: this is a very long email.* The critical information is as
follows: The Wikimedia Foundation Board has approved a spending resolution
and timeline for the upcoming strategy work. We anticipate beginning broad
community conversations on the process, goals, and themes in early 2017.
The Foundation is looking for an external expert to work with us (community
and staff) to support an effective, inclusive process. I’ve been remiss in
regular updates, but we will share them going forward. And of course,
please share your thoughts and feedback on this list and on Meta [3].)
*Strategic direction*
We are expecting that we will begin a movement-wide strategy discussion in
early 2017, with a process that runs throughout the year. The goal is to
close 2017 with clarity and consensus on a strategic direction for our
movement, and begin planning for how we will make progress in that
direction.
We are currently doing good work across our movement, but lack a unifying
sense of how that work coheres into something greater than its individual
parts. Wikipedia and the sister projects are remarkable, and our community
is responsible for their success. Our movement has done an incredible job
spreading our values and principles around the world—but we often look
backwards to improve on our past, rather than looking fully at both our
past and future. There’s an opportunity for us to consider how our vision
and mission will remain current amidst changing media, demographics, and
technology, and how we can better coalesce our efforts (ecosystem of
affiliates, users, experts, new users, cultural and educational
institutions, and the Wikimedia Foundation).
Additionally, we (community, affiliates, Board, and staff) are increasingly
aware of the challenges which arise without a unified movement strategy. We
have heard from members of the FDC, grant applicants, community leaders,
and a growing number of affiliates that they at times struggle with
understanding how our separate efforts tie together and where we are going
as an overall movement. The absence of a movement strategy, in other words,
is hampering our ability to work toward our mission. Given the importance
of that mission, and the need to hold ourselves to the highest account on
responsible stewardship of donor resources, this is an expensive
opportunity cost.
*Budget*
At the June Board meeting, I committed to develop a proposed process and
budget in time for the Board’s annual November Board retreat. This process
would reflect the type of approach we might take, and be accompanied by an
estimated budget for the associated work.
To prepare, we wanted to understand past efforts at developing strategies
for our movement. We audited these past processes (2010, 2012/Narrowing
Focus, 2014, and some other efforts) and interviewed past participants to
learn what worked and what did not,[4] and took stock of what was
missing—from external expertise to audience research—to clear ownership of
outcomes.
We recognized that, for example, while the 2010 process was highly
collaborative, it had some notable challenges. For example, it was unable
to turn collaborative goal setting into shared ownership of the work needed
to reach those goals. It also did not have strong participation from
emerging communities, particularly those in countries outside of Europe and
North America. For movement planning to succeed in the future, we will need
both broad and deep participation, from various perspectives and languages.
To consider how we could realize this level of meaningful consultation, we
spoke to people in the Foundation’s Community Engagement team and
elsewhere, taking recommendations on everything from community toolkits and
convenings to multilingual translation.
Past processes have also often focused on qualitative perspectives, usually
of our existing communities of editors and readers. We have had limited
ways of understanding how broadly representative these experiences, needs,
and challenges were, even for our existing communities. We have tens of
thousands of editors, but even in our most collaborative effort in 2010,
only 2,000 people contributed to the strategic discussions. Similarly, we
have limited research about why and how people around the world use and
engage with the Wikimedia projects as non-editors—and our understanding
about what keeps people from using the projects, as editors or non-editors,
is highly qualitative.
As we engage in the consultation going forward, we see an opportunity to
bring substantive audience-based research into our discussion, to inform
our possibilities and challenges with good data. We worked with the Global
Reach team, and staff from the New Readers and Audience Research projects
to scope out qualitative and quantitative audience research in new,
emerging, and existing editor and reader communities, and estimate
associated budgets. And while we see this as an exciting opportunity to
incorporate new data into our conversations, we also expect it to have
lasting value beyond the coming year. Good audience research and data will
help inform not just strategy discussions, but also should be helpful for
Foundation and other product and programming decisions now and in the
future.
And of course, we are not alone in the world! We exist in an ecosystem of
people who use, reuse, and remix the knowledge on the Wikimedia projects in
all sorts of ways. We have a strong and growing community of institutions
and partners in education, government, culture, and the sciences. We also
have many technical partners and re-users who have a vested interest in our
health. These stakeholders offer valuable insight into how our work extends
into the world, well beyond the sites we run. We want to talk to them,
understand the opportunities they see in the future, and the challenges
they face today. We want to speak to people working at the edge of
innovation in technology, to better understand how these trends affect our
future, and to engage them in our mission.
And last, but certainly not least, these discussions, collaborations, and
conclusions need to be open and consultative. We want to work together to
design a process of consultation, with opportunities for on-wiki
conversation, face to face meetings, working groups, and more. In some
cases, this may mean new conversations, and in others, we may want to bring
additional capacity and participation to already scheduled community
events. We will need additional resources for multilingual facilitation, or
documentation. We will also need additional capacity to support these
discussions, so that community and staff alike can retain their focus on
the programs, grants, and product work to which they have committed.
We want to bring this to life. But before we could commit to this approach,
we needed to be sure we could assemble the appropriate resources to make it
happen. Based on our research into past processes, best practices, and
conversations with community and staff—we built a high-level estimated
budget with resources for the following: inclusive, multilingual community
consultation on-wiki and in-person; research into our users, new users, and
consultation with external experts and stakeholders; and additional
external capacity for management and production of the process. All in, we
estimate that the full scope of work over 1.5 years will cost somewhere
around US$2.5 million. This is divided out roughly as 35% support for
direct community participation, 35% support for audience research and
understanding external ecosystems, and 30% support for facilitation and
external support.
I know this sounds like a lot! As we break it down into budget lines, it
starts to become more tangible. This estimated budget was developed in
close consultation with the Community Engagement, Global Reach, and Finance
teams. We worked with the Community Engagement team to use their models for
community events and facilitation to budget for additional support and
participation in community events. We worked with the Global Reach team to
estimate the costs of qualitative and quantitative research around the
world. And we worked with the Finance teams to understand hourly rates for
non-profit strategic consultancies (finding that, even with non-profit
organizations our commitment to meaningful consultation quickly added many
hours to our planning).
An overview of this budget estimate was presented to the Board at the 13
November Board meeting. There the Board approved a spending resolution of
up to $2.5 million over Fiscal Year 2016-17 (July 2016 - June 2017) and
Fiscal Year 2017-18 (July 2017 - June 2018). We are currently working to
migrate this proposed budget into a format similar to the one we use for
Annual Planning, for the purpose of consistency and clarity of review. This
detailed budget, tied to specific events, contracts, and research areas,
will be shared with to the Foundation Board’s Audit Committee[5], and with
the greater communities for feedback.
*Assembling a team*
To increase our likelihood of success, we want to bring additional capacity
and expertise to the table. No single Wikimedia Foundation department or
Wikimedia movement affiliate currently has the complete skillset or
available capacity to independently manage a strategy process of this size
and scale. Our goal is to find an external entity with experience in
organizational or movement strategies to help move us all (affiliates,
current users, new users, experts, cultural and educational institutions,
community committees, and Wikimedia Foundation) toward collaborative
development of a movement strategy, and assembling a team to support this
process.
Practically, this means finding an entity capable of recommending a
strategic approach, identifying necessary inputs (e.g., user research or
sector mapping) to inform meaningful consultation and decision making,
making timely process against deadlines, and helping ensure the delivery of
the final work. We’re referring to this role as the “lead architect,”
although it is likely to be a team, rather than an individual.
We recognize that several individuals in our community already possess
significant expertise in strategic planning, and we hope you will
contribute your talents to the shape and content of the discussion. We also
recognize it can be difficult to both facilitate a conversation and
contribute to it at the same time. To help alleviate procedural and
operational pressures on community contributors, and enable people to
participate in primarily strategic and generative roles, we expect the lead
architect and team will work closely with existing community and staff
liaisons and advocates to support discussions as facilitators. They will be
expected to support any community and Wikimedia Foundation bodies involved
in the development of strategy.
Last month, I asked Lisa Gruwell, Anna Stillwell, and Guillaume Paumier to
begin a search for this external capacity. They spoke with a number of
smaller organizations—a deliberate choice, to find someone who could be
flexible and open to our needs—and put together a request for proposal
(RFP) for interested firms. The minimal criteria for the lead architect is
someone who:
- Has created successful strategies before (organizational or movement
strategies, rather than just a strategy for a department, a program, or a
product)
- Has proposed a coherent outcome and understands the need to build an
incredibly inclusive process
- Is willing to be paired with a full-time partner/advisor who knows the
movement well
- Has significant nonprofit experience
- Has significant international experience
- Understands that Wikimedia communities are passionate! There will be
an occasional raucous[6] debate. They must be willing and able to have
difficult conversations (difficult in substance, but not in tone).
Although we spoke to many firms that were interested, some were unable to
mobilize resources on our timeline. Others we didn’t feel were the right
fit. In the end, we received two viable responses. We are hoping to make a
decision by the end of this or next week.
We recognize that our movement, mission, and culture are wonderfully
idiosyncratic. While we know we need external skills in the area of
movement strategies, we also know that any external organization will need
extensive support understanding our movement values, culture, history, and
projects.
We are proposing pairing any external consultants with community and staff
members who have deep community experience as guides, translators, and
mentors. We don’t know exactly how we will work yet, or who will be
interested in playing these roles. This is one question of many we will
need to answer together.
*Next steps*
All the resource and planning progress in the world doesn’t get us far
without community conversation. Beyond the budget, the decision to bring in
additional expertise, and the timeline of the coming year, we don’t have
many more concrete details at this point. That’s intentional. We are
committed to developing the specifics in partnership with you as we move
forward.
We also recognize we are embarking on something new. We’re proposing a
model that, while based on research, past experience, extensive
conversations, and a detailed budget—may not be perfect. We welcome the
ideas you bring to make it stronger. We anticipate we will work in the
open, communicate among ourselves regularly, pause along the way to assess
our progress, and course-correct as necessary. This will be part of
building together.
Additionally, we’ll be providing regular documentation via email, and
adding it to Meta-Wiki.[7] If you would like to receive updates via your
user talk page, you can do so by signing up on Meta-Wiki.[8]
If you’ve made it this far, thank you for reading. I imagine this is the
start of many conversations. I look forward to them.
Thank you!
Katherine
PS. An on-wiki version of this message is available for translation:
https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2017/Updates/15…
[1] https://lists.wikimedia.org/pipermail/wikimedia-l/2016-June/084627.html
[2]
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_metrics_and_activities…
[3] https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2017
[4]
https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2017/Audit_of_p…
[5] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Audit_Committee
[6] https://en.wiktionary.org/wiki/raucous
[7] https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2017
[8]
https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2017/Updates/Si…
--
Katherine Maher
Wikimedia Foundation
149 New Montgomery Street
San Francisco, CA 94105
+1 (415) 839-6885 ext. 6635
+1 (415) 712 4873
kmaher(a)wikimedia.org
_______________________________________________
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>