And if it is smaller than what the team agreed, then all the better!

I'm fine with the task as it is, if we agree on points. We can have big tasks.

1 because:

Sent an email to discuss.

By using runtime it shaves 1/3rd of the size :)

@Aleksey_WMDE I didn't know that was the case, I see now in https://vuejs.org/v2/guide/installation.html#Runtime-Compiler-vs-Runtime-only

The examples from T167041#3394034 but reformatted and + preact and preact(no-jsx):

In T167041#3390764, @phuedx wrote:

The doc definitely addresses the desired outcomes. Is there supposed to be a conclusion here or not?

👏

Seems like a topic for a different card.

Tested it on a patch, seems to work well and fast. Let's see how it serves us, maybe we can revisit in a few weeks to see if we've been using it.

Nice, consistent and clear.

Will signoff soon.

@ovasileva @Nirzar For what is worth (I'm a terrible user), I did go through both prototypes, and in the second one I 100% missed the settings cog, and thought we were getting rid of it, and asked myself where would we put the settings like the font size stuff if we got rid of it once things came to stable, and them moved on.

@ovasileva Any html can be there theoretically. Practically probably not much more.

Re: Developer notes 2, from an irc chat w/ @phuedx, if this ends up being a REST service, we could consume the parsoid HTML or MCS which have well formed html and sectioning logic already done, instead of using textextracts.

Ping @ovasileva, you have a question in the description.

Coverage is a vanity metric. Please don't use it to justify priority or imply the code is well tested. It isn't.

I've clarified title and description, removed the experiment word from the description.

In T168380#3384389, @Nuria wrote:

Could we please clarify what is the overall goal here cause I am not sure I understand.

T144622: Add exparagraphs parameter to API has been declined in favor of this task. That one was High prio, so I'm setting this one as High. Feel free to back it down if it isn't.

I'm going to go ahead and decline this one given the proposed use case is being tackled in T168625: Make the Page Summary API return an "intro" for a page.

@bmansurov For the data about hypothesis 3 (browsers), is there any way we could identify if the duplicate events are sent by a few clients, or many of them? Any anon client token we could group by?

I'd appreciate review

Sounds great!

In T167236#3380249, @Tbayer wrote:

Hold on - please keep in mind that I basically have not been involved with this schema until last month, so this kind of question is perhaps best addressed to the people who were involved with T114303 back in 2015 and/or these later (February 2017) changes ;)

Very interesting. Seems in line with previous research 👍

cc/ @phuedx who is working on gathering requirements for the html version of the summary endpoint for Page-Previews.

In T164762#3311406, @Jdlrobson wrote:

Done > https://www.mediawiki.org/wiki/Reading/Web/Projects/NewMobileWebsite/API_Inventory

Thanks a lot @Jdlrobson 👏 . Great work

IMO sorting the preferred languages by number of previous clicks, would be preferable. Or even showing an (x) to the right of the item to remove it from the list of clicked languages.

In T167236#3375645, @Nuria wrote:

Not being familiar with the feature this is what I see:

I think related articles is enabled for all wikipedia here: https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L17285
and that whether you are showed more articles is driven by isEnabledForCurrentUser function here: https://github.com/wikimedia/mediawiki-extensions-RelatedArticles/blob/master/resources/ext.relatedArticles.readMore.bootstrap/index.js#L73 which has two buckets on unequal size: 1% and 99%, Thus this code "disables related articles for 1% of population" Terminology is confusing cause it talks about buckets and control when in this case (if I am understanding the code right) is neither, we are just enabling a feature for 99% of devices.

In T167236#3375289, @Tbayer wrote:

Hi folks, just to double triple check: Can someone verify whether the bucketing and sampling method and rates now match the description on the schema talk page? There seems to be a contradiction regarding sampling rates. (T167310 says 0.01%, but the talk page specification says 1%, based on what I was told last month when I started looking into this whole issue, and vetted later by someone from the team.

I've started work here. I'll bring the summary table back when I'm finished.

In T167041#3367447, @Jan_Dittrich wrote:

As far as I understood this, preact says it is compatible with React. That "compatibility to react" is what I referred to with "react API" (but maybe, technically, this is not API)

Not necessarily undefined I guess, maybe it is being called with NaN or 'NaN' or something like that.

In T167181#3363861, @Jdlrobson wrote:

Yep. I did originally do this for all runs but it's super slow, so I decided the same, just didn't implement it. I want to make sure this is useful before coding it some more.

Thanks @Tbayer, good to know.

@Jan_Dittrich There is this optional package preact-compat that shims the React API if you need it.

To be clear, the approach listed on WikimediaEvents is per schema.

I'm closing this declined as I haven't experienced this exact behavior for some time and the task is old enough.

I don't have any particular opinions on the design of the tracking and the test, but just wanted to point out that Hygiene: SamplingRate -> BucketSize is just a name change for the variables, from sampling to bucketing, given that the they are used for bucketing with mw.experiments.

@pmiazga Nice catch!, but unrelated to this task, and affects probably other events like the settings cog one.

To be fixed in the service:

• https://en.wikipedia.beta.wmflabs.org/api/rest_v1/page/summary/List_of_bands_from_Finland

I've listed a proposal as an example. It may suck so comment or add other proposals to it.

I've reviewed but not merged to get @Jdlrobson to have a look at it. LGTM.

Found when testing T167273: pageLoaded events are logged infrequently, if at all

Needs technical signoff.

@Jdlrobson Nice, great job with the docs!

Added info to description

I've submitted some hygiene changes related to this patch. No change in functionality should occur.

Discussed in the reading/services sync,

@Kaartic If that is the issue then it seems easy to fix, nice. jQuery provides event.which, which should be the keyCode normalized across browsers (see .keyup().

@Nirzar says: Subtitle should be aligned with the title of the checkbox.

I see this, is it broken? (Chrome)

For the record, I sent an email to wikitech-l asking how does a build process look like for extensions to gather feedback: https://lists.wikimedia.org/pipermail/wikitech-l/2017-June/088264.html

@bmansurov Something like Schema:UploadWizardExceptionFlowEvent but instead of the flow* we should probably log the full URL (with hash fragments too).

Isn't this too big to be just one task?

@phuedx I've clarified the item to mention both approaches. I believe mobilefrontend heavily uses eventlogging.Schema instances so we should probably follow suit here. What do you think?

Tested locally with beta cluster as the api and yorkshire terrier as the sample.