FYI
We are headed into the season of vacations and high risk fundraising, as
such, the WMF is (I am) putting in place "deployment freezes" for a few
weeks over the next seven. See full details below and on the Deployments
page on wikitech.
Greg
----- Forwarded message from Greg Grossmeier <greg(a)wikimedia.org> -----
> Date: Wed, 25 Nov 2015 08:19:26 -0800
> From: Greg Grossmeier <greg(a)wikimedia.org>
> To: Development and Operations engineers <engineering(a)lists.wikimedia.org>, Operations Engineers <ops(a)lists.wikimedia.org>
> Cc: Katie Horn <khorn(a)wikimedia.org>, Megan Hernandez <mhernandez(a)wikimedia.org>
> Subject: Deploy freeze(s) in effect for the next 7 weeks (ish, read for more details)
>
> A reminder of the upcoming deployment freezes. All details, of course,
> can always be found on the Deployments[0] page on wikitech; it is the
> canonical location for all deployment freeze (and exception)
> information.
>
>
> FTR: "High Priority" means security and data loss, really. There may be
> other exceptions but they need pre-approval from at least myself and
> sometimes Katie.
>
>
> * Week of Nov 23rd: No normal deploys - high prioity SWATs only
> (pre-approval from Greg needed) (Why: Thanksgiving)
>
> * Week of Nov 30th: No normal deploys - high prioity SWATs only
> (pre-approval from Greg and/or Katie needed) (Why: First of Dec
> Fundraising)
>
> * Week of Dec 7th: Normal deploy week
>
> * Week of Dec 14th: Normal deploy week
>
> * Week of Dec 21st: No normal deploys - high prioity SWATs only (and
> only on Monday and Tuesday) (pre-approval from Greg and/or Katie needed)
> (Why: End of year Fundraising)
>
> * Week of Dec 28th: No normal deploys - high prioity SWATs only
> (pre-approval from Greg and/or Katie needed) (Why: End of year
> Fundraising)
>
> * Week of Jan 4th: No normal deploys - high prioity SWATs only
> (pre-approval from Greg needed) (Why: DevSummit16 and WMF All Hands)
>
> * Week of Jan 11th: Resume normal deploy schedule
>
>
> Thanks and enjoy the break from breakages (hopefully!),
>
> Greg
>
> [0] https://wikitech.wikimedia.org/wiki/Deployments
>
> --
> | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
> | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
----- End forwarded message -----
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hey all,
Starting in January 2016, MediaWiki will end JavaScript support for
Microsoft Internet Explorer 8. This raises the cut-off up from MSIE 7.
Users with this browser will still be able to browse, edit, and otherwise
contribute to the site. However, some features will not be available to
them. For example, the enhanced edit toolbar will not appear, and the
notification buttons will take you to a page rather than a pop-out.
This change will affect roughly 0.89% of all traffic to Wikimedia wikis (as
of October 2015). For comparison, 0.33% of traffic comes from Internet
Explorer 6, and 1.46% from Internet Explorer 7. Support for these was
dropped in August and September 2014 respectively.
Providing JavaScript for IE 8 adds a significant maintenance burden. It
also bloats the software we ship to all users, without proportionate
benefit. This enables us to simplify and streamline the JavaScript codebase
for all other users. Users unable to upgrade from Internet Explorer 8 will
have a faster experience going forward, based on well-tested and more
stable code.
This change will land in the development branch in January, and so will be
part of MediaWiki 1.27 (to be released around May 2016).
Tech News will announce this change as well, but please help carry this
message into your communities. In January, we will send a reminder before
the change happens.
Yours,
-- Krinkle
For details about the JavaScript-less experience, see
https://www.mediawiki.org/wiki/Compatibility
Hi, this is an update on the work we in the Collaboration team are
doing. Our focus is on cross-wiki notifications and other back-end
improvements to that system.
Our long-term goals are to make various improvements to the Notification system.
Notifications are at the core of many different on-wiki activities.
Making notifications easy to find and use can help those processes. We
are focusing our immediate plans on supporting cross-wiki
notifications. These will help editors stay informed about the changes
they care about on every Wikimedia project on which they work. This is
especially important for the editors who work on more than one wiki.
Examples include if you upload to Commons, curate on Wikidata, or edit
in two or more languages.
The team has spent the last few weeks researching the existing and
proposed features. This has included examining existing tools such as
Crosswatch. We've been considering the problems of:
* technical performance (scaling the requests across 800+ wikis),
* user preferences (both existing and desired),
* user interface design possibilities (how it should work),
* how to release an initial, user-testable version for feedback and
improvement, and
* how to measure the impact of the project (reducing the time it takes
to process a notification).
We are also doing user research via 1-on-1 interviews. In these we ask
active editors about their current notification usage and pain-points.
Using a prototype we are evolving, we get feedback on directions to
take the design.
== Details and further reading ==
You can read more about the technical details at:
https://www.mediawiki.org/wiki/Requests_for_comment/Cross-wiki_notifications
.
Some of the new backend improvements to Echo:
https://phabricator.wikimedia.org/T107823 ("Rewrite
EchoNotificationFormatter") and linked tasks.
User preference options are:
* https://phabricator.wikimedia.org/T117670 ("Define Cross-wiki
Notifications settings")
User interface design possibilities cover several questions. For
example, how should cross-wiki notifications look within the pop-up?
How and when should we add enhancements to the Special:Notifications
page to filter things? We are drafting and discussing these in:
* https://phabricator.wikimedia.org/T114357 (Clarifications to the
currently confusing "primary/secondary" link, and proposed future
enhancements)
* https://phabricator.wikimedia.org/T114356 (Bundled notifications)
* https://phabricator.wikimedia.org/T115264 (Controlling notification
'volume' based on the type or location)
* https://phabricator.wikimedia.org/T115845 (Clearer use of the
notification badges (coloured number in personal toolbar))
* https://phabricator.wikimedia.org/T115316 (Better organization of
the Special:Notifications page)
Note: Most of these are not part of the cross-wiki notifications
feature. We won't for sure roll all these out together with the main
change.
We started user research at https://phabricator.wikimedia.org/T114086
and it continues at https://phabricator.wikimedia.org/T116741 . (Note:
You can sign-up as a volunteer at https://wikimedia.org/research .)
A user-testable release is still just in planning. We decided on a
Beta Feature on each wiki as the most scalable and least confusing of
all the do-able options. Read our plans in
https://phabricator.wikimedia.org/T114237 ("Present cross-wiki
notifications as a beta feature to users"). This will help users to
try the feature anytime, disabling it if it interferes with their work
in some context, and easily suggest how the tool could be improved.
There is no system for users having or setting cross-wiki preferences.
Waiting to building this would take a long time. For now, we plan to
let you enable the Beta Feature at each wiki on which you want to test
it. This will let you have a small-scale Beta Feature that you can all
try out. We will be able to discover bugs, edge-cases, iterate more,
and get even more feedback. Later, when we know what features you
need, we can build such a cross-wiki preferences system (including the
task linked above).
Whilst you wait, we would love to hear your feedback on the above.
What comments, what design ideas, and what technical concerns do you
have? Please tell us on the linked tasks if you can.
I'll send further updates, when the planned Beta Feature is about to be ready.
On behalf of the Collaboration team, thank you to everyone who has
given your help already.
--
Nick Wilson / Quiddity
Superprotect [1] was introduced by the Wikimedia Foundation to resolve a
product development disagreement. We have not used it for resolving a
dispute since. Consequently, today we are removing Superprotect from
Wikimedia servers.
Without Superprotect, a symbolic point of tension is resolved. However, we
still have the underlying problem of disagreement and consequent delays at
the product deployment phase. We need to become better software partners,
work together towards better products, and ship better features faster. The
collaboration between the WMF and the communities depends on mutual trust
and constructive criticism. We need to improve Wikimedia mechanisms to
build consensus, include more voices, and resolve disputes.
There is a first draft of an updated Product Development Process [2] that
will guide the work of the WMF Engineering and Product teams.[3] It
stresses the need for community feedback throughout the process, but
particularly in the early phases of development. More feedback earlier on
will allow us to incorporate community-driven improvements and address
potential controversy while plans and software are most flexible.
We welcome the feedback of technical and non-technical contributors. Check
the Q&A for details.[4]
[1] https://meta.wikimedia.org/wiki/Superprotect
[2] https://www.mediawiki.org/wiki/WMF_Product_Development_Process
[3] https://www.mediawiki.org/wiki/Wikimedia_Engineering
[4]
https://www.mediawiki.org/wiki/WMF_Product_Development_Process/2015-11-05#Q…
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
