Hello,
We had a short downtime of CI between roughly 3am and 9am UTC that
caused roughly 2/3 of triggered jobs to fail cloning.
The reason is we deployed additional zuul-merger instances (which takes
your patches, merge it on tip of branch and then expose the result to
jobs) but the git-daemon exposing the repositories was not started.
I respawned the git-daemon and it all works properly now. I am doing a
recheck and CR+2 again all patches that got affected.
Reference: https://phabricator.wikimedia.org/T157785
cheers,
--
Antoine "hashar" Musso
We're in progress of deploying a small change to the video scalers[1],
which should improve availability of newly uploaded video and audio files.
The queue will now be split in two, one which covers low-resolution
conversions for relatively short files, and one which covers long files and
high-resolution conversions. When there's a flood of large uploads, other
new files should still go through the high-priority queue while the large
uploads and HD conversions may back up on the low-priority queue.
The queue-runner side is updated now (done during the 'puppet SWAT'
deployment window), with the MediaWiki side ready to roll around 19:00 UTC
(11am Pacific time, regular SWAT deployment window).
[1] https://gerrit.wikimedia.org/r/#/c/336846/
-- brion
Hey,
Today I was checking mediawiki/core in github:
https://github.com/wikimedia/mediawiki
And number of contributors is now 400. It might be a little more if we
count SVN era.
To me, it's an important milestone. More important than number of commits
or releases. It's about people not numbers or lines of code.
Best
Please take this as a final opportunity to do review/suggest
changes/etc. to the Amendments section of the draft Code of Conduct.
This text has been up for a while, but I recently put in a small
proposed change to make it harder for the Committee to veto amendments.
This is the last section. After it's approved, the Code of Conduct will
become policy, and the Amendments section will specify how future
changes to the policy work.
* Current text:
https://www.mediawiki.org/w/index.php?title=Code_of_Conduct/Draft&oldid=238…
(under "Page: Code of Conduct/Amendments")
* Discussion:
https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#New_proposal_for_…
The approval discussion hasn't started yet. It will be next and I will
send out a separate email.
Thanks,
Matt Flaschen
P.S. You can still participate in deciding whether to approve "Creation
and renewal of the Committee" at
https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Finalize_.22Creat…
.
Forwarding.
Pine
---------- Forwarded message ----------
From: Victoria Coleman <vcoleman(a)wikimedia.org>
Date: Tue, Feb 7, 2017 at 9:22 PM
Subject: [Wikimedia-l] Wikimedia Cloud Services: new team, new name,
renewed focus
To: wikimedia-l(a)lists.wikimedia.org
Hello everyone,
Starting in April 2017, we will be taking a number of projects related to
services we are offering "in the cloud" and creating a new team, Wikimedia
Cloud Services (WMCS), to support a more unified approach to these efforts.
The sub-teams currently managing these efforts - the Labs sub-team within
the Wikimedia Technical Operations team and the Tool Labs support sub-team
from the Community Tech team - will be merged to form this new team.
Wikimedia Cloud Services will be a new team in the Technology Department of
the Wikimedia Foundation reporting to Victoria as the Foundation's Chief
Technology Officer (CTO). This team is being formed based on a proposal
made by the members of the Labs sub-team and the Tool Labs support sub-team.
The new team will be managed by Bryan Davis, who previously managed the
Reading Infrastructure and Community Tech teams before helping found the
Tool Labs support team in 2016. Chase Pettet, formerly manager of the Labs
team, is taking on the new role of Lead Operations Engineer. Andrew Bogott,
Yuvaraj Pandian, and Madhumitha Viswanathan are transferring in their
existing roles from the former Labs team.
The WMCS team will maintain and extend the existing Wikimedia Labs
infrastructure as a service platform, the Tool Labs platform as a service <
https://en.wikipedia.org/wiki/Platform_as_a_service> project, and many
additional supporting technologies used in the cloud environment. The new
team is excited to continue supporting developers who create innovative
solutions to further the free knowledge movement, and will continue to
partner with the larger Wikimedia volunteer community to manage the
physical and virtual resources that power the environment and provide
technical support to volunteer developers and other Wikimedia Cloud
Services users.
This new team will focus on three areas of ongoing support and improvement:
Providing a stable and efficient hosting platform
Creating and maintaining services that empower the creation and operation
of tools
Delivering technical and community support for users of the products
This new team will soon begin working on rebranding efforts intended to
reduce confusion about the products they maintain. <
https://wikitech.wikimedia.org/wiki/Labs_labs_labs> This refocus and
re-branding will take time to execute, but the team is looking forward to
the challenge.
Stay tuned for more announcements, and as always Community members are
encouraged to participate on labs-l(a)lists.wikimedia.org, <
https://phabricator.wikimedia.org/project/profile/832/>Phabricator and the
#wikimedia-labs IRC channel.
Thank you,
Victoria & Wes
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
wiki/Wikimedia-l
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>
Hola hive,
We are in the process of submitting Wikimedia's application for Google
Summer of Code 2017 <https://developers.google.com/open-source/gsoc/>
and Outreachy
Round 14 <https://www.mediawiki.org/wiki/Outreachy>.
Do you have any projects in mind that you would like to mentor?
Do you find anything interesting in the Possible Tech Projects
<https://phabricator.wikimedia.org/tag/possible-tech-projects/> or the
Community
Wishlist: Not-top-ten wishes (need-owner) column
<https://phabricator.wikimedia.org/project/board/2420/> on the Phabricator
workboard?
If you are interested, I will encourage you to add the following project
tag(s) to a task on Phabricator: *#Google-Summer-of-Code-2017* or
*#Outreachy-Round-14* and *#Outreach-Programs-Projects*. And, we'll take it
from there :)
For both programs, the student application period will start on February
16th (Outreachy) and February 27th (GSOC). Students will work on projects
between May and August.
Cheers,
Srishti
--
Srishti Sethi
Developer Advocate
Technical Collaboration team
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:SSethi_(WMF)
Hello Wikitext-l,
-----------------------------------
TL;DR: The Wikidata team is considering to use a MVVM/Single-State solution
for Wikidata’s UI. What are requirements and concerns would be important to
consider?
-----------------------------------
Wikidata’s current UI is built on jQuery UI. Since jQueryUI shall be faded
out, we are looking at possible future frameworks or paradigms to build our
UI on. Our needs are:
- Having a sustainable foundation
- Being able to handle complex state dependencies (simplest are like: "if
element x is in edit mode, set element y to saving mode")
- A solution that is easy to learn for beginners and easy to read and
reason about for our engineers.
State management and data/event propagation goes beyond of what OOUI can
provide, as far as I (Jan) know. So an obvious candidate was looking into
MVVM solutions of which the most well known is the React library.
We had a deeper look at Vue.js which is known for having a large community,
too, but being easier to understand and not using an additional patent
clause in its licensing.
We see the following possible advantages:
- Better modularization
- understandability of our code, in particular reasoning about event- and
data-flow
- better separation of concerns and testability for:
-- HTML templates
-- Component interactivity
-- Data manipulation
-- connection to backend-API
- If we use a well documented framework, learning to contribute is much
easier compared to software for which there is only auto-generated
code-level-docs
Here are some answers to obvious questions:
1) Does using a MVVM mean we need to write mixed JS/CSS/HTML in a new
syntax? (aka JSX)? -> No, it is possible, but for most frameworks (Vue,
too) normal HTML templates are used
2) Does that mean that people coming from Object oriented languages will
need to learn a whole new paradigm – reactive, pure-functional programming?
-> While there are some elements of functional programming used in
react-like-frameworks, I would (subjectively) say that few additional,
totally new knowledge is needed and most can be covered by "take
parameters, work with them, return values; don't manipulate non-local
values"
3) How does DOM access work? Does this mean no jQuery?
-> DOM can be still be directly accessed. Libraries like jQuery can still
be reused (even if they might not be necessary in many points any more).
However, to change data or dom persistently, you need to tell the library
(which is not unusual, afaic)
There are also some other concerns:
- Should we introduce a new dependency like a framework as Vue?
- What would be the process of introducing such a dependency (if we agree
on one)?
- Can we agree on this (or another?) paradigm for managing complex UIs, so
that it is not a Wikidata-only solution, but could be used by other
Wikimedia projects in the future, too?
- How will this work with OOUIjs? OOUI seems to be mainly responsible for
creating DOM elements and this actions are usually owned by the MVVM
framework. One can use hooks to use libraries like OOUI and such, but it
feels like having the same functionality twice. A possible solution would
be using OOUI styles and markup but leaving DOM creation to the framework.
Do you think using Vue (or a similar framework) is an option for us? What
are requirements and concerns which would be important?
Kind Regards,
Jan
--
Jan Dittrich
UX Design/ User Research
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0
http://wikimedia.de
Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.