[Wikitech-l] Re: Wiki content and other dumps new ownership, feedback requested on new version!

[Steven Walling]

+1 to Dan. Ariel thank you for so many years of doing this essential work.

On Thu, Sep 28, 2023 at 4:14 AM Dan Andreescu 
wrote:

> Ariel, your dedication to dumps has always been an inspiration to me, both
> in how you handled the technology and how you fused that with your care for
> the ideas behind it.  Thank you, and hope we can do it justice with the
> next phase of Dumps.
>
> On Thu, Sep 28, 2023 at 12:39 AM Ariel Glenn WMF 
> wrote:
>
>> Hello folks!
>>
>> For some years now, I've been the main or only point of contact for the
>> Wiki project sql/xml dumps semimonthly, as well as for a number of
>> miscellaneous weekly datasets.
>>
>> This work is now passing to Data Platform Engineering (DPE), and your new
>> points of contact, starting right away, will be Will Doran (email:wdoran)
>> and Virginia Poundstone (email:vpoundstone). I'll still be lending a hand
>> in the background for a little while but by the end of the month I'll have
>> transitioned into a new role at the Wikimedia Foundation, working more
>> directly on MediaWiki itself.
>>
>> The Data Products team, a subteam of DPE, will be managing the current
>> dumps day-to-day, as well as working on a new dumps system intended to
>> replace and greatly improve the current one. What formats will it produce,
>> and what content, and in what bundles?  These are all great questions, and
>> you have a chance to help decide on the answers. The team is gathering
>> feedback right now; follow this link [
>> https://docs.google.com/forms/d/e/1FAIpQLScp2KzkcTF7kE8gilCeSogzpeoVN-8yp_SY6Q47eEbuYfXzsw/viewform?usp=sf_link]
>> to give your input!
>>
>> If you want to follow along on work being done on the new dumps system,
>> you can check the phabricator workboard at
>> https://phabricator.wikimedia.org/project/board/6630/ and look for items
>> with the "Dumps 2.0" tag.
>>
>> Members of the Data Products team are already stepping up to manage the
>> xmldatadumps-l mailing list, so you should not notice any changes as far as
>> that goes.
>>
>> And as always, for dumps-related questions people on this list cannot
>> answer, and which are not covered in the docs at
>> https://meta.wikimedia.org/wiki/Data_dumps or
>> https://wikitech.wikimedia.org/wiki/Dumps you can always email ops-dumps
>> (at) wikimedia.org.
>>
>> See you on the wikis!
>>
>> Ariel Glenn
>> ar...@wikimedia.org
>> ___
>> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
>> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
>>
>> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
>
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Book creation

[Steven Walling]

On Feb 15, 2023 at 3:45:23 PM, Samuel Klein  wrote:

> I ran across another reference to our lovely, important book creation
> tools of yore, on a global Open Education forum
> 
> .
>
> What is the best place to discuss the broad, important version of this?
>  * How we support conversion to standalone formats, for reading and
> printing
>  * Clarity for Dirk (M2L ),
> PediaPress, the PDF-feature
> team, and
> other maintainers
>
> This is important to a wide range of reuse, and the uncertainty around
> what is possible, what is planned, and what is desired by various audiences
> makes it hard to make progress even when it's obvious that is important.
>

Why is it important if virtually no one used it over the years it was
available? The forum itself points out that very few people ever used these
tools. (I was one of them back in the day, and it worked ok but the use
cases were super limited, and that was true even a decade ago when
smartphones were far less ubiquitous globally.)

Generating a series of print/PDF format articles from the browser is 80% as
good with far less effort. We should take all of the engineering resources
it would require to resurrect investment in the Book creator, and instead
apply them to things like a 10X better offline reader mode for Wikipedia
apps and making sure that our apps and mobile website work incredibly well
on lower end devices. Both of those things would be much higher impact for
reaching readers who might have limited connectivity and therefore find
utility in alternative ways to access content.


>
>
>
>
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
>
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

Re: [Wikitech-l] Logging everyone out

[Steven Walling]

Good to know it was so few people. Thanks for your diligence as always.

On Thu, Jun 25, 2020 at 10:57 PM Tim Starling 
wrote:

> On 26/6/20 3:26 pm, Steven Walling wrote:
> > Thanks Tim,
> >
> > 1. Does “saw the site” mean users actually had full or partial access to
> > the accounts of other users, or simply were viewing a cached version of
> the
> > site that appeared as if they were logged in as someone else?
>
> Users reportedly had full access to the accounts of other users.
>
> > How many users were impacted?
>
> We had three reports. We've added logging which should help to
> determine whether anyone else was affected. So far, the indications
> are that it is an extremely rare event.
>
> > 2. Does the WMF hold incident review meetings and publish reports about
> > what steps are taken to prevent repeat incidents with the same root
> cause?
>
> Incidents are documented at
> <https://wikitech.wikimedia.org/wiki/Incident_documentation>
>
> Action items are tagged with the Incident Prevention tag in Phabricator:
> <https://phabricator.wikimedia.org/project/view/4758/>
>
> Whether there is an incident review meeting depends on the nature of
> the incident.
>
> -- Tim Starling
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Logging everyone out

[Steven Walling]

Thanks Tim,

1. Does “saw the site” mean users actually had full or partial access to
the accounts of other users, or simply were viewing a cached version of the
site that appeared as if they were logged in as someone else? How many
users were impacted?

2. Does the WMF hold incident review meetings and publish reports about
what steps are taken to prevent repeat incidents with the same root cause?

On Thu, Jun 25, 2020 at 7:44 PM Tim Starling 
wrote:

> Everyone on Wikimedia wikis will shortly be logged out and will have
> to log back in again.
>
> We are resetting all sessions because we believe that, due to a
> configuration error, session cookies may have been sent in cacheable
> responses. Some users reported that they saw the site as if they were
> logged in as someone else. We believe that the number of affected
> users was very small. However, we believe that resetting all sessions
> is a prudent measure to ensure that the impact is limited.
>
> There are several layers of protection against something like this
> happening, and we don't yet know how all of them failed, but we have
> made a configuration change which should be sufficient to prevent it
> from happening again.
>
> -- Tim Starling
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Please comment on the draft consultation for splitting the admin role

[Steven Walling]

I'm definitely supportive of greater security for sitewide JS/CSS, but
Bart's proposal is an interesting one. (Sorry for top posting, on mobile)

What if we required review of edits to JS/CSS in the MediaWiki namespace
(not in other namespaces), ala pending changes or something similar? We
require code review in Gerrit, so why not sitewide code in the wiki?

I propose this because if we split code editing rights into a separate
userright, this entails increased process bloat for managing who and who
doesn't get the right, the criteria for deciding that, and so on. Requiring
code review would allow for more flexibility while increasing security. It
would require less process bloat too because the community already has
mechanisms for requesting edits be confirmed via talk pages and such.

On Mon, Jun 11, 2018 at 8:15 AM Bart Humphries 
wrote:

> " I remember a situation when I posted a fix for a script in the
> MediaWiki namespace
> as an {{edit request}}, and a well-meaning administrator tried to "improve"
> my line of code and forgot a comma, breaking all JavaScript for all
> logged-in as well as not logged-in Wikipedia editors and readers for some
> painful minutes"
>
> Everyone makes mistakes.  I presume that under this revised proposal, that
> administrator would still have had JS edit permission, and might have still
> made the mistake.  I mean, they apparently knew JS well enough to have been
> able to pass whatever test would have been required to get that permission
> added to their account.
>
> Perhaps we need a real test environment of some sort, so that changes like
> that must be run on the test server for X [time period] before being pushed
> to live?  Changes can't happen on live until there's some sort of consensus
> that the test code actually works as run -- any additional changes reset
> the test time period counter before it can be pushed to live.
>
> Bart Humphries
> bart.humphr...@gmail.com
> (909)529-BART(2278)
>
> On Mon, Jun 11, 2018 at 7:40 AM, Thiemo Kreuz 
> wrote:
>
> > > Is there any historical evidence that sysops being able to edit JS /
> CSS
> > caused some serious issues?
> >
> > Oh yes, this happens more often than I feel it needs to. I remember a
> > situation when I posted a fix for a script in the MediaWiki:…
> > namespace as an {{edit request}}, and a well-meaning administrator
> > tried to "improve" my line of code and forgot a comma, breaking all
> > JavaScript for all logged-in as well as not logged-in Wikipedia
> > editors and readers for some painful minutes.
> >
> > I believe such can be avoided with more clear roles that are visible
> > for everybody. A separate "tech admin" role would also allow
> > volunteers to apply for exactly that, and not be asked why they don't
> > do enough "administrator actions" with their privileges.
> >
> > Sure, this is anecdotal evidence. Please forgive me, but I currently
> > don't have the time to find the pages documenting these situation.
> >
> > Best
> > Thiemo
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikistats gets a facelift - Alpha Launch of Wikistats 2

[Steven Walling]

This is an amazing improvement. Great work!

On Thu, Dec 14, 2017 at 12:41 PM zppix e  wrote:

> Great Work I love the design. Can't wait for finished product!
>
> --
> Zppix
> Volunteer Wikimedia Developer
> Volunteer Wikimedia GCI2017 Mentor
> enwp.org/User:Zppix
> **Note: I do not work for Wikimedia Foundation, or any of its chapters.**
>
> > On Dec 14, 2017, at 1:17 PM, Jonathan Morgan 
> wrote:
> >
> > This is fabulous! Thank you, Erik Zachte, Analytics team, and everyone
> else
> > involved in this project for giving us the powerful, usable stats
> dashboard
> > we deserve :)
> >
> > - J
> >
> > On Thu, Dec 14, 2017 at 5:10 AM, Niharika Kohli 
> > wrote:
> >
> >> This is awesome. Great job A-team!
> >>
> >> On Thu, Dec 14, 2017 at 12:12 PM, Victoria Coleman <
> vcole...@wikimedia.org
> >>>
> >> wrote:
> >>
> >>> Nuria and team, fabulous work!  Wikistats 2 is such a huge improvement!
> >>> Thank you!
> >>>
> >>>
> >>> Best wishes,
> >>>
> >>> Victoria Coleman
> >>>
> >>> Chief Technology Officer
> >>> Wikimedia Foundation
> >>> 1 Montgomery Street, Suite 1600
> >>> San Francisco, CA 94104
> >>>
> >>> +1-650-703-8112 <(650)%20703-8112>
> >>>
> >>> vcole...@wikimedia.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
>  On Dec 13, 2017, at 8:26 PM, Nuria Ruiz  wrote:
> 
>  Hello from Analytics Team!
> 
>  We are happy to announce the Alpha release of Wikistats 2. Wikistats
> >> has
>  been redesigned for architectural simplicity, faster data processing,
> >>> and a
>  more dynamic and interactive user experience. First goal is to match
> >> the
>  numbers of the current system, and to provide the most important
> >> reports,
>  as decided by the Wikistats community (see survey) [1].  Over time, we
> >>> will
>  continue to migrate reports and add new ones that you find useful. We
> >> can
>  also analyze the data in new and interesting ways, and look forward to
>  hearing your feedback and suggestions. [2]
> 
>  You can go directly to Spanish Wikipedia
>  https://stats.wikimedia.org/v2/#/es.wikipedia.org
> 
>  or browse all projects
>  https://stats.wikimedia.org/v2/#/all-projects
> 
>  The new site comes with a whole new set of APIs, similar to our
> >> existing
>  Pageview API but with edit data. You can start using them today, they
> >> are
>  documented here:
> 
>  https://wikitech.wikimedia.org/wiki/Analytics/AQS/Wikistats
> 
> 
>  FAQ:
> 
>  Why is this an alpha?
>  There are features that we feel a full-fledged product should have
> that
> >>> are
>  still missing, such as localization. The data-processing pipeline for
> >> the
>  new Wikistats has been rebuilt from scratch (it uses
> >>> distributed-computing
>  tools such as Hadoop) and we want to see how it is used before calling
> >> it
>  final. Also while we aim to update data monthly, it will happen a few
> >>> days
>  after the month rolls because of the amount of data to move and
> >> compute.
> 
>  How about comparing data between two wikis?
>  You can do it with two tabs but we are aware this UI might not solve
> >> all
>  use cases for the most advanced Wikistats users. We aim to tackle
> those
> >>> in
>  the future.
> 
>  How do I file bugs?
>  Use the handy link in the footer:
>  https://phabricator.wikimedia.org/maniphest/task/edit/?
> >>> title=Wikistats%20Bug=Analytics-Wikistats,Analytics
> 
>  How do I comment on design?
>  The consultation on design already happened but we are still watching
> >> the
>  talk page:
>  https://www.mediawiki.org/wiki/Wikistats_2.0_Design_
> >>> Project/RequestforFeedback/Round2
> 
> 
>  [1]
>  https://www.mediawiki.org/wiki/Analytics/Wikistats/
> >>> DumpReports/Future_per_report
>  [2] https://wikitech.wikimedia.org/wiki/Talk:Analytics/
> >> Systems/Wikistats
>  ___
>  Wikitech-l mailing list
>  Wikitech-l@lists.wikimedia.org
>  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >>>
> >>> ___
> >>> Wikitech-l mailing list
> >>> Wikitech-l@lists.wikimedia.org
> >>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >>>
> >>
> >>
> >>
> >> --
> >> Niharika
> >> Software Engineer
> >> Community Tech
> >> Wikimedia Foundation
> >> ___
> >> Wikitech-l mailing list
> >> Wikitech-l@lists.wikimedia.org
> >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >>
> >
> >
> >
> > --
> > Jonathan T. Morgan
> > Senior Design Researcher
> > Wikimedia Foundation
> > User:Jmorgan (WMF) 
> > ___
> > Wikitech-l mailing list
> > 

Re: [Wikitech-l] ResistanceManual.org looking for co-maintainers

[Steven Walling]

Dear Brad,

Yes.

On Mon, Jan 30, 2017 at 6:42 AM Brad Jorsch (Anomie) 
wrote:

> On Sun, Jan 29, 2017 at 6:38 PM, Ori Livneh  wrote:
>
> > Resistance Manual <
> https://www.resistancemanual.org/Resistance_Manual_Home
> > >
> > is a guide for organizing resistance to the policies of the Trump
> > administration in the United States. The site is running MediaWiki 1.28,
> > and its admins are looking for help maintaining the site. The main page
> > says to reach out to i...@staywoke.org if interested.
> >
>
> Is "some random wiki needs sysadmins" really on-topic for this list?
>
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Changes in colors of user interface

[Steven Walling]

Pine, please chill for once.
On Fri, Dec 9, 2016 at 5:40 PM Legoktm  wrote:

> Hi,
>
> On 12/09/2016 05:25 PM, Pine W wrote:
> > While I appreciate the attempt to be funny, I am not amused in this case.
> > Surprise UI changes could, for example, result in thousands of dollars'
> > worth of instructional videos becoming instantly out of sync with the
> > real-world user experience. Also, users who may have spent considerable
> > time perfecting their templates may be surprised to find that they need
> to
> > make changes to keep the templates in sync with other changes to the UI.
> > The problem isn't so much that the UI was changed, as that it was changed
> > without notice and consultation. This isn't funny.
>
> Well, I was specifically responding to Strainu's comment that "No change
> is to small to be disliked by one or more people!" which seemed to be in
> jest too.
>
> But I think you're significantly over-exaggerating the costs of this UI
> change, and changes in general. MediaWiki's UI changes literally every
> day when localization messages are updated, reworded, or added. Special
> pages are re-organized to be made more intuitive, toolbars re-arranged,
> etc. If you're making instructional videos, colors *barely* changing
> seem like the least of your problems in terms of becoming out of date.
> The VisualEditor project has a script that automatically generates
> localized screenshots of the user interface so the user manual stays up
> to date, I don't know if any solution has been worked out for videos yet.
>
> -- Legoktm
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikitech-ambassadors] Opening the door to a new look...a Wikipedia.org Portal Page Update

[Steven Walling]

On Tue, Aug 16, 2016 at 9:39 AM Anne Gomez  wrote:

> Congrats portal team! Very cool to look at both the new and the old side by
> side - the visual design is much cleaner, but more than that the
> improvements to clarifying flows for the user is remarkable.
>
> I particularly like the language detection from the user's browser
> settings. That should help people get what they're looking for so much more
> easily, while still giving them access to other languages if they'd like to
> browse that way.
>

Big +1. Doing automatic language detection is a big step forward. Awesome
work!


> Congrats again :)
>
>
>
>
>
> On Tue, Aug 16, 2016 at 9:25 AM, Deborah Tankersley <
> dtankers...@wikimedia.org> wrote:
>
> > Everyone who uses the wikipedia.org  [1]
> > portal is familar with the look of the page: a beautiful puzzle globe
> > encirled by the top ten viewed languages; a long list with Wikipedias in
> > hundreds of languages that can all be read and explored; the search box
> > that can make queries in nearly any language; and a compilation of
> related
> > Wikimedia projects.
> >
> >
> > Over the last eight months, the Wikimedia Foundation's Portal team
> >  [2], part of the
> Discovery
> > department  [3], has
> > been busy improving the discoverability of information within the portal
> to
> > make it more contemporary and easier to use.
> >
> > To start, we’ve updated the search box. When you are entering a query,
> you
> > will now see images and metadata that correspond to your search
> > <
> https://commons.wikimedia.org/wiki/File:Wikipedia,org-searchbox_highlight-Aug2016_screenshot.png
> >
> > [4], and you're also free change the search language without leaving the
> > page.
> >
> > We’ve also optimized the portal site, making it load faster by utilizing
> > smaller sized images and streamlining the page code.
> >
> > A fairly inconspicuous change to the page will immediately detect your
> > browser’s preferred (or default) language and rearrange the top ten links
> > to display those languages first, along with the remaining top ten viewed
> > wiki’s by language, around the globe.
> >
> > In this example
> > <
> https://commons.wikimedia.org/wiki/File%3AWikipedia.org-globe-sorted-languages_screenshot.png
> >
> > [5], The Free Encyclopedia is displayed in Portuguese, since it is the
> > browser’s first preferred language and English is the second.
> >
> > Here is a helpful site
> >  [6] that
> > explains how to change your preferred language on various browsers.
> >
> > We’ve also added sister project descriptions
> > <
> https://commons.wikimedia.org/wiki/File:Wikipedia.org-sister-projects-text_screenshot.png
> >
> > [7], located in the page’s footer, which will hopefully spark curiosity
> > as to what a person might find when they visit those individual projects.
> >
> > The look and feel of the long list of every available language wiki
> > (sorted by article count) has been modernized and placed inside an
> > elegant drop down
> > <
> https://commons.wikimedia.org/wiki/File:Wikipedia.org-language-dropdown_screenshot.png
> >
> > [8]. This new feature makes finding your language wiki a bit easier on
> > the eyes as well as providing easy access on any device.
> >
> > We hope you enjoy using the new portal page! You can view a short video
> > <
> https://upload.wikimedia.org/wikipedia/commons/8/8c/Wikipedia.org-new-layout_movie-Aug2016.ogg
> >
> > [9] that shows some of these new features.
> >
> > *And, if you don’t quite remember what the old Wikipedia portal site
> > looked like before we made any changes, here’s a reminder
> >  *
> > [10].
> >
> > Cheers from the Discovery Portal Team!
> >
> > [1] https://www.wikipedia.org/
> > [2] https://www.mediawiki.org/wiki/Wikipedia.org_Portal
> > [3] https://www.mediawiki.org/wiki/Wikimedia_Discovery
> > [4] https://commons.wikimedia.org/wiki/File:Wikipedia,org-search
> > box_highlight-Aug2016_screenshot.png
> > [5] https://commons.wikimedia.org/wiki/File%3AWikipedia.org-glob
> > e-sorted-languages_screenshot.png
> > [6] https://www.w3.org/International/questions/qa-lang-priorities
> > [7] https://commons.wikimedia.org/wiki/File:Wikipedia.org-sister
> > -projects-text_screenshot.png
> > [8] https://commons.wikimedia.org/wiki/File:Wikipedia.org-langua
> > ge-dropdown_screenshot.png
> > [9] https://upload.wikimedia.org/wikipedia/commons/8/8c/Wikipedi
> > a.org-new-layout_movie-Aug2016.ogg
> > [10] https://commons.wikimedia.org/wiki/File:Wikipedia.org-01Jan2016.png
> >
> >
> > --
> > Deb Tankersley
> > Product Manager, Discovery
> > IRC: debt
> > Wikimedia Foundation
> >
> > ___
> > Wikitech-ambassadors mailing list
> > 

Re: [Wikitech-l] Campaigns extension / ServerSideAccountCreation log - does anyone still use it?

[Steven Walling]

Hey Brad,

That sounds fine to me.

We previously used the loginCTA campaign to measure the value of that
secondary button on the login page (
ee-dashboard.wmflabs.org/graphs/enwiki_campaigns) but it doesn't need to
happen on an ongoing basis.

On Tue, May 31, 2016 at 11:31 AM Brad Jorsch (Anomie) 
wrote:

> On Thu, May 26, 2016 at 2:56 PM, Brad Jorsch (Anomie) <
> bjor...@wikimedia.org
> > wrote:
>
> > Question 1: Would anyone care if we kill the "loginCTA" campaign, which
> > tracks when people use the link at the bottom of Special:UserLogin to get
> > to the account creation page?
> >
> > Question 2: Would anyone care if we remove the extension entirely from
> > Wikimedia wikis? Wikiapiary seems to show only one user outside of
> > Wikimedia.
> >
>
> Following up on this: Since the answer to Question 2 was yes, we've done
> the necessary update to Campaigns so it will continue working with
> AuthManager.[1] Since no one answered Question 1, the loginCTA campaign has
> been removed. It will stop showing up in 1.28.0-wmf.4, which rolls out this
> week.
>
>  [1]: https://gerrit.wikimedia.org/r/#/c/291280/
>
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] QA: Holding our code to better standards.

[Steven Walling]

Just to hop on the bandwagon here: this seems like the only sane path going
forward. One unmentioned benefit is that this is a step toward continuous
deployment. Having integration tests run on every commit and then block
when there are failures is pretty much a requirement if Wikimedia ever
wants to get there.

On Thu, Sep 3, 2015 at 1:43 PM Pine W  wrote:

> I just want to say that I appreciate this overview.
>
> Pine
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Code of conduct

[Steven Walling]

On Fri, Aug 7, 2015 at 7:32 AM MZMcBride z...@mzmcbride.com wrote:

 Matthew Flaschen wrote:
 We're in the process of developing a code of conduct for technical
 spaces.  This will be binding, and apply to all Wikimedia-related
 technical spaces (including but not limited to MediaWiki.org,
 Phabricator, Gerrit, technical IRC channels, and Etherpad).

 Who's we? This seems to be a pet issue of yours. I'm curious who else is
 supportive of this initiative to enact a binding policy.

 MZMcBride


What kind of standards for behavior we want and think are acceptable is a
core concern of everyone in the Wikimedia and MediaWiki technical
communities.

This kind of personally-directed and demeaning feedback (This seems to be
a pet issue of yours) is, perhaps ironically, precisely an example of why
it would improve interaction in technical spaces to have some clearer
ground rules.




 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Search engine indexing of userspace - has something changed?

[Steven Walling]

FWIW I have also seen many cases of userspace drafts being indexed. Perhaps
something to do with the fact that they are always subpages?

On Mon, Jul 6, 2015 at 10:35 AM Jon Robson jdlrob...@gmail.com wrote:

 Looks like a bug

 Looking closely this meta tag is present in user pages:
 meta name=robots content=noindex,follow

 but not present in that particular sub page [1].
 I haven't had time to investigate further but please raise a phabricator
 task.

 [1]
 https://en.m.wikipedia.org/wiki/User:Nobleeagle/India_as_an_emerging_superpower

 On Mon, Jul 6, 2015 at 10:32 AM, Dan Garry dga...@wikimedia.org wrote:
  Hello!
 
  In this thread
  
 https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Userpage_drafts_shown_in_search_engines
 ,
  there was a discussion about indexing of user space by search engines.
 In a
  nutshell, user space pages are not subject to content policies so that
  users can write drafts freely, and having those pages indexed by search
  engines like Google is viewed as problematic since those pages can seem
  fairly official.
 
  I seem to recall that it was not the default in the past that user pages
  were indexed by search engines. I'm trying to figure out if there's some
  other cause for this that's happened recently, because I'd prefer to
 avoid
  piling hacks on and not address the root issue.
 
  Does anyone know of anything that's changed recently that might've
 changed
  the way that search engines index user space?
 
  Thanks,
  Dan
 
  --
  Dan Garry
  Product Manager, Discovery
  Wikimedia Foundation
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l



 --
 Jon Robson
 * http://jonrobson.me.uk
 * https://www.facebook.com/jonrobson
 * @rakugojon

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki, as seen on TV

[Steven Walling]

There's a pretty hilarious American police procedural TV show in 2015
called CSI: Cyber, featuring mostly cybercrime. Obviously they have to
dredge up snippets of code from places for screenshots on the show.

Episode 4 happened to include a tidbit from MediaWiki 1.25/wmf3. Supposedly
the code was a hack to make your printer blow up.

Original lulz and screenshots via
http://moviecode.tumblr.com/post/114815574587/this-is-from-csi-cyber-s01e04-according-the-the
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikimedia-l] ContentTranslation gets to 2000

[Steven Walling]

-Wikimedia-l

Amir, this is awesome. Glad to see it's taking off.

On Thu, Apr 30, 2015 at 6:24 AM Amir E. Aharoni 
amir.ahar...@mail.huji.ac.il wrote:

 * In all the Wikipedias in which ContentTranslation is deployed, it is
 currently defined as a Beta feature, which means that it is only available
 to logged-in users who opted into it in the preferences.


Regarding Beta feature status: what would it take to enable this as a
default? You mentioned this in plans for the coming months.

That deletion rate (60 out of 2000 = 3%?) looks actually a lot better than
pretty OK. According to historical stats, it's basically equivalent to
deletion rates for article creators with more than a month of experience.[1]

It seems like the only risk in taking this out of beta status as moving to
a default is UI clutter for monolingual users who can't ever make use of
the feature? Maybe it's unobtrusive enough that you don't need to do this,
but perhaps you could enable as a default for only those users who have
substantively edited more than one language edition of Wikipedia? Either
that, or we could consider adding a languages I edit in section to
the Internationalisation section of user preferences?

I'm sure you've thought about this before, but I'd love to hear more about
the rollout plan.

1. http://meta.wikimedia.org/wiki/Research:Wikipedia_article_creation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Extension:Gather launching on beta for English WP mobile users.

[Steven Walling]

Thanks for the link Jon.

It seems only fair that people actually try the feature before ripping it
to shreds. Right? We've had extensions to create alternative content
curation features in the past, such as books, and this is hardly the first
time an experimental feature was launched on mobile first. So hardly seems
like time to grab the pitchforks before you even give it a fair shot.


On Thu, Mar 26, 2015 at 8:00 AM Jon Robson jrob...@wikimedia.org wrote:

 I should add you can opt into mobile beta using this link:
 http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:MobileOptions

 The design still has kinks and the extension still needs work before.
 Releasing to mobile beta will get us an audience to identify those issues
 and fix them. I'd be keen to get this as a desktop beta feature too if
 anyone is willing to help me.
 On 26 Mar 2015 7:41 am, Jon Robson jrob...@wikimedia.org wrote:

  A few notes:
  * lists are public in the first version but there is APIs to make them
  private. Public lists is something that will have moderation problems and
  interesting to explore.
  * the feature is _launching_ on mobile. It's built to work on desktop and
  with a tiny bit of work I can turn it on as a beta feature on desktop
 (the
  issue is how to replace the existing watchstar on desktop).
  * We considered doing it straight in core based on the watchlist code but
  we figured it would be more responsible to experiment in an extension,
 fine
  tune it against a completely different use case to watchlist and then
 make
  a proposal to move the good parts/all parts into core. I'm still
 personally
  dedicated to resolving the RFC [1]. We have worked hard so that the api
 to
  gather is backwards compatible with watchlist methods.
  * you can play with it on betalabs:
  ** http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:
 Gather/by/Jdlrobson
  ** http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:Gather
  * I'm personally excited to make multiple watchlists a reality using this
  extension at Lyon if anyone is keen to help me there. The infrastructure
  required is all in Gather.
 
  [1]
  https://m.mediawiki.org/wiki/Requests_for_comment/Support_
 for_user-specific_page_lists_in_core
  On 26 Mar 2015 7:20 am, Brian Wolff bawo...@gmail.com wrote:
 
  On Mar 26, 2015 11:04 AM, Brian Wolff bawo...@gmail.com wrote:
  
  
   On Mar 26, 2015 9:58 AM, MZMcBride z...@mzmcbride.com wrote:
   
Hi.
   
Moushira Elamrawy wrote:
The Extension will keep the name Gather and internally the team was
  more
inclined to name the feature Stacks. However, a survey study has
  been
carried out by the design research team and Collections, as a name
  for
  a
feature, scored far better than the other suggested alternatives.
  Full
survey information and results are documented here

  https://www.mediawiki.org/wiki/Extension%CB%90Gather/renaming_survey.
   
Right... in the January 2015 thread you linked, it was quickly
 pointed
  out
that Extension:Collection already exists. The mobile team, in
 typical
form, decided to ignore any previous work and instead make its own
project. At least we were able to shout loudly enough to stop this
functionality from being part of the MobileFrontend extension.
   
  
   Hey, count your blessings its not called collections with just an s
 at
  the end to distinguish it...
  
This is a new experiment in content curation, which hopefully helps
  with
learning new users behavior on mobile web. We are looking forward
 to
learning awesome lessons from this beta launch.
   
As was also previously pointed out, we've had curation support for a
  long
time in the form of categories (another feature that could have been
improved rather than making a new extension). Or making a list of
  pages
using wikilinks. Or tagging pages with templates, which
 auto-generates
  an
index. Perhaps you can explain why this new feature is limited to
  mobile?
   
  
   I dont know if this criticism is fair. Many users have been asking for
  multiple watchlist type functionality for years despite the option of
  creating a subpage or category and throwing special:recentchangeslinked.
  Categories dont really have per user namespace, and i think its
 important
  to have interfaces that encourage users to do this sort of thing rather
  then making them figure out that they are physically able to and allowed
  to.
  
   I do agree that its odd that this isnt developed in core for all
 users.
  The faq entry is unconvincing.
  
   --bawolff
 
  Actually after reading the extension page, I'm a little confused. If the
  goal is to create private personal lists why are the lists public? I can
  understand the use case for private lists (watchlist). I understand the
  use
  case for public lists (categories). What is the use case for
  pseudo-private
  lists?
 
  Maybe it will make more sense to me when the extension is deployed and I
  see 

Re: [Wikitech-l] [Wmfall] VisualEditor on Wikipedia now faster with RESTBase

[Steven Walling]

Nice work! This is big.
On Thu, Mar 19, 2015 at 3:08 PM Erik Moeller e...@wikimedia.org wrote:

 Fantastic work! :) VisualEditor is becoming really zippy -- which had been
 one of the top concerns in user feedback in the past. Congratulations to
 everyone involved.

 Erik
 --
 Erik Möller
 VP of Product  Strategy, Wikimedia Foundation
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] S Page debuts as Technical Writer

[Steven Walling]

Congrats S! You'll do great at this and MediaWiki sure needs your help.
On Mon, Jan 5, 2015 at 3:59 PM Subramanya Sastry ssas...@wikimedia.org
wrote:

 On 01/05/2015 04:06 PM, Quim Gil wrote:
  It is an honor to announce that S Page[1] has moved from the
 Collaboration
  (Flow) team to join the WMF Engineering Community team as a Technical
  Writer[2]. We were really lucky to find such a great combination of
 English
  communication skills, awareness of MediaWiki documentation pain points,
  more-than-basic MediaWiki development experience, and Wikimedia community
  mileage.
  
  Welcome S to your new role and to the Engineering Community team!
  ...

 Congrats, S! :-)

 Subbu.

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Our CAPTCHA is very unfriendly

[Steven Walling]

MZ: you mean removing just for account creation right? There is also a
CAPTCHA delivered on external link addition for some editors–I think IPs
and users not autoconfirmed. This is probably a lot more important for
combating spam.

(Sorry for top posting. On my phone.)
On Wed, Dec 3, 2014 at 8:03 PM MZMcBride z...@mzmcbride.com wrote:

 svetlana wrote:
 I like how my message to try abandoning captcha entirely came up with a
 myriad of complaints how we can be smart, enable new captcha which is
 unique, etc.
 
 Let's measure the impact.

 We disabled the CAPTCHA entirely on test.wikipedia.org a few weeks ago.
 The wiki seems to be about the same. It probably makes sense to continue
 slowly disabling the CAPTCHA on wikis until users start to shout. Perhaps
 we'll disable the CAPTCHA on the rest of the phase 0 wikis next?

 MZMcBride



 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Our CAPTCHA is very unfriendly

[Steven Walling]

On Wed Dec 03 2014 at 8:57:38 PM MZMcBride z...@mzmcbride.com wrote:

 Steven Walling wrote:
 MZ: you mean removing just for account creation right? There is also a
 CAPTCHA delivered on external link addition for some editors–I think IPs
 and users not autoconfirmed. This is probably a lot more important for
 combating spam.

 For testwiki, we actually set $wmgEnableCaptcha to false, which disabled
 both ConfirmEdit and FancyCaptcha entirely. My suspicion is that we need
 enhanced spam protection only on larger wikis and on a few smaller wikis
 that happen to be the target of spammers for whatever reason. Even on
 sites that are frequent spam targets, smarter heuristics, as Robert
 suggests, and existing tools such as AbuseFilter may be sufficient.


Yeah I agree it doesn't matter on testwiki to turn it off 100%. I'd suggest
we not do that for larger wikis though.

There are about a million IP edits a month on English Wikipedia alone, last
time we checked.[1] If we increased anonymous bot spam by even only 1/10th
of the total number of edits before we managed to put IP blocks in place,
that's still 100k edits worth of spam. And we might not want to use
something like Special:Nuke on an IP, since it may be shared with legit
edits. However, for account creation, there were only ~21,000 registrations
last month and it's automatically rate limited by IP even without CAPTCHA,
so experimenting in that area is much safer.

1.
https://meta.wikimedia.org/wiki/Research:Anonymous_editor_acquisition/Volume_and_impact




 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Our CAPTCHA is very unfriendly

[Steven Walling]

On Fri, Nov 7, 2014 at 2:19 PM, MZMcBride z...@mzmcbride.com wrote:

 I think that's unfair.

 Wikis have a serious spam problem. People associate CAPTCHAs with spam
 prevention. On the English Wikipedia, one of the actions that results in
 the user being required to successfully enter a CAPTCHA is adding an(y?)
 external link to a page as a newly registered user. This, of course, in
 addition to the CAPTCHA presented when registering an account (consider
 that many new account creations only come about as the result of the
 requirement for an account to make a new page on the English Wikipedia).

 Why not disable the extension for a week and see what happens? If you're
 wrong and there's a marked increase in wiki spam (account creations and
 edits), then you can help devise a better solution than a CAPTCHA.
 CAPTCHAs are clearly not a sustainable fix to the underlying problems they
 were implemented to address, or so I think you're saying. If you're right
 and the CAPTCHA is simply ineffective and unneeded, we've eliminated some
 code from production and we can move on. In other words: what exactly is
 stopping you from disabling the extension?


When we did usability tests of the new version and the old version, it was
exceedingly clear that what Jon has said is true: the CAPTCHA is by far the
most painful part of our signup form. Results and videos of those tests at:
https://www.mediawiki.org/wiki/Account_creation_user_experience/User_testing

Back in the day, when we did the last redesign of the signup form, we
considered running an A/B test of removing the CAPTCHA. Docs for that are
at https://meta.wikimedia.org/wiki/Research:Account_creation_UX/CAPTCHA

The turn it off for a week and see what happens with spam test is the
easiest implementation of the above, and even though normally it's a great
way to produce garbage data (not being a controlled experiment) I'd be in
favor of trying it. Every indication we have is that we'd get marked
increases in signup conversion rates (ours are not great -- only 30% of
visitors complete the form successfully IIRC).

For some more background, when we proposed something like that to Chris
Steipp he was pretty iffy about it, and he's not wrong. At other sites that
don't have a CAPTCHA on signup (like Facebook, Quora, others) they avoid a
spam problem in part because they require an email address and
confirmation. For some irrational reason, even in the era of throwaway
email accounts from web services, not requiring email is some kind of
sacred cow among Wikimedians, even if it would make it an easy choice to
throw away our wretched CAPTCHA.

If we want to avoid spam bots signing up, there is going to be a hit in
ease of use somewhere. Our network of sites is just too large to avoid
being a target. It's just a matter of testing to see how much we can reduce
that hit, and which method might be less easy.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Looking for project status updates

[Steven Walling]

On Thu, Oct 23, 2014 at 12:27 AM, Erik Moeller e...@wikimedia.org wrote:

 Yes, the Growth team was disbanded, and the engineers working on this
 team are now supporting Mobile (Rob Moen, Sam Smith) and Flow (Matt
 Flaschen). We'll be updating wiki pages as we go, but help is welcome.


Meta, MediaWiki.org, and English Wikipedia docs are all updated to mark
appropriate documentation hubs as historical. Sorry for any confusion Pine.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] jQuery UI 1.10.4 and IE6 support

[Steven Walling]

On Sat, Jul 26, 2014 at 9:54 AM, Krinkle krinklem...@gmail.com wrote:

 As for IE6, that roadmap is quite simple in my opinion.

 At this point MediaWiki already degrades gracefully in older browsers in a
 number of different ways. We've put our cut off point for javascript
 execution in general at IE  6 and Firefox  4. And for stylesheets we also
 support IE6 for the basic layout (enough for text to be readable in a way
 that isn't distorted or hard to read).

 In any browsers where we don't abort the javascript pipeline from the
 startup[1] module, there must be no fatal errors or uncaught exceptions due
 to browser support.

 While a library doesn't have to throw an exception in an older browser per
 se, in case of jQuery UI it's quite simple. We can only upgrade to jQuery
 1.10 when we drop IE6 support for Grade A. And when we do, IE6 will become
 javascriptless[1] and jQuery UI will no longer be relevant as problem in
 IE6.


This seems really reasonable.

Are we still agreed that Grade A means anything over 1% of readership? If
so, we should reconfirm what our browser share is really like, because last
time I checked, IE6 was less than 1% of total and thus eligible for
dropping from Grade A now and forever (he says with great
antici.pation.)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] logging out on one device logs user out everywhere

[Steven Walling]

On Mon, Jul 21, 2014 at 11:35 AM, Jon Robson jdlrob...@gmail.com wrote:

 It seems like there is agreement on an approach

 As I understand it:
 * special button that when clicked logs you out everywhere
 * default behaviour is just to log you out on current device


Where would this log me out of all sessions button go? Preferences?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] logging out on one device logs user out everywhere

[Steven Walling]

On Mon, Jul 21, 2014 at 1:20 PM, Jon Robson jdlrob...@gmail.com wrote:

 http://en.wikipedia.org/wiki/Special:UserLogout might be an obvious
 place (closest to the action)... although not sure how discoverable.

 Do you want to logout everywhere YES NO
 [] Remember this decision

 It seems like we could split this into 2 features though in the
 interest of getting things done. Right now I'm interested in just
 fixing the logout behaviour - in this day and age to many people are
 using too many different devices and this experience seems very
 broken.


This seems potentially overcomplicated. Other sites doing this (Facebook,
Google, others) don't put this kind of close all sessions option directly
on logout. Let's get some input here from the UX team.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Phabricator migration update

[Steven Walling]

On Fri, Jul 18, 2014 at 11:59 AM, Andre Klapper aklap...@wikimedia.org
wrote:

 Hi,

 this is a quick status update on the planned migration of our
 development planning tools to Phabricator. See
 https://www.mediawiki.org/wiki/Phabricator for general info.


 Several things have been worked on and achieved in the meantime:
   * WMF SUL Authentication has been implemented for Phabricator.
   * A separate server legalpad.wikimedia.org was deployed (a tool to
 manage trusted users - workflow to be further defined with
 Legal.
   * A data backup system for Phabricator in place.
   * Code to restrict access to tasks in a certain project is in
 place (same as Bugzilla's Security project)
   * The dedicated Phabricator server was upgraded to Ubuntu Trusty.
   * Packaging for Debian using pkg-php-tools/dh_php5


 The identified tasks are listed on the planning board at
 http://fab.wmflabs.org/project/board/31/


 Bugzilla:
 When it comes to the planning of how to convert data in Bugzilla tickets
 to Phabricator, we are mostly done.
 The elements that a Bugzilla report includes are listed in
 http://fab.wmflabs.org/T423 with links to subtasks.

 Obviously, Phabricator has a different UI and different workflow
 concepts than Bugzilla.
 While it's not the goal to have complete feature parity in every
 possible way, I'm pretty confident that we are close enough.

 As people are likely more interested in what Bugzilla functionality will
 be different, I'll try to summarize what I'm aware of:
   * Bugzilla's products, components and keywords will be turned into
 projects / tags in Phabricator.
   * Bugzilla votes will be turned into tokens.
   * Bugzilla's Severity field itself should get dropped - for
 example, if there is a real need to be able to search for
 critical severity (which translates to crash), it can become a
 crash project in Phabricator (think of keywords in terms of
 Bugzilla here).
   * For those ~50 users who have used Bugzilla's private Tags
 feature so far (introduced in February), this feature will be
 dropped, but you will get warned before. Similar, some
 Whiteboard data will likely also get dropped (or moved into the
 first comment if really considered relevant).

 Apart from that I am not aware of any other data we might drop or
 lose, or any other important functionality that would not be available
 in Phabricator.


 If you are passionate about a specific topic of task management /
 development workflows  if you think after reading existing comments in
 the discussion of the related task that an important aspect has not been
 considered yet, please feel free to provide your input.

 To follow the progress of our Phabricator migration and to help, please
 see the planning board at http://fab.wmflabs.org/project/board/31/
 Regular status updates are published at
 https://www.mediawiki.org/wiki/Phabricator/Migration#Status


 As usual, big thanks to Chase and Mukunda for their work, and to many
 others for providing input, feedback and help.


 Cheers,
 andre


Thanks for the update Andre, this plan sounds great.

When we've migrated from Bugzilla, are you looking for teams to be guinea
pigs and try out Phabricator? Overall, I feel like we're not going to get
the real benefit until we migrate from Gerrit and the entire toolset is on
Phabricator. That said, I think Growth would be interested in provisionally
giving Phabricator a try as a Trello/Bugzilla replacement.


 --
 Andre Klapper | Wikimedia Bugwrangler
 http://blogs.gnome.org/aklapper/


 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Product] Winter, v. 0.6

[Steven Walling]

On Tue, Jul 15, 2014 at 2:07 PM, Brandon Harris bhar...@wikimedia.org
wrote:

 On Jul 14, 2014, at 3:55 PM, David Gerard dger...@gmail.com wrote:

  I *love* how typing into the search bar gives you related articles.
  How are you doing that?

 Through the magic of the new search API.


If you like that, you're also going to like upcoming work from the Growth
team on task suggestions for things to edit. It's powered by the same
search API. :)


-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] logging out on one device logs user out everywhere

[Steven Walling]

On Tuesday, July 15, 2014, Jon Robson jdlrob...@gmail.com wrote:

 (Forked from Re: [Wikitech-l] Not logged in page)

 Is it time to revisit this behaviour? It's come up as being a usability
 problem a few times now.

 Currently if I log out of a public computer it logs me out of my tablet
 device,mobile device and home computer. :(

 See bug for reference [1]

 [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=49890


Yes, this is terrible UX. Logging out or in should only apply to one
device.


 On 15 Jul 2014 18:38, Bryan Davis bd...@wikimedia.org javascript:;
 wrote:

  On Tue, Jul 15, 2014 at 7:25 PM, Jon Robson jdlrob...@gmail.com
 javascript:; wrote:
   regularly.  I've found mediawiki logs me out despite the 'keep me
   logged in' box, when logging out on a different device, etc.
   Well that's the bug then no and that should be fixed. Help us work out
  why
   it is occurring and let's get that dealt with.:)
  
   We shouldn't be designing features for edge cases!
 
  Logout was discussed recently on the QA list [0]. The discussion lead
  to Jon Robson pointing out bug 49890 [1] where Chris Steipp stated
  that logout is global.
 
  [0]:https://www.mail-archive.com/qa@lists.wikimedia.org/msg01559.html
  [1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=49890
  --
  Bryan Davis  Wikimedia Foundationbd...@wikimedia.org
 javascript:;
  [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
  irc: bd808v:415.839.6885 x6855
 
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org javascript:;
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org javascript:;
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikitech-ambassadors] Roadmap and deployment highlights - week of June 23rd

[Steven Walling]

Also next week we will likely be ready to launch a second A/B test of a
guided tour inviting anonymous editors to sign up.

Design specification at:
https://www.mediawiki.org/wiki/Anonymous_editor_acquisition/Signup_invites_v2


On Fri, Jun 20, 2014 at 1:57 PM, Greg Grossmeier g...@wikimedia.org wrote:

 Hello and welcome to the latest edition of the WMF Engineering Roadmap
 and Deployment update.

 The full log of planned deployments next week can be found at:
 https://wikitech.wikimedia.org/wiki/Deployments#Week_of_June_23rd

 A quick list of notable items...


 == Tuesday ==

 * MediaWiki deploy
 ** group1 to 1.24wmf10: All non-Wikipedia sites (Wiktionary, Wikisource,
Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites)
 ** https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf10

 * The In other projects sidebar Beta Feature will be enabled.
 ** https://www.mediawiki.org/wiki/Beta_Features/Other_projects_sidebar


 == Wednesday ==
 * The updated Android Wikipedia app will be released via Google Play


 == Thursday ==

 * MediaWiki deploy
 ** group2 to 1.24wmf10 (all Wikipedias)
 ** group0 to 1.24wmf11 (test/test2/testwikidata/mediawiki)


 Thanks and as always, questions and comments welcome,

 --
 | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
 | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

 ___
 Wikitech-ambassadors mailing list
 wikitech-ambassad...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors




-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Huggle] Huggle 3 released / Mac people needed

[Steven Walling]

On Sun, Jun 1, 2014 at 1:32 PM, Petr Bena benap...@gmail.com wrote:


 We didn't release any mac bundle, because we have nobody with a mac in
 our team, so in case you have mac and you have some programming
 skills, you can figure out how to build huggle (need Qt and CMake) and
 once you do that, let us know how you did it, so that we can update
 the manual.

 If you are willing to contribute more permanently, you can become
 release manager for Mac builds and provide them for download every new
 release. Let us know in e-mail or irc://chat.freenode.net/#huggle


I really tried to set this up on my machine (OSX 10.9) and could really get
it to work. Have there been updates lately?

I think until there's a one click installer for a Huggle.app in OSX, we're
probably not going to get much uptick among Mac users.


-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Process change: New contributors getting editbugs on Bugzilla

[Steven Walling]

On Thursday, May 29, 2014, Mark Holmquist mtrac...@member.fsf.org wrote:

 Hi,

 For the nth time, in #mediawiki, I've had someone ask how to be able to
 mark a bug as resolved, or claim it, or mark it as a duplicate of another
 bug. I conceptually know that this means getting editbugs permissions but
 it happens so infrequently that I never know where to go.

 Usually what happens is this:
 1. I wrack my brain trying to remember the process for about 30 seconds
 2. Failing, I try to ping Andre, Quim, and Sumana (none of whom are in the
 channel, sadly)
 3. I search with duckduckgo and pull up nothing of any use
 4. I search MediaWiki.org and find outdated status reports about
 greasemonkey scripts but nothing useful
 5. I go to the developer hub pages and look at the
 welcome-to-the-community process but again find nothing describing this
 process

 Solution: We've made every editbugs user able to add editbugs to an
 account. I've documented the process here:
 https://www.mediawiki.org/wiki/Bugzilla#Why_can.27t_I_claim_a_bug_or_mark_it_resolved.3F

 Thanks to Chad for the quick resolution on this, hopefully this will be a
 positive change overall.

 --
 Mark Holmquist


Thank you! This is extremely sensible. Hopefully we can make sure avoid
duplicating this problem again in Phabricator.



 Software Engineer, Multimedia
 Wikimedia Foundation
 mtrac...@member.fsf.org javascript:;
 https://wikimediafoundation.org/wiki/User:MHolmquist

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] FlaggedRevs gone from mediawiki.org

[Steven Walling]

On Thu, May 22, 2014 at 4:17 PM, Chad innocentkil...@gmail.com wrote:

 I've just undone the mistake I made almost 5 years ago getting FlaggedRevs
 turned on for mw.org with no consensus[0].

 The average review time was  58 days.
 There were over 50 pages pending review (I didn't bother paging)
 The vast majority of edits are harmless/productive and don't need review.

 You probably noticed me removing you from the editor and/or reviewer groups
 since they're unused now. Since FlaggedRevs is gone you shouldn't notice
 any
 net permission changes.

 -Chad

 [0] I'm not joking. There was a thread where there was little/no consensus.
 I
 then went on IRC and asked Brion and he said sure.


Thank you!
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Login to Wikimedia Phabricator with a GitHub/Google/etc account?

[Steven Walling]

On Fri, May 16, 2014 at 5:19 PM, Chad innocentkil...@gmail.com wrote:

 I'm mostly worried about security issues in 3rd party implementations of
 oAuth
 that we can't control. I asked Chris S. about this earlier today and I hope
 he'll
 expand on this some more--especially concerning to me was the concrete
 example he gave with Facebook's own oAuth. Also he mentioned that Twitter's
 oAuth is known to be insecure in its implementation.

 Depending on how Github's oAuth is implemented that's the one I could see
 the strongest case being made for.


I think we all know there are many insecure things about most login
systems, including our own. The question is what do we get for the
potential cost/risk. Obviously with Google and Facebook as options we don't
stand to gain a lot in terms of technical contributions. With GitHub, the
balance is probably tipped the other way. If we try it and in the long run,
it provides very little benefit, we could consider phasing it out.


 Enabling all of them seems like it'll just make the login page cluttered
 with
 options used by about 1-2 people each but I could be wrong.


Yes, absolutely. The login page of Phabricator's own phabricator instance
is an example of providing too many choices. This slows people down when
they have evaluate all the options.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Login to Wikimedia Phabricator with a GitHub/Google/etc account?

[Steven Walling]

On Thu, May 15, 2014 at 2:20 PM, Quim Gil q...@wikimedia.org wrote:

 However, Phabricator can support authentication using 3rd party providers
 like GitHub, Google, etc. You can get an idea at
 https://secure.phabricator.com/auth/start/


I think since this is already built and would require no extra work, we
should definitely support GitHub and Persona as well.

There are basically two types of users for our issue trackers and code
review tools:

1). Users who are already Wikimedia community members or staff. These users
will have Wikimedia and/or Labs accounts to authenticate with. This
includes basically all Wikipedians etc. as well. Wikimedia OAuth support
will make most of these people happy.

2.) Users who are technical or design-oriented who may be willing to help,
but who come from outside Wikimedia. Basically anyone who does FOSS
development these days has a GitHub account, which is a big part of why we
mirror to GitHub already. If we are serious about wanting to be friendly
towards additional open source contributors, all of these users will be
familiar with either GitHub or Persona. (Mozilla Persona is less
well-known, but is extremely user friendly and will be beloved by the hard
core FOSS person who doesn't like GitHub's centralized model).

Other providers (like Google, Facebook, etc.) are not really going to get
us a lot of extra traction among either Wikimedians or new technical
contributors. Plus, having too many choices is a bad user experience.[1]

Steven

1.
http://uxmyths.com/post/712569752/myth-more-choices-and-features-result-in-higher-satisfac
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] Rob Moen takes on new role in Growth team

[Steven Walling]

On Wed, May 7, 2014 at 2:46 PM, Terry Chay tc...@wikimedia.org wrote:

 Hello everyone,

 I’m pleased to announce Rob Moen is moving from the VisualEditor team to
 the Growth team.

 In Growth, Rob will fill the team's third full-time engineer position,
 joining Matthew Flaschen, Sam Smith, and Andrew Russell Green (who's
 collaborating with Growth on the Campaigns extension). With Rob's help, the
 team will be able to move faster on projects like its experiments acquiring
 anonymous editors and building features for new article creators.

 Rob has done amazing work on VisualEditor. Starting with when the team
 specifically requested him from Editor Engagement two years ago to work on
 the user interface features such as toolbars and inspectors and finishing
 up with mobile integration and major UploadWizard media integration
 changes.

 He’ll bring that deep knowledge of VisualEditor, OOJS, and OOUI to
 projects focused on experimentation and growth in the editor community.
 Besides being a rare combination of front-end and full-stack engineer with
 extensive MediaWiki experience, he’s also the only engineer in Growth in
 the same timezone as Steven Walling and the design team members.

 VisualEditor team is now looking for two candidates for open engineering
 positions, one of which will fill Rob's spot on the team. Check out the job
 description[0] especially if you can help refer someone.

 Take care,

 terry


I'm super happy to have Rob join us on Growth, obviously. :-)

+1 to what Sumana said. I think it's really healthy that in WMF
engineering, we've figured out how to let engineers, product managers, and
others switch teams gracefully and with minimal fuss. It's a credit to VE
team that they were so open to this idea.

Also: thank you to Emily in recruiting. It's been a long search for two
engineering candidates to fill the spots previously held on Growth by Ori
and S Page. We may not have ended up hiring someone externally for Rob's
position, but she has put in a huge effort to help teams like ours, and
will no doubt do the same for VisualEditor now too.

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Fwd: Typography refresh, now that dust has settled

[Steven Walling]

FYI, if you're interested in continuing to talk about this and related
issues, I strongly encourage Wikitech subscribers to join the Design list.

-- Forwarded message --
From: Steven Walling swall...@wikimedia.org
Date: Mon, Apr 28, 2014 at 6:42 PM
Subject: Typography refresh, now that dust has settled
To: A list for the design team. des...@lists.wikimedia.org


Hi everyone,

For curious, I wanted to share a quick update on the typography refresh.
The following four recent pieces of news that should be of interest...

1). The French Wikipedia community closed their vote on most aspects of the
new design (color, size, new headers, etc.) and it was very much in favor
of keeping the new design in all aspects.[a]

 2). Spanish Wikipedians also closed their vote, which was more of a simple
yes/no on whether to revert. This was also in favor of keeping the new
design.[b]

3). Jon Robson has put up a patch to allow LESS styles to be set
per-language.[c] This means that many local site hacks, like Japanese
Wikipedia removing the serif headers or Farsi Wikipedia having to set
completely different Farsi-friendly fonts, will potentially no longer be
necessary. Review and testing is needed!

4). For some time now MediaWiki.org and the test replica of English
Wikipedia (en.wikipedia.beta.wmflabs.org) have been using a new proposed
body font stack by Erwin Dokter. This puts Nimbus Sans L first, and
restores the other body font settings like Helvetica Neue for Mac users,
Arial for all Windows users etc. Please try it out, especially if you're on
Windows or Linux. We'd like to put this in Vector/core at some point, if we
can make sure it works.

Thanks!

a.
https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Prise_de_d%C3%A9cision/Affichage_par_d%C3%A9faut
b.
https://es.wikipedia.org/wiki/Wikipedia:Votaciones/2014/Sobre_la_actualizaci%C3%B3n_tipogr%C3%A1fica#No
c. https://gerrit.wikimedia.org/r/#/c/125760/

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/



-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Retrospective on Typography Refresh

[Steven Walling]

Hi all,

Typography Refresh was one of the first batch of Beta Features launched
last November. It's also now the first Beta Feature that was removed and
then deployed in core. You'll probably have noticed the many threads about
it on Wikitech in the past. ;-)

While this might not have been a particularly large technical change (it's
mostly just some tweaks to the Vector Less styles in core) we wanted to
publicly share notes from the team about it. The purpose of a retrospective
is to focus on concrete actions we can take to ensure good process.
Hopefully we have learned some lessons that could help other beta features
testing/release go smoothly.

Notes are up at
https://www.mediawiki.org/wiki/Typography_refresh/Retrospective if you're
interested. Since these reflect the feelings of the team working on it, I'd
like to ask that you first add questions and comments on the Talk page,
rather than directly to the document.

Thanks!

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [teampractices] RfC on Product Management Tools and Development Toolchain

[Steven Walling]

On Tue, Apr 15, 2014 at 9:19 AM, Dan Andreescu dandree...@wikimedia.orgwrote:

 I had volunteered my team to try it out for one of our projects, but I've
 been hesitating until we have a blessed version.


+1 for Growth.


-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposed body font stack for Latin

[Steven Walling]

On Tue, Apr 15, 2014 at 9:59 AM, Gergo Tisza gti...@wikimedia.org wrote:

- instead of guessing about user preferences, you could just create a
simple survey which shows them the same text with two different font
 stacks
side by side, and ask them which is more readable. This is good for
 making
aesthetic decisions more objective, and also for catching weird issues
 with
old machines, CJK fonts etc: you can add a comment field to the survey,
 and
if the browser is sufficiently modern to support canvas elements, you
 can
even save a snapshot if the rendered text; you can skim through the
 survey
replies which are different from what you have expected, and look for
display problems.


Are you volunteering to build such a survey tool? ;-)

We don't have a powerful/easy to use/not annoying/privacy-respecting survey
tool that can do side-by-side comparisons. This is why the feature was
launched using Beta Features for five months first. Putting out in opt-in
mode and gathering feedback via the channels we have now is the most
efficient way to make a change that doesn't have a big WMF team assigned to
like Multimedia or VisualEditor.

When it comes to using a survey to catch problems early and gauging
preferences, a survey still very much suffers from the self-selection bias
that all opt-in options have. It's just the name of the game. When you move
something from opt-in to opt-out you reach a wider audience and encounter
new complaints/questions/bugs.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposed body font stack for Latin

[Steven Walling]

On Tue, Apr 15, 2014 at 11:23 AM, David Gerard dger...@gmail.com wrote:

  We don't have a powerful/easy to use/not annoying/privacy-respecting
 survey
  tool that can do side-by-side comparisons. This is why the feature was
  launched using Beta Features for five months first. Putting out in opt-in
  mode and gathering feedback via the channels we have now is the most
  efficient way to make a change that doesn't have a big WMF team assigned
 to
  like Multimedia or VisualEditor.
  When it comes to using a survey to catch problems early and gauging
  preferences, a survey still very much suffers from the self-selection
 bias
  that all opt-in options have. It's just the name of the game. When you
 move
  something from opt-in to opt-out you reach a wider audience and encounter
  new complaints/questions/bugs.


 ... so the answer to what user testing did you do, where are the user
 test results is we didn't?


A survey and a user test are not the same thing. User test is also
slightly too generic for me to understand what you're asking. Are you
asking if we did scripted usability tests? Or are you asking if we ran an
A/B test with users?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposed body font stack for Latin

[Steven Walling]

On Tue, Apr 15, 2014 at 12:08 PM, Gergo Tisza gti...@wikimedia.org wrote:

  Are you volunteering to build such a survey tool? ;-)
 

 Will see if I find the time. Survey probably gives the wrong idea here,
 it is really just an overlay with two buttons, more of an interactive A/B
 test. Could be probably cobbled together from GuidedTours and EventLogging.


A similar toolkit that is extremely well-designed is Polar (polarb.com), if
you're looking for inspiration.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] English Wikipedia Homepage Framework

[Steven Walling]

On Tue, Apr 15, 2014 at 1:47 PM, Liangent liang...@gmail.com wrote:

 zhwiki main page is already div-based :)


Not surprising. zhwiki has one of the best-looking Main Pages around. :)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Documenting MediaWiki-Vagrant roles

[Steven Walling]

Please help fill in https://www.mediawiki.org/wiki/MediaWiki-Vagrant/Roles:)

It's hard to know what a role does precisely without more docs than are
provided via the 'vagrant list-roles' command. Maybe we could add a
description to the list there? First step would be getting content I guess.

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposed body font stack for Latin

[Steven Walling]

On Mon, Apr 14, 2014 at 3:55 PM, Isarra Yos zhoris...@gmail.com wrote:

 Deemed better? Better how? But that's what I'm saying - if the
 configuration is optimised for dejavu sans, nimbus won't be better at all
 even if it is a better-engineered font (doubtful, though, it being an arial
 clone from what I understand). Letters will be too close together, sizes
 and hinting will be off, and that's not even going into the whole rabbit
 hole of messing with what people are used to, which seems to be the single
 biggest determining factor as to what they find easy to read once the
 basics are covered...


Design involves making choices on the behalf of users. What color should
these buttons be? Where should this text go? We can't design for every
person's individual taste. We have to design for what we think will do the
most functional good for the most people. This is why the vast majority of
sites a user will visit on a regular basis do not simply leave typography
up to the browser defaults. Even MediaWiki, by choosing sans-serif for
many years, forced users who might want everything to be serif to not get
that.

To be honest Isarra, the number of emails and on-wiki comments you have
written with this exact same question is kind of mindblowing. You ask it
every time the subject comes up, regardless of which particular font stack
is under discussion or who is talking about it. No amount of detailed
explanation ever seems enough for you.

On Wikitech-l, Design-l, and in the extensive documentation on mediawiki.org,
people have laid out highly objective rationales for why each font and the
associated type sizing, spacing, leading, and more were selected to be
harmonious with each other. If your objection is not to the particular
choices made, but to the fact that we're making specific design choices at
all, I don't really think there's much point in talking about it more.

Steven
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

[Steven Walling]

On Thu, Apr 10, 2014 at 4:26 PM, Brian Wolff bawo...@gmail.com wrote:

 I would add as an issue, that there are major variance in the font
 selection based on platform and configuration. For some platforms, the
 typo refresh chooses a font that is significantly lower quality than
 the browser default (The opposite of bad defaults concern. I think
 the browser choosing a bad default is much rarer then typo refresh
 overriding the good browser default with something bad). So the
 question becomes, to what extent are we willing to degrade some users
 experience in order to make other user's experiance better. Which
 immediately raises the question of what is the level of degradation,
 and for how many people, compared to what is the level of user
 experience improvement, and for what percentage is the experience
 improved.

 By lower quality I mean both subjectively, but also objectively. For
 example, today I was reading

 https://en.wikinews.org/wiki/Hamilton_wins_%27incredible%27_Bahrain_race,_F1%27s_900th_Grand_Prix
 (enwikinews is one of the few wikis I haven't overridden the font
 changes with css). At first I thought there was a typo in the image
 caption toward the end of the page, an extra space between prote and
 stor. But no, the kerning on the font chosen is just literally that
 bad, that you can't tell if it is an extra space, or just a kerning
 error. I call that objectively bad (There's other things I don't like
 about the font choice, but they are more touchy-feely subjective)


I've filed this at https://bugzilla.wikimedia.org/show_bug.cgi?id=63807 so
we can talk in more detail outside the thread. I tested again in Chrome and
Firefox on Linux.

Steven
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users; final plea!

[Steven Walling]

On Fri, Apr 11, 2014 at 9:44 AM, Erwin Dokter er...@darcoury.nl wrote:

 I forgot to include the URL:

 [1] https://www.mediawiki.org/wiki/Talk:Typography_refresh#
 Languages_problems


Out of all of these, the most clear is that serifs are not great for the
headings in CJK (Chinese, Japanese, Korean) languages. This seems to be
true even of default 'serif', per
https://bugzilla.wikimedia.org/show_bug.cgi?id=63817

In the interim, I'm going to help the wikis with these languages if they
want to set a local override. Starting next week, I think Jon and I would
like to explore how to extend our Less variables to set a better default
for headings in CJK languages. (I will file a bug today).

This is a pretty important enhancement for the long run I think. There are
wikis like Farsi and Japanse Wikipedia that have needed to override the
default settings basically forever, to get good basic readability. If we
can use Less to set language-specific fonts then we can start upstreaming
some of the settings that have lingered in Vector and Common CSS for a long
time.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users; final plea!

[Steven Walling]

On Fri, Apr 11, 2014 at 10:01 AM, Erwin Dokter er...@darcoury.nl wrote:

 There is also a tracking bug [2] with plenty bugs attached, among the [3],
 [4] and [5]; *all* language related. Buth the bug reports and Typography
 talk page have plenty of screenshots.

 [1] https://www.mediawiki.org/wiki/Talk:Typography_refresh#
 Languages_problems
 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=63549
 [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=63720
 [4] https://bugzilla.wikimedia.org/show_bug.cgi?id=63718
 [5] https://bugzilla.wikimedia.org/show_bug.cgi?id=63817


3 is not language-related, it's about how some users have bad (basically
knockoff) versions of Helvetica installed by HP printers or the user, which
render poorly on older Windows systems. We're trying to figure out whether
this is a real problem at scale, or whether the best thing to recommend is
to simply turn off those fonts, since they won't render well on any site.

4 is a bug that needs to be dealt with in ULS, per Santhosh's comment at
https://bugzilla.wikimedia.org/show_bug.cgi?id=63718#c5

5 will be fixed per what I said in the email just before.

The one thing on the mediawiki.org Talk page we haven't fully investigated
is the potential issue with inconsistent x-height in Cyrillic. We still
need to figure out whether that's font specific, browser specific or what.
There are no details present about what OS/font is used in that report, so
we need to investigate how widely applicable the report actually is.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users; final plea!

[Steven Walling]

On Fri, Apr 11, 2014 at 11:17 AM, Brian Cox
nativeforeignerw...@gmail.comwrote:

 Perhaps all the user reported bugs should be added to Bugzilla for tracking
 purposes. But it's not reasonable to expect the average user to report them
 there.

 Brian/NF


Yes I think we definitely need to track things in Bugzilla, but you're
right Brian. The average reader especially is not going to be able to
figure out bug filing.

Nemo, Jared, and others have been trying to migrate bugs there or ask
people to do so where they can.  Nemo in particular deserves thanks for
trying to spend some time helping us wrangle Bugzilla for typography
refresh. :) Once things are tracked there and we can replicate them, we'll
do our best to fix issues that are widely applicable.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

[Steven Walling]

On Fri, Apr 11, 2014 at 11:42 AM, Bartosz Dziewoński matma@gmail.comwrote:

 I have merged the Gerrit change (https://gerrit.wikimedia.org/
 r/#/c/124475/),
 restoring the body font to sans-serif. The heading font is unchanged for
 now.

 I've read the entire wikitech-l thread (89 emails as of writing) and
 pondered this carefully. My summary of the situation is:

 * This font stack, according to WMF Design, only provides real
   improvements for Macs (~6% of Wikimedia sites visitors per
   http://stats.wikimedia.org/wikimedia/squids/
 SquidReportOperatingSystems.htm)
   and should be (nearly) identical to defaults for other systems.
   However, it causes major rendering issues for an unspecified number
   of Windows and Linux users (especially with, respectively, Helvetica
   and Nimbus Sans L; see both open and closed dependencies of bug
   63549).
 * This font stack also apparently causes issues with non-Latin-script
   languages (not very well-specified ones, though; more bug reports
   like bug 63817 would be welcome); it's serious enough for at least
   one affected Wikimedia wiki (the Japanese Wikipedia) to have already
   reset the stack to sans-serif. This might affect the serif heading
   fonts more than the sans-serif body fonts (again, more precise
   reports needed).
 * The wikitech-l discussion, as well as various on-wiki discussions
   (e.g. on WP:VPT on the English Wikipedia) have been overwhelmingly
   in favor of restoring the plain sans-serif font definition.
 * Orthogonally to these issues, all other aspects of the typography
   refresh have been generally considered successful and minor problems
   with them have been quickly fixed.

 Based on the points above and my own common sense I think this should
 be merged, and a similar follow-up for serif heading fonts might also
 be necessary (but that's obviously a lower-severity problem, there
 isn't that much text in headings). Steven, I'm sorry, but I'm
 overriding your -2.

 (I'm posting this on the Gerrit change
 https://gerrit.wikimedia.org/r/#/c/124475/, on the tracking bug
 https://bugzilla.wikimedia.org/show_bug.cgi?id=63549 and in the
 wikitech-l thread. Please reply on wikitech-l.)


Replicating what I wrote on the patch:

Bartosz: thanks for the considered, factual take on the matter. I
appreciate you taking the time to read up on everything though obviously I
disagree about Nimbus Sans L and Helvetica Neue not being improvements.

I would caution against being English Wikipedia centric in talking about
user acceptance of the new typography. Spanish Wikipedia is far less
aligned against it (
https://es.wikipedia.org/wiki/Wikipedia:Votaciones/2014/Sobre_la_actualizaci%C3%B3n_tipogr%C3%A1fica)
and other wikis (German, French) have declined to open a vote on the matter
while they wait for continued tweaks from us. I posted in the other thread
Erwin started about our plan for dealing with serifs in non-Latin languages.

In any case, I think this is acceptable for now since we can always submit
a new patch again later that puts a free/libre font first in addition to
the current stack being reverted. Either way we need to do more research
and testing to accomplish that, or even explore webfonts more.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposed body font stack for Latin

[Steven Walling]

On Friday, April 11, 2014, Erwin Dokter er...@darcoury.nl wrote:

 First, I like to aplologize to anyone who I may have come over too
 passionate at some times. Frustration is known to get the better of me,
 even though I should control that. (I also quit smoking.)


Much harder to quit than to find a perfect font stack that pleases
everyone. :) Thanks for all your work on this Erwin.



 Not sure where a new font stack should be discussed, so I'm just throwing
 it in here. Also, note I propose this for Latin wikis only.

 Asuming we want the 'Helvetca' look for the body font:

 font-family: Nimbus Sans L, Helvetica Neue, Arial, Helvetica,
 sans-serif;

 Breakdown:

 Nimbus Sans L - for Linux. This is the defacto helv font on Linux systems
 which result in an look similair to Mac/Windows. Windows will not match
 this font, as the Windows versions of the Nimbus font packages have
 different font family names (ie. 'NimbusSanL' instead of 'Nimbus Sans L').


This is the part I want to confirm and test. I want to be 100% sure that we
are not gonna run in to the same ClearType rendering issues. (I have a
Windows 7 laptop at my disposal that I can test with, as well as XP virtual
machines.)



 Helvetica Neue - for Mac. Like Nimbus, this should not match fonts on
 Windows (or Linux for that matter), as those copies for Windows have
 differen font family names (like 'Helvetica Neue LT Com 55 Roman').

 Arial - For Windows. Positioned after Nimbus Sans and Helvetica Neue, so
 Mac and Linux do not match Arial, but positioned before Helvetica to
 prevent matching an inferiour Helvetica font that may be installed on some
 Windows machines.

 Helvetica - Generic Helvetica fallback for any system not matching any of
 the previous fonts.


Putting this after Arial will avoid any Windows users getting a bad version
of Helvetica rendered on their machines.



 I'd like to test this locally on the English Wikipedia, and I am quit
 confident this makes everyone happy because 1) every OS should end up using
 a native font, and 2) it promotes a free font at the beginning of the
 stack (not a high priority in my book though).


Why don't we test this on Beta Labs and Mediawiki.org first instead of using
enwiki as a guinea pig? We can make you a sysop there.



 Next up I may think about the headers font stack; While Georgia is a good
 serif; I detest its use of text figures.


Times and Times New Roman are worse overall. ;)



 Regards,
 --
 Erwin Dokter


 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Keeping Code-Review votes across trivial changes of patch sets?

[Steven Walling]

On Friday, April 11, 2014, Christian Aistleitner christ...@quelltextlich.at
wrote:

 Hi,

 TL;DR: Gerrit would allow to keep Code-Review votes across
 * rebases and
 * commit message modifications
 of patch sets.

 Thereby dropping need to re-review trivial changes on patch sets.

 Shall we turn that feature on?


Yes please.



 
 Longer version.

 Currently, upon uploading a new patch set for a change in gerrit,
 votes get scrubbed. Especially, all Code-Review votes except -2 are
 gone.

 However, for new patch sets that
 * are a plain rebase, or
 * only change non-code parts (commit message, ...)
 gerrit would allow to reapply votes of the previous patch set to the
 new patch set.

 People asked me to turn this feature on gerrit-wide for the
 Code-Review label.

 But I would not want to turn it on without giving people a chance to
 discuss it beforehand.

 So ... example: Assume for a given change the current patch set's votes
 are:

   +-+-+--+
   | Reviewer| Code-Review | Verified |
   +-+-+--+
   | Foo |  +2 |  |
   | Bar | |   +1 |
   | Baz |  +1 |   -1 |
   | Qux |  -2 |  |
   | jenkins-bot | |   +2 |
   +-+-+--+

 Assuming we turn the feature on in gerrit, and I upload a plain rebase
 of the current patch set, the votes for the plain rebase would be

   +-+-+--+
   | Reviewer| Code-Review | Verified |
   +-+-+--+
   | Foo |  +2 |  |
   | Bar | |  |
   | Baz |  +1 |  |
   | Qux |  -2 |  |
   | jenkins-bot | |  |
   +-+-+--+

 right after uploading the rebase to gerrit (instead of the current
 behaviour of an empty table with only Qux CR-2). Same if I only edit
 the patch set's commit message.

 But if I upload a patch set that is changing the patch set's diff, the
 table of votes would of course still get scrubbed of all votes except
 -2 on Code-Review (as it also the case right now):

   +-+-+--+
   | Reviewer| Code-Review | Verified |
   +-+-+--+
   | Foo | |  |
   | Bar | |  |
   | Baz | |  |
   | Qux |  -2 |  |
   | jenkins-bot | |  |
   +-+-+--+


 Should we turn that feature on?


 Best regards,
 Christian



 --
  quelltextlich e.U.  \\  Christian Aistleitner 
Companies' registry: 360296y in Linz
 Christian Aistleitner
 Gruendbergstrasze 65aEmail:  christ...@quelltextlich.atjavascript:;
 4040 Linz, Austria   Phone:  +43 732 / 26 95 63
  Fax:+43 732 / 26 95 63
  Homepage: http://quelltextlich.at/
 ---

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikitech-ambassadors] Roadmap and deployment highlights - Week of April 14th

[Steven Walling]

On Fri, Apr 11, 2014 at 4:15 PM, Greg Grossmeier g...@wikimedia.org wrote:

 * Revert font stack change in Typography Refresh to be just sans-serif
 ** https://gerrit.wikimedia.org/r/#/c/125447/


To be clear per the amended commit message: this is just for the body font
stack. All other aspects of the typography update (serif headsing, new font
size, new body font color, spacing, etc.) are in place. This will also
deploy a small bug fix which improves the line height (thanks Erwin!).

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

[Steven Walling]

On Thu, Apr 10, 2014 at 12:10 PM, Quim Gil q...@wikimedia.org wrote:

 On Thu, Apr 10, 2014 at 9:54 AM, Erik Moeller e...@wikimedia.org wrote:

 (snip)

  My understanding is that there are three separate major issues:
 
  * serif may not be a good choice for certain languages

  * The explicitly specified sans-serif stack needs to be further
  optimized

  * some people feel that either reverting to the previous state would be
 preferable. The

  Are those the main issues? Am I misrepresenting anything or forgetting
  something / additional major issues?

 The analysis of these points looks accurate. We could add:

 * A MediaWiki Core change vs a Wikimedia specific configuration.


I definitely agree with Erik's summation, but I would not like to open up
discussion about Wikimedia-specific consideration vs. core, which is a
broader question about what Vector should be/do that I don't think should
block us reaching a consensus on typography in the meantime.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

[Steven Walling]

On Wed, Apr 9, 2014 at 9:44 PM, Gerard Meijssen
gerard.meijs...@gmail.comwrote:

 Given that you do have statistics, how did all the huha around the ULS
 performance issue and now all this hit the use of the functionality for
 dyslexic people?


I'm not sure what statistics you're referring to.


 We know that it helps but how do we help people with dyslexia? They are
 only 7 to 10% of a population.. I have not done the arithmetic but would
 that be more than 7 to 10% of all our readers? (what is the breakdown in
 fonts for our total public)


In the FAQ (https://www.mediawiki.org/wiki/Typography_refresh#FAQ) we
specifically mentioned enhancing the view for dyslexic users as one of the
reasons why the body font color was changed. To go in to more detail about
other aspects... dyslexic users is one of the reasons why we did not
suggest we switch to a serif for body text along with the headers. As far
as I understand, it's also a reason to not specify a more humanist-style
sans-serif like Open Sans, Verdana, or DejaVu where the letterforms have
more calligraphic characteristics compared to a Grotesk-style sans like
Arial, Helvetica, and Nimbus.

Of course there is also the question about whether to deliver Open Dyslexic
as a webfont option via ULS. I don't know why it was removed and how that
decision was made, so I can't comment on it.

Steven
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Free fonts and Windows users

[Steven Walling]

On Thursday, April 10, 2014, MZMcBride
z...@mzmcbride.comjavascript:_e(%7B%7D,'cvml','z...@mzmcbride.com');
wrote:

 Erik Moeller wrote:
 On Thu, Apr 10, 2014 at 7:39 AM, Derk-Jan Hartman
 d.j.hartman+wmf...@gmail.com wrote:
  So for me, the question is not how can we apply pretty serif fonts to
  headers, the question is what can we do short term and long term to
  make that happen.
 
 It would be good if we could focus the conversation as much on
 concrete bugs and issues as possible.

 You mean something like this?

 Derk-Jan Hartman wrote:
 Short term:
 * Accept that the current solution is not working
 * Rely on Operating System to make the best choice it can, because we
 cannot do better (return to status quo)
 * Accept that maybe it might just not be possible right now
 * Gather statistics on cleartype font rendering (just like we look at
 tofu).
 * See if there are ways to make the target group to which the font
 change is applied narrower/stricter/better defined.
 


How are these specific, replicable bugs? DJ is saying things the current
solution is not working and we cannot do better but there is no
evidence about why this is the case for such a large number of users that
it requires a revert back to plain sans-serif.

People are talking in generalities and about problems related to areas like
non-Latin script support, but not referring to bugs filed and which would
be fixed by the suggested patch.

Meanwhile, in this thread and in the documentation on mediawiki.org, we
have been extremely specific about how each aspect of the new typography
(including the body fonts specified) is a pragmatic improvement for users,
and what we lose by reverting that part. I also posted links to that effect
on the patch.

The patch as it stands does not refer to an unresolved bug or enhancement.
It also explicitly refers to the issue as an ideological one
about promoting non-free fonts in our code, even though Jon already wrote a
FIXME acknowledging this.

Unless you can raise issues that cause actual functional problems that
outweigh the benefits of the new body font stack, I don't think merging
that patch is required to improve things for readers and editors, and is
worth the churn in the user experience for millions of readers and editors.

Steven




 I agree with all of this. Both Erik's and Derk-Jan's posts are very
 good, but I get the feeling that people are talking past each other in
 this thread sometimes.

 As Quim notes, there's an upcoming MediaWiki release. We should merge
 https://gerrit.wikimedia.org/r/124475 into master and figure out what to
 do with the other font-family adjustments for the short-term.

 There seems to be demonstrable consensus for merging Gerrit change 124475
 into master, though Steven refuses to remove his -2, which he should never
 have been able to set. If you (Erik) are truly interested in focusing the
 conversation on concrete bugs and issues, that's where I would start.

 MZMcBride



 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Free fonts and Windows users

[Steven Walling]

On Thursday, April 10, 2014, MZMcBride z...@mzmcbride.com wrote:

 Erik Moeller wrote:
 On Thu, Apr 10, 2014 at 7:39 AM, Derk-Jan Hartman
 d.j.hartman+wmf...@gmail.com wrote:
  So for me, the question is not how can we apply pretty serif fonts to
  headers, the question is what can we do short term and long term to
  make that happen.
 
 It would be good if we could focus the conversation as much on
 concrete bugs and issues as possible.

 You mean something like this?

 Derk-Jan Hartman wrote:
 Short term:
 * Accept that the current solution is not working
 * Rely on Operating System to make the best choice it can, because we
 cannot do better (return to status quo)
 * Accept that maybe it might just not be possible right now
 * Gather statistics on cleartype font rendering (just like we look at
 tofu).
 * See if there are ways to make the target group to which the font
 change is applied narrower/stricter/better defined.
 


How are these specific, replicable bugs? DJ is saying things the current
solution is not working and we cannot do better but there is no
evidence about why this is the case for such a large number of users that
it requires a revert back to plain sans-serif.

People are talking in generalities and about problems related to areas like
non-Latin script support, but not referring to bugs filed and which would
be fixed by the suggested patch. Brian's recent comment here is an example
of what we are asking to hear, though I don't think that requires a full
revert.

Meanwhile, in this thread and in the documentation on mediawiki.org, we
have been extremely specific about how each aspect of the new typography
(including the body fonts specified) is a pragmatic improvement for users,
and what we lose by reverting. I also posted links to that effect on the
patch.

The patch as it stands does not refer to an unresolved bug or enhancement.
It also explicitly refers to the issue as an ideological one about
potentially promoting non-free fonts in our code, even though Jon already
out a FIXME acknowledging this.

Unless you can raise issues that cause actual functional problems that
outweigh the benefits of the new body font stack, I don't think merging
that patch is required to improve things and is worth the churn in user
experience for millions of readers.

Steven




 I agree with all of this. Both Erik's and Derk-Jan's posts are very
 good, but I get the feeling that people are talking past each other in
 this thread sometimes.

 As Quim notes, there's an upcoming MediaWiki release. We should merge
 https://gerrit.wikimedia.org/r/124475 into master and figure out what to
 do with the other font-family adjustments for the short-term.

 There seems to be demonstrable consensus for merging Gerrit change 124475
 into master, though Steven refuses to remove his -2, which he should never
 have been able to set. If you (Erik) are truly interested in focusing the
 conversation on concrete bugs and issues, that's where I would start.

 MZMcBride



 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

[Steven Walling]

On Thursday, April 10, 2014, Steven Walling steven.wall...@gmail.com
wrote:



 On Thursday, April 10, 2014, MZMcBride z...@mzmcbride.com wrote:

 Erik Moeller wrote:
 On Thu, Apr 10, 2014 at 7:39 AM, Derk-Jan Hartman
 d.j.hartman+wmf...@gmail.com wrote:
  So for me, the question is not how can we apply pretty serif fonts to
  headers, the question is what can we do short term and long term to
  make that happen.
 
 It would be good if we could focus the conversation as much on
 concrete bugs and issues as possible.

 You mean something like this?

 Derk-Jan Hartman wrote:
 Short term:
 * Accept that the current solution is not working
 * Rely on Operating System to make the best choice it can, because we
 cannot do better (return to status quo)
 * Accept that maybe it might just not be possible right now
 * Gather statistics on cleartype font rendering (just like we look at
 tofu).
 * See if there are ways to make the target group to which the font
 change is applied narrower/stricter/better defined.
 


 How are these specific, replicable bugs? DJ is saying things the current
 solution is not working and we cannot do better but there is no
 evidence about why this is the case for such a large number of users that
 it requires a revert back to plain sans-serif.

 People are talking in generalities and about problems related to areas
 like non-Latin script support, but not referring to bugs filed and which
 would be fixed by the suggested patch. Brian's recent comment here is an
 example of what we are asking to hear, though I don't think that requires a
 full revert.

 Meanwhile, in this thread and in the documentation on mediawiki.org, we
 have been extremely specific about how each aspect of the new typography
 (including the body fonts specified) is a pragmatic improvement for users,
 and what we lose by reverting. I also posted links to that effect on the
 patch.

 The patch as it stands does not refer to an unresolved bug or enhancement.
 It also explicitly refers to the issue as an ideological one about
 potentially promoting non-free fonts in our code, even though Jon already
 out a FIXME acknowledging this.

 Unless you can raise issues that cause actual functional problems that
 outweigh the benefits of the new body font stack, I don't think merging
 that patch is required to improve things and is worth the churn in user
 experience for millions of readers.

 Steven


Sorry that Gmail mobile sent that twice. :/






 I agree with all of this. Both Erik's and Derk-Jan's posts are very
 good, but I get the feeling that people are talking past each other in
 this thread sometimes.

 As Quim notes, there's an upcoming MediaWiki release. We should merge
 https://gerrit.wikimedia.org/r/124475 into master and figure out what
 to
 do with the other font-family adjustments for the short-term.

 There seems to be demonstrable consensus for merging Gerrit change 124475
 into master, though Steven refuses to remove his -2, which he should never
 have been able to set. If you (Erik) are truly interested in focusing the
 conversation on concrete bugs and issues, that's where I would start.

 MZMcBride



 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

[Steven Walling]

On Tue, Apr 8, 2014 at 10:05 PM, Risker risker...@gmail.com wrote:

 It's pretty clear that the objectives of this project are not successfully
 met at this point, and in fact have caused major problems on non-Latin
 script WMF sites, and significant but less critical problems on Latin
 script sites. Several factors for this have been identified in the thread -
 including limited attention to the effects on non-Latin script projects,
 the insertion of philosophical principles (FOSS) without a clear
 understanding of the effects this would have on the outcome, and the
 unwillingness to step back when a major change results in loss of
 functionality.


[citation needed]

Loss of functionality? The functionality we're talking about here is
reading of Wikimedia content. It's the most core, most basic functionality
we have. In the case of VisualEditor, which picks up read-mode typography
styles, it's also editing.

Did reading suddenly become seriously impaired? No. If these things had
happened, you'd see a hell of a lot more outcry than what we've seen now.
If millions of readers and tens of thousands of editors were functionally
unable to read our content easily and smoothly, you would hear a lot more
complaints. If you didn't hear complaints, you'd probably still see a swift
drop in pageviews.[1]

Instead, what I see is this: a tiny handful of bugs raised.[2] I also see a
relatively small number of editors complaining on Village Pumps -- we have
75,000+ contributors a month. 137 of them have showed up to complain in
English so far, our largest project. Fewer in other languages. Does that
suggest to you most of our editors are having serious functional issues
reading, particularly when we had 14,000 registered users voluntarily
opt-in to the changes? For reader feedback: comments from readers (on-wiki
and off) have slowed significantly in the days since the change was
made.[3] The same look has been in place on mobile (20% of our traffic) for
more than a year with basically zero complaints.

This is the first time we've significantly changed Wikimedia typography in
many years. I do not under any circumstances suggest that everything has
gone forward with perfect smoothness. I also 100% agree it can and should
continue to improve.[4] Particularly, I agree that in the immediate future
we need to pay more attention to non-Latin wikis, though everyone keeps
saying major problems without actually being specific about what bugs
there are, which doesn't really help constructively. I also would prefer to
find a freely-licensed font to put first in the stack again, as soon as we
can get one that doesn't cause bugs for users on Windows systems. But to
suggest the project was a failure and that is serious loss of reading
functionality is just untrue and frankly hyperbolic.

Steven

1. Our realtime pageviews data is lacking, but HTTP requests and edit rates
for top wikis via gdash.wikimedia.org don't seem to show unusual drops. Am
I wrong?
2. See https://bugzilla.wikimedia.org/show_bug.cgi?id=63549 for tracking.
Only four are open, and they pretty minor.
3.
https://en.wikipedia.org/wiki/Wikipedia:User_experience_feedback/font_sizeas
an example had many comments the first two days. As of today and
yesterday, there are a tiny handful. OTRS has not even had enough comments
to warrant creating a template response. And the number of tweets and
Facebook comments has died down to almost nothing.
4. We're going to hold a retrospective on the process around this change
later next week. That will include a public wiki page with more opportunity
for people to suggest ways the general process of Beta Features
testing/graduation can be handled better.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

[Steven Walling]

On Wed, Apr 9, 2014 at 9:33 AM, David Gerard dger...@gmail.com wrote:

 On 9 April 2014 17:30, Brian Wolff bawo...@gmail.com wrote:

  That said, we shouldn't be afraid of making changes where we
  reasonably think they might be a good idea, even without evidence they
  actually are. You can't have data on everything. I just don't like
  Well we are undoubtedly making things better for the reader used as
  a counter argument to criticism when we simply don't know what it will
  do for the average reader.



 Yes, it is the sort of statement that probably should not be used
 without being followed by a link to actual UI testing results.


I should follow up on this and say that no one working on the Beta Feature
thinks it's a good idea to try and design typography that only works for
people who aren't logged in/don't edit. The design goals listed at
http://blog.wikimedia.org/2014/03/27/typography-refresh/ and
https://www.mediawiki.org/wiki/Typography_refresh#Summary_of_changes are
pretty universal to all users, as they should be.

I don't really think that when it comes to typography, either type of
visitor to Wikimedia sites is more or less important when it comes to
listening to feedback. Even if Nathan was right, sometimes it's hard for us
to balance the two. What I said in reply to Risker is that I don't think
there saying the change is a failure is fair or true, based on the level
and kind of feedback we've been getting from both readers *and* editors.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

[Steven Walling]

On Tue, Apr 8, 2014 at 8:10 AM, Isarra Yos zhoris...@gmail.com wrote:

 Linux often gets arial. Anyone with wine will probably have it installed,
 too, and most will have wine even if they don't use it. It's not
 necessarily a particularly good copy, either.


With the current stack that won't happen even if the user has downloaded
Arial, because Helvetica comes before Arial in the font-family settings.
Linux systems (you can check this using fc-match
https://en.wikipedia.org/wiki/Fontconfig#Utilities) recognize and try to
match Helvetica first. We specifically put Helvetica there first so Linux
users would always get a good free font they have that is equivalent. For
most users (Ubuntu, Debian) this will be Nimbus Sans L.

Steven
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

[Steven Walling]

On Tue, Apr 8, 2014 at 12:33 PM, Martijn Hoekstra martijnhoeks...@gmail.com
 wrote:

 On Tue, Apr 8, 2014 at 8:13 PM, Erik Moeller e...@wikimedia.org wrote:

  On Tue, Apr 8, 2014 at 10:59 AM, Martijn Hoekstra
  martijnhoeks...@gmail.com wrote:
   So, the font stack changes with regards to the status quo now change
   nothing for Windows users, changes Helvetica - Helvetica neue for Mac
   users and changes Arial, DejaVu Sans or Arimo for possibly something
  else,
   amongst which Nimbus Sans L, maybe, maybe not.
 
  Actually, it's a bit more complicated. All users get serif fonts for
  headings, which they didn't before and which is probably the biggest
  visual before/after difference. The serif fonts still prioritize
  free/libre fonts over non-free ones.
 
  The body fonts prioritized free/libre fonts on deployments, but for
  Windows users without ClearType/anti-aliasing, those render very
  poorly, so they were disabled shortly after deployment. This is now
  causing people to be upset because the initial agreement to never
  prioritize non-free fonts is no longer maintained for the body.
 
  Odder's patch would revert to sans-serif as a generic classification
  for the body, but doesn't touch the font specification for the headers
  (yet). The commit summary is a bit misleading in that regard.
 

 Yes, I should have made that clear: I do very much support the Odder
 patch[1] ( https://gerrit.wikimedia.org/r/#/c/124475/ ) that reverts body
 to sans serif and keeps @content-heading-font-family: Linux Libertine,
 Georgia, Times, serif;

 That is not the status quo, but the diff between the Odder patch and the
 typography refresh basically is the Set a non-free font stack to give Mac
 now Helvetica Neue rather than Helvetica, with a -2 is planted in the
 ground before as a demarcation line. That's the point that I don't think is
 worth having a non-free font-stack for, and that I certainly think standing
 your ground for the brave new world of typography refresh is constructive
 for.


This is a persistent myth floating around about this. Neue for Mac users is
most definitely not the only effect of explicitly declaring the stack. As
Jared, S Page, and others have already pointed out, and as is stated in the
FAQ on mediawiki.org, the impact of the current stack is:

-- Linux users get Nimbus Sans L, instead of DejaVu Sans, Liberation Sans,
or whatever else the default sans is on your distro. Nimbus has an improved
x-height and is much more consistent with the other sans-serifs we're
specifying.
-- Windows users always get Arial, unless they have Helvetica installed.
This means many of the Windows users who might otherwise have set an
alternative sans in their browser default (like Verdana or Tahoma) will now
always get Arial.
-- And yes, Mac users or those with it installed get Neue Helvetica instead
of older version. This is a minor but worthwhile improvement for Mac users.
For example, Neue Helvetica actually has properly designed font weights for
bold, italic, etc. so that the cap height and x-height are consistent
between weights. Regular Helvetica was really not consistently designed
across weights.

Declaring some of the system defaults explicitly is not only an improvement
for Mac users. It means that regardless of whether you switch between
devices/browsers, you always get a grotesque/neo-grotesque sans-serif (
https://en.wikipedia.org/wiki/Vox-ATypI_classification) which is ideal for
reading long, large blocks of text and is more neutral.



 [1]My only nitpick about it is that I'm wondering what Times is doing in
 that stack. I can't think of any situation where a user wouldn't have Linux
 Libertine or Georgia, but does have Times, yet doesn't have it as its
 default serif font. When one has specifically set a default serif different
 from Times, you probably have a good reason for it - or at least a better
 reason than the websites desire for Times, and we should respect that. Yet
 this beef is very small compared to all other issues in this thread.


Times, like setting Helvetica, is there because it's what Linux systems
recognize and match to. Linux fc-match has no idea what Georgia and Linux
Libertine are unless you've installed them. By setting Times, we ensure
that Linux uses Nimbus Roman No9 L for headings, which complements the body
typeface selected on Linux well and which is consistent in style with the
other serifs specified.

A lot of this stuff is already documented in the FAQ on [[Typography
refresh]] on mediawiki.org. We produced it to answer the basic questions
just like this.




 
  There's some additional discussion about Georgia as a font choice due
  to its use of text figures (AKA old-style numerals), which some people
  find look odd in headings with numbers, especially in non-Latin
  scripts where old-style numerals may not be commonly encountered. Due
  to this, some are arguing for also changing the style for headings to
  serif (_not_ sans-serif) as a generic 

Re: [Wikitech-l] Free fonts and Windows users

[Steven Walling]

On Tue, Apr 8, 2014 at 2:18 PM, Matthew Walker mwal...@wikimedia.orgwrote:

 Perhaps this is a question that has an answer elsewhere but, irrespective
 of if this change should be made to WMF wikis, why are we:

 a) Making this a change in core?

 and b) Not making the change in core be a SASS variable that can then be
 set as a preference somewhere? (I say this because we've consistently
 identified that some languages need different default fonts. If it was a
 preference in that we could set via our multiversion scripts it would
 obviate the need for overrides in common.css just to make things work.)


The patches (such as the first one at
https://gerrit.wikimedia.org/r/#/c/120978/) are to the LESS variables that
define Vector styles. So they're in core because Vector is in core. Based
on conversations with Jon we should be able to work out how to do per-wiki
or preferably per-language styles, right?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

[Steven Walling]

On Mon, Apr 7, 2014 at 1:19 PM, Jon Robson jrob...@wikimedia.org wrote:

 1) Picking a new open font that is either
 ** widely available on Linux but not so much on Windows
 ** renders well in Windows


Coming back to the above option...

Today we spent some time testing a stack that puts Nimbus Sans L first,
before Helvetica Neue. This is the font that currently most Linux users
(we've tested on Ubuntu and Debian) are getting via matching to Helvetica
regular. The thing we tested for primarily is how this font renders on
Windows, for the users who may have it. So far it unfortunately appears
that for Windows users with ClearType turned off, Nimbus Sans also suffers
from bug 63512, like Liberation Sans does. (Screengrab from a Windows 7
machine I have for testing: http://i.imgur.com/pAHTu1f.png).

I would like to keep trying to find a freely-licensed font that A) matches
the other neutral sans-serifs that we have specified and B) which we feel
comfortable putting first in the stack, meaning that it renders well on
Windows, Linux, and Mac on major browsers. So far we are still coming up
short.

[I am copying the above to the Talk page on mediawiki.org in case anyone
else is interested.]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

[Steven Walling]

On Mon, Apr 7, 2014 at 1:52 PM, Isarra Yos zhoris...@gmail.com wrote:

 5) Restore the status quo - specifying 'sans-serif' as the font, which
 translates to the default font for the platform, had none of these
 problems, and resulted in fonts for all platforms which were good for those
 platforms (though perhaps not necessarily the best).


We're not going to do this.

 The idea that one bug requires a complete revert and even more disruption
for users is pretty absurd. Do we revert deployment of an extension every
time a bug occurs? No. We do it when the disruption caused by keeping the
new version is greater than taking it away again. This is not one of those
times.

We made the last change, which includes vital improvements besides slightly
altered body copy font family, after months of testing and prep. But all
new software has bugs, even simple LESS-only changes when they have a
scope this wide. The latest patch by Jon was a bug fix, but that doesn't
mean we're going to cause further disruption for users by completely
reverting back to the old defaults.

What we're going to do is discuss the options Jon laid out for trying to
promote free fonts in our stack, while also being practical and retaining
the enhancements that most users have been delivered so far. This is why we
iterate on changes in any realm of design and development.

I'll also nudge us here to remember that we cannot make design decisions
like this in a vacuum, without feedback from non-technical users. It wasn't
perfect, but we've been working hard to do that as part of Typography
Refresh. Jon's latest bug fix itself is based on reports from many users.
So far they've been thankful we did this.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

[Steven Walling]

On Mon, Apr 7, 2014 at 3:42 PM, Jon Robson jdlrob...@gmail.com wrote:

 I noticed from Kaldari's notes [1] that Open sans was rejected based
 on language support and install base. I notice however that it is
 pretty popular on the web [2,3]. Can someone elaborate on these
 results as it is surprised me?

 To me we can learn from this experience that install base (especially
 where Windows is concerned) is probably not such an important factor.
 The language support is more of an issue, but I wonder if this can be
 resolved by specific font stacks with more suitable open fonts is
 provided.

 To improve install base we can easily iterate on this and start using
 web fonts in some form in the future.

 [1]
 https://www.mediawiki.org/wiki/Typography_refresh/Font_choice#Body_font_evaluation
 [2]
 http://www.typeandgrids.com/blog/the-ten-most-popular-web-fonts-of-2013
 [3]
 http://www.smashingmagazine.com/2014/03/12/taking-a-second-look-at-free-fonts/


A similar example is Google's Noto font (
https://en.wikipedia.org/wiki/Noto_fonts). It has basically no default
install base that I'm aware of, but it's focused on readability in as many
scripts as possible and is Apache-licensed.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

[Steven Walling]

On Mon, Apr 7, 2014 at 5:46 PM, Brian Wolff bawo...@gmail.com wrote:

 No you don't get more consistency by moving back to an experience
 where you let the browser determine fonts. However you do get a
 situation where things are more likely to work for non-latin scripts
 (and other issues that have been brought up, if I understand
 correctly). Consistency and actually working for all scripts are
 separate goals. If you can't satisfy both, you're going to have to
 make one take higher priority than the other. I personally consider
 the Actually working for all languages to be much more important
 consideration than consistency.


I totally agree. I don't see how there is any indication this is
functionally broken or a major regression across languages, keeping in mind
the necessity of ULS et al still. What major language-related bugs have
been raised that would not be present regardless for most default
sans-serifs?

I see some cases, such as CJK, where users may not prefer the serif
headings, since serifs look closer to a brush script in those languages
than they do in Latin languages. That doesn't seem to be what we're
discussing though? When it comes to the body font settings and language
support, we've been able to remove some local overrides. Some others, like
Persian, had Common.css overrides long before the new version was released.
The general state of affairs before *and* after is that there aren't
great-looking, freely-licensed fonts with support across all languages and
which are widely installed on our most popular OS/device combos. We're
making incremental improvements here.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Forget mailing lists and on-wiki discussions; Twitter's the place!

[Steven Walling]

On Sun, Apr 6, 2014 at 2:59 PM, Tomasz W. Kozlowski
tom...@twkozlowski.netwrote:

 You are responding to the bug based on reports that come from outside the
 Wikimedia universe -- and to say otherwise is untrue and absurd in itself.

 You saw the feedback, Steven, with your own eyes, in January of this year:
 it
 was submitted by Wikipedian Patrick87 on January 8 at
 
 https://www.mediawiki.org/wiki/Talk:Typography_refresh/Archive_2#Default_sys

 tem_fonts_should_be_given_preference_over_free_fonts_.28especially_on_Windows
 .29.

 You had almost three full months to deal with the problem, and yet you are
 only responding to it when people pointed it out to you on Twitter, Reddit,
 Quora, and wherever else.

 /If/ you value feedback from Wikipedians, why don't you act on it?


Tomasz,

We should be having this conversation in Bugzilla. I replied to this issue
at https://bugzilla.wikimedia.org/show_bug.cgi?id=63512#c29

TL;DR: one user saying they chose to download the fonts in question is not
the same thing as a report that a significant minority might have them.

On the general point: you and others seem to be simultaneously angry that
we tried a version without a freely-licensed font *and* that we have tried
versions which did have FOSS fonts, but that had unexpected bugs for some
Windows users. Which is it? Or is that you're just looking for an excuse to
be mad and cause a fuss because we changed the typography at all? It sounds
to me like it's the latter.

New software updates that reach this widely always have issues that come up
for unexpected edge cases. The preexisting defaults have been around a long
time, and gone through much bug fixing and tweaking based on user feedback
across wikis. The same will be necessary for the new typography as well.

Steven
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Forget mailing lists and on-wiki discussions; Twitter's the place!

[Steven Walling]

On Sun, Apr 6, 2014 at 4:05 PM, Tomasz W. Kozlowski
tom...@twkozlowski.netwrote:

1. I am deeply uncomfortable with the fact that you are choosing un-free
 fonts over free ones.
 2. I am deeply uncomfortable with the fact that you decided not to respect
 the consensus /not/ to choose non-free fonts -- such as Arial and Helvetica
 --
 over free fonts; a discussion which I only read, but which, as far as I
 remember, saw participation from yourself, Quim, Greg, and some other
 people.


We've tried the alternative and it's untenable according to the feedback
we're getting. I wish it wasn't. I'd rather put free fonts first in the
stack, if they actually work for users. Twice now we've tried putting
different freely-licensed fonts first. Both times, Windows users who had
them have told us they either merely disliked them or they have caused
unacceptably poor rendering, particularly for those without font smoothing.
There simply is not widely-available font that meets all our needs while
also being freely-licensed. The compromise is either to deliver a
freely-licensed webfont to all users (which we're not going to do right
now, though it's the ideal IMO) or to specify the best fonts users already
have on their system free or not, which accomplish the consistency and
legibility we're looking for. This is just the reality. Whether or not the
CSS/LESS declares them explicitly or not, non-free fonts are what most
users have already and want to use, because they actually work. This is
true whether we set a more specific stack than sans-serif or not.


 As for your suggestion that I'm only looking to make a fuss, here's some
 basic facts for you to ponder.

 A. /I/ pointed it out to Greg and to you on IRC that deploying Typography
 Refresh to all wikis on the same day (March 28) was a bad idea, and that it
 would be better to roll it out with MediaWiki 1.23wmf21, as it would give
 time to inform the community (as well as to push some last-minute fixes).


Delaying release to anticipate bugs that have not yet been reported by
anyone makes no sense. At the time of release there were only four bugs
open related to VectorBeta as an extension, none of which could have told
us about the issue. How could last minute fixes be pushed for a bug no one
had actually reported yet?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Forget mailing lists and on-wiki discussions; Twitter's the place!

[Steven Walling]

On Sun, Apr 6, 2014 at 4:24 PM, wctaiwan wctaiwan+li...@gmail.com wrote:

 I don't think we should prioritise users with font smoothing disabled.
 ClearType has been available since at least Windows XP. If there are
 legibility issues, we should probably fix it; but if it merely looks
 ugly, the solution is for the users to enable font smoothing if they
 want prettier font rendering.


I too was surprised at how many users are A) on XP with ClearType off,
which is the default there or B) turn font smoothing off intentionally.

I should note that by fixing this bug we won't be changing the appearance
for users on most platforms, except those on Windows who have these two
fonts (Arimo, Liberation Sans), so we're not degrading the quality of font
rendering just to optimize for those without smoothing.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Typography update to Vector in core

[Steven Walling]

On Thu, Mar 27, 2014 at 8:09 AM, C. Scott Ananian canan...@wikimedia.orgwrote:

 My reading of

 https://gerrit.wikimedia.org/r/#/c/120978/3/skins/vector/variables.lessindicates
 that this was merged to the master branch of mediawiki, and so
 will apply to everyone using the vector skin in the next mediawiki release.


Scott is correct.

This was designed primarily with Wikimedia readers in mind, but this is
extremely minimal stylistically. The typography has no loud personality
that is so unique to Wikimedia sites that it that prevents or discourages
use by someone say, installing a new MediaWiki instance. In the past, we've
discussed the idea of providing either a specific Wikimedia skin or a
general MediaWiki skin we don't use at WMF. The discussion about that is at
https://bugzilla.wikimedia.org/show_bug.cgi?id=51912
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Typography update to Vector in core

[Steven Walling]

Hey all,

I wanted to give people an extra notice that we're updating the default
typography across all Wikimedia sites, for users of the Vector skin. This
was also mentioned in the last Tech News edition, and announced by Greg as
part of the deployment roadmap.

This will happen in the following order:

   1. Test wikis and mediawiki.org tomorrow. That's Thursday, March 27th.
   2. Non-Wikipedia projects on Tuesday, April 11th.
   3. All Wikipedias on Thursday April 3rd.

If people have questions, there is a summary of the changes and an
extensive FAQ at https://www.mediawiki.org/wiki/Typography_refresh. There
will also be a post at blog.wikimedia.org tomorrow morning, and we have
other messages to go out on-wiki.

Wikitech-l subscribers: you may remember an extensive recent thread that
mostly debated the use of non-free fonts like Helvetica Neue and Georgia as
the primary fonts in the new font-family settings. We took this feedback to
heart. Thanks to patches/testing led by Ryan Kaldari and Vibha Bamba, we
released a new version a couple weeks ago, which puts a set of fine FOSS
fonts first (say that ten times fast). For the curious, the relevant patch
is gerrit 120978.

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maintaining or replacing Gerrit

[Steven Walling]

On Mon, Mar 17, 2014 at 9:52 AM, MZMcBride z...@mzmcbride.com wrote:

 The Gerrit installation at https://gerrit.wikimedia.org is currently a
 critical part of Wikimedia's development infrastructure. I think it's
 becoming increasingly clear that Gerrit needs love. To me, this means:

 * working with upstream to make incremental improvements to Gerrit (such
 as the great work that Christian A. and Chad H. have done) and having at
 least one person dedicated to general upkeep of our Gerrit installation; or

 * figuring out whether a different solution such as Phabricator makes
 sense (expensive and fraught).

 The Wikimedia Foundation currently has staff or contractors dedicated to
 maintaining human resources software and Bugzilla, but perhaps it could
 spare the additional resources for a person dedicated to Gerrit or another
 code review tool. Or this is possibly an area where a Wikimedia Chapter
 could provide support.


This is partially being discussed systematically under the umbrella of the
Project Management Tools Review work, described at
https://www.mediawiki.org/wiki/Project_management_tools/Review. People
should participate in the discussions there, particularly at
https://www.mediawiki.org/wiki/Project_management_tools/Review/Options and
the associated Talk page.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit Commit Wars

[Steven Walling]

On Fri, Mar 7, 2014 at 5:23 AM, Isarra Yos zhoris...@gmail.com wrote:

 The changeset was the result of the discussion on the Design list. The
 reason Steven Walling gave for the -1 was simply not true, but attempts to
 explain this failed and consensus apparently wound up being to ignore him.

 Just for a little background/context here


Just for more background/context here... As you can see in the latest
comments on bug 61416, I'm not the only one who objects to the
implementation as currently designed. Prior to the bug, Erik M. also
proposed an alternative solution which was ignored for some reason.

That being said, I +2'd the quick revert because it made the mobile signup
flow a mess. Whether it should have been merged in the first place is
another debate.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Usability testing

[Steven Walling]

On Fri, Mar 7, 2014 at 9:29 AM, Gerard Meijssen
gerard.meijs...@gmail.comwrote:

 Steven do I understand correctly that there is no user testing except in
 English ?


You can only do usability testing (i.e. sit down with a person and listen
to them talk, or do it remotely) if you understand their language.
Otherwise you're just listening to someone give feedback you can't
understand.

Someone multilingual like Pau may be able to do tests in languages like
Spanish or Catalan, which I believe he might have in the past. But we
almost exclusively test in English because it's our universal working
language, and we're usually not designing specifically for non-English
projects (at least in my work anyway).

Steven
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit Commit Wars

[Steven Walling]

On Thu, Mar 6, 2014 at 8:29 PM, Tyler Romeo tylerro...@gmail.com wrote:

 1) not everybody is subscribed to mobile-l, so you cannot expect the
 original reviewers to see or know about it
 2) this is an issue with MobileFrontend, not MediaWiki core
 3) code being merged does not automatically cause a deployment, and if code
 being deployed breaks something in production, it is the operations team's
 job to undeploy that change


If your patch causes a serious UX regression like this, it's going to get
reverted. The core patch involved was being deployed to Wikimedia sites /
impacting MobileFrontEnd users today. If we had more time in the deployment
cycle to wait and the revert was a simple disagreement, then waiting would
be appropriate. It is obvious in this case no one tested the core change on
mobile. That's unacceptable.

And yes, Jon should have made sure the revert and the original patch were
cross-referenced. I'm sure he'll do that next time he commits a revert.

Steven
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Usability testing

[Steven Walling]

From: David Gerard dger...@gmail.com
Date: Thu, Mar 6, 2014 at 9:44 PM
Subject: Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
To: Wikimedia developers wikitech-l@lists.wikimedia.org

(Veering off topic: So what does WMF use for a usability lab, anyway?)


...not sure what Kaldari did. In this case, he may have simply sat down
with the UX designers and done a test in person.

We do not have a usability testing lab on-site in San Francisco, and
typically prefer to do remote usability tests. Either we do this manually
via sending out a survey,[1] and then running a Google Hangout which we
record for later. This is good since it is guided by the person who wrote
the test script, so they can adapt to what the user is doing/failing to do.
It takes a lot more leg work though.

More often, we write a testing script and use usertesting.com, which is
more automated remote testing and is $35/test (this is really cheap since
the going US rate for an in-person test is something like a $50 Amazon gift
card). The service uses people from all over the English-speaking world who
have a variety of levels of technical expertise, and the tests are recorded
for viewing after they're completed.[2]

The UX team is actually in the process of hiring a UX researcher, so expect
to hear more about this kind of qualitative research soon.

Steven

1. We recently did this kind of recruitment and testing for article drafts
work. https://www.mediawiki.org/wiki/Draft_namespace/Usability_testing and
the /Results subpage
2. This kind of testing is something we used during the account creation
redesign
https://www.mediawiki.org/wiki/Account_creation_user_experience/User_testing



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] captcha idea: proposal for gnome outreach for women 14

[Steven Walling]

On Fri, Feb 28, 2014 at 6:29 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org
 wrote:

 If you display 8 images and the user has to pick one, then even by random
 guessing the attacker has a 12.5% chance of passing the captcha. That's not
 good at all. Finding all matching is slightly better since it reduces the
 guessability (1/256 for 8 images), but still not very good. A traditional
 captcha using only A-Z is 1/308915776. To do as well with image picking,
 you'd need to ask the user to choose the matches from a set of about 28.
 Adding in numbers 2-9 is 1/1544804416, needing a set of about 31 images.

 The set of possible images also needs to be very large and the
 categorization private.

 https://www.mediawiki.org/wiki/Talk:Requests_for_comment/CAPTCHA#Issue:_image_classification_CAPTCHAs_need_a_secret_corpusgoes
 into much more detail on this issue.


A recent example that springs to mind with image-based CAPTCHAs (instead of
text) is Snapchat's Find the Ghost, which is very fun for users and
apparently was broken very quickly.[1] A lot of times I hear people also
suggest we try a honeypot on login/signup instead of text-based CAPTCHAs,
and like the Snapchat example, one of the weaknesses here is just not
accounting for that fact that people will target popular sites/apps
directly. They'll inspect the DOM to find honeypots, they'll notice you use
the same logo shape and use computer vision to find that shape, etc.

However, it is not overstating it to say that the text-based CAPTCHA we use
now is the single most frustrating part of creating an account or logging
in (if you misremember your password, which users do all the time). To
quote one of our usability tests during the last login/signup redesign:
This is ridiculous. I can't even see this..[2]

One simpler thing we might try and do right now is regenerate our current
pool of CAPTCHAs to make them a bit less hard to read. We've done this kind
of tweaking before without too much trouble I think?[3]

1. techcrunch.com/2014/01/21/snaptcha/
2.
https://www.mediawiki.org/wiki/Account_creation_user_experience/User_testing
3. See bug 43546 which Aaron Schulz kindly took care of. He may be able to
elaborate more.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?

[Steven Walling]

On Mon, Mar 3, 2014 at 1:22 PM, Brad Jorsch (Anomie)
bjor...@wikimedia.orgwrote:

 What does neutrality mean in the context of a font?

 I'm having trouble figuring out what authority might actually mean
 besides Does this seem familiar to me from sites I use for reference?.


These are not terms with a purely objective measurement Brad, even if they
have a dictionary definition. It's a qualitative, subjective assessment. As
a secondary part of the design goals (behind readability) is to convey
these subjective qualities, you have to use a subjective measurement
system.

Something this subjective could probably do with a much more diverse sample.


Agreed, it would be awesome if we could make a little Surveymonkey to let
anyone do this blind test. Though I wouldn't necessarily trust Wikitech
readers not to use browser devtools to cheat. ;-)

A fun example of how similar qualities can be measured is the following
experiment in trustworthiness of fonts:
http://opinionator.blogs.nytimes.com/2012/08/08/hear-all-ye-people-hearken-o-earth/


I actually consulted our research and data team (Dario Taraborelli and
Aaron Halfaker) about whether we should A/B test the beta with readers.
Their reply was that a split test was not likely to produce statistically
significant results in reader-related metrics like time on site, pageviews
per unique visitor, etc. and that we have a great deal of trouble measuring
these things with precision anyway. Producing a muddled and potentially
flawed A/B test is much much worse than producing a small qualitative
assessment that we know to take with a large grain of salt. :-)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?

[Steven Walling]

On Mon, Feb 17, 2014 at 12:15 PM, Derk-Jan Hartman 
d.j.hartman+wmf...@gmail.com wrote:

 There is one area where ULS made true mistakes and that is thinking that
 it can always do better than the operating system/user. And that is the
 same risk that this exercise is running into. Thinking that we can define
 fonts in a way that is 'better' than the OS can do it. And though that is a
 lofty goal and in some specific cases/browsers is probably achievable, it
 also introduces a lot of potential risks.


In this regard we are something of an odd duck though, which should be a
red flag. The vast majority of well-designed and highly usable sites, large
and small, do 'declare fonts in a way that is better than the OS can do
it.' Even an *exceptionally* plain product like Gmail has a more specific
font family setting than Vector does at the moment.

Which is not to deny that there are no risks. It's to say that, with elbow
grease and attention to the cases you talk about below (IPA, different
scripts, etc.) we can actually have a setting that is better for most users
on most platforms. Sacrificing the readability and beauty of content for
most users because there is no universally perfect solution is the kind of
hard-line approach that limits the reach of FOSS, and ultimately undermines
our goal of making something the entire world can use and enjoy.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?

[Steven Walling]

On Sat, Feb 15, 2014 at 3:59 PM, Greg Grossmeier g...@wikimedia.org wrote:

 quote name=Federico Leva (Nemo) date=2014-02-15 time=22:52:31 +0100
  And surely, before WMF/MediaWiki tell the world that no free fonts
  of good quality exist, there will be some document detailing exactly
  why and based on what arguments/data/research the numerous free
  alternatives were all rejected? Free fonts developers are an
  invaluable resource for serving Wikimedia projects' content in all
  languages, we shouldn't carelessly slap them in their face.

 I just skimmed the entire thread again, and yes, this has been requested
 a few times but no one from the WMF Design team has responded with that
 analysis (or if would respond with an analysis). The first time it was
 requested the person was told to ask the Design list, then the next
 message CC'd the design list, but no response on that point.

 I don't see much on https://www.mediawiki.org/wiki/Typography_refresh
 nor it's talk page. Nor
 https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Typography

 cc'ing the Design list :)


Update on this: after discussing with Greg, Jared, etc. I've edited
wikitech Deployments calendar to reflect a longer term goal of mid to late
March at the earliest.

The calls from Greg, Kaldari, Nemo and others for better documentation are
100% correct, and it's something we should do before we move to merge
anything from the typography refresh in to Vector proper. There's a better
FAQ and more in development by the design team, but getting that out and
properly translated in just a week is not realistic. Overall the continued
discussion on Wikitech-l suggestions to me that doing this by the 27th
would be a rush job.

Note that there was a small update to the feature on Friday, which removed
the max-width restriction and tweaked some padding. I'd encourage anyone
who hasn't tried the beta feature in a few weeks to give it another shot.
We'll update Typography Refresh and the accompanying Talk page on
mediawiki.org accordingly.

Thanks,

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?

[Steven Walling]

On Mon, Feb 17, 2014 at 12:59 PM, Derk-Jan Hartman 
d.j.hartman+wmf...@gmail.com wrote:

 There was also a small addition to that feature, which concerns the ToC
 styling, which has had NO time to garner feedback yet, so I think
 postponing is a good idea. Also a good pass of the feedback page seems a
 requirement for any deploy if you ask me :D


The TOC style is actually not new as of Friday (see:
https://gerrit.wikimedia.org/r/#/c/108155/), and rolled out to most
Wikimedia sites on Feb 6th. I think it's just that enough MediaWiki
insiders disliked the max-width that they stopped using the beta feature,
and haven't seen the updates since then. ;)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?

[Steven Walling]

Rob,

I think you should cross-post all or most of that on Talk:Typography
Refresh, since not all the designers are actually on Wikitech. A few
thoughts of my own...

On Mon, Feb 17, 2014 at 4:42 PM, Rob Lanphier ro...@wikimedia.org wrote:

 This doesn't seem like a satisfying leap forward, given the level of
 disruption.


1). I don't really see how there is or will be actually any serious level
of disruption for users beyond a temporary shock of an incremental change.
Right now what I see internal MediaWiki community drama over changing a
longstanding precedent, which is not the same thing. I don't know about
you, but I care ultimately what happens for users of MediaWiki/Wikimedia
not whether people want to fight about something on a mailing list. If
that's the measure of disruptive, then almost everything we do is extremely
disruptive.

As you say, it's not a hugely radical chance, and so far overall use of the
beta has stayed steady or grown over time. Millions more mobile readers
have been happily using almost the exact same font family settings for all
our projects for more than a year. (That's the basic consistency we're
talking about.) Feedback from most end users on the Talk page has been
positive or neutral the base content font family, or has been more
concerned with other details (like serif headings).

People here mostly seem to have debated two points: are violating our free
software requirement? (unequivocal answer: no) and is this better?

The answer to that is partially a matter of personal taste, which is why
everyone who wants is still free to customize the skin however they like.
Typography is one of those elements of design that everyone has a strong
opinion about, even if they don't really grasp fundamentals of the domain.
The second part of the answer seems to me that the UX team, as the experts
in this, needs to do a better job of documenting their research and the
feedback so far from end users. That is why I recommended we hold back on
pushing the beta feature to Vector for now.

2). I think Jared and others hinted that the most satisfying leap forward
would be delivering free/open webfonts to all users. Ideally, it would even
be something custom designed for Wikimedia. However, that's just not a
realistic bet right now, and we have reason to tread cautiously as Erik
said.

3). Last and most important, you listed main body font family, but ignored
the other changes that are a part of the Typography Refresh as housed in
Extension:VectorBeta. A large part of what makes typography good or bad is
not simply the font family you choose. It's how you set it -- the visual
context -- that matters just as much. Ultimately arguing about that one
line of CSS is not really a discussion about the actual experience on our
sites.

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?

[Steven Walling]

On Mon, Feb 17, 2014 at 4:58 PM, Erik Moeller e...@wikimedia.org wrote:

 So, what would be the downside of listing a font like Arimo for
 sans-serif and Libertine for serif first in the stack? While not
 affecting the reader experience for a significant number of users, it
 would still be a symbolic expression of a preference for freely
 licensed fonts, and a conscious choice of a beautiful font for readers
 that have installed it.


We basically tried the equivalent of this (placing relatively free fonts
unknown on most platforms first) which Kaldari talked about previously.
Ultimately that kind of declaration is useless for the vast majority of
users and we got very specific negative feedback about it on the Talk page.
These fonts are ignored by most systems when placed first or when placed
later in the stack. Systems match the first font they recognize, so using
something they don't recognize or putting it later is a largely just
feel-good measure.

The whole Arimo/Arial conundrum is largely a matter of the fact that
Windows users simply do not have a Helvetica-like font available on most
versions which is better than Arial, warts and all. Again, the best
solution is to deliver a webfont, which most people with good design sense
are doing these days, and we can't yet.

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?

[Steven Walling]

On Sat, Feb 15, 2014 at 11:52 PM, Denis Jacquerye moy...@gmail.com wrote:

 Maybe I haven't looked in the right place, but why aren’t webfonts being
 considered?

 Webfonts would mean the same fonts can be delivered everywhere, relying on
 installed font only as a last resort.
 There are more options than just the 4 fonts mentioned (DejaVu Serif,
 Nimbus Roman No9 L, Linux Libertine, Liberation Sans): PT Sans/PT Serif,
 Droid Sans/Droid Serif and likes (Open Sans, Noto), the other Liberation
 fonts and likes (Arimo, Tinos), Source Sans, Roboto, Ubuntu, Clear Sans, if
 you just want hinted fonts and household names.

 I’ll also point out that Georgia is a great font originally designed for
 small size, and Helvetica Neue/Helvetica/Arial was originally designed for
 display. When it comes to language coverage both are lacking but that
 cannot be fixed easily.


To add on to what Jared said...

On webfonts: it's not just that it would take more research. We have
already tried webfonts and failed miserably so far.
UniversalLanguageSelector is an example of how even the most
well-intentioned efforts in this area can face serious setbacks. Keep in
mind also that this typography work is largely being done with volunteer or
side project time from myself, the developers, and most of the designers.
We are simply not prepared to implement and test a webfonts system to work
at Wikipedia scale.

There are many gorgeous, well-localized free fonts out there... but few
that meet our design goals are delivered universally in popular mobile and
desktop operating systems. We can't get a consistent and more readable
experience without delivering those as webfonts, and webfonts are not
practically an option open to us right now. Maybe in the future we will get
(as Jared says) a foundry to donate a custom free font for us, or maybe
we'll just use a gorgeous free font out there now, like Open Baskerville or
Open Sans.

For now, however, we get the following result from the Typography Refresh
beta feature:

   1. the vast majority of our 500 billion or more users get a more
   readable experience
   2. we unify the typography across mobile and desktop devices, which is a
   good thing for both Wikimedia and third party users of Vector/MobileFrontEnd
   3. individual users and individual wikis can still change their CSS as
   needed and desired
   4. we don't jeopardize Vector and MediaWiki's status as FOSS, by not
   distributing nor creating a dependency on any proprietary software
   *whatsoever*. Thank you, CSS font-family property and fallbacks.

That all sounds like a pretty good way to maintain freedom while improving
readability and consistency to me.

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?

[Steven Walling]

On Sun, Feb 16, 2014 at 1:16 AM, David Gerard dger...@gmail.com wrote:

 On 16 February 2014 08:54, Gerard Meijssen gerard.meijs...@gmail.com
 wrote:

  Working towards a more beautiful viewing experience is a secondary
  objective. Primary is that our readers and editors can read and edit.
  ULS is a huge success in doing what it was intended to do. I am afraid
 that
  we have lost sight of what our primary objective is about.


 Indeed. What precisely was the problem with ULS?


From https://www.mediawiki.org/wiki/Universal_Language_Selector: Universal
Language Selector has been disabled on 21-01-2014 to work out some
performance issues that had affected the Wikimedia sites. To my
understanding part of the major performance issues here related to issues
like loading the Autonym font via webfonts.

I probably should not have brought up ULS because feelings are still raw
about it and I'm not interested in rehashing its problems, but my point is
that it's an example of how delivering webfonts is not a trivial thing for
us. No one has offered to spend time on a highly performant webfonts system
that can deliver better typography reliably to all Wikimedia sites, and
we're certainly not going to officially task a team to do so when there's a
reasonable alternative that thousands of users are trying out right now in
beta mode.


 What consideration
 did the designers give to non-Latin?


The beta feature has involved lots of testing in non-Latin scripts. It's
not perfect yet but we certainly haven't ignored scripts that represent so
many users. (Remember we're not talking about something actually that new.
A very similar font stack has been in use for 100% of mobile users for more
than a year.)

Steven

P.S. Sorry for answering from a different account. My work address is not
subscribed to Wikitech.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?

[Steven Walling]

On Sun, Feb 16, 2014 at 2:00 PM, Brian Wolff bawo...@gmail.com wrote:

 I've seen setiment like this (discuss in person, in hangout, or otherwise
 privately) pop up recently (e.g on [1]). I think attitudes like that are a
 real problem. Supposedly we are an open community. People should be
 entirely prepared to explain their reasoning for doing anything on a public
 mailing list no matter if the request comes from a wmf staffer like Brad,
 or if it comes from somebody you have never heard of before. In fact i
 would argue that the criteria and results of evaluations should be public
 on the wiki from the get go, without anyone even asking for it.


I would like to ask if people want to discuss side issues like whether to
use a mailing list or not, or David's suspicions about a growing trend of
preferring non-free software :P, or ULS history, you start a new thread and
not hijack this one. This conversation is heated and complex enough.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Communication of decisions (was Re: Should MediaWiki CSS prefer non-free fonts?)

[Steven Walling]

On Sun, Feb 16, 2014 at 3:36 PM, Greg Grossmeier g...@wikimedia.org wrote:

 See also: The general rule among many engineering departments at WMF is
 If it didn't happen on the list (or somewhere similarly public and
 indexable) it didn't happen.


Wikitech is great for discussing things with a wider audience especially
where we need to seek opinions of developers outside the staff. But most
decisions people make are documented on a wiki, Bugzilla, and/or their
preferred project management tool. A mailing list is quite bad at reaching
a consensus decision on something, as evidenced by the fact that we hold
RFCs on a wiki, and not here.

No one is suggesting that we should make all decisions via
teleconferencing. If you read Jon's comment with good faith, he obviously
wants to reach common ground with Brad on a contentious issue, and
suggested using a medium that is different than what we've tried already.
Brad has brought this up repeatedly on the list and Talk:Typography
Refresh, discussing this with both end users who disagreed and fellow staff
members. Little apparent progress has been made in reaching consensus.
Jon's trying to be respectful and reach common ground with a coworker. I
don't think anyone should be taken to task for such behavior, not when (as
you say) Jon's clearly been part of a team that has pushed for better
documentation of decisions than just in-office face to face meetings.

In short: mountain out of a mole hill. Don't assume people don't care about
public discussion because they want to have a 1-1 with someone whose
opinion they think is important.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?

[Steven Walling]

On Sat, Feb 15, 2014 at 3:59 PM, Greg Grossmeier g...@wikimedia.org wrote:

 quote name=Federico Leva (Nemo) date=2014-02-15 time=22:52:31 +0100
  And surely, before WMF/MediaWiki tell the world that no free fonts
  of good quality exist, there will be some document detailing exactly
  why and based on what arguments/data/research the numerous free
  alternatives were all rejected? Free fonts developers are an
  invaluable resource for serving Wikimedia projects' content in all
  languages, we shouldn't carelessly slap them in their face.

 I just skimmed the entire thread again, and yes, this has been requested
 a few times but no one from the WMF Design team has responded with that
 analysis (or if would respond with an analysis). The first time it was
 requested the person was told to ask the Design list, then the next
 message CC'd the design list, but no response on that point.

 I don't see much on https://www.mediawiki.org/wiki/Typography_refresh
 nor it's talk page. Nor
 https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Typography


There wasn't an answer because the question is a fundamental
misunderstanding of the way CSS works and options that are within our
reach. The question isn't are there good free fonts? the question is can
we deliver good free fonts to all users?. I'll try to help the UX team
document the answer better.


-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Let's improve our password policy

[Steven Walling]

If feel like I should reiterate why I proposed this change. Maybe no one
cares, but I think it might help convince folks this is NOT an argument for
let's reduce user freedom in the name of security.

I didn't worked on the RFC because I love tinkering with password security
in my spare time and know lots about it. Far from it. I did it because I
think we're failing MediaWiki users on *all installations* by inviting them
to sign up for an account, and then failing to set default requirements
that help them adequately secure those accounts. Users tend to follow
defaults and do the minimum effort to reach their goals -- in this case to
sign up and then get editing. It's our job as the MediaWiki designers and
developers to set good defaults that encourage account security without
being excessively annoying.

In addition to just being sane about security defaults, there is more.
Allow me to wax poetic a moment... If you can edit anonymously, why do we
allow and encourage registration at all? Many reasons of course, but one of
them is because it is a rewarding experience to have a persistent identity
on a wiki. We all know how real that identity becomes sometimes. When I
meet Krinkle or MZMcbride in real life, I don't call them Timo and Max. Or
if I do, I don't think of them as those names in my head.

When wiki users start an account, they might think that they are just
creating something unimportant. They may actually have bad intentions. But
part of this is that we're offering people an account because it gives them
a chance to be recognized, implicitly and explicitly, for the work they do
on our wikis.

I think setting a default of 1 character passwords required doesn't
reinforce the idea that an account is something you might actually come to
cherish a bit, and that it might even represent you in some important way
to others. By signaling to new users that an account is so worthless that
it's cool if you have a one character password... well, is that really such
a good thing?

On Thu, Feb 6, 2014 at 5:44 PM, MZMcBride z...@mzmcbride.com wrote:

 P.S. I also casually wonder whether there's a reasonable argument to be
 made here that requiring longer passwords will hurt editor retention more
 than it helps, but this thought is still largely unformed and unfocused.


I think that's a canard. There are many many sites that do not have user
acquisition or retention problems, while also having sane password length
requirements. Yes, this is a potential extra roadblock, which may slightly
reduce conversion rates on the signup form by slowing people down. However,
one of the clear arguments in favor of doing this now (as opposed to say,
back in 2001) is that users will largely expect an account on a popular
website to require them to have a password longer than 1 character.

If we really are scared about the requirements in our signup form driving
people away from editing, we can make many user experience improvements
that would, like every other site, offset the terrible awful horrible evil
of requiring a six character password. I'd be happy to list specifics if
someone wants, but this email is already too long.

Steven
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Let's improve our password policy

[Steven Walling]

On Tue, Feb 4, 2014 at 11:59 PM, Martijn Hoekstra martijnhoeks...@gmail.com
 wrote:

 I think Steven meant upping the requirements for new accounts only. In that
 way nothing gets broken immediately. I'm still not absolutely convinced
 this is more useful than a hindrance if we clearly inform the user about
 password strength when they set them (see my earlier post about this
 password can be brute forced in x). If users are then not deterred from
 setting their password to wiki, apparently they didn't care, as we told
 them how easy it is to brute force.


We do not mean for new accounts only. We mean for all accounts.



 If Steven did mean something that will lock people out of their account on
 upgrades, then I don't think that's a good idea at all.


We will not lock people who are using their accounts out. The RFC
explicitly mentions two things which will help us having people avoid being
locked out of their account:

1. Being extremely loud about announcing the change. We have used
cluster-wide banners for this kind of purpose before.
2. As described in the RFC, there is a patch undergoing review which will
make it possible to force a reset *after* the user logs in again.

In any case, this RFC is about the MediaWiki default. If we want to set the
MediaWiki default in core but wait to update Wikimedia sites until we are
sure we won't lock a bunch of active users out of their accounts we can do
that. We should separate out the rollout strategy from whether we think
that a minimum password length is a good default in MediaWiki.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Let's improve our password policy

[Steven Walling]

On Tuesday, February 4, 2014, Petr Bena benap...@gmail.com wrote:

 To be honest one of things I liked most on wikipedia over other sites,
 was no password policy whatsoever. I hope we never get into such a
 creepy state like oracle website which requires so complicated
 password that I always immediately forget it...


I fully agree. This is why the RFC explicitly


 On Tue, Feb 4, 2014 at 3:04 PM, Petr Bena benap...@gmail.comjavascript:;
 wrote:
  hacking into password manager might be easier than hacking into a human
 brain :P
 
  On Tue, Feb 4, 2014 at 11:03 AM, Željko Filipin 
  zfili...@wikimedia.orgjavascript:;
 wrote:
  On Tue, Feb 4, 2014 at 10:33 AM, Petr Bena 
  benap...@gmail.comjavascript:;
 wrote:
 
  fde#@%62jtgjsl$#5kgsgjgseojgro@
  #$%SEGsgesjojahREAGHkerahj23YJ34pwyjw3$#^WrejgshSH
  (...)
  Now just remember that password.
 
 
  All my passwords look like that and there is no need to remember them.
 You
  can use a password manager[1]. I am aware of the fact that most people
 on
  this list do not use one, and that people that are not technical do not
  even know what a password manager is.
 
  Željko
  --
  1: https://en.wikipedia.org/wiki/Password_manager
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org javascript:;
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org javascript:;
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Let's improve our password policy

[Steven Walling]

On Tue, Feb 4, 2014 at 11:58 AM, Steven Walling steven.wall...@gmail.comwrote:

 On Tuesday, February 4, 2014, Petr Bena benap...@gmail.com wrote:

 To be honest one of things I liked most on wikipedia over other sites,
 was no password policy whatsoever. I hope we never get into such a
 creepy state like oracle website which requires so complicated
 password that I always immediately forget it...


 I fully agree. This is why the RFC explicitly


Sorry, was on my phone. I meant to say...

I fully agree, and this is why the RFC is very clear that the *only
immediate change proposed* is an increase in required minimum length from
one character to six. It does not suggest that we require more complex
character types, such as mixed upper/lower case, numbers, symbols and so
on. Just increasing the length, and hopefully suggesting to users how to
pick a strong password, is plenty for MediaWiki defaults.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Let's improve our password policy

[Steven Walling]

On Sat, Jan 25, 2014 at 10:25 AM, Isarra Yos zhoris...@gmail.com wrote:

 On 25/01/14 13:02, rupert THURNER wrote:

 for the password policy: display a strength indicator is great. anything
 more? i would say just leave it to the user.

 rupert.

 This.


We should probably have this discussion on the RFC comments. The trade-off
between security and user freedom is already brought up there, and there
are some clarifying comments that are relevant. Namely, that the RFC is
about the MediaWiki default. If a given MediWiki install wants to change
the default, they can like all config settings.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Let's improve our password policy

[Steven Walling]

Hi everyone,

For some time now we've had two Requests for Comment floating around
related to passwords, neither of them making much progress.

One is the older password strength RFC which proposed creating a module
to tell users about the strength of their passwords. The second, Password
requirements, had some discussion but wasn't reaching consensus and
implementation.

After proposing it about a month ago, I've merged these two RFCs and
refactored them in to
https://www.mediawiki.org/wiki/Requests_for_comment/Passwords, partially
based on feedback from Chris Steipp.

Please comment. I've tried to sharpen the proposals down in to one thing we
can do _right now_ which will do the most good for the most users. However,
there are several other viable ideas which merit discussion and example
implementations.

Thanks!

Steven
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] Announcement: Sam Smith (phuedx) joins Wikimedia as Growth Engineer in Features

[Steven Walling]

On Tue, Jan 21, 2014 at 1:50 PM, Terry Chay tc...@wikimedia.org wrote:

 Hello everyone,

 It’s with great pleasure that I’m announcing that Sam Smith[1] has joined
 the WIkimedia Foundation as a Software Engineer in Features Engineering.
 He'll be working with the Growth team.[2]

 Before joining us, Sam was previously a member of the Last.fm web team
 (web-slingers) where he helped to build the new catalogue pages, the
 Last.fm Spotify app, the new (*the only*) user on-boarding flow, and
 helped immortalise his favorite band (Maybeshewill) in most of their unit
 test cases. Before that he worked on everything from Java job schedulers,
 to Pascal windows installers, to Microsoft server sysadmining, to Zend
 Framework and symfony migrations. Ask him which was the was the worst—my
 money is on the PHP migration[3]. He received his Masters Degree in physics
 at the University of Warwick.

 Sam is based in London (the capital of England, not the city in Ontario or
 the settlement the island of Kiribati). He lives in Surray Quays with his
 wife, Lisa, and his 19 month old son, George. His hobbies include juggling
 (he's juggled for 6 years), unicycling (one day he's going to attempt the
 distance record… one day!), climbing (specifically bouldering, he's
 actually really afraid of heights), coffee (it's not really a hobby, it's
 an obsession), and playing Lineage 1[4]. Ask him to do some unicycling up a
 boulder while drinking coffee and playing Lineage… now *that* would be
 juggling!

 His first official day is today, Tuesday, January 21, 2013. (What? On
 time? He signed his contract last year, so I had a lot of time to prepare.
 Having said that, I didn't start this e-mail until this morning so balance
 has been restored to the force.)

 Please join me in a not-belated welcome of Sam Smith to the Wikimedia
 Foundation. :-)


\o/ Very very glad to have you aboard Sam. And not just because you're a
fellow coffee snob. ;-)

Sam is our people. From our very first transatlantic conversation, I got a
clear sense that Sam doesn't just like solving engineering problems. He
really deeply cares about doing right by users, making sure they have a
decent (maybe even a fun and enjoyable!) experience. I'm privileged to have
someone of his experience, intelligence, and empathy for users on our team.

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] Shahyar Ghobadpour joins Wikimedia Core features team as Software Engineer

[Steven Walling]

On Mon, Jan 6, 2014 at 11:17 AM, Terry Chay tc...@wikimedia.org wrote:

 Hello everyone,

 It’s with great pleasure that I’m announcing that Shahyar G(whatever)[1]
 has joined the Wikimedia Foundation as Software Engineer in Features
 Engineering.

 Before joining us, Shahyar worked as an engineer at DeviantART[2]
 developing both front-end and back-end software, with a focus on analytics.
 He was also the lead API engineer at ViaFoura and web developer for a
 company that works on what the Internet is really for[3]. He’s a long-time
 Wikipedian (he collaborated on two Good Articles[4]) and will be invaluable
 in his new role working with the Core Features Team, ensuring that Flow is
 full of parallax scrolling unicorns.

 Shahyar lives in Montreal and claims to have come to Canada for the
 poutine and never left, which pretty much summarizes his life. He is
 trilingual in English, French, and Persian. When he’s not writing JS, he’s
 drinking whisky to cope with the fact that he’s not writing JS (preferably
 Yamazaki 12 year), travelling, and practicing his beatific expression for
 avatar photos.

 His first day is today! [5] He’ll be working remotely but will be visiting
 the office during the architecture summit, so keep an eye on your fries!

 Please join me in welcoming Shahyar to the Wikimedia Foundation!


Welcome! Very glad you've joined us.

Also please excuse Terry's weird email. He is just like that. ;-)


-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Captcha filter list

[Steven Walling]

On Tue, Dec 31, 2013 at 7:05 PM, George Herbert george.herb...@gmail.comwrote:

 Just got a report and screenshot that a new user got this string for their
 captcha on en.wikipedia nigerblew

 http://snag.gy/JpSUR.jpg

 Though several people are pointing out that Niger is a country, I think
 it's reasonable to try and avoid things close to the two-g version of that
 word; nobody's denigrated by avoiding possibly offensive if misinterpreted
 words.  I recall there's a filter list?...


I don't know if there's a filter list, but this has happened before. I've
seen many of our past and current CAPTCHAs when we were testing the
signup/login redesign. I recall seeing both headshits and obamadick.

The CAPTCHA is two randomly generated English words. Personally, I think it
might just be good to regenerate the CAPTCHAs entirely from time to time.
AFAIK it's not that hard and our CAPTCHAs are weak anyway.

Steven
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Announcement: Kunal Mehta joins Wikimedia as Features Contractor

[Steven Walling]

On Thu, Dec 12, 2013 at 5:08 PM, Terry Chay tc...@wikimedia.org wrote:

 Hello everyone,

 It’s with great pleasure that I’m announcing that Kunal Mehta[1] has
 joined the Wikimedia Foundation as contractor in Features Engineering.

 Before joining us (and currently), Kunal is a student in college,
 switching from computer science to business administration for reasons that
 I’m sure warrant more discussion.

 Kunal is currently a Wikipedia admin got involved working on the projects
 8 years ago. He also helps writing and maintaining bots (legoktm 3’s
 pywikibot) and working on the nether regions of the volunteer developer
 community as part of the Volunteer Response Team, which he currently
 continues to do[2]. I met him at Wikimania through a Wikidata scholarship
 because apparently we were too cheap to spring for his ticket.

 Kunal will be working with the Core Features Team since MassMessage[3] and
 Echo[4] have overlapping concerns, and Flow[5] can use more development
 support now that it is out. When he isn’t doing that you’ll see him around
 adding this and that to core or the bots. :-)

 Kunal lives and goes to school in San Jose. Most importantly, he’s
 unlocked level 2 in Naan Sense on FourSquare[6]. From his username on the
 projects, I’d also bet he must like Lego Mindstorms[7].

 For the record, Kunal, I, for one, welcome our new robot overlords.

 As you have guessed from my usual tardiness and my drive to finish my
 announcements before the calendar year, his first official day was actually
 October 28th (Only two months ago? Not bad, not bad at all).

 Please join me in a belated welcome of Kunal Mehta to the Wikimedia
 Foundation.

 Take care,
 Terry


Welcome to the Evil Wikimedia Foundation Empire ;-)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Steven Walling]

On Thu, Nov 7, 2013 at 9:06 AM, C. Scott Ananian canan...@wikimedia.orgwrote:

 I'm a little puzzled here: this whole discussion is because new owners want
 to have the bug actually assigned to them, instead of just commenting, I'm
 working on this in the bug?

 Let's look at the github model -- there's no assignment at all.  I just
 file a bug, maybe make some comments on it to say I'm working on it, and
 some time later I submit a pull request referencing the bug and saying, I
 fixed it.  That seems to work fine for collaboration, and offers no
 roadblocks.

 Maybe we should be turning off bugzilla features instead of trying to 'fix'
 them.  The whole 'file a bug in bugzilla' process is already far too
 complicated with a dozen fields which are either irrelevant or just
 confusing to newcomers.  Can we just hide all this cruft (including the
 'assigned to' field) for most users?
   --scott


I would be okay just turning off assignment.

In theory, a primary use case for assigning bugs is Product Manager A (say,
me) sees a new bug, and assigns it to Engineer B (say, Ori). Other than
self-assignment, this kind of workflow is the most common argument for
needing assignment I think. Since generally, WMF engineering teams use a
secondary task tracking tool (Trello, Mingle, etc.), turning off the
feature would not hurt us. We can also, you know, talk to people if we want
them to tackle a bug.

Since we have PATCH TO REVIEW and cross-linking from Gerrit to BZ, it
becomes clear who is actually working on resolving an issue. This also
focuses more on actually getting working software patches, instead of just
fiddling with bugs. ;)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Steven Walling]

On Fri, Nov 8, 2013 at 2:12 PM, Chad innocentkil...@gmail.com wrote:

 Not all teams have drank the Mingle Kool-Aid yet ;-)


That includes mine. :) Chad: does Platform really depend on bug assignment?
Maybe Dan Garry could chime in here as well.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l