Re: [Wikitech-l] Page for newbie/projects?

[Quim Gil]

Hi Andrew,

On Wed, Jan 20, 2016 at 5:00 PM, Andrew Lih  wrote:

> Is there a wiki page that acts as a first stop or landing page for computer
> science students who might be interested in working on coding projects with
> Wikipedia/Wikimedia projects?
>
> We have a page on Wikipedia greeting students/instructors who want to do
> class projects related to *writing* articles, but do we have a similar
> thing for CS instructors and students who might want to do an assignment or
> class project with Mediawiki, APIs, or with database dumps?
>
> If anyone could point me to the best of what we have now, that’d be great.
> This would be a way to find “shovel ready” challenges for students to work
> on, or contribute to projects in progress.


For what is worth, all Wikimedia wikis have a "Developers" link in the
footer that points to

https://www.mediawiki.org/wiki/How_to_contribute

That page features a first link to
https://www.mediawiki.org/wiki/Starter_kit and different sections for types
of technical contributions, each of them pointing to a specialized landing
page.

I wish we had a clearer path for newcomers. The https://mediawiki.org
homepage should provide a clear answer to the expected question you ask.
The diversity of replies you got shows the dimension of the prob... of the
opportunity ;) we have.

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

[Wikitech-l] New MediaWiki structure test for API module's i18n completeness

[Legoktm]

Hi,

Anomie has written a new structure test[1] that checks whether API
modules have all the proper i18n messages needed for their documentation.

It's possible that your extension's tests will start failing due to
this; if you need help figuring it out, please ping one of us and we can
help out.

[1] https://gerrit.wikimedia.org/r/#/c/260598/

-- Legoktm

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

[Wikitech-l] VisualEditor roadmap - extensibility within MediaWiki?

[Daniel Barrett]

I was looking through the VisualEditor roadmap 
(https://www.mediawiki.org/wiki/VisualEditor/Roadmap) and did not notice 
anything about third-party MediaWiki extensions for the editor.   Did I miss it?

I do see plans for "non-Mediawiki" extensions (under "Release for third-party 
non-MediaWiki users"), and also for Mediawiki admins to 
"easily install and use VisualEditor" (under "Release for third-party MediaWiki 
users"), but nothing about extending it within MediaWiki. For example, adding a 
button or menu item to insert a particular parser tag.

Is this by design?

I did notice "Non-template transclusions" on the roadmap, which looks like a 
way to insert parser tags & parser functions if you already know their name 
(the way template transclusions work right now). That will be a big help. 
However, for (say) inserting a given parser tag, it would be great if we could 
easily add a button or menu item for it.

Thank you very much for any info.
DanB


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

Re: [Wikitech-l] Video: Loading Barack Obama on 2G from Spain on a Nexus 5

[Peter Hedenskog]

>
https://grafana.wikimedia.org/dashboard/db/mobile-webpagetest?panelId=28
> I'm guessing they can be milliseconds?
yes sorry I forgot to change that, now it is easier to understand.

On Wed, Jan 20, 2016 at 5:09 PM, Joaquin Oltra Hernandez <
jhernan...@wikimedia.org> wrote:

> Thanks for the responses Federico & Peter.
>
> Federico, I fully agree that a video is not a replacement for data, but
> they serve different purposes. Peter expanded on it better than I what I
> could do, but basically data driven tests serve a great deal for
> development purposes to assessing impact of changes since they give us a
> controlled environment to see the impact of changes trying to improve
> performance.
>
> The reality is a lot messier and hard to measure, and I find it greatly
> useful to see real experiences on real devices, where the network
> conditions vary a lot, and there are multiple applications/services
> competing for CPU and bandwidth on the device, making the experience
> completely different to what it is on the numbers that the performance
> tests provide.
>
> Surely it is anecdotal data, but it is an anecdotal experience that a lot
> of people probably experience, so I end up caring about it.
>
> ---
>
> Thanks Peter for the links and the thoughtful response. Great points and
> advice. I didn't know about that dashboard, it is great!
>
> What are the units on the Y axis here for example?
>
> https://grafana.wikimedia.org/dashboard/db/mobile-webpagetest?panelId=28
> I'm guessing they can be milliseconds?
>
> One last thing: We will not pickup things as CPU usage faking real devices
> > but to do that, I think we need to look at another tool than WebPageTest
> to
> > do that correctly. Do we have one already?
>
>
> Not that I know of, we were thinking about doing some searching to see what
> we could find. It would be a great addition to have.
>
> Joaquin
>
>
> On Wed, Jan 20, 2016 at 10:28 AM, Peter Hedenskog 
> wrote:
>
> > I like videos because it's so easy for non technical people to understand
> > the value of performance. For me it has been a really good way to show
> and
> > explain performance changes and what it looks like for the user.
> >
> > Picking a representative connection is hard and the good thing is I think
> > we don't need to. Connections in the real world vary so much: You could
> > have 3G but a really bad connection to the nearest station because
> there's
> > a lot of other phones connected etc. We have tests running with real
> > connections 2G/3G from Bangalore and LTE in San Francisco, you can check
> it
> > out how it looks here:
> >
> >
> https://grafana.wikimedia.org/dashboard/db/mobile-webpagetest?panelId=30
> > I really like that graph because it shows how much variances you can have
> > on the same connection type from the same location. Check out how it
> looks
> > like in Bangalore.
> >
> > When we throttle the connection for WebPageTest (or other tools) we don't
> > get that type of variations, we just use hard coded values for a specific
> > connection. And that's good, because it makes it possible for us to
> measure
> > improvements so that when we do fixes, we can easily see if it makes it
> > better or worse. Picking a slow connection like 2G is good because then
> it
> > is easier to spot what impact we get from our changes.
> >
> > I like automated testing with real devices, we have automatic tests up
> and
> > running with a Iphone 6, Ipad Mini and Motorola G (using the ones
> provided
> > in WebPageTest) and it looks like this:
> >
> >
> https://grafana.wikimedia.org/dashboard/db/mobile-webpagetest?panelId=28
> >
> > You can click on the each row in the table to only show one graph, that
> > makes it easier to see what numbers we have. Click
> > on Dulles_iPhone6_iPhone_6_iOS_9.render and you can see that the start
> > rendering time (when something is first showed on the screen) is pretty
> > stable for the Iphone 6 but if you
> > choose Dulles_iPhone6_iPhone_6_iOS_9.SpeedIndex (SpeedIndex is a way of
> > calculate when content within the viewport is visible for the end user)
> > vary a lot. The thing is that we only have limited access to automated
> > tests with real phones (we don't have anything setup for ourselves). So
> we
> > use it now to just get a feeling of what it looks like on real devices.
> >
> > Most IMPORTANT: When we measure performance it is important that we
> always
> > do it exactly the same way, so we try to limit the changes to as few as
> > possible (=our code change). Using WebPageTest I think it's ok to use
> > Mobile 2G Fast, emulating mobile using Chrome. When we run the automated
> > tests in Jenkins we test each URL 5 times, it seems to be pretty stable.
> > Our tests will not give us the same numbers as the users gets, but it
> will
> > give us constant numbers so that we can see that the changes we do impact
> > the site. When we push these changes to production we can hopefully pick
> > them up with 

Re: [Wikitech-l] VisualEditor roadmap - extensibility within MediaWiki?

[Trevor Parscal]

VisualEditor is very extendable by design. You can do pretty much anything
you want with a plugin, and we've demonstrated this with many existing
plugins that provide all sorts of interesting features.

The APIs for adding features to VisualEditor, while perhaps not as well
documented as we'd like them to be, have existed for years and are now
quite stable.

We have seen extensions such as math, graph and score be integrated into
VisualEditor by developers who are relatively new to the code base.
However, direct communication with the team was still important to those
efforts.

The documentation that does exist is generated from code comments, and the
VisualEditor code base is particularly well documented. There was
a supplemental documentation effort for OOjs UI this time last year, and I
think that worked out pretty well. This may be something we can do in the
next six months, but there are not yet any concrete plans to do so.

Ed Sanders is a good person to be in touch with, along with others on the
VosualEditor team, who are easily reached on IRC. See the MediaWiki page on
VisialEditor for details.

- Trevor

On Thursday, January 21, 2016, Daniel Barrett  wrote:

> I was looking through the VisualEditor roadmap (
> https://www.mediawiki.org/wiki/VisualEditor/Roadmap) and did not notice
> anything about third-party MediaWiki extensions for the editor.   Did I
> miss it?
>
> I do see plans for "non-Mediawiki" extensions (under "Release for
> third-party non-MediaWiki users"), and also for Mediawiki admins to
> "easily install and use VisualEditor" (under "Release for third-party
> MediaWiki users"), but nothing about extending it within MediaWiki. For
> example, adding a button or menu item to insert a particular parser tag.
>
> Is this by design?
>
> I did notice "Non-template transclusions" on the roadmap, which looks like
> a way to insert parser tags & parser functions if you already know their
> name (the way template transclusions work right now). That will be a big
> help. However, for (say) inserting a given parser tag, it would be great if
> we could easily add a button or menu item for it.
>
> Thank you very much for any info.
> DanB
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org 
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Modern module loading needing code review

[Jon Robson]

As part of the work of the frontend standards group
https://gerrit.wikimedia.org/r/#/c/260071/ adds require and
module.exports to MediaWiki ResourceLoader. This will make it easier
to share code outside MediaWiki and with nodejs systems as well as
discouraging the overloading of the mediawiki variable.

I'm looking for code review at the moment. If you are familiar with
ResourceLoader's internals I'd appreciate your input.

See https://phabricator.wikimedia.org/T108655 for further background

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

Re: [Wikitech-l] VisualEditor roadmap - extensibility within MediaWiki?

[Daniel Barrett]

Thank you! Which class on this page is the best starting point for learning to 
write a plugin?

https://doc.wikimedia.org/VisualEditor/master/

DanB


From: Wikitech-l [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of 
Trevor Parscal
Sent: Thursday, January 21, 2016 11:28 AM
To: Wikimedia developers
Subject: Re: [Wikitech-l] VisualEditor roadmap - extensibility within MediaWiki?

VisualEditor is very extendable by design. You can do pretty much anything
you want with a plugin, and we've demonstrated this with many existing
plugins that provide all sorts of interesting features.

The APIs for adding features to VisualEditor, while perhaps not as well
documented as we'd like them to be, have existed for years and are now
quite stable.

We have seen extensions such as math, graph and score be integrated into
VisualEditor by developers who are relatively new to the code base.
However, direct communication with the team was still important to those
efforts.

The documentation that does exist is generated from code comments, and the
VisualEditor code base is particularly well documented. There was
a supplemental documentation effort for OOjs UI this time last year, and I
think that worked out pretty well. This may be something we can do in the
next six months, but there are not yet any concrete plans to do so.

Ed Sanders is a good person to be in touch with, along with others on the
VosualEditor team, who are easily reached on IRC. See the MediaWiki page on
VisialEditor for details.

- Trevor

On Thursday, January 21, 2016, Daniel Barrett  wrote:

> I was looking through the VisualEditor roadmap (
> https://www.mediawiki.org/wiki/VisualEditor/Roadmap) and did not notice
> anything about third-party MediaWiki extensions for the editor. Did I
> miss it?
>
> I do see plans for "non-Mediawiki" extensions (under "Release for
> third-party non-MediaWiki users"), and also for Mediawiki admins to
> "easily install and use VisualEditor" (under "Release for third-party
> MediaWiki users"), but nothing about extending it within MediaWiki. For
> example, adding a button or menu item to insert a particular parser tag.
>
> Is this by design?
>
> I did notice "Non-template transclusions" on the roadmap, which looks like
> a way to insert parser tags & parser functions if you already know their
> name (the way template transclusions work right now). That will be a big
> help. However, for (say) inserting a given parser tag, it would be great if
> we could easily add a button or menu item for it.
>
> Thank you very much for any info.
> DanB
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org 
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] RFC: Defining a policy for REST API result format versioning / negotiation

[Gabriel Wicke]

Hi,

we are considering a policy for REST API end point result format
versioning and negotiation. The background and considerations are
spelled out in a task and mw.org page:

https://phabricator.wikimedia.org/T124365
https://www.mediawiki.org/wiki/Talk:API_versioning

Based on the discussion so far, have come up with the following
candidate solution:

1) Clearly advise clients to explicitly request the expected mime type
with an Accept header. Support older mime types (with on-the-fly
transformations) until usage has fallen below a very low percentage,
with an explicit sunset announcement.

2) Always return the latest content type if no explicit Accept header
was specified.

We are interested in hearing your thoughts on this.

Once we have reached rough consensus on the way forward, we intend to
apply the newly minted policy to an evolution of the Parsoid HTML
format, which will move the data-mw attribute to a separate metadata
blob.

Gabriel Wicke

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

[Wikitech-l] Last call on RFC: drop PHP 5.3/5.4 support

[Tim Starling]

This is a last call for new arguments and facts related to the
proposal to drop PHP 5.3 and PHP 5.4 support in MediaWiki core git master.

If you have anything new to say about this issue, please comment on
the Phabricator ticket:

https://phabricator.wikimedia.org/T118932

The Architecture Committee plans on making a decision on this issue on
the basis of the Phabricator comments in next week's committee meeting
(January 27).

-- Tim Starling


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

[Wikitech-l] Fwd: [Wikimedia-l] Launch of Community Consultation on strategic approaches

[Quim Gil]

The Wikimedia Foundation has started a consultation about strategic
priorities.

https://meta.wikimedia.org/wiki/2016_Strategy

There is a survey with one question and several possibilities for each of
the main themes: Reach, Community, Knowledge. It is a good chance to
influence the WMF strategy with your individual voice. I really mean it!
Taking the survey took me about 15 minutes and I found the exercise
interesting.

This survey is being promoted across all Wikimedia projects. I'm forwarding
the announcement to this list in order to help assuring that our technical
communities are well represented. Please take the survey, and feel free
forwarding this message to whoever might be interested as well.


-- Forwarded message --
From: Lila Tretikov 
Date: Tue, Jan 19, 2016 at 2:37 AM
Subject: [Wikimedia-l] Launch of Community Consultation on strategic
approaches
To: Wikimedia Mailing List 


Dear Wikimedians,



We are excited to have you participate in an important Community Engagement
regarding our strategic approaches. This is a major step to help us
prioritize the work of the Foundation beginning in July 2016 and running
for the next 12 to 24 months thereafter into a strategic plan.

Throughout 2015 the Foundation has been exploring how to prioritize its
work to best support the movement's goals, set forth, but not yet reached,
in the 2010-15 strategic plan.

The strategic approaches presented here are based on our vision, strategy
consultations in 2010 
and 2015
,
research on external impacts, and input from staff and a few small
community think groups on key challenges and potential solutions.

Timeline: These are our target dates for this process.

   -

   January 11: Put up pages for translation (done)
   -

   January 18: Launch of community consultation on key questions
   -

   February 15: Close of consultation
   -

   By February 26: Release synthesis of consultation
   -

   By March 4: Publish first draft strategy for comment


We appreciate your time and efforts to help guide the Foundation in its
work to support the movement.

Warm regards,

Lila
___
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: wikimedi...@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,




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