Re: [WikimediaMobile] [Wikitech-l] 2017-01-04 Scrum of Scrums meeting notes

[Bahodir Mansurov]

Federico,

Please create a task on Phabricator and tag it with "MobileFrontend". The
task will be on our team's radar and we will prioritize it accordingly.

Baha

On Thu, Jan 5, 2017 at 5:10 AM, Federico Leva (Nemo) 
wrote:

> Thanks. https://www.mediawiki.org/wiki/Scrum_of_scrums/2017-01-04#Web
> mentions a next sprint about MobileFrontend technical debt. How can one
> propose tickets for such sprint?
>
> Nemo
>
> ___
> 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] Update on Upload to Commons Android App project

[Bahodir Mansurov]

Thank you! I use regularly use this app and improvements are always  
welcome.


On Wed, 17 Feb 2016 00:48:53 -0500, Josephine Lim  
 wrote:



Hi all,
I've been working on a project to improve the categorization of
pictures in the Upload to Commons Android app
 as part of the Outreachy
Dec '15 program, which is soon drawing to an end. To summarize, 3 new
features have been implemented in this app:

1. If a picture with geolocation is uploaded, nearby category
suggestions are offered (based on the categories of other Commons
images with similar coordinates)

2. If a picture with no geolocation is uploaded, nearby category
suggestions are offered based on the user's current location. This is
optional and only works if enabled in Settings.

3. Category search (when typing in the search field) has been made
more flexible, whereas previously this was done solely by prefix
search. E.g. now searching for 'latte' should be able to return 'iced
latte'.

The latest version of the app is v1.11 and can be downloaded at
.
Please feel free to leave feedback or bug reports at
.

I have had an amazing time working on this app as part of the
Outreachy program, and I greatly appreciate all the support and help
that the WMF community has given me. :)


Cheers!





--
Baha

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

Re: [WikimediaMobile] Breaking apart MobileFrontend's front and back ends

[Bahodir Mansurov]

Looks interesting!

On Tue, 2015-09-01 at 14:52 +0100, Sam Smith wrote:
> Hey all,
> 
> I've been encouraged to write an update on a 1%* project that I've 
> been
> working on: separating the HTML formatter and APIs from the Minerva 
> skin.
> 
> Right now, I've created a new extension, which contains the code,
> associated configuration variables, and unit/integration tests [0] 
> and am
> running it alongside a cut down version of the MobileFrontend 
> extension [1]
> locally.
> 
> My long-term goal is to further separate out the HTML formatter into 
> a
> versioned library and to version the API extension so that we can 
> make
> smaller, more easily reasoned about changes to smaller, more easily
> reasoned about components and update the (relative) titan that is the
> MobileFrontend extension more responsibly.
> 
> My short-term goals are:
> 
> * to *cover* the new extension in integration tests so that I can 
> make
> structural changes
> * to get the unit tests passing without hitting the DB
> * to document the new extension thoroughly
> * to reduce the binding between the two extensions to exactly one 
> call [2]
> * to get the extension deployed
> 
> Cool? Cool!
> 
> –Sam
> 
> * Not a typo
> 
> [0] https://github.com/phuedx/MobileView
> [1] https://github.com/phuedx/mediawiki-extensions-MobileFrontend
> [2]
> https://github.com/phuedx/mediawiki-extensions
> -MobileFrontend/blob/dd9e99e0f805812914b8d3266dc17239b2968a24/include
> s/MobileFrontend.body.php#L38
> ___
> 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] outcomes from beta header analysis

[Bahodir Mansurov]

On Thu, 2015-08-13 at 10:07 -0700, Jon Katz wrote:
> We need to either increase beta users, a/b test, or test in stable 
> more (which would also mean a/b testing on a small % of the 
> population)

Thanks, Jon for the write up. I strongly believe this is the way
forward for our future experiments. Comparing beta results to stable
doesn't make much sense.

Baha

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

Re: [WikimediaMobile] [Apps] New Android production release

[Bahodir Mansurov]

Hi Orsolya,

> On Jul 8, 2015, at 2:34 PM, Orsolya Gyenes  
> wrote:
> 
> It doesn't work with the WP Beta app at all but if I log into 
> hu.wikipedia.org  with Google Chrome with my 
> username I can access my watchlist but it's really basic. 

I’m just curious what features are missing from the mobile watchlist site? Any 
specific examples?

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

Re: [WikimediaMobile] [Apps] New Android production release

[Bahodir Mansurov]

On Jul 8, 2015, at 10:30 AM, Dmitry Brant  wrote:
> 
> Stay tuned for future updates! We have some big things in store for our next 
> release. You won't want to miss it!
> 
That’s great news, Dmitry. Is watchlist coming to Android too? (Or is it 
already there which I didn’t see?) I’d really love to be able to access all my 
watched pages on Android and add them to the saved pages for a later reading.

Thanks,
Baha___
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]

It looks good to me. Thanks for the hard work, Joaquin.

> On Jun 30, 2015, at 2:56 PM, Joaquin Oltra Hernandez 
>  wrote:
> 
> Any feedback folks?
> 
> I've been talking to the tech lead and we're considering adopting this and 
> adapting as we go along for improvements we could make.
> 
> Cheers
> 
> On Mon, Jun 29, 2015 at 8:14 PM, Bahodir Mansurov  <mailto:bmansu...@wikimedia.org>> wrote:
> On Jun 29, 2015, at 8:34 AM, Joaquin Oltra Hernandez 
> mailto:jhernan...@wikimedia.org>> wrote:
>> 
>> I've mapped the proposed workflow: https://i.imgur.com/Wu7crcB.png 
>> <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 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] [Update] Browser tests per patch

[Bahodir Mansurov]

May I suggest that Barry should not +1 patches. It gives a false impression 
that the code is alright even though the code may not be covered at all. Can we 
have it just -1 when there is a problem, and stay silent otherwise?

> On Jun 18, 2015, at 8:55 PM, Jon Robson  wrote:
> 
> So far I'm seeing some extremely positive results. The tests are
> running super fast (in phantomjs the smoke tests are taking less than
> 3 minutes...).
> 
> I've been manually running him whilst I do code review in parallel and
> he's already generated some interesting conversation on this patchset:
> https://gerrit.wikimedia.org/r/#/c/219249/ 
> 
> 
> If you want to pair and get this to be less hacky I'm more than happy!
> 
> 
> On Thu, Jun 18, 2015 at 5:41 PM, Dan Duvall  > wrote:
>> Nice work, Jon.
>> 
>> I've opened a task for defining a JJB builder/template and getting something
>> like this into CI sooner rather than later.[1] I think your setup proves
>> that a set of well-groomed MW-Selenium integration tests can be stable
>> enough for this purpose, and we can start with an even smaller subset of
>> core tests for a pre-merge build. Of course this isn't something that we
>> planned to do 'now' now—sometimes 'then' suddenly becomes 'now' so
>> 'soon'—but we can start with an experiment on Gather or MobileFrontend
>> tests, since their health has greatly improved, and see how it goes.
>> 
>> [1] https://phabricator.wikimedia.org/T103039
>> 
>> On Thu, Jun 18, 2015 at 11:03 AM, Jon Robson  wrote:
>>> 
>>> So the script that actually runs the browser test is not in a generic
>>> useful form but it is:
>>> https://gist.github.com/jdlrobson/32b607f8009e897ee80c
>>> 
>>> It uses the GerritCommandLine tool to do grabbing and reviewing
>>> https://github.com/jdlrobson/GerritCommandLine
>>> 
>>> Ideally if we can use labs-tools-gerrit-to-redis for identifying
>>> patches and then pulling them down we wouldn't need the
>>> GerritCommandLine tool since the code to submit a review is pretty
>>> trivial and captured in this function:
>>> https://github.com/jdlrobson/GerritCommandLine/blob/master/gerrit.py#L277
>>> 
>>> I've also put this in the task
>>> https://phabricator.wikimedia.org/T101069#1379462
>>> 
>>> We'll probably want an instance per extension, to simplify having to
>>> worry about dependencies (we can just run a git update on all
>>> extensions after each checkout)
>>> 
>>> On Thu, Jun 18, 2015 at 4:32 AM, Joaquin Oltra Hernandez
>>>  wrote:
 Awesome Jon! I'm so happy to finally see this developing :DD
 
 Loving the : `Browserbot happy!`
 
 I've noticed it can report either the name of the failing test or the
 full
 log. What do you think if we show that, and a url with the pasted log
 somewhere publicly to not put too much noise on the comments but still
 be
 able to see it? Something like
 https://phabricator.wikimedia.org/paste/...
 
 +1 to where is the source.
 +1 to documenting how you've set it all up on wiki somewhere.
 
 I also think we need a catchy phrase for the -1s!
 
 Thanks for you work on this, we'll get more focused time for it soon.
 
 On Thu, Jun 18, 2015 at 11:33 AM, Sam Smith 
 wrote:
> 
> I agree with Florian everything that you've written should be in a
> public
> version control system.
> 
> Second, I'd ask that you document your experiences so far in getting
> this
> set up and how it works so that other members of the vertical can help
> to
> maintain it moving forward.
> 
> Third, great work!!1
> 
> <3
> 
> –Sam
> 
> On Thu, Jun 18, 2015 at 7:09 AM, florian.schmidt.wel...@t-online.de
>  wrote:
>> 
>> 
>>> It's currently working via a script that you can find here:
>>> /srv/mediawiki/extensions/Gather/tests/browser/Barry.sh
>> 
>> It would be great to have the script in a public version control
>> system
>> (e.g. github?), especially for people, e.g. volunteers, who can't ssh
>> to
>> gather-browser-tests.eqiad.wmflabs[1]
>> 
>> [1] all people, who're not members of
>> https://wikitech.wikimedia.org/wiki/Nova_Resource:Mobile-smoketests
>> 
>> Best,
>> Florian
>> 
>> -Original-Nachricht-
>> Betreff: [WikimediaMobile] [Update] Browser tests per patch
>> Datum: Thu, 18 Jun 2015 03:27:32 +0200
>> Von: Jon Robson 
>> An: "QA (software quality assurance) for Wikimedia projects."
>> , mobile-l 
>> 
>> Background: mobile wants to gain more confidence in its browser tests
>> by running a subset of browser tests on a case by case basis [0].
>> 
>> Good news: I've got a proof of concept running and Barry the browser
>> test bot has given some legitimate helpful reviews to Gather [1].
>> 
>> Even better news: It's proving itself valuable already [

Re: [WikimediaMobile] "Flag for later" in Phabricator's Maniphest

[Bahodir Mansurov]

To me flagging sounds like subscribing without notifications.

> On May 12, 2015, at 4:36 AM, Joaquin Oltra Hernandez 
>  wrote:
> 
> Hi,
> 
> Kaldari asked yesterday on irc what the "Flag for later" button does on a 
> task on Maniphest.
> 
> After a few minutes of confusing googling (you can imagine the freaking 
> button appearing in thousands of bugs with the button...) I found that it is 
> like a favourites list, personal and hidden, with color coded categories.
> 
> Go to https://phabricator.wikimedia.org/flag/ 
>  while logged in and you will see 
> the items you have flagged for later.
> 
> Not sure what to use it for, but for example I've flagged a bug I created 
> that I was having difficulty finding everytime, for easy access.
> 
> If you think of other use cases or actually are using it for something, it 
> would be great to know.
> 
> Cheers.
> ___
> 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] Skynet is winning the battle on IRC

[Bahodir Mansurov]

I use LimeChat, but haven’t tried hard enough to filter out bots. I don’t mind 
creating a new channel and directing bots there. XChat advanced settings 
related to “Text Events”, which maybe what you want. Not sure about the backlog 
support though.

> On Apr 30, 2015, at 3:36 PM, Joaquin Oltra Hernandez 
>  wrote:
> 
> Bryan that's exactly what I'd like. Direct the bots to other channels and 
> join those if you want the notifications. I personally will because I find 
> them very useful.
> 
> Baha the reality is not that easy. I want backlog so I've moved to the 
> irccloud chat, and there I can only ignore users. The problem is that I find 
> wikibugs and grrrit-wm very useful and I don't want to hide them, I want to 
> separate them to another channel. This way for activity and notifications 
> I'll join the notifications channel, and in the main channel I'll be able to 
> read and have conversations with people without tons of noise.
> Would you mind having another channel open with the notifications? We should 
> expect all team members to autojoin that channel when working too.
> 
> Jon, Ori told me that limechat can hide messages based on regexes. I poked 
> around it and searched google but found nothing useful and he didn't reply on 
> irc so I'm not sure which dark secrets he holds :P
> 
> What client are you using baha?
> 
> On Thu, Apr 30, 2015 at 9:18 PM, Jon Robson  <mailto:jdlrob...@gmail.com>> wrote:
> I personally detest them now I am working with mostly a remote team.
> They are useful occasionally but not missing messages from team
> members is far too important for me.
> 
> I've not found a good way to filter these out (look at the pink lines
> that mean pings in my irc client - http://imgur.com/MsYk9OO 
> <http://imgur.com/MsYk9OO>)
> 
> I've also noticed an increase in private conversations recently to
> compensate for this which sucks for openness.
> 
> A compromise to reduce noise might be:
> * don't include name of author in patch submits/phabricator tasks
> reported by the bot (so that author doesn't get pings that mask other
> pings from other users) - but someone would have to implement this.
> 
> I think moving to a new channel seems like an easy solution. Nothing
> gets missed provided people know to join it and nothing needs to be
> implemented.
> 
> On Thu, Apr 30, 2015 at 11:36 AM, Bahodir Mansurov
> mailto:bmansu...@wikimedia.org>> wrote:
> > I think they should stay and everyone should be able to configure their
> > client to hide specific message from showing.
> >
> > On Apr 30, 2015, at 1:50 PM, Brian Gerstle  > <mailto:bgers...@wikimedia.org>> wrote:
> >
> > Totally agree, having *important messages only* in IRC would be nice.
> > Another idea would be to have notifs go to more specific chat rooms based on
> > the project.
> >
> > On Thu, Apr 30, 2015 at 1:45 PM, Corey Floyd  > <mailto:cfl...@wikimedia.org>> wrote:
> >>
> >> I think this is a good idea… the only thing I think should be in the main
> >> channel is something like breaking the build (at least for the apps guys)
> >>
> >> On Thu, Apr 30, 2015 at 1:29 PM, Joaquin Oltra Hernandez
> >> mailto:jhernan...@wikimedia.org>> wrote:
> >>>
> >>> Hi!
> >>>
> >>> I've been feeling that the signal to noise ratio on #wikimedia-mobile
> >>> since the addition of wikibugs and our new apps engineers (more grrrit-wm
> >>> spam) is turning to be 0 (that is, no signal because of too much noise).
> >>>
> >>> It is really difficult to talk about anything when somebody else is
> >>> working (and that is what we do, so...).
> >>>
> >>> I would like to propose moving the machines to a different channel, maybe
> >>> a couple of them ( #wikimedia-mobile-web-bots & 
> >>> #wikimedia-mobile-apps-bots
> >>> for example ) so that they continue to be useful but in a different 
> >>> channel,
> >>> and so that we can read again the chats with just the conversations.
> >>>
> >>> What do you think?
> >>>
> >>> Cheers.
> >>>
> >>> ___
> >>> Mobile-l mailing list
> >>> Mobile-l@lists.wikimedia.org <mailto:Mobile-l@lists.wikimedia.org>
> >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l 
> >>> <https://lists.wikimedia.org/mailman/listinfo/mobile-l>
> >>>
> >>
> >>
> >>

Re: [WikimediaMobile] Skynet is winning the battle on IRC

[Bahodir Mansurov]

I think they should stay and everyone should be able to configure their client 
to hide specific message from showing.

> On Apr 30, 2015, at 1:50 PM, Brian Gerstle  wrote:
> 
> Totally agree, having *important messages only* in IRC would be nice. Another 
> idea would be to have notifs go to more specific chat rooms based on the 
> project.
> 
> On Thu, Apr 30, 2015 at 1:45 PM, Corey Floyd  > wrote:
> I think this is a good idea… the only thing I think should be in the main 
> channel is something like breaking the build (at least for the apps guys)
> 
> On Thu, Apr 30, 2015 at 1:29 PM, Joaquin Oltra Hernandez 
> mailto:jhernan...@wikimedia.org>> wrote:
> Hi!
> 
> I've been feeling that the signal to noise ratio on #wikimedia-mobile since 
> the addition of wikibugs and our new apps engineers (more grrrit-wm spam) is 
> turning to be 0 (that is, no signal because of too much noise).
> 
> It is really difficult to talk about anything when somebody else is working 
> (and that is what we do, so...).
> 
> I would like to propose moving the machines to a different channel, maybe a 
> couple of them ( #wikimedia-mobile-web-bots & #wikimedia-mobile-apps-bots for 
> example ) so that they continue to be useful but in a different channel, and 
> so that we can read again the chats with just the conversations.
> 
> What do you think?
> 
> Cheers.
> 
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org 
> https://lists.wikimedia.org/mailman/listinfo/mobile-l 
> 
> 
> 
> 
> 
> -- 
> Corey Floyd
> Software Engineer 
> Mobile Apps / iOS 
> Wikimedia Foundation
> 
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org 
> https://lists.wikimedia.org/mailman/listinfo/mobile-l 
> 
> 
> 
> 
> 
> -- 
> EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle 
> 
> IRC: bgerstle
> ___
> 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] Removing MobileFrontend from Gather dependencies

[Bahodir Mansurov]

Essentially, does that mean we want to re-create Mantle? If so, we should 
consider the reasons why we dismantled it.

> On Apr 13, 2015, at 3:10 PM, Jon Robson  wrote:
> 
> I did a quick spike [1] to work out how Gather could stop depending on
> MobileFrontend.
> 
> Essentially problems come into 2 categories:
> 
> 1) Finding a place for Gather in the desktop skin and addressing
> styling issues in desktop skins (I am working on these and don't see
> any major blockers here).
> I think to fix this we simply need to provide Gather as a desktop beta 
> feature.
> This is tracked here: https://phabricator.wikimedia.org/T95227 and I
> see no issues with doing this.
> 
> 2) frontend code standardisation
> The main problem with the hard dependency is that MobileFrontend uses
> a library that was built around the same time as OOJSUI. Migrating
> MobileFrontend to use OOJSUI is a big task and although has happened
> somewhat (the codebase now uses OOJS for class inheritance) it is by
> no means complete.
> 
> Gather current depends on a variety of MobileFrontend modules which
> mainly include: API, overlay, user and user setting code, EventLogging
> schema code, notifications code. We also have a method
> mw.mobileFrontend.require and mw.mobileFrontend.define for defining
> modules. OOJS ui does this differently writing class names to the OO
> global variable object.
> 
> ==The long term fix===
> ... is obviously to migrate all the code to OOJS UI which I believe
> would require the following steps:
> * https://phabricator.wikimedia.org/T88559 which as an end result will
> rewrite overlay code in oojs ui
> * Rewriting mw.util.notify as an oo js ui component and folding the
> mobile toast notification into it. -
> https://phabricator.wikimedia.org/T66565
> * Core should have a way to store user settings in localStorage rather
> than using $.cookie (similar to M.require( 'settings' ) ) - something
> akin to https://phabricator.wikimedia.org/T67008
> * EventLogging Schema.js should be ported to oojs ui and moved into core.
> * We only use user for the getEditCount function - it would be trivial
> to rewrite using mw.user
> 
> == the short term fix==
> We could split out the frontend library MobileFrontend uses to allow
> us to share it between Gather and MobileFrontend.
> 
> The way I see this working is to merge all the shared generic JS code
> into its own project just like oojs ui and slowly rewrite it there
> till it is pure oo js ui. This would take everything in the
> javascripts/common/ folder except application.js and bundle it into
> one file.
> 
> We could include this as a submodule in both projects, both extensions
> conditionally adding a RL module for it when it does not exist.
> 
> What do people think about taking this approach on the short term?
> 
> [1] https://phabricator.wikimedia.org/T94100
> 
> ___
> 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] Versioning MobileFrontend

[Bahodir Mansurov]

That’s great Florian. Jon, does that address your concern?

> On Mar 25, 2015, at 2:46 AM, florian.schmidt.wel...@t-online.de wrote:
> 
> Hint:
> For a better wiki-formatted output (e.g. with {{git}} and {{phabricator}} we 
> could reuse mediawiki-tools-release[1]. With the following command (e.g.) you 
> can create a new changelog of MF:
>  
> $ cd /var/www/.../extensions/MobileFrontend/
> $../../../mediawiki-release/make-deploy-notes/make-deploy-notes 
> origin/wmf/1.25wmf20 origin/wmf/1.25wmf21
> (depends on where you cloned mediawiki-tools-release)
>  
> The output would be: https://phabricator.wikimedia.org/P431 
> 
> (== Core == are the changes of MobileFrontend, the exceptions and errors are, 
> because the script isn't designed to run from an extension dir, but we could 
> ignore them, or rewrite the script).
>  
> That's how we create the changelogs for wmf-versions[2].
>  
> [1] https://github.com/wikimedia/mediawiki-tools-release 
> 
> [2] https://www.mediawiki.org/wiki/Category:WMF_Releases 
> 
>  
> Freundliche Grüße / Kind regards
> Florian Schmidt 
>  
>  
> -Original-Nachricht-
> Betreff: Re: [WikimediaMobile] Versioning MobileFrontend
> Datum: Tue, 24 Mar 2015 18:42:48 +0100
> Von: Sam Smith 
> An: Jon Robson , mobile-l 
> 
>  
>  
>  
> Seems sensible, but knowing history I don't think it will be updated 
> correctly.
>  
> We're a different team now. Whaddya say we give it a try? 
>  
> I think the updating of VERSION.txt really needs to be automated. Can we have 
> a script that can be run bumps the version number and  generates these logs 
> by searching for keywords e.g. 'Bug:' 'Feature:' and generates this list. I 
> think without this, this is a nice idea but will be disastrous.
>  
> https://github.com/tj/git-extras/wiki/Commands#git-changelog 
>  is one of the 
> many solutions to this turned up by a quick Google :)
>  
> –Sam
>  
> ___
> 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] Versioning MobileFrontend

[Bahodir Mansurov]

Great link, Sam. We should use it.

> On Mar 24, 2015, at 1:42 PM, Sam Smith  wrote:
> 
> Seems sensible, but knowing history I don't think it will be updated 
> correctly.
> 
> We're a different team now. Whaddya say we give it a try? 
>  
> I think the updating of VERSION.txt really needs to be automated. Can we have 
> a script that can be run bumps the version number and  generates these logs 
> by searching for keywords e.g. 'Bug:' 'Feature:' and generates this list. I 
> think without this, this is a nice idea but will be disastrous.
> 
> https://github.com/tj/git-extras/wiki/Commands#git-changelog 
>  is one of the 
> many solutions to this turned up by a quick Google :)
> 
> –Sam
> ___
> 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] Fwd: Versioning MobileFrontend

[Bahodir Mansurov]

Moving to mobile-l

> Begin forwarded message:
> 
> Date: March 20, 2015 at 5:00:09 PM EDT
> Subject: Re: Versioning MobileFrontend
> From: Jon Robson 
> To: Bahodir Mansurov 
> Cc: mobile-tech 
> 
> Seems sensible, but knowing history I don't think it will be updated 
> correctly.
> 
> I think the updating of VERSION.txt really needs to be automated. Can we have 
> a script that can be run bumps the version number and  generates these logs 
> by searching for keywords e.g. 'Bug:' 'Feature:' and generates this list. I 
> think without this, this is a nice idea but will be disastrous.
> 
> 
> On Fri, Mar 20, 2015 at 1:56 PM, Bahodir Mansurov  <mailto:bmansu...@wikimedia.org>> wrote:
> Hello,
> 
> I’ve submitted a patch [1] in which I’d like to start documenting changes in 
> MobileFrontend and versioning it so that interested third parties are more 
> informed about developments in MF. I think we will bump versions at the end 
> of our sprints. I would appreciate it if anyone can share any similar 
> experience they had or any other suggestions. Thank you.
> 
> Baha
> 
> 
> [1] https://gerrit.wikimedia.org/r/#/c/198382/ 
> <https://gerrit.wikimedia.org/r/#/c/198382/>

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

Re: [WikimediaMobile] Readability of the first sentence on Wikipedia articles

[Bahodir Mansurov]

It’s official, Ryan is old-fashioned, unless you can show otherwise. Here is 
the challenge: [1].

[1] 
http://www.nytimes.com/interactive/2015/03/08/opinion/sunday/algorithm-human-quiz.html?_r=0
 


> On Mar 9, 2015, at 2:17 PM, Ryan Kaldari  wrote:
> 
> Call me old-fashioned, but I would really hate to see the lead sentences of 
> Wikipedia articles auto-generated by a program. Our text is dry and 
> monotonous enough as it is :)
> 
> On Mon, Mar 9, 2015 at 5:05 AM, Jane Darnell  > wrote:
> I agree with Magnus that it should be Wikidata to the rescue for problems 
> like these, not some new policy that throws current WP contributors into a 
> tizzy. I am not sure how precisely, but maybe if all parts of a lead sentence 
> were in Wikidata then one could then experiment with a new Wikidata property 
> for "Mobile lead" which could first be seeded with the label and barring that 
> the WP lead?
> 
> On Mon, Mar 9, 2015 at 12:47 PM, Amir E. Aharoni 
> mailto:amir.ahar...@mail.huji.ac.il>> wrote:
> I'll state a bunch of things that are obvious to me, but should probably be 
> written down in some way...
> 
> IPA, other names, and names in other languages indeed make reading harder. 
> They are there because of a tradition. There's a tradition of printing 
> encyclopedia articles like this (that's also where the bold font in each 
> articles' first words comes from). Just open any printed encyclopedia. It's a 
> nice continuation of tradition, and Wikipedia takes it to extremes thanks to 
> the blessings of Unicode - old printed encyclopedias were lucky to have 
> Cyrillic characters in their typography, and some good ones had IPA, Arabic, 
> and Devanagari, but you won't find pervasive use of Georgian or Kannada in a 
> lot of printed encyclopedias. We have pretty much everything in Wikipdeia. 
> The information is valuable, but having it all in parentheses in the first 
> sentence begins to be non-practical.
> 
> It will help to at least be aware that a proposal to change this will break 
> with traditions; traditions must be treated with respect. But in the 21st 
> century on the web it may make sense to transfer IPA and names in other 
> languages to the infobox. Other names in the same language will probably have 
> to stay in the opening sentence, because article naming is a 
> super-contentious issue.
> 
> And yes, the Foundation has no authority to just change it, because it's a 
> matter for the Manual of Style, which is owned by the community (in all 
> languages). As a member of the editing community, I would support it, and I 
> even mentioned it on mailing lists in the past (too busy to search where), 
> but it needs to go through proper discussion.
> 
> 
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com 
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore‬
> 
> 2015-03-07 2:49 GMT+02:00 Dan Garry  >:
> (moving to mobile-l)
> 
> Thanks Vibha, this is really informative.
> 
> It's very clear that our first sentences really suck for supporting quick 
> lookup, primarily because their information hierarchy is all wrong. That 
> said, it's important to remember that we now have Wikidata descriptions 
> displayed in the apps for this exact reason: to let people find out quickly 
> and easily what something is.
> 
> So, although I agree that our first sentences are suboptimal, it's important 
> to put the problem in context and remember that users do have Wikidata 
> descriptions now to satisfy this use case. It's not like we're totally 
> failing them, we could just be doing a bit better.
> 
> Rather than piling on hacks by trying to scrape the content in the first 
> sentence and reorganise it (which causes information loss, and is extremely 
> fragile from a technological perspective), the long term solution is, at 
> least to me, to invest in is getting our engaged readers to write clear, 
> coherent Wikidata descriptions. These can then be used across all platforms 
> to support that workflow.
> 
> Of course, there may be room for some quick wins that we can put in place 
> while we figure out truly compelling UX for getting readers to submit 
> descriptions.  We can explore those quick wins in our brainstorming session 
> on Monday. But we must remember that these will only be short-term, hacky 
> solutions to the problem, and that we need to address this problem at the 
> source in order to be really successful at it.
> 
> Thanks!
> 
> Dan
> 
> On 6 March 2015 at 16:13, Jon Robson  > wrote:
> Any reason this is on mobile-tech and not mobile-l (I'd love to hear from 
> people like Amir on this subject)? It would be good to flag this problem to a 
> wider audience and part of our problem with most mobile issues is people just 
> are not awa

Re: [WikimediaMobile] [Web] WikiGrok code review session

[Bahodir Mansurov]

Cool

> On Feb 19, 2015, at 10:46 AM, Sam Smith  wrote:
> 
> Hey,
> 
> I've been working on removing WikiGrok version A from the codebase (per [0]). 
> During a round of code review Baha mentioned that there are some changes that 
> he'd like to make, which I definitely agree with.
> 
> AFAICT there's one card that tracks cleaning up one part of WikiGrok [1]. How 
> about we get together via Hangouts and do a group review of WikiGrok. The 
> Growth team did this while we were spinning down in order to identify all of 
> the unnecessary code to delete as well as a few minor improvements that could 
> be made. I suggest that the outcome of this meeting would be a set of cards 
> detailing the changes we'd like to make to WikiGrok as well as a tracking 
> card – with a story!
> 
> Cool? Cool!
> 
> –Sam
> 
> [0] 
> https://trello.com/c/t995SzUd/3-3-remove-obsolete-wikigrok-version-and-consolidate-code
>  
> 
> [1] 
> https://trello.com/c/HMAkwvyr/22-5-hygiene-cleanup-wikigrokdialog-js-views 
> ___
> 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] tmi (too many images)

[Bahodir Mansurov]

> On Jan 27, 2015, at 10:39 AM, Jon Robson  wrote:
> 
> We previously explored this
> but it didn't get enough support and I think it is worth revisiting
> now the MobileFrontend code is in a stronger place.

I was not part of the previous conversation, but I guess one of the reasons 
against it was that we wanted users to be able to view images when they go 
offline. How can we solve this problem if we delay loading images?___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Long-form editing on mobile

[Bahodir Mansurov]

It looks great. I’m surprised that their default layout is QWERTY though.

> On Jan 17, 2015, at 2:26 AM, Monte Hurd  wrote:
> 
> I think we're all aware of the challenges of editing on mobile, especially 
> when it comes to long-form editing.
> 
> Does the device in the following video make anyone else feel hopeful about 
> the future of long-form edits on mobile?
> 
> http://youtu.be/HwGK5RvNOFI 
>  
> http://i.imgur.com/DWrI2JY.gif 
> ___
> 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] WikiGrok test in stable now live

[Bahodir Mansurov]

It’s amazing to see it live.

> On Dec 12, 2014, at 12:53 PM, Ryan Kaldari  wrote:
> 
> I would also like to thank Dario, Magnus, the rest of the kick-ass mobile web 
> team, my parents, God, and the Foundation!
Are you sure you didn’t forget anyone else? ;))___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Web] Spike: Explore using CSSLint/LessLint in mobile

[Bahodir Mansurov]

There is lesslint for running on less code. It uses CSSLint under the hood. I 
don’t think CSSLint can be run on less code.

> On Nov 23, 2014, at 7:38 PM, Jon Robson  wrote:
> 
> Can CSSLint be run on less code though, or will we have to generate
> load.php urls and run it there?
> 
> is there any advantage to using lesslint / any reason we wouldn't use it?
> 
> 
> On Sat, Nov 22, 2014 at 5:12 AM, Bahodir Mansurov
>  wrote:
>> Here are our [1] LESS code conventions. Basically, CSSLint doesn’t support
>> any of our existing conventions. It’s more concerned about errors,
>> compatibility, and performance. Our rules are mainly about syntax. We could
>> write (in JavaScript) CSSLint rules to support our current code conventions
>> though. Here [2] are some custom rules.
>> 
>> Since our code convention doesn’t talk about the existing CSSLint rules [3],
>> in order to figure out which rules are controversial I think we should all
>> discuss the existing rules [3].
>> 
>> Also, the VE team uses CSSLint; possibly other teams too. However, I don’t
>> think any team is using lesslint.
>> 
>> 
>> [1] http://www.mediawiki.org/wiki/Manual:Coding_conventions/CSS#LESS
>> [2] https://github.com/medikoo/csslint-next/tree/master/rules
>> [3] https://github.com/CSSLint/csslint/wiki/Rules
>> 
>> On Nov 21, 2014, at 3:45 AM, Joaquin Oltra Hernandez
>>  wrote:
>> 
>> CSS is a beast and any help is going to be useful.
>> 
>> As Jon said, we probably need a longer spike/task to see if any other teams
>> are doing CSS linting and there are already conventions we can use, and to
>> determine what validation rules we want to use.
>> 
>> El 21/11/2014 2:53, "Jon Robson"  escribió:
>>> 
>>> Which rules would MobileFrontend be able to use from the start?
>>> Which rules might be controversial to adopt?
>>> 
>>> 
>>> On Fri, Nov 21, 2014 at 9:00 AM, Bahodir Mansurov
>>>  wrote:
>>>> After reading benefits of CSSLint there is no doubt in my mind that we
>>>> should use it. Here [1] are some of the benefits. They range from
>>>> possible
>>>> errors to compatibility to performance, etc. With grunt we can use
>>>> grunt-lesslint [2], which employs CSSLint under the hood so we can also
>>>> tweak it using CSSLint rules.
>>>> 
>>>> What do you guys think?
>>>> 
>>>> [1] https://github.com/CSSLint/csslint/wiki/Rules.
>>>> [2] https://github.com/jgable/grunt-lesslint
>>>> 
>>>> ___
>>>> 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
>> 
>> 


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

Re: [WikimediaMobile] [Web] Spike: Explore using CSSLint/LessLint in mobile

[Bahodir Mansurov]

Here are our [1] LESS code conventions. Basically, CSSLint doesn’t support any 
of our existing conventions. It’s more concerned about errors, compatibility, 
and performance. Our rules are mainly about syntax. We could write (in 
JavaScript) CSSLint rules to support our current code conventions though. Here 
[2] are some custom rules.

Since our code convention doesn’t talk about the existing CSSLint rules [3], in 
order to figure out which rules are controversial I think we should all discuss 
the existing rules [3].

Also, the VE team uses CSSLint; possibly other teams too. However, I don’t 
think any team is using lesslint.


[1] http://www.mediawiki.org/wiki/Manual:Coding_conventions/CSS#LESS 
<http://www.mediawiki.org/wiki/Manual:Coding_conventions/CSS#LESS>
[2] https://github.com/medikoo/csslint-next/tree/master/rules 
<https://github.com/medikoo/csslint-next/tree/master/rules>
[3] https://github.com/CSSLint/csslint/wiki/Rules 
<https://github.com/CSSLint/csslint/wiki/Rules>

> On Nov 21, 2014, at 3:45 AM, Joaquin Oltra Hernandez 
>  wrote:
> 
> CSS is a beast and any help is going to be useful.
> 
> As Jon said, we probably need a longer spike/task to see if any other teams 
> are doing CSS linting and there are already conventions we can use, and to 
> determine what validation rules we want to use.
> 
> El 21/11/2014 2:53, "Jon Robson"  <mailto:jrob...@wikimedia.org>> escribió:
> Which rules would MobileFrontend be able to use from the start?
> Which rules might be controversial to adopt?
> 
> 
> On Fri, Nov 21, 2014 at 9:00 AM, Bahodir Mansurov
> mailto:bmansu...@wikimedia.org>> wrote:
> > After reading benefits of CSSLint there is no doubt in my mind that we
> > should use it. Here [1] are some of the benefits. They range from possible
> > errors to compatibility to performance, etc. With grunt we can use
> > grunt-lesslint [2], which employs CSSLint under the hood so we can also
> > tweak it using CSSLint rules.
> >
> > What do you guys think?
> >
> > [1] https://github.com/CSSLint/csslint/wiki/Rules 
> > <https://github.com/CSSLint/csslint/wiki/Rules>.
> > [2] https://github.com/jgable/grunt-lesslint 
> > <https://github.com/jgable/grunt-lesslint>
> >
> > ___
> > Mobile-l mailing list
> > Mobile-l@lists.wikimedia.org <mailto:Mobile-l@lists.wikimedia.org>
> > https://lists.wikimedia.org/mailman/listinfo/mobile-l 
> > <https://lists.wikimedia.org/mailman/listinfo/mobile-l>
> >
> 
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org <mailto:Mobile-l@lists.wikimedia.org>
> https://lists.wikimedia.org/mailman/listinfo/mobile-l 
> <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] [Web] Spike: Explore using CSSLint/LessLint in mobile

[Bahodir Mansurov]

After reading benefits of CSSLint there is no doubt in my mind that we should 
use it. Here [1] are some of the benefits. They range from possible errors to 
compatibility to performance, etc. With grunt we can use grunt-lesslint [2], 
which employs CSSLint under the hood so we can also tweak it using CSSLint 
rules.

What do you guys think?

[1] https://github.com/CSSLint/csslint/wiki/Rules 
.
[2] https://github.com/jgable/grunt-lesslint 
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Using jsbeautify in MobileFrontend

[Bahodir Mansurov]

Do you know why there are spaces inside () but not inside []. Just curious.

> On Nov 20, 2014, at 7:07 PM, Max Semenik  wrote:
> 
> Spaces inside of () is the MW convention, inside of [] they're indeed 
> unneeded.
> 
> On Thu, Nov 20, 2014 at 4:03 PM, Bahodir Mansurov  <mailto:bmansu...@wikimedia.org>> wrote:
> I honestly think that we should do away with spaces inside () and []. It puts 
> an end to ugly code like this:
> 
> if ( $viewportMeta[ 0 ] && ( isIPhone4 || isIPhone5 ) ) {
> 
> compare with this (so much nicer)
> if ($viewportMeta[0] && (isIPhone4 || isIPhone5)) {
> 
> By removing space we are no longer stressing () and [], the focus shifts to 
> other parts of code for easier reading.
> 
> 
>> On Nov 20, 2014, at 3:19 PM, Jon Robson > <mailto:jrob...@wikimedia.org>> wrote:
>> 
>> Follow up
>> If I run `make jsbeautify` now
>> then https://gist.github.com/jdlrobson/a05ddad00175ebceac68 
>> <https://gist.github.com/jdlrobson/a05ddad00175ebceac68> is the result.
>> 
>> Outstanding actions:
>> * Need input on rest of the team about which of delete
>> this.cache[title]; or delete this.cache[ title ]; is the preferred
>> standard.
>> * You'll notice jsbeautify and inlne comments need to be ironed out.
>> For example:
>> https://gist.github.com/jdlrobson/a05ddad00175ebceac68#file-gistfile1-diff-L257
>>  
>> <https://gist.github.com/jdlrobson/a05ddad00175ebceac68#file-gistfile1-diff-L257>
>> 
>> Apart from the above 2 jsbeautify makes some adjustments to our
>> whitspace which I guess we'll just have to live with.
>> 
>> Please can everyone else let me know how they think we should proceed?
>> 
>> 
>> 
>> On Wed, Nov 19, 2014 at 4:12 AM, Bahodir Mansurov
>> mailto:bmansu...@wikimedia.org>> wrote:
>>> As for # Rule 4, it makes sense to add spaces inside square brackets. The 
>>> reasoning is the same as why we add spaces inside parenthesis.
>>> 
>>>> On Nov 18, 2014, at 12:28 PM, Jon Robson >>> <mailto:jrob...@wikimedia.org>> wrote:
>>>> 
>>>> I explored running jsbeautify [1] on the MobileFrontend codebase and
>>>> looked at how the output differs from the current styling. It
>>>> introduces various rules that MobileFrontend is currently not adhering
>>>> too. MobileFrontend already uses jscs [2] so we want to make sure the
>>>> outputs of both are compatible. Here is my report on that with the
>>>> recommendation that we should use it.
>>>> 
>>>> #Rule 1: object properties defined on a single line.
>>>> e.g.
>>>> {
>>>> foo: 2,
>>>> bar: 3
>>>> }
>>>> NOT { foo: 2, bar: 3 }
>>>> 
>>>> I think this would be a good idea to adopt. I will explore if jscs can
>>>> enforce this.
>>>> 
>>>> # Rule 2: variables that are initialised must be followed by a new
>>>> line (although I noted a few odd cases e.g. in Page.js after a "?:"
>>>> expression and /MobileWebClickTracking.js
>>>> e.g.
>>>> var Foo, bar = $( 'div' ),
>>>> Baz,
>>>> Bar;
>>>> 
>>>> not:
>>>> var Foo, bar = $( 'div' ), Baz, Bar;
>>>> 
>>>> This will be fixed if I implement https://trello.com/c/0dkx0ldL 
>>>> <https://trello.com/c/0dkx0ldL>
>>>> 
>>>> # Rule 3: All chained events should be indented
>>>> e.g.
>>>> foo()
>>>> .bar();
>>>> 
>>>> not
>>>> foo().
>>>> bar();
>>>> 
>>>> Seems like a no brainer. One that happens naturally most of the time.
>>>> 
>>>> # Rule 4: Spacing in object parameters
>>>> e.g.
>>>> foo[ 1 ]
>>>> [ 1, 2, 3, 4 ]
>>>> 
>>>> not:
>>>> foo[1]
>>>> [1, 2, 3, 4]
>>>> 
>>>> This is different to MediaWiki coding conventions but I can implement
>>>> https://github.com/beautify-web/js-beautify/issues/424 
>>>> <https://github.com/beautify-web/js-beautify/issues/424> to give us
>>>> this.
>>>> We seem a bit inconsistent ourselves with this convention - let me
>>>> know how you think this rule should work in our codebase...
>>>> 
>>>> # Rule 5: New line after variable declarations
>>>> 
>>>> var x, y, z;
>

Re: [WikimediaMobile] Using jsbeautify in MobileFrontend

[Bahodir Mansurov]

I honestly think that we should do away with spaces inside () and []. It puts 
an end to ugly code like this:

if ( $viewportMeta[ 0 ] && ( isIPhone4 || isIPhone5 ) ) {

compare with this (so much nicer)
if ($viewportMeta[0] && (isIPhone4 || isIPhone5)) {

By removing space we are no longer stressing () and [], the focus shifts to 
other parts of code for easier reading.


> On Nov 20, 2014, at 3:19 PM, Jon Robson  wrote:
> 
> Follow up
> If I run `make jsbeautify` now
> then https://gist.github.com/jdlrobson/a05ddad00175ebceac68 is the result.
> 
> Outstanding actions:
> * Need input on rest of the team about which of delete
> this.cache[title]; or delete this.cache[ title ]; is the preferred
> standard.
> * You'll notice jsbeautify and inlne comments need to be ironed out.
> For example:
> https://gist.github.com/jdlrobson/a05ddad00175ebceac68#file-gistfile1-diff-L257
> 
> Apart from the above 2 jsbeautify makes some adjustments to our
> whitspace which I guess we'll just have to live with.
> 
> Please can everyone else let me know how they think we should proceed?
> 
> 
> 
> On Wed, Nov 19, 2014 at 4:12 AM, Bahodir Mansurov
>  wrote:
>> As for # Rule 4, it makes sense to add spaces inside square brackets. The 
>> reasoning is the same as why we add spaces inside parenthesis.
>> 
>>> On Nov 18, 2014, at 12:28 PM, Jon Robson  wrote:
>>> 
>>> I explored running jsbeautify [1] on the MobileFrontend codebase and
>>> looked at how the output differs from the current styling. It
>>> introduces various rules that MobileFrontend is currently not adhering
>>> too. MobileFrontend already uses jscs [2] so we want to make sure the
>>> outputs of both are compatible. Here is my report on that with the
>>> recommendation that we should use it.
>>> 
>>> #Rule 1: object properties defined on a single line.
>>> e.g.
>>> {
>>> foo: 2,
>>> bar: 3
>>> }
>>> NOT { foo: 2, bar: 3 }
>>> 
>>> I think this would be a good idea to adopt. I will explore if jscs can
>>> enforce this.
>>> 
>>> # Rule 2: variables that are initialised must be followed by a new
>>> line (although I noted a few odd cases e.g. in Page.js after a "?:"
>>> expression and /MobileWebClickTracking.js
>>> e.g.
>>> var Foo, bar = $( 'div' ),
>>> Baz,
>>> Bar;
>>> 
>>> not:
>>> var Foo, bar = $( 'div' ), Baz, Bar;
>>> 
>>> This will be fixed if I implement https://trello.com/c/0dkx0ldL
>>> 
>>> # Rule 3: All chained events should be indented
>>> e.g.
>>> foo()
>>> .bar();
>>> 
>>> not
>>> foo().
>>> bar();
>>> 
>>> Seems like a no brainer. One that happens naturally most of the time.
>>> 
>>> # Rule 4: Spacing in object parameters
>>> e.g.
>>> foo[ 1 ]
>>> [ 1, 2, 3, 4 ]
>>> 
>>> not:
>>> foo[1]
>>> [1, 2, 3, 4]
>>> 
>>> This is different to MediaWiki coding conventions but I can implement
>>> https://github.com/beautify-web/js-beautify/issues/424 to give us
>>> this.
>>> We seem a bit inconsistent ourselves with this convention - let me
>>> know how you think this rule should work in our codebase...
>>> 
>>> # Rule 5: New line after variable declarations
>>> 
>>> var x, y, z;
>>> 
>>> z();
>>> 
>>> not:
>>> var x, y, z;
>>> z();
>>> 
>>> Also:
>>> function foo() {}
>>> 
>>> function bar() {}
>>> 
>>> not:
>>> function foo() {}
>>> function bar() {}
>>> 
>>> Seems like a no brainer and shouldn't introduce any major issues with
>>> code review.
>>> 
>>> # Rule 6: Comments must respect the current indentation level
>>> 
>>> if () {
>>> ...
>>> // If i is 5 we do something special
>>> } else if ( i === 5 ){
>>> 
>>> }
>>> becomes
>>> if () {
>>> ...
>>> // If i is 5 we do something special
>>> } else if ( i === 5 ){
>>> 
>>> }
>>> We'll have to think about what to do with these comments but I don't
>>> think this should be a blocker to using jsbeautify. It will only pop
>>> up occasionally.
>>> 
>>> # Rule 7: On long if statements the curly brace must be indented.
>>> And the first condition should be 

Re: [WikimediaMobile] Using jsbeautify in MobileFrontend

[Bahodir Mansurov]

As for # Rule 4, it makes sense to add spaces inside square brackets. The 
reasoning is the same as why we add spaces inside parenthesis.

> On Nov 18, 2014, at 12:28 PM, Jon Robson  wrote:
> 
> I explored running jsbeautify [1] on the MobileFrontend codebase and
> looked at how the output differs from the current styling. It
> introduces various rules that MobileFrontend is currently not adhering
> too. MobileFrontend already uses jscs [2] so we want to make sure the
> outputs of both are compatible. Here is my report on that with the
> recommendation that we should use it.
> 
> #Rule 1: object properties defined on a single line.
> e.g.
> {
> foo: 2,
> bar: 3
> }
> NOT { foo: 2, bar: 3 }
> 
> I think this would be a good idea to adopt. I will explore if jscs can
> enforce this.
> 
> # Rule 2: variables that are initialised must be followed by a new
> line (although I noted a few odd cases e.g. in Page.js after a "?:"
> expression and /MobileWebClickTracking.js
> e.g.
> var Foo, bar = $( 'div' ),
> Baz,
> Bar;
> 
> not:
> var Foo, bar = $( 'div' ), Baz, Bar;
> 
> This will be fixed if I implement https://trello.com/c/0dkx0ldL
> 
> # Rule 3: All chained events should be indented
> e.g.
> foo()
> .bar();
> 
> not
> foo().
> bar();
> 
> Seems like a no brainer. One that happens naturally most of the time.
> 
> # Rule 4: Spacing in object parameters
> e.g.
> foo[ 1 ]
> [ 1, 2, 3, 4 ]
> 
> not:
> foo[1]
> [1, 2, 3, 4]
> 
> This is different to MediaWiki coding conventions but I can implement
> https://github.com/beautify-web/js-beautify/issues/424 to give us
> this.
> We seem a bit inconsistent ourselves with this convention - let me
> know how you think this rule should work in our codebase...
> 
> # Rule 5: New line after variable declarations
> 
> var x, y, z;
> 
> z();
> 
> not:
> var x, y, z;
> z();
> 
> Also:
> function foo() {}
> 
> function bar() {}
> 
> not:
> function foo() {}
> function bar() {}
> 
> Seems like a no brainer and shouldn't introduce any major issues with
> code review.
> 
> # Rule 6: Comments must respect the current indentation level
> 
> if () {
> ...
> // If i is 5 we do something special
> } else if ( i === 5 ){
> 
> }
> becomes
> if () {
> ...
> // If i is 5 we do something special
> } else if ( i === 5 ){
> 
> }
> We'll have to think about what to do with these comments but I don't
> think this should be a blocker to using jsbeautify. It will only pop
> up occasionally.
> 
> # Rule 7: On long if statements the curly brace must be indented.
> And the first condition should be on the same line
> 
> if ( enableToc || ...
> 
> && baz ) {
> 
> 
> not:
> if (
> enableToc || ...
> 
> && baz ) {
> 
> Again I'm not sure if this will happen too often. This to me is a sign
> that we should be using functions rather than long if statements
> personally. Again not a blocker.
> 
> Actions:
> * Implement https://github.com/beautify-web/js-beautify/issues/424
> * You guys need to advise me on how we should handle square brackets
> in our codebase in such a way we respect MediaWiki coding conventions
> and come up with a consistent style we are happy with and can adhere
> to.
> * I'll implement https://trello.com/c/0dkx0ldL in some form
> * I'll explore if jscs can support objects defined on new line
> * When the above are done I recommend we turn on jsbeautify for the project.
> 
> I've setup a tracking card for the above work:
> https://trello.com/c/5btWf2JN/90-snakes-on-a-plane
> and will be looking at these problems today.
> 
> [1] https://github.com/beautify-web/js-beautify
> [2] https://github.com/jscs-dev/node-jscs
> 
> ___
> 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] Investigate expanding WikiGrok scope (Biographies)

[Bahodir Mansurov]

Here is the text for non-trello people:

For Actors

* Was this person a [cast member, role] in this [movie, TV show]?

1) How would we generate potential claims of this type?
Get the list of titles from 
http://www.wikidata.org/wiki/Wikidata:List_of_properties/Works#Film. This list 
can be used to fill in the first placeholder (cast member, role, etc.).
Get the Filmography [P1283] of the Actor. This can be used to suggest a movie / 
TV show. The query may looks like this: claim[1283:2263] - (filmography of Tom 
Hanks).

2) How difficult/expensive is that?
Pretty straightforward.

3) How interesting would it be for users to answer?
I don't think this type of question is interesting that much. The question 
stresses the role of the actor in a movie. A better (easier for the user) 
question maybe: "Was this person involved in some movie?".



For team sports players [baseball/football/basketball/cricket, etc.] players:

* What team?

1) How would we generate potential claims of this type?

Find the team in which the player plays: 
P54 = member of the sports team
Q615 = Lionel Messi

Find the league in which the team plays: 
P118 = league
Q7156 = FC Barcelona

Find all sports teams in the league: 
Q324867 = La Liga
Q12973014 = sports team

2) Randomly pick a team from the list and construct a question.
How difficult/expensive is that?
Doesn't look difficult at all.

3) How interesting would it be for users to answer?
Very interesting especially for sports fans.


Thanks,
Baha


On Oct 17, 2014, at 2:53 PM, Bahodir Mansurov  wrote:

> In this spike 
> (https://trello.com/c/qf8vEwP3/12-spike-investigate-expanding-wikigrok-scope-biographies)
>  I’ve looked into how we can expand WikiGrok scope by asking questions about 
> actors and sports team players. I’d love to hear what you guys think.
> 
> Baha 

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

[WikimediaMobile] Investigate expanding WikiGrok scope (Biographies)

[Bahodir Mansurov]

In this spike 
(https://trello.com/c/qf8vEwP3/12-spike-investigate-expanding-wikigrok-scope-biographies)
 I’ve looked into how we can expand WikiGrok scope by asking questions about 
actors and sports team players. I’d love to hear what you guys think.

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