Re: [Wikitech-l] Communication about proposed and planned UI changes

[Pine W]

Quim,

I like your line of thought here.

The Newsletter extension could be useful in all kind of ways, and I
was glad to see that it's apparently still in active development.

It would be helpful for me to have proposals shown in the newsletter
divided by approximate time horizon (next week, next month, next
quarter, etc), as well as their status (proposed but not in
development, in development, stalled, ready for review by (insert team
here), deploying soon, under discussion, deployment complete on X
wikis and deploying to Y soon, etc.)

What would it take to get a newsletter like that launched, when might
it happen, and who should coordinate and publish it?

Pine



On Fri, Dec 16, 2016 at 5:16 AM, Quim Gil  wrote:
> On Fri, Dec 16, 2016 at 12:51 AM, Pine W  wrote:
>
>> The issue which I am attempting to address is not a UI change itself
>> (good or bad) but rather communication about proposed and upcoming UI
>> changes.
>
>
> Communication of proposals and changes is a problem indeed. Not just for
> UX, the problem is common to other areas of development. We are trying to
> define the good practices in the Technical Collaboration Guideline, at
> Milestone
> communication
> 
> .
>
> This is how I personally think that the technical solution should work,
> taking UI as an example.
>
> * A UX review checkpoint exists, consisting of a wiki page in MediaWiki.org
> where current and past proposals reviewed are logged. Users can see which
> proposals are currently under review (with deadlines optionally) and which
> ones have been resolved and when.
>
> * Each proposal lives in its own URL (a wiki page, a Phabricator task)
> where rationale, updates, and discussion happens.
>
> * Anyone can subscribe to the UX Reviews newsletter
> . Teams initiating or
> resolving a proposal will announce the move in the newsletter. Users
> subscribe to this newsletter will receive updates related exclusively to UX
> reviews, no more, no less.
>
> Imagine the same approach for new projects/features, security reviews, new
> betas, release plans... This is a good way to scale communications without
> drowning central spaces like Tech News, wikitech-ambassadors or your
> nearest Village Pump. This is also a good way to attract specialized
> contributors and help them shine where they can contribute best (i.e.
> design students or professionals happy to volunteer) as opposed to trying
> to convince them to follow Tech News, wikitech-ambassadors or your nearest
> Village Pump.
>
> This idea doesn't define whether a change of color shade merits a review or
> whether the review should last three months, but it helps creating focused
> spaces where productive collaboration may happen sooner and more often
> without everybody dying out of exasperation or exhaustion.
>
> --
> Quim Gil
> Engineering Community Manager @ Wikimedia Foundation
> http://www.mediawiki.org/wiki/User:Qgil
> ___
> 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] Discovery Weekly Update for the week starting 2016-12-12

[Chris Koerner]

Greetings,
Here is another weekly update on the work of the Discovery department. If
you have questions, please ask!

== Highlights ==
* Published Maps Terms of Use [0]

== Discussions ==

=== Search ===
* The time needed to restart our elasticsearch clusters is improving [1]
* Fixed a rare edge case where a wiki could show duplicate results when
detecting query language [2]
* Fixed a rare edge case that could cause fewer results to be displayed
than expected on French projects [3]


=== Portal ===
* Wikipedia.org portal article stats were updated on 12 Dec 2016 [4]
* Updated Wikipedia portal with translations for browsers that have their
primary language other than English. [5]

=== Interactive ===
* Kartotherian and Tilerator configurations are now deployed with scap3, a
more streamlined process [6]
* Updated static maps to now be faster in showing updated details [7]
* Updated what we're logging for metrics [8]


[0] https://wikimediafoundation.org/wiki/Maps_Terms_of_Use
[1] https://phabricator.wikimedia.org/T145065
[2] https://phabricator.wikimedia.org/T153051
[3] https://phabricator.wikimedia.org/T151173
[4] https://phabricator.wikimedia.org/T128546
[5] https://phabricator.wikimedia.org/T142582
[6] https://phabricator.wikimedia.org/T150021
[7] https://phabricator.wikimedia.org/T150358
[8] https://phabricator.wikimedia.org/T151929



The full update, and archive of all past updates, can be found on
MediaWiki.org:

https://www.mediawiki.org/wiki/Discovery/Status_updates

Interested in getting involved? See tasks marked as "Easy" or "Volunteer
needed" in Phabricator.

[1] https://phabricator.wikimedia.org/maniphest/query/qW51XhCCd8.7/#R
[2] https://phabricator.wikimedia.org/maniphest/query/5KEPuEJh9TPS/#R


Yours,
Chris Koerner
Community Liaison - Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Design] [Wmfall] Design statement of purpose reviewed

[Wes Moran]

Very happy to see the progress as well as the team work on the statement of
purpose and look forward to the next steps.  Thank you also to the guidance
and facilitation by Arthur.

On Fri, Dec 16, 2016 at 4:13 PM, Grace Gellerman 
wrote:

> +1 to Anna's :)
>
> Good job everyone!
>
> On Fri, Dec 16, 2016 at 8:10 AM, Anna Stillwell 
> wrote:
>
>> :)
>>
>> On Thu, Dec 15, 2016 at 3:09 AM, Pau Giner  wrote:
>>
>>> Hi all,
>>>
>>> Some months ago we started to define a statement of purpose for design
>>> at Wikimedia. We shared our initial iteration and got useful feedback.
>>> Based on that feedback, we have updated a new version:
>>> https://www.mediawiki.org/wiki/Design/Statement_of_purpose
>>>
>>> Please, feel free to check the updated version, and provide any
>>> suggestion in the talk page.
>>>
>>> If the statement just sounds as a logical, simple, and obvious
>>> description for the purpose of design here, that was the goal. Putting this
>>> in writing has been helpful for designers and people working with us to get
>>> into the same page, and will be useful in the future to achieve the level
>>> of support for design we envision for those areas where we are not there
>>> yet.
>>>
>>> Thanks to everyone that has contributed to the process.
>>>
>>> --
>>> Pau Giner
>>> Senior User Experience Designer
>>> Wikimedia Foundation
>>>
>>>
>>> ___
>>> Wmfall mailing list
>>> wmf...@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wmfall
>>>
>>>
>>
>>
>> --
>> "If you have knowledge, let others light their candles in it." - Margaret
>> Fuller
>>
>> Anna Stillwell
>> Director of Culture
>> Wikimedia Foundation
>> 415.806.1536 <(415)%20806-1536>
>> *www.wikimediafoundation.org *
>>
>>
>> ___
>> Wmfall mailing list
>> wmf...@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wmfall
>>
>>
>
> ___
> Design mailing list
> des...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/design
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] Design statement of purpose reviewed

[Grace Gellerman]

+1 to Anna's :)

Good job everyone!

On Fri, Dec 16, 2016 at 8:10 AM, Anna Stillwell 
wrote:

> :)
>
> On Thu, Dec 15, 2016 at 3:09 AM, Pau Giner  wrote:
>
>> Hi all,
>>
>> Some months ago we started to define a statement of purpose for design at
>> Wikimedia. We shared our initial iteration and got useful feedback. Based
>> on that feedback, we have updated a new version: https://www.mediawiki
>> .org/wiki/Design/Statement_of_purpose
>>
>> Please, feel free to check the updated version, and provide any
>> suggestion in the talk page.
>>
>> If the statement just sounds as a logical, simple, and obvious
>> description for the purpose of design here, that was the goal. Putting this
>> in writing has been helpful for designers and people working with us to get
>> into the same page, and will be useful in the future to achieve the level
>> of support for design we envision for those areas where we are not there
>> yet.
>>
>> Thanks to everyone that has contributed to the process.
>>
>> --
>> Pau Giner
>> Senior User Experience Designer
>> Wikimedia Foundation
>>
>>
>> ___
>> Wmfall mailing list
>> wmf...@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wmfall
>>
>>
>
>
> --
> "If you have knowledge, let others light their candles in it." - Margaret
> Fuller
>
> Anna Stillwell
> Director of Culture
> Wikimedia Foundation
> 415.806.1536 <(415)%20806-1536>
> *www.wikimediafoundation.org *
>
>
> ___
> Wmfall mailing list
> wmf...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wmfall
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Making Wikipedia speak to you

[André Costa]

*Cross posting on purpose, no excuses made.*

Hi,

At Wikimedia Sverige we have been working on an extension called
Wikispeech. It will be a text-to-speech solution which aim to make the
information on Wikipedia more accessible for people that have limited
abilities to read.

This is Wikimedia Sverige's first MediaWiki development project from
scratch and it has been suggested to us that we should ask for endorsements
- as this will make the need clear if/when the extension needs support. So,
if you think that this sound like something important, please let everybody
know it! https://www.mediawiki.org/wiki/Wikispeech#Endorsement

Please spread the word. Best,
André Costa
André Costa | Senior Developer, Wikimedia Sverige | andre.co...@wikimedia.se
| +46 (0)733-964574

Stöd fri kunskap, bli medlem i Wikimedia Sverige.
Läs mer på blimedlem.wikimedia.se
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Arbitrary Wikidata querying

[Magnus Manske]

I strongly support "native" Wikipedia lists using Wikidata queries, and by
that I mean proper SPARQL, not Lua hacks.

Listeria is used "in production", e.g. on Welsh (about 17.000 lists in
articles, see https://tools.wmflabs.org/listeria/botstatus.php), but it was
always intended as a proof of concept. It is also designed around WDQ and
only later retrofitted for SPARQL, which explains some of its peculiarities.

It can handle ~23K lists per day, easily, without any caching. I believe
(naively, perhaps) an extension would be feasible that renders "row
templates" based on SPARQL queries. No Lua needs to be involved in this, or
current Wikidata "fact transclusion". In a first iteration, it might not
even have an automatic update mechanism:
* Render some  construct based on SPARQL
* Tag pages with such tags in the database, or even through categories
* Have an external service/bot purge these pages on a regular basis; that
would update the list without the need of editing the page
* These automated updates could be staged by the time the SPARQL query
required on the last update - <2sec once/day, >10sec once/week etc.
* Have an "update now!" button (as I have on Listeria lists) that just
links to "action=purge", for the impatient (instant gratification)

The Wikipedia setup wasn't always as heavily cached as it is today; it grew
with usage. I believe we could do this for Wikidata-based lists as well, as
the WMF would control the update cycles.

On Fri, Dec 16, 2016 at 7:30 AM Stas Malyshev 
wrote:

> Hi!
>
> > Actually, specifically for list of presidents you don't need bot.
>
> Yeah, you are right, I was thinking about going through query route, but
> if your list is contained in one property (like Q30/P6) then using Lua
> is just fine. It's not always the case (e.g. "list of all movies where
> Brad Pitt played"). But where it works it's definitely a good way to go.
>
> > 3. It is limited to simple lists (you can't have list of Republican
> > presidents - because it requires additional filters and you don't want to
> > create new property for it)
>
> Exactly. You probably could still do something in Lua, but that's
> pushing it already.
>
> > 4. Internationalization - What if yi Wikipedia wants to create list of
> > governors of some small country where there are no yi labels for the
> > presidents? The list would be partially in yi partially in en - is this
> > desired behavior? or they can show only presidents who have label in yi -
> > but this would give partial data - is this the desired behavior?
> [Probably
> > the correct solution is to do show the fallback labels in en, but add
> some
> > tracking category for pages requires label translation or [translate me]
> > links)
>
> That sounds like a good idea :)
> --
> Stas Malyshev
> smalys...@wikimedia.org
>
> ___
> 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] Development on img_auth.php

[Bartosz Dziewoński]

img_auth.php is used in some private Wikimedia wikis, so you might be 
able to get WMF people to review your changes. It also means that they 
will be scrutinized more closely before they're merged.


--
Bartosz Dziewoński

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

[Wikitech-l] Final Call for Comments on the new Deprecation Policy for PHP code

[Daniel Kinzler]

Hi all!

At the ArchCom office hour (aka RFC IRC meeting) on December 14, we discussed
Legoktm's proposal for a deprecation policy for PHP code [1]. This would
supersede the current guideline [2], allowing deprecated code to be removed
after a couple of releases, even if it may still used by some extensions.

At the IRC meeting, we decided to approve this policy for a final call [3][4].
This means that it will be adopted as official policy if no new pertinent issues
are raised within a week.


Cheers,
Daniel


[1] https://www.mediawiki.org/wiki/Requests_for_comment/Deprecation_policy
[2] https://www.mediawiki.org/wiki/Deprecation
[3]
https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-12-14-22.04.html
[4]
https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-12-14-22.04.log.html

-- 
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

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

[Wikitech-l] Draft Goals for for Fiscal Year 2016-17, Q3 (January - March)

[Wes Moran]

Hello everyone,

The draft goals for the Technology and Product teams at the Wikimedia 
Foundation have been posted on MediaWiki for FY2016-17, Q3 (January–March)  [1]

Goals for this quarter will become final the beginning of January.  The Product 
and Technology teams regularly post draft goals a month before they are final.  
This email is just a reminder that we do so.

Please feel free to engage with the respective owners identified in each area 
for feedback or additional information before we finalize our goals.  Also 
teams provide additional information on their respective feature pages as well.

Thank you,
Wes

[1] https://www.mediawiki.org/wiki/Wikimedia_Engineering/2016-17_Q3_Goals
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Development on img_auth.php

[Robert Vogel]

Hello!

Recently I've worked on some MediaWiki setups with enabled "img_auth.php". 
During that work I've noticed a few things that I think can be improved, to 
make an extension developer's life easier.
I know that this feature is mostly used by private/intranet wikis, so there are 
only limited resources for future development available at the WMF. Therefore 
I'd like to volunteer to work on "img_auth.php".
Is this something the Wikimedia dev community is interested in? Can I count on 
some support by the original maintainers of "img_auth.php"? I'd be happy about 
any feedback.

Oh, and I've already created a Phabricator task:  
https://phabricator.wikimedia.org/T153174

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

Re: [Wikitech-l] Communication about proposed and planned UI changes

[Johan Jönsson]

On Fri, Dec 16, 2016 at 2:16 PM, Quim Gil  wrote:

> Imagine the same approach for new projects/features, security reviews, new
> betas, release plans... This is a good way to scale communications without
> drowning central spaces like Tech News, wikitech-ambassadors or your
> nearest Village Pump.

This. Many Village Pumps on smaller Wikimedia wikis are already
dominated by untranslated announcements from the WMF. I find it hard
to believe newcomers will be convinced that's a place for them to
discuss, rather than a graveyard for announcements in a foreign
language they might or might not understand. Tech News depends on
volunteer translators who make sure we can reach out with with updates
in ~20 languages. This is possible partly because the amount of
updates they have to translate every week is limited. The vast
majority of Wikimedians – focused on editing their home wikis – have
limited time and energy to keep up with what's happening in the bigger
Wikimedia world; the solution to this is not to turn up the volume
everywhere.

(This, too, is not to define whether something mertis review or not,
but a general comment on communicating technical changes in the
Wikimedia world.)

//Johan Jönsson
--

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

Re: [Wikitech-l] Communication about proposed and planned UI changes

[Quim Gil]

On Fri, Dec 16, 2016 at 12:51 AM, Pine W  wrote:

> The issue which I am attempting to address is not a UI change itself
> (good or bad) but rather communication about proposed and upcoming UI
> changes.


Communication of proposals and changes is a problem indeed. Not just for
UX, the problem is common to other areas of development. We are trying to
define the good practices in the Technical Collaboration Guideline, at
Milestone
communication

.

This is how I personally think that the technical solution should work,
taking UI as an example.

* A UX review checkpoint exists, consisting of a wiki page in MediaWiki.org
where current and past proposals reviewed are logged. Users can see which
proposals are currently under review (with deadlines optionally) and which
ones have been resolved and when.

* Each proposal lives in its own URL (a wiki page, a Phabricator task)
where rationale, updates, and discussion happens.

* Anyone can subscribe to the UX Reviews newsletter
. Teams initiating or
resolving a proposal will announce the move in the newsletter. Users
subscribe to this newsletter will receive updates related exclusively to UX
reviews, no more, no less.

Imagine the same approach for new projects/features, security reviews, new
betas, release plans... This is a good way to scale communications without
drowning central spaces like Tech News, wikitech-ambassadors or your
nearest Village Pump. This is also a good way to attract specialized
contributors and help them shine where they can contribute best (i.e.
design students or professionals happy to volunteer) as opposed to trying
to convince them to follow Tech News, wikitech-ambassadors or your nearest
Village Pump.

This idea doesn't define whether a change of color shade merits a review or
whether the review should last three months, but it helps creating focused
spaces where productive collaboration may happen sooner and more often
without everybody dying out of exasperation or exhaustion.

-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Communication about proposed and planned UI changes

[Sam Wilson]

On Fri, 16 Dec 2016, at 04:18 PM, Gergo Tisza wrote:
> * write a detailed list of everything you intend to do in March
> * in that month, avoid doing anything that you did not think to put on
> that list
> I think you will gain some insights about the cost of trying to organize
> things far ahead if you do actually try it out.


Wow, this really reminds me of the 6 months I once spent under the
Personal Software Process!
https://en.wikipedia.org/wiki/Personal_software_process It did actually
make me feel really productive, but then I'm pretty into stationery and
printed forms and things.

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

Re: [Wikitech-l] Communication about proposed and planned UI changes

[Gergo Tisza]

On Thu, Dec 15, 2016 at 3:51 PM, Pine W  wrote:

> My proposal would be that proposed UI changes which affect large
> proportions of the user base should be announced 3 months in advance.
>

So here is a fun experiment:
* choose an activity you do a lot (say, editing Wikipedia pages)
* write a detailed list of everything you intend to do in March
* in that month, avoid doing anything that you did not think to put on that
list
I think you will gain some insights about the cost of trying to organize
things far ahead if you do actually try it out.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l