[Wikitech-l] The future of Related Pages feature

[Moushira Elamrawy]

Hello everyone,

Related pages feature has been in beta for over two months now,  the future
of the feature depends on our discussions.  While we currently don't have a
clear process for deciding collaboratively on an all languages product,
Alsee and the reading team have put together this document on meta [0], as
a request for comment, seeking comments and ideas on modifications
required, and how to further test the feature.  In fact, we are not sure if
an rfc is the best strategy to move forward with product decisions, but
lets see how the discussion evolves, and we might explore the need for a
different process, as we move on with this one.

We managed to translate a brief introduction about the topic, please feel
free to fully translate the document and/or further promote the discussion
on your wiki.  We are trying hard to avoid having an English centric
discussion for a feature that could be available across all language
projects, and while we don't have a clear solution for this, we are trying
this method as an experiment, where at least our communities can leave
comments in their preferred language if they aren't comfortable writing in
English but they can understand it.

Please check the page, help with translation or promotion in your
Wikipedia, and most importantly, comment on how you think it can evolve. :)

Lets see how this works!


All the best,
M

[0] https://meta.wikimedia.org/wiki/Requests_for_comment/Related_Pages
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] ArchCom RFC update

[Gabriel Wicke]

Hi,

please have a look at this week's summary of new and ongoing RFC
discussions. There are several new RFCs, and some existing ones are moving
close to a decision. No RFCs were decided finally this week.

Because of the parallel Hackathon, no IRC discussion is scheduled for next
week.

Gabriel

New RFCs:

T130663 WIP RFC: Reference API requirements and options
 (Timo): API access and
component  markup for references; focus on gathering use cases /
requirements.

T122942 RFC: Support language variants in the REST API
 (Gabriel): Different options
for supporting languange variant selection in the REST API. Needed for
languages like Chinese.

T122825 Service Ownership and Maintenance
 (Gabriel): Ownership and
minimum maintenance requirements for production services. Strongly driven
by unclear ownership of OCG (PDF renderer).

T39902 RFC: Implement rendering of redlinks (in a post-processor?)
 (Gabriel): Solutions for
highlighting links to non-existing pages in Parsoid HTML. Main question is
preprocessing vs. separate metadata processed on client.

T130528 RFC: PSR-6 Cache interface in Mediawiki core
 (No shepherd): Exploring use of
standard PHP cache interface.

Today's IRC session:

T124792 Service Locator for MediaWiki core
 (Daniel): Introduce a service
locator (aka DI container) to allow code in mediaWiki core to make use of
the Dependency Injection (DI) and Service Locator (SL) patterns.

The discussion showed general support. Several participants expressed a
desire to write more code with it before making a final call. Concrete
suggestions on areas would be welcome. Tentative working group forming,
aiming to discuss at Jerusalem Hackathon.

Under discussion:

T129435 RFC: drop support for running without mbstring
 (Gabriel): Very focused RFC by
Max. Main question in discussion so far is whether polyfilling is worth it.
Max reaching out to mediawiki-l.

T108655 Standardise on how to access/register JavaScript interfaces
 (Roan): No update since last
week, I need to split this task but I haven’t had time to yet. Last week’s
update:

Considering to split out contentious part (file-based require, or something
like it; to support embedding libraries), move forward on less
controversial part (basic module-name-based require infrastructure)

T18691 RFC: Section headings should have a clickable anchor
 (Timo): Under discussion with
Volker and  Frontend Standards Group. Volker and team to collect different
benefits and concerns to determine whether this is generally a desirable
feature. And to explore other conceptually different solutions to the
underlying use case of “sharing a link to a section” (e.g. a better table
of contents, or live address bar).

T124504 Transition WikiDev '16 working areas into working groups
 (RobLa): No concrete progress;
MZMcBride advocates for organic growth.

T128351 RfC: Notifications in core
 (Brion): No movement last week.
Needs clarification of interfaces & scope as follow-up from IRC meeting.

T66214 Use content hash based image / thumb URLs & define an official thumb
API  (Brion): Clarified
requirements & priorities in last week's IRC discussion. Needs update to
reflect discussion.

T118517 [RFC] Use  for media
 (Brion): Revisit soon.

T88596 Improving extension management
 (Daniel): Discussion is picking
up again, patch for review.

T113034 RFC: Overhaul Interwiki map, unify with Sites and WikiMap
 (Daniel): Has been discussed
before, needs somebody to actually take this on.

T11 [RFC] Introduce notion of DOM scopes in wikitext
 (Tim): Active related
discussion and prototyping at Balanced templates
 and Hygienic transclusions for
WYSIWYG, incremental parsing & composition: Options and trade-offs
.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Review Service Locator / DI Container proposal (upcoming RFC discussion on March 23)

[Daniel Kinzler]

Quick reminder: this is coming up today on #wikimedia-office.
See  for details.


Am 18.03.2016 um 20:44 schrieb Daniel Kinzler:
> Hi all!
> 
> Over the last couple of months, I have worked on introducing a dependency
> injection mechanism into MediaWiki core (don't fear, no auto-wiring). My
> proposal is described in detail at 
> (yea, TL;DR - just read the top and search the rest if you have a question).
> 
> Before we discuss this again on IRC at the RFC meeting on Wednesday (March 23,
> 2pm PST / 22:00 CEST due to daylight confusion), I would like to invite you to
> review the proposal as well as the patches that are up on gerrit. In 
> particular,
> any feedback would be appreciated on:
> 
> * Introduce top level service locator
> .
> * Allow reset of global services 
> * WIP: Make storage layer services injectable.
> 
> 
> Perhaps also have a look at the documentation included in the change, in
> particular the migration part:
> 
> 
> Before commenting on design choices on gerrit, please have a look at T124792 
> and
> see whether I have written something about the issue in question there. I 
> would
> like to focus conceptual discussion on the RFC ticket on phabricator, rather
> than on gerrit. On gerrit, we can talk about the implementation.
> 
> 
> I very much want this to move forward. Perhaps we can even get the first bits 
> of
> this merged at the hackathon. So, criticize away!
> 
> 
> Thanks for your help!
> -- daniel
> 
> 
> PS: phabricator event page (still blank, we'll fix that soon):
> 
> 
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> 


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

Re: [Wikitech-l] [Analytics] [Data Release] [Data Deprecation] [Analytics Dumps]

[Dan Andreescu]

On Wed, Mar 23, 2016 at 1:06 PM, Federico Leva (Nemo) 
wrote:

> Dan Andreescu, 23/03/2016 15:58:
>
>>
>> *Clean-up:* Analytics data on dumps was crammed into /other with
>> unrelated datasets.  We made a new page to receive current and future
>> datasets [3] and linked to it from /other and /.  Please let us know if
>> anything there looks confusing or opaque and I'll be happy to clarify.
>>
>
> I assume the old URLs will redirect to the new ones, right?
>

Good question, we didn't change any old URLs actually, so if you're trying
to get to other/pagecounts-ez, other/pagecounts-raw and all that, they're
all still there, just linked-to from /analytics.  We did it this way
because we figured people had scripts that depended on those URLs.  We
thought about moving and symlinking but it's probably unlikely that we'll
ever be able to delete the other/** location.

So mainly we just have a new page where we can do a better job of focusing
on the analytics datasets.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Data Release] [Data Deprecation] [Analytics Dumps]

[Dan Andreescu]

cc-ing our friends in research and wikitech (sorry I forgot initially)

We're happy to announce a few improvements to Analytics data releases on
> dumps.wikimedia.org:
>
> * We are releasing a new dataset, an estimate of Unique Devices accessing
> our projects [1]
> * We are officially making available a better Pageviews dataset [2]
> * We are deprecating two older pageview statistics datasets
> * We moved Analytics data from /other to /analytics [3]
>
> Details follow:
>
>
> *Unique Devices:* Since 2009, the Wikimedia Foundation used comScore to
> report data about unique web visitors.  In January 2016, however, we
> decided to stop reporting comScore numbers [4] because of certain
> limitations in the methodology, these limitations translated into
> misreported mobile usage. We are now ready to replace comscore numbers with
> the Unique Devices Dataset [5][1]. While unique devices does not equal
> unique visitors, it is a good proxy for that metric, meaning that a major
> increase in the number of unique devices is likely to come from an increase
> in distinct users. We understand that counting uniques raises fairly big
> privacy concerns and we use a very private conscious way to count unique
> devices, it does not include any cookie by which your browser history can
> be tracked [6].
>
> We invite you to explore this new dataset and hope it’s helpful for the
> Wikimedia community in better understanding our projects. This data can
> help measurethe reach of wikimedia projects on the web.
>
> *Pageviews:* This [2] is the best quality data available for counting the
> number of pageviews our projects receive at the article and project level.
> We've upgraded from pagecounts-raw to pagecounts-all-sites, and now to
> pageviews, in order to filter out more spider traffic and measure something
> closer to what we think is a real user viewing content.  A short history
> might be useful:
>
> * pagecounts-raw: was maintained by Domas Mituzas originally and taken
> over by the analytics team.  It was and still is the most used dataset,
> though it has some majore problems.  It does not count access to the mobile
> site, it does not filter out spider or bot traffic, and it suffers from
> unknown loss due to logging infrastructure limitations.
> * pagecounts-all-sites: uses the same pageview definition as
> pagecounts-raw, and so also does not filter out spider or bot traffic.  But
> it does include access to mobile and zero sites, and is built on a more
> reliable logging infrastructure.
> * pagecounts-ez: is derived from the best data available at the time.
> So until December 2015, it was based on pagecounts-raw and
> pagecounts-all-sites, and now it's based on pageviews.  This dataset is
> great because it compresses very large files without losing any
> information, still providing hourly page and project level statistics.
>
> So the new dataset, pageviews, is what's behind our pageview API and is
> now available in static files for bulk download back to May 2015.  But the
> multiple ways to download pageview data is confusing for consumers, so
> we're keeping only pageviews and pagecounts-ez and deprecating the other
> two.  If you'd like to read more about the current pageview definition,
> details are on the research page [7].
>
> *Deprecating:* We are deprecating the pagecounts-raw and
> pagecounts-all-sites datasets in May 2016 (discussion here:
> https://phabricator.wikimedia.org/T130656 ).  This data suffers from many
> artifacts, lack of mobile data, and/or infrastructure problems, and so is
> not comparable to the new way we track pageviews.  It will remain here
> because we have historical data that may be useful, but it will not be
> maintained or updated beyond May 2016.
>
> *Clean-up:* Analytics data on dumps was crammed into /other with
> unrelated datasets.  We made a new page to receive current and future
> datasets [3] and linked to it from /other and /.  Please let us know if
> anything there looks confusing or opaque and I'll be happy to clarify.
>
>
> [1] http://dumps.wikimedia.org/other/unique_devices
> [2] http://dumps.wikimedia.org/other/pageviews
> [3] http://dumps.wikimedia.org/analytics/
> [4] https://meta.wikimedia.org/wiki/ComScore/Announcement
> [5] https://meta.wikimedia.org/wiki/Research:Unique_Devices
> [6]
> https://meta.wikimedia.org/wiki/Research:Unique_Devices#How_do_we_count_unique_devices.3F
> [7] https://meta.wikimedia.org/wiki/Research:Page_view
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l