Re: [WikimediaMobile] Skins Usage Data

[Toby Negrin]

And just to be clear -- everybody who has browsed the site but has not
logged in (i.e. the vast majority of our readers) will be using Vector?

thanks for putting this together.

-Toby

On Mon, Jun 29, 2015 at 2:47 PM, Gergo Tisza  wrote:

> On Mon, Jun 29, 2015 at 11:16 AM, Adam Baso  wrote:
>
>> I think it was Joaquin, Sam, and Bryan with whom I discussed relative
>> skins usage on some popular skins, in the context of which skins Reading is
>> on the hook for in the sense of full maintenance or high priority fixes
>> (even if only coordinating) when issues arise. Here's that data, based on
>> some queries Timo ran recently (thanks, Timo!).
>>
>> * en.wikipedia.org, users active since 2015-01-01, skin=cologneblue: 7k
>> users.
>> * en.wikipedia.org, users active since 2015-01-01, skin=monobook: 193k
>> users.
>> * en.wikipedia.org, users active since 2015-01-01: 3.1m users.
>>
>> * en.wikipedia.org, users active since 2015-03-01, skin=cologneblue: 6k
>> users.
>> * en.wikipedia.org, users active since 2015-03-01, skin=monobook: 179k
>> users.
>> * en.wikipedia.org, users active since 2015-03-01: 2.3m users.
>>
>> * commons.wikimedia.org, users active since 2015-03-01,
>> skin=cologneblue: 1k users.
>> * commons.wikimedia.org, users active since 2015-03-01, skin=monobook:
>> 59k users.
>> * commons.wikimedia.org, users active since 2015-03-01: 687k users.
>>
>
> Expect the ratio of users with obscure configuration settings to sharply
> rise when you look at groups with higher activity. E.g. a year ago, when I
> looked up various stats for the MediaViewer launch, non-Vector usage was 5%
> for users who edited Wikipedia in the last 30 days, and 15% for those who
> made at least 100 edits in the last 30 days. Non-Monobook usage also grows
> (over a percent for very active editors).
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Skins Usage Data

[Gergo Tisza]

On Mon, Jun 29, 2015 at 11:16 AM, Adam Baso  wrote:

> I think it was Joaquin, Sam, and Bryan with whom I discussed relative
> skins usage on some popular skins, in the context of which skins Reading is
> on the hook for in the sense of full maintenance or high priority fixes
> (even if only coordinating) when issues arise. Here's that data, based on
> some queries Timo ran recently (thanks, Timo!).
>
> * en.wikipedia.org, users active since 2015-01-01, skin=cologneblue: 7k
> users.
> * en.wikipedia.org, users active since 2015-01-01, skin=monobook: 193k
> users.
> * en.wikipedia.org, users active since 2015-01-01: 3.1m users.
>
> * en.wikipedia.org, users active since 2015-03-01, skin=cologneblue: 6k
> users.
> * en.wikipedia.org, users active since 2015-03-01, skin=monobook: 179k
> users.
> * en.wikipedia.org, users active since 2015-03-01: 2.3m users.
>
> * commons.wikimedia.org, users active since 2015-03-01, skin=cologneblue:
> 1k users.
> * commons.wikimedia.org, users active since 2015-03-01, skin=monobook:
> 59k users.
> * commons.wikimedia.org, users active since 2015-03-01: 687k users.
>

Expect the ratio of users with obscure configuration settings to sharply
rise when you look at groups with higher activity. E.g. a year ago, when I
looked up various stats for the MediaViewer launch, non-Vector usage was 5%
for users who edited Wikipedia in the last 30 days, and 15% for those who
made at least 100 edits in the last 30 days. Non-Monobook usage also grows
(over a percent for very active editors).
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Skins Usage Data

[Timo Tijhof]

Yes, it include all users who have used activated their user account in some 
way after 2015-01-01 00:00:00.

Merely reading pages while logged-in usually will not trigger such "touch". 
Logging in, changing preferences, and other actions do set the touch timestamp 
however. Remember that user sessions don't last forever. Currently, Wikimedia 
wikis have a session expiration of 30 days. This means users visiting 
frequently will still "log in" at least once 30 days if they want to remain 
logged-in while visiting.

As included below, I also ran the same query for users active since 2015-03-01. 
This helps to get a sense of the drop off (or "comeback").

— Timo

> On 29 Jun 2015, at 22:19, Jon Robson  wrote:
> 
> Timo - so to clarify these are users who have logged in since 2015-01-01 ?
> 
> It is possible to get a sense of whether they come back?
> e.g. What if someone registered on 2015-01-01, switched to Monobook
> and never came back - are they included?
> 
> 
> On Mon, Jun 29, 2015 at 2:10 PM, Timo Tijhof  wrote:
>> I specified that in the original mail but I guess that got lost:
>> 
>> "Active" here relates to the MediaWiki user_touched database field. This is
>> set whenever the user logs in, as well as after various other actions that
>> users can perform.
>> 
>> 
>> 
>> — Timo
>> 
>> On 29 Jun 2015, at 21:47, Adam Baso  wrote:
>> 
>> Timo, would you please clarify on the definition of "active"?
>> 
>> On Mon, Jun 29, 2015 at 11:30 AM, Jon Robson  wrote:
>>> 
>>> Can you clarify what "active" means?
>>> Does that mean users visiting the page on a daily basis or does it relate
>>> to editors or something else?
>>> 
>>> I'm keen to understand if some of these accounts are dormant and unused or
>>> are frequently logged into.
>>> 
>>> On 29 Jun 2015 11:16 am, "Adam Baso"  wrote:
 
 Hi,
 
 I think it was Joaquin, Sam, and Bryan with whom I discussed relative
 skins usage on some popular skins, in the context of which skins Reading is
 on the hook for in the sense of full maintenance or high priority fixes
 (even if only coordinating) when issues arise. Here's that data, based on
 some queries Timo ran recently (thanks, Timo!).
 
 * en.wikipedia.org, users active since 2015-01-01, skin=cologneblue: 7k
 users.
 * en.wikipedia.org, users active since 2015-01-01, skin=monobook: 193k
 users.
 * en.wikipedia.org, users active since 2015-01-01: 3.1m users.
 
 * en.wikipedia.org, users active since 2015-03-01, skin=cologneblue: 6k
 users.
 * en.wikipedia.org, users active since 2015-03-01, skin=monobook: 179k
 users.
 * en.wikipedia.org, users active since 2015-03-01: 2.3m users.
 
 * commons.wikimedia.org, users active since 2015-03-01, skin=cologneblue:
 1k users.
 * commons.wikimedia.org, users active since 2015-03-01, skin=monobook:
 59k users.
 * commons.wikimedia.org, users active since 2015-03-01: 687k users.
 
 -Adam
 
 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l
 
>> 
>> 
>> 
>> ___
>> Mobile-l mailing list
>> Mobile-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>> 
> 
> 
> 
> -- 
> Jon Robson
> * http://jonrobson.me.uk
> * https://www.facebook.com/jonrobson
> * @rakugojon


___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Skins Usage Data

[Jon Robson]

Timo - so to clarify these are users who have logged in since 2015-01-01 ?

It is possible to get a sense of whether they come back?
e.g. What if someone registered on 2015-01-01, switched to Monobook
and never came back - are they included?


On Mon, Jun 29, 2015 at 2:10 PM, Timo Tijhof  wrote:
> I specified that in the original mail but I guess that got lost:
>
> "Active" here relates to the MediaWiki user_touched database field. This is
> set whenever the user logs in, as well as after various other actions that
> users can perform.
>
>
>
> — Timo
>
> On 29 Jun 2015, at 21:47, Adam Baso  wrote:
>
> Timo, would you please clarify on the definition of "active"?
>
> On Mon, Jun 29, 2015 at 11:30 AM, Jon Robson  wrote:
>>
>> Can you clarify what "active" means?
>> Does that mean users visiting the page on a daily basis or does it relate
>> to editors or something else?
>>
>> I'm keen to understand if some of these accounts are dormant and unused or
>> are frequently logged into.
>>
>> On 29 Jun 2015 11:16 am, "Adam Baso"  wrote:
>>>
>>> Hi,
>>>
>>> I think it was Joaquin, Sam, and Bryan with whom I discussed relative
>>> skins usage on some popular skins, in the context of which skins Reading is
>>> on the hook for in the sense of full maintenance or high priority fixes
>>> (even if only coordinating) when issues arise. Here's that data, based on
>>> some queries Timo ran recently (thanks, Timo!).
>>>
>>> * en.wikipedia.org, users active since 2015-01-01, skin=cologneblue: 7k
>>> users.
>>> * en.wikipedia.org, users active since 2015-01-01, skin=monobook: 193k
>>> users.
>>> * en.wikipedia.org, users active since 2015-01-01: 3.1m users.
>>>
>>> * en.wikipedia.org, users active since 2015-03-01, skin=cologneblue: 6k
>>> users.
>>> * en.wikipedia.org, users active since 2015-03-01, skin=monobook: 179k
>>> users.
>>> * en.wikipedia.org, users active since 2015-03-01: 2.3m users.
>>>
>>> * commons.wikimedia.org, users active since 2015-03-01, skin=cologneblue:
>>> 1k users.
>>> * commons.wikimedia.org, users active since 2015-03-01, skin=monobook:
>>> 59k users.
>>> * commons.wikimedia.org, users active since 2015-03-01: 687k users.
>>>
>>> -Adam
>>>
>>> ___
>>> Mobile-l mailing list
>>> Mobile-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>>
>
>
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>



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

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Skins Usage Data

[Timo Tijhof]

I specified that in the original mail but I guess that got lost:

> "Active" here relates to the MediaWiki user_touched database field. This is 
> set whenever the user logs in, as well as after various other actions that 
> users can perform.



— Timo

> On 29 Jun 2015, at 21:47, Adam Baso  wrote:
> 
> Timo, would you please clarify on the definition of "active"?
> 
> On Mon, Jun 29, 2015 at 11:30 AM, Jon Robson  > wrote:
> Can you clarify what "active" means?
> Does that mean users visiting the page on a daily basis or does it relate to 
> editors or something else?
> 
> I'm keen to understand if some of these accounts are dormant and unused or 
> are frequently logged into.
> 
> On 29 Jun 2015 11:16 am, "Adam Baso"  > wrote:
> Hi,
> 
> I think it was Joaquin, Sam, and Bryan with whom I discussed relative skins 
> usage on some popular skins, in the context of which skins Reading is on the 
> hook for in the sense of full maintenance or high priority fixes (even if 
> only coordinating) when issues arise. Here's that data, based on some queries 
> Timo ran recently (thanks, Timo!).
> 
> * en.wikipedia.org , users active since 2015-01-01, 
> skin=cologneblue: 7k users.
> * en.wikipedia.org , users active since 2015-01-01, 
> skin=monobook: 193k users.
> * en.wikipedia.org , users active since 2015-01-01: 
> 3.1m users.
> 
> * en.wikipedia.org , users active since 2015-03-01, 
> skin=cologneblue: 6k users.
> * en.wikipedia.org , users active since 2015-03-01, 
> skin=monobook: 179k users.
> * en.wikipedia.org , users active since 2015-03-01: 
> 2.3m users.
> 
> * commons.wikimedia.org , users active since 
> 2015-03-01, skin=cologneblue: 1k users.
> * commons.wikimedia.org , users active since 
> 2015-03-01, skin=monobook: 59k users.
> * commons.wikimedia.org , users active since 
> 2015-03-01: 687k users.
> 
> -Adam
> 
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org 
> https://lists.wikimedia.org/mailman/listinfo/mobile-l 
> 
> 
> 

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Skins Usage Data

[Adam Baso]

Timo, would you please clarify on the definition of "active"?

On Mon, Jun 29, 2015 at 11:30 AM, Jon Robson  wrote:

> Can you clarify what "active" means?
> Does that mean users visiting the page on a daily basis or does it relate
> to editors or something else?
>
> I'm keen to understand if some of these accounts are dormant and unused or
> are frequently logged into.
> On 29 Jun 2015 11:16 am, "Adam Baso"  wrote:
>
>> Hi,
>>
>> I think it was Joaquin, Sam, and Bryan with whom I discussed relative
>> skins usage on some popular skins, in the context of which skins Reading is
>> on the hook for in the sense of full maintenance or high priority fixes
>> (even if only coordinating) when issues arise. Here's that data, based on
>> some queries Timo ran recently (thanks, Timo!).
>>
>> * en.wikipedia.org, users active since 2015-01-01, skin=cologneblue: 7k
>> users.
>> * en.wikipedia.org, users active since 2015-01-01, skin=monobook: 193k
>> users.
>> * en.wikipedia.org, users active since 2015-01-01: 3.1m users.
>>
>> * en.wikipedia.org, users active since 2015-03-01, skin=cologneblue: 6k
>> users.
>> * en.wikipedia.org, users active since 2015-03-01, skin=monobook: 179k
>> users.
>> * en.wikipedia.org, users active since 2015-03-01: 2.3m users.
>>
>> * commons.wikimedia.org, users active since 2015-03-01,
>> skin=cologneblue: 1k users.
>> * commons.wikimedia.org, users active since 2015-03-01, skin=monobook:
>> 59k users.
>> * commons.wikimedia.org, users active since 2015-03-01: 687k users.
>>
>> -Adam
>>
>> ___
>> Mobile-l mailing list
>> Mobile-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Skins Usage Data

[Jon Robson]

Can you clarify what "active" means?
Does that mean users visiting the page on a daily basis or does it relate
to editors or something else?

I'm keen to understand if some of these accounts are dormant and unused or
are frequently logged into.
On 29 Jun 2015 11:16 am, "Adam Baso"  wrote:

> Hi,
>
> I think it was Joaquin, Sam, and Bryan with whom I discussed relative
> skins usage on some popular skins, in the context of which skins Reading is
> on the hook for in the sense of full maintenance or high priority fixes
> (even if only coordinating) when issues arise. Here's that data, based on
> some queries Timo ran recently (thanks, Timo!).
>
> * en.wikipedia.org, users active since 2015-01-01, skin=cologneblue: 7k
> users.
> * en.wikipedia.org, users active since 2015-01-01, skin=monobook: 193k
> users.
> * en.wikipedia.org, users active since 2015-01-01: 3.1m users.
>
> * en.wikipedia.org, users active since 2015-03-01, skin=cologneblue: 6k
> users.
> * en.wikipedia.org, users active since 2015-03-01, skin=monobook: 179k
> users.
> * en.wikipedia.org, users active since 2015-03-01: 2.3m users.
>
> * commons.wikimedia.org, users active since 2015-03-01, skin=cologneblue:
> 1k users.
> * commons.wikimedia.org, users active since 2015-03-01, skin=monobook:
> 59k users.
> * commons.wikimedia.org, users active since 2015-03-01: 687k users.
>
> -Adam
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Skins Usage Data

[Adam Baso]

Hi,

I think it was Joaquin, Sam, and Bryan with whom I discussed relative skins
usage on some popular skins, in the context of which skins Reading is on
the hook for in the sense of full maintenance or high priority fixes (even
if only coordinating) when issues arise. Here's that data, based on some
queries Timo ran recently (thanks, Timo!).

* en.wikipedia.org, users active since 2015-01-01, skin=cologneblue: 7k
users.
* en.wikipedia.org, users active since 2015-01-01, skin=monobook: 193k
users.
* en.wikipedia.org, users active since 2015-01-01: 3.1m users.

* en.wikipedia.org, users active since 2015-03-01, skin=cologneblue: 6k
users.
* en.wikipedia.org, users active since 2015-03-01, skin=monobook: 179k
users.
* en.wikipedia.org, users active since 2015-03-01: 2.3m users.

* commons.wikimedia.org, users active since 2015-03-01, skin=cologneblue:
1k users.
* commons.wikimedia.org, users active since 2015-03-01, skin=monobook: 59k
users.
* commons.wikimedia.org, users active since 2015-03-01: 687k users.

-Adam
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [reading web] Phabricating in Q1

[Bahodir Mansurov]

On Jun 29, 2015, at 8:34 AM, Joaquin Oltra Hernandez  
wrote:
> 
> I've mapped the proposed workflow: https://i.imgur.com/Wu7crcB.png 
> 


TLDR ^___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [reading-wmf] Improving Privacy Policy on Mobile

[Jon Robson]

Hi Jacob
I've cc'ed wikitech to get an update on bug
https://phabricator.wikimedia.org/T483
The last update here was in February 2015. I personally think this is
one of our most urgent bugs to fix, but it's not clear who is
responsible for this, and who has the expertise to help resolve it.

The fundamental issue this privacy policy hits, is many our editors
are also hitting - that there is no way to style wikitext content
differently on a mobile screen. This has been a recurring problem for
some time now. https://phabricator.wikimedia.org/T483

The only way to make any progress here currently is the following:
* Add the nomobile class to an element to hide it
* Add a reset rule to MediaWiki:Common.css to reset problematic styles
e.g. https://www.mediawiki.org/w/index.php?title=MediaWiki:Mobile.css

I'm near positive these very same issues were discussed over a year go
for the privacy policy on English Wikipedia and I think the conclusion
was there was little that could be done in current form (if anyone can
remember where that conversation happened).

Note: For wikimediafoundation.org it might be acceptable to move all
inline style rules into
https://m.wikimediafoundation.org/w/index.php?title=MediaWiki:Mobile.css
and use media queries to style content differently. Any capable web
developer should be able to help you with that (I'm not sure who is
building the privacy policy for you).

Jon

On Thu, Jun 25, 2015 at 2:33 PM, Adam Baso  wrote:
> Moving to mobile-l. Discuss.
>
> -Adam
>
> On Wed, Jun 24, 2015 at 10:05 PM, Jon Robson  wrote:
>>
>> cc. reading-list. You'll get more feedback there :)
>> Short reply: There are lots of bugs and larger problems here that need
>> to be solved.
>>
>>
>> On Wed, Jun 24, 2015 at 5:42 PM, Jacob Rogers 
>> wrote:
>> > Hi Jon,
>> >
>> > James A suggested you might be the right person to talk with about
>> > improving
>> > the readability of the WMF privacy policy on mobile devices. Currently,
>> > it's
>> > pretty difficult to look at. It starts with the massive language list,
>> > the
>> > disclaimer renders 1-2 words a line, and the blue boxes also render in
>> > hard
>> > to read lines as well as pushing the main section to scroll off the
>> > screen.
>> >
>> > If you are the right person, what I'm hoping we can do is make the
>> > language
>> > list into an expandable menu, get rid of the blue boxes on the sides if
>> > necessary, and possibly make the examples into an expandable view rather
>> > than have everything shown by default.
>> >
>> > If you're not the right person to this, could you forward me on to
>> > someone
>> > that might be able to help?
>> >
>> > Many thanks,
>> > Jacob
>> > --
>> >
>> > Jacob Rogers
>> > Legal Counsel
>> > Wikimedia Foundation
>> >
>> > NOTICE: This message might have confidential or legally privileged
>> > information in it. If you have received this message by accident, please
>> > delete it and let us know about the mistake. As an attorney for the
>> > Wikimedia Foundation, for legal/ethical reasons I cannot give legal
>> > advice
>> > to, or serve as a lawyer for, community members, volunteers, or staff
>> > members in their personal capacity. For more on what this means, please
>> > see
>> > our legal disclaimer.
>> >
>>
>> ___
>> reading-wmf mailing list
>> reading-...@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/reading-wmf
>
>
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [reading-wmf] Improving Privacy Policy on Mobile

[Jon Robson]

On Mon, Jun 29, 2015 at 10:31 AM, Jon Robson  wrote:
> Hi Jacob
> I've cc'ed wikitech to get an update on bug
> https://phabricator.wikimedia.org/T483
> The last update here was in February 2015. I personally think this is
> one of our most urgent bugs to fix, but it's not clear who is
> responsible for this, and who has the expertise to help resolve it.
>
> The fundamental issue this privacy policy hits, is many our editors
> are also hitting - that there is no way to style wikitext content
> differently on a mobile screen. This has been a recurring problem for
> some time now. https://phabricator.wikimedia.org/T483
>
> The only way to make any progress here currently is the following:
> * Add the nomobile class to an element to hide it
> * Add a reset rule to MediaWiki:Common.css to reset problematic styles
> e.g. https://www.mediawiki.org/w/index.php?title=MediaWiki:Mobile.css
>
> I'm near positive these very same issues were discussed over a year go
> for the privacy policy on English Wikipedia and I think the conclusion
> was there was little that could be done in current form (if anyone can
> remember where that conversation happened).
>
> Note: For wikimediafoundation.org it might be acceptable to move all
> inline style rules into
> https://m.wikimediafoundation.org/w/index.php?title=MediaWiki:Mobile.css
> and use media queries to style content differently. Any capable web
> developer should be able to help you with that (I'm not sure who is
> building the privacy policy for you).
>
> Jon
>
> On Thu, Jun 25, 2015 at 2:33 PM, Adam Baso  wrote:
>> Moving to mobile-l. Discuss.
>>
>> -Adam
>>
>> On Wed, Jun 24, 2015 at 10:05 PM, Jon Robson  wrote:
>>>
>>> cc. reading-list. You'll get more feedback there :)
>>> Short reply: There are lots of bugs and larger problems here that need
>>> to be solved.
>>>
>>>
>>> On Wed, Jun 24, 2015 at 5:42 PM, Jacob Rogers 
>>> wrote:
>>> > Hi Jon,
>>> >
>>> > James A suggested you might be the right person to talk with about
>>> > improving
>>> > the readability of the WMF privacy policy on mobile devices. Currently,
>>> > it's
>>> > pretty difficult to look at. It starts with the massive language list,
>>> > the
>>> > disclaimer renders 1-2 words a line, and the blue boxes also render in
>>> > hard
>>> > to read lines as well as pushing the main section to scroll off the
>>> > screen.
>>> >
>>> > If you are the right person, what I'm hoping we can do is make the
>>> > language
>>> > list into an expandable menu, get rid of the blue boxes on the sides if
>>> > necessary, and possibly make the examples into an expandable view rather
>>> > than have everything shown by default.
>>> >
>>> > If you're not the right person to this, could you forward me on to
>>> > someone
>>> > that might be able to help?
>>> >
>>> > Many thanks,
>>> > Jacob
>>> > --
>>> >
>>> > Jacob Rogers
>>> > Legal Counsel
>>> > Wikimedia Foundation
>>> >
>>> > NOTICE: This message might have confidential or legally privileged
>>> > information in it. If you have received this message by accident, please
>>> > delete it and let us know about the mistake. As an attorney for the
>>> > Wikimedia Foundation, for legal/ethical reasons I cannot give legal
>>> > advice
>>> > to, or serve as a lawyer for, community members, volunteers, or staff
>>> > members in their personal capacity. For more on what this means, please
>>> > see
>>> > our legal disclaimer.
>>> >
>>>
>>> ___
>>> reading-wmf mailing list
>>> reading-...@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/reading-wmf
>>
>>
>>
>> ___
>> Mobile-l mailing list
>> Mobile-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [video club] RailsConf 2015 - Implementing a Strong Code Review Culture

[Toby Negrin]

Thanks for posting this Sam -- code review is one of the best parts of our
engineering culture, I'll definitely watch this when I get a chance.

-Toby

On Mon, Jun 29, 2015 at 7:59 AM, Sam Smith  wrote:

> Hey y'all,
>
> I watch a lot of talks in my downtime. I even post the ones I like to a
> Tumblr… sometimes [0]. I felt like sharing Derek Prior's "Implementing a
> Strong Code Review Culture" from RailsConf 2015 in particular because it's
> relevant to the conversations that the Reading Web team are having around
> process and quality. You can watch the talk on YouTube [1] and, if you're
> keen, you can read the paper that's referenced over at Microsoft Research
> [2].
>
> I particularly like the challenge of providing two paragraphs of context
> in a commit message – to introduce the problem and your solution – and
> trying to overcome negativity bias in written communication* by offering
> compliments whenever possible and asking, not telling, while providing
> critical feedback.
>
> I hope you enjoy the talk as much as I did.
>
> –Sam
>
> [0] http://sometalks.tumblr.com/
> [1] https://www.youtube.com/watch?v=PJjmw9TRB7s
> [2] http://research.microsoft.com/apps/pubs/default.aspx?id=180283
>
> * The speaker said "research has shown" but I didn't see a citation
>
> *Notes (width added emphasis)*
>
>- Code review isn't for catching bugs
>- "Expectations, Outcomes, and Challenges of Modern Code Review"
>- Chief benefits of code review:
>   - Knowledge transfer
>   - Increased team awareness
>   - Finding alternative solutions
>- Code review is "the discipline of explaining your code to your peers"
>- Process is more important than the result
>- Goes on to define code review as "the discipline of discussing your
>code with your peers"
>- If we get better at code review, then we'll get better at
>communicating technically as a team
>
> Rules of Engagement
>
>- As an author, provide context
>
>
>- "If content is king, then context is God"
>   - *In a pull request (patch set) the code is the content and the
>   commit message is the context*
>   - Provide sufficient context - bring the reviewer up to speed with
>   what you've been doing in the past X hours
>   - *Challenge: provide at least two paragraphs of context in your
>   commit message*
>   - This additional context lives on in the commit history whereas
>   links to issue trackers might not
>
>
>- As a reviewer, ask questions rather than making demands
>   - Research has shown that there's a negativity bias in written
>   communication. *Offer compliments whenever you can*
>   - *When you need to provide critical feedback, ask, don't tell*,
>   e.g. "extract a service to reduce some of this duplication" could be
>   formulated as "what do you think about extracting a service to reduce 
> some
>   of this duplication?"
>  - "Did you consider?", "can you clarify?"
>  - "Why didn't you just..." is framed negatively and includes the
>  word just
>   - Use the Socratic method: asking and answering questions to
>   stimulate critical thinking and to illuminate ideas
>
> Insist on high quality reviews, but agree to disagree
>
>- Conflict is good. *Conflict drives a higher standard of coding
>provided there's healthy debate*
>- Everyone has a minimum bar to entry for quality. Once that bar is
>met, then everything else is a trade-off
>- Reasonable people disagree all the time
>- Review what's important to you
>- SRP (Single Responsibility Principle) (the S from SOLID)
>   - Naming
>   - Complexity
>   - Test Coverage
>   - ... (whatever else you're comfortable in giving feedback on)
>
>
>- What about style?
>   - Style is important
>   - "People who received style comments on their code perceived that
>   review negatively"
>   - Adopt a styleguide
>
>
> Benefits of a Strong Code Review Culture
>
>- Better code
>- Better developers through constant knowledge transfer
>- Team ownership of code, which leads to fewer silos
>- Healthy debate
>
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] [video club] RailsConf 2015 - Implementing a Strong Code Review Culture

[Sam Smith]

Hey y'all,

I watch a lot of talks in my downtime. I even post the ones I like to a
Tumblr… sometimes [0]. I felt like sharing Derek Prior's "Implementing a
Strong Code Review Culture" from RailsConf 2015 in particular because it's
relevant to the conversations that the Reading Web team are having around
process and quality. You can watch the talk on YouTube [1] and, if you're
keen, you can read the paper that's referenced over at Microsoft Research
[2].

I particularly like the challenge of providing two paragraphs of context in
a commit message – to introduce the problem and your solution – and trying
to overcome negativity bias in written communication* by offering
compliments whenever possible and asking, not telling, while providing
critical feedback.

I hope you enjoy the talk as much as I did.

–Sam

[0] http://sometalks.tumblr.com/
[1] https://www.youtube.com/watch?v=PJjmw9TRB7s
[2] http://research.microsoft.com/apps/pubs/default.aspx?id=180283

* The speaker said "research has shown" but I didn't see a citation

*Notes (width added emphasis)*

   - Code review isn't for catching bugs
   - "Expectations, Outcomes, and Challenges of Modern Code Review"
   - Chief benefits of code review:
  - Knowledge transfer
  - Increased team awareness
  - Finding alternative solutions
   - Code review is "the discipline of explaining your code to your peers"
   - Process is more important than the result
   - Goes on to define code review as "the discipline of discussing your
   code with your peers"
   - If we get better at code review, then we'll get better at
   communicating technically as a team

Rules of Engagement

   - As an author, provide context


   - "If content is king, then context is God"
  - *In a pull request (patch set) the code is the content and the
  commit message is the context*
  - Provide sufficient context - bring the reviewer up to speed with
  what you've been doing in the past X hours
  - *Challenge: provide at least two paragraphs of context in your
  commit message*
  - This additional context lives on in the commit history whereas
  links to issue trackers might not


   - As a reviewer, ask questions rather than making demands
  - Research has shown that there's a negativity bias in written
  communication. *Offer compliments whenever you can*
  - *When you need to provide critical feedback, ask, don't tell*, e.g.
  "extract a service to reduce some of this duplication" could be
formulated
  as "what do you think about extracting a service to reduce some of this
  duplication?"
 - "Did you consider?", "can you clarify?"
 - "Why didn't you just..." is framed negatively and includes the
 word just
  - Use the Socratic method: asking and answering questions to
  stimulate critical thinking and to illuminate ideas

Insist on high quality reviews, but agree to disagree

   - Conflict is good. *Conflict drives a higher standard of coding
   provided there's healthy debate*
   - Everyone has a minimum bar to entry for quality. Once that bar is met,
   then everything else is a trade-off
   - Reasonable people disagree all the time
   - Review what's important to you
   - SRP (Single Responsibility Principle) (the S from SOLID)
  - Naming
  - Complexity
  - Test Coverage
  - ... (whatever else you're comfortable in giving feedback on)


   - What about style?
  - Style is important
  - "People who received style comments on their code perceived that
  review negatively"
  - Adopt a styleguide


Benefits of a Strong Code Review Culture

   - Better code
   - Better developers through constant knowledge transfer
   - Team ownership of code, which leads to fewer silos
   - Healthy debate
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] [reading web] Phabricating in Q1

[Joaquin Oltra Hernandez]

[Long email, sorry]

Hi friends,

There's been some talk about how we currently phabricate and there doesn't
seem
to be much satisfaction in our current workflows, and as part of the new
team
we are getting more software artifacts so we are going to have to adapt to
this
new situation.

For that, I've mapped how we do things now, and proposed how we could move
forward to effectively avoid more conphusion (sorry 'bout that).


## Current workflows

Reading web currently uses 3 permanent boards + current sprint board.

Reading-web:
* Type: Team project.
* Contains: Epics, bugs, features.
* Board: Columns with should have, could have, etc.  Mixed columns.
Triaging column.

MobileFrontend:
* Type: Software project.
* Contains: Bugs, tech tasks, features, discussions.
* Board: Backlog.

Gather:
* Type: Team project + Software project (mix between the two above).
* Contains: Epics, bugs, tech tasks, features.
* Board: Columns with should have, could have, etc.  Mixed columns.
Triaging column.

### Bugs

MobileFrontend bugs are added to MobileFrontend and Reading-web. They get
categorized and triaged in Reading-web by team/standup and brought into the
sprint if appropriate.

Gather bugs are added to Gather & current sprint. Gather is triaged by JonR
--
high priority are brought straight into the sprint.

### Features

MobileFrontend/Gather features added to Reading-Web **Needs triage** column.
Have MobileFrontend or Gather project added by TechPro as needed. Moved to
**Must Have**, **Should Have**, or **Could Have** as necessary

### Problems

* Workflow is different for MobileFrontend and Gather.
* Boards have mixed responsibilities.
* No one place to triage bugs and features.
* Reading-Web is *noisey*.
* Tasks with several tags -- leads to noise across all projects.
* No clear high level overview of Reading-Web workload/workflow.

On top of how we are currently working, we are getting a bunch of software
artifacts that we are going to have to triage & maintain really soon. We
need
to adapt to deal with multiple projects/boards and maintain team vision of
what
we are doing. (Current process probably won't scale well with more than a
few
software projects).

## Proposal

Taking into account that we want to:

* Be able to work across multiple phabricator projects for different
software
  artifacts.
* Maintain a high level overview of team focus through time (so that we all
  know what we are focusing on mainly).
* Have a clear place to triage for the projects we are responsible for.

### Solution

 phStructure

Reading web will use N+2 boards. N+1 permanent boards + current sprint
board.
* *N being the number of software projects we maintain*.

Reading-web:
* Type: Team project.
* Contains: Epics.
* Board: Time based columns, left is closer, right is further on time. (Can
be
  sprint based + Quarter based, or something else)
  (Ex: In progress | Next sprint | ...).

MobileFrontend:
* Type: Software project.
* Contains: Bugs, tech tasks, small features, discussions.
* Board: Backlog | Discussion.

Gather:
* Type: Software project.
* Contains: Bugs, tech tasks, small features, discussions.
* Board: Backlog | Discussion.

PageImages:
* Type: Software project.
* Contains: Bugs, tech tasks, small features, discussions.
* Board: Backlog | Discussion.

TextExtracts:
* Type: Software project.
* Contains: Bugs, tech tasks, small features, discussions.
* Board: Backlog | Discussion.

ETC. (same for the rest of the software projects we're getting).

Suggestion is that software projects get the same layout, but not necessary.

 Phrocess

# Bugs and pheatures

Such tasks will get submitted against the corresponding software project
that
involves them.

If there is a bug on the mobile web, it'll get submitted to MobileFrontend,
if
there is a bug with collections, it'll get submitted against Gather. Same
for
feature requests. If there is a bug on MobileFrontend & PageImages it'll get
submitted to both.

Default priority *Needs triage* means task hasn't been triaged yet.

Each project has tasks that involve that project. Reading-web stays a high
level view of the team's focuses through time available for everybody.

# Triaging

We'll have a **saved query** available to everybody to triage (standups or
else). Example:
https://phabricator.wikimedia.org/maniphest/query/c_ZQlOwVk9I8/
(note this looks like shit because we don't use priorities at all right
now).

When triaging a bug, we'll set it's priority to something that makes sense
regarding severity and add to current sprint project if priority is high.

When triaging a feature, we'll set it's priority to something that makes
sense
regarding perceived importance and ping product owner. PO should add as
subtask
of epic if makes sense.

# Sprint preparation. Task creation.

>From the epics on Reading-web we'll spin off subtasks of specific work
that'll
get tagged with the concrete software project where they need to be acted
upon
with a priority.

Sprint groomin