[Wikitech-l] Weigh in on whether to finalize "Conflict of interest" sections of Code of Conduct

[Matthew Flaschen]

Please comment on whether to approve the "Conflict of interest" section 
of the draft Code of conduct for technical spaces.  This section did not 
reach not reach consensus earlier, but changes were made seeking to 
address the previous concerns.


You can find the section at 
https://www.mediawiki.org/w/index.php?title=Code_of_Conduct/Draft=2293195#Conflict_of_interest


You can comment at 
https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Finalize_new_version_of_.22Conflict_of_interest.22_section.3F 
.


A position and brief comment is fine.

You can also send private feedback to conduct-discuss...@wikimedia.org .

I really appreciate your participation.

Thanks again,

Matt Flaschen

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

[Wikitech-l] CI: New unit tests for skins (mw)

[Paladox]

Hi, hashar today managed to get unit tests to work for mw skins. See task 
https://phabricator.wikimedia.org/T68926
Also see https://gerrit.wikimedia.org/r/#/c/323161/
But he has identified some repo's fail the test, please see 
https://phabricator.wikimedia.org/T113860
Please could we have help to fix the skins so we can make the test voting for 
these repo's.
  

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

[Wikitech-l] Making bot rights not mark edits to mediawiki namespace as being bot

[Brian Wolff]

Hi all,

I would like to propose that we separate the bot right into bot and
boteditinterface, where the bot right only allows you to mark edits as
bot edits for non-mediawiki namespace edits and you would need the
boteditinterface right to mark any mediawiki namespace edits as a bot
edit. Furthermore, I would propose that nobody on Wikimedia wikis ever
get the boteditinterface right (But if I end up having to cave on that
requirement, at least we could restrict it to people who really need
it)

The idea being that any potential edit to site javascript should be
highly scrutinized and shown on the RC by default. Additionally, most
bots do not make edits to the MediaWiki namespace so this should not
cause an undue burden. Those that do make edits, do not make a super
large number. This proposal does not include edits made by
centralnotice extension, which will continue to be marked bot.

If you think this is a horrible idea, please object now :) For more
information see https://phabricator.wikimedia.org/T151408 . If there
are no major objections from the wikitech-l community, I also plan to
notify the owners of bots who make edits to mediawiki namespace.

Thanks,
Brian.

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

[Wikitech-l] Triaging Summit proposals for "How to grow our technical community"

[Quim Gil]

The Wikimedia developer Summit main topic "How to grow our technical
community
"
has nine proposals aiming to be accepted as pre-scheduled sessions.
Mathematically speaking, it is very unlikely that we will have slots for
all of them. Please help making a good selection by expressing your
interest in your preferred candidates, by commenting/subscribing to your
preferred tasks, or awarding them a token.

Pre-scheduled sessions are supposed to be preceded by active discussions,
so the best way to support your preferred topics is by joining the
discussion now.

Proposals:

   - Actions to grow the diversity of our technical community
   
   - Drawing in new MW tech volunteers with Hackathons, and then what
   
   - Better recommending of tasks suitable for new technical contributors
   
   - Better code review processes for reviewers
   
   - IdeaLab for Wikimedia Foundation technical projects
   
   - How to unleash the power of JavaScript
   
   - MediaWiki Documentation 
   - How to unleash the power of 3rd party extension developers
   
   - Bringing "Enterprise MediaWiki" to the Wikimedia Foundation
   


-- 
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

Re: [Wikitech-l] About the frontend development tools we use

[Bartosz Dziewoński]

On Fri, Nov 18, 2016 at 11:16 AM, Niklas Laxström
 wrote:
> I was reading http://stateofjs.com/2016/introduction/#sections and
> could not avoid noticing that the frameworks or technologies we use
> are not among the most popular or most liked among the participants of
> this survey.
>
> Examples:
> * Frontend frameworks: We use jQuery and OOjs UI. The latter does not
> appear at all in the list, jQuery is not in the top ten. This question
> might be biased though on what people perceive as a framework.

I definitely wouldn't call jQuery a framework. (My rule of thumb is:
if you call its functions, it's a library. If it calls your functions,
it's a framework.) But it's interesting how low it appears. I guess
jQuery provides less functionality over bare JavaScript in modern
browsers.

Given that OOjs UI was developed by us, for our needs, and that we've
put basically no effort into promoting it (folks have gotten it on
https://cdnjs.com/ recently, though), I'm not surprised no one outside
of us heard of it.


> * Testing framework: We mostly use qUnit, Cucumber, Selenium. Of these
> only Cucumber appears in the top 6 and it has very low satisfaction
> (people who have used do not like it).

QUnit wasn't even in their survey, yet it took second place among the
"write-in" votes.

Parsoid uses Mocha (the most popular in the survey) for testing. We
experimented with Jasmine (second most popular) in MediaWiki around
2012, but it was abandoned in favor of QUnit.


> * CSS tools: We use plain CSS and Less. Less has considerable lower
> satisfaction than SASS/SCSS and is less popular.

CSS has high usage and satisfaction scores though. I always said
allowing Less was a mistake ;)

Less is more accessible than SASS to developers who know CSS,
syntax-wise. SCSS is almost the same though, I honestly don't see why
you'd prefer one to the other.

We experimented with SCSS too, for MediaWiki UI styling. It was
abandoned in favor of Less in 2013, mostly because we have Less
support and SCSS required a build step before committing.


> * Build tools: We don't use these in core to my knowledge, but many
> extensions seem to use Grunt for running linting tools. Again, Grunt
> has very low satisfaction compared to other tools.

Just about everything that includes any JavaScript code uses Grunt for
linting, including MediaWiki core.


-- 
Matma Rex

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

[Wikitech-l] 2016-11-23 Scrum of Scrums meeting notes

[Grace Gellerman]

https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-11-23

= 2016-11-23 =
== Technology ==
=== Analytics ===
* Blockers: none
* on track for quaterly goals
* main project about edit data (mediawiki edit history reconstruction)
progressing,
 * we are now calculating standard edit metrics for all wikis since the
beginning of time using denormalized edit history:

https://wikitech.wikimedia.org/wiki/Analytics/Data_Lake/Denormalized_edit_history
experimental dataset on pivot: https://goo.gl/XAMVsh
* working on productionizing infrasructure for event streams
* waiting for hardware for pageview API
* owning now statsv together with ops (utility that can consume kafka data
and report to graphana)
* Thanking discovery for contributing to our metric reporting tools
Upcoming:
Start design work to revamp information architecture of
http://stats.wikimedia.org



=== Performance ===
Not blocking, not blocked
* thanks everyone who attended the active/active DC meeting after I flagged
it here, it has helped getting the ball rolling on two blockers
* hidden tabs confirmed as messing with timing data, now excluded from perf
metrics
* investigating little-known legacy features in mediawiki thumbnailing to
decide whether we continue supporting them on Thumbor (302 redirects)
* second view tests added for firefox and IE in WebPageTest (was previously
only looking at Chrome)
* still active on thumbnail URL/API RFC discussion
* briefly discussed witth multimedia team setting up Thumbor for them to
leverage in their ImageTweaks extension

=== Security ===
* Security Reviews
  * Linter review complete
  * LoginNotify schedule for this week
* Continuing work on wiki account compromise remediation (T150554)
  * Assistance needed -- e-mail to engineering@ is forthcoming with request

=== Services ===
* Blockers: none
* Updates:
** PDF render service deployed in codfw, eqiad and public exposure next
week
** New version of service-template-node: ES6 and ESLint are coming

=== Technical Operations ===
* '''Blockers'''
** IOS native app
*** Requesting timeline for Wikipedia iOS app requesting 0px thumbs:
https://phabricator.wikimedia.org/T147648
https://phabricator.wikimedia.org/T151078
   iOS 5.3.0 was shipped last week
**  Performance ?
*** MW fix to return 400 on 0px thumbs
https://phabricator.wikimedia.org/T147784
* '''Blocking'''
** None
* Updates
** jobqueue woes https://phabricator.wikimedia.org/T151196
** kubernetes/calico work ongoing, goal on track
** dropping varnish 3 compatibility code from our puppet repos
** labsdb goals on track as well

=== Release Engineering ===
* Blocking
**
* Blocked
**
* Updates
** Mediawiki 1.28 tarball release this week!

== Product ==
=== Reading ===
 Mobile Content Service (MCS) 
* Board: https://phabricator.wikimedia.org/tag/mobile-content-service/
* Added announcements feed endpoint (public now). More info and request URL
at
https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/RESTBase_services_for_apps#2Ffeed.2Fannouncements
:

 Android native app 
* Last week:
** Continuing Q2 goals for Wikidata descriptions
** New fundraising announcement explore feed card in progress
** Now building against Android Nougat 7.1 API 25
** Fixing login and editing issues
** Lots of unit tests
* Next week (https://phabricator.wikimedia.org/project/view/2352/):
** More Q2 goals for Wikidata descriptions (tutorial and polish)

 iOS Native App 
* Last Week:
** Shipped 5.3.0 (In the news notifications & feed content, MCS backed
feed, language variant support, other bug fixes and enhancements)
https://phabricator.wikimedia.org/project/view/2220/
** Added announcement card to the feed (for user research and fundraising)
** Started update of data layer to fix issue with data access &
modification from widgets and notifications
** Started dynamic font size updates to the app
* This week: https://phabricator.wikimedia.org/project/view/2357/
** Finishing data layer update
** Continuing dynamic font size updates
** Other minor bug fixes for 5.3.1

 Web 
* Current sprint:
https://phabricator.wikimedia.org/tag/reading-web-sprint-86-%F0%9F%94%AA%F0%9F%A6%83/
** Stopping HoverCards A/B tests from Russian and Italian wikis
** New readers work
** Make PageImages return the image in the lead section
** MobileFrontend tech debt
** Trending service
** Hovercards rewrite
* Next week: probably the same stuff as the current week.

 Reading Infrastructure 
* not blocking
* Still looking for reviews on the API error/warning i18n patches
** https://gerrit.wikimedia.org/r/#/c/321402/ - Improve handling of Message
objects as Message parameters
** https://gerrit.wikimedia.org/r/#/c/321404/ - Add Message::listParam()
** https://gerrit.wikimedia.org/r/#/c/321405/ - Fix MediaTransformError
message handling
** *https://gerrit.wikimedia.org/r/#/c/321406/*
 - API: i18n for warnings and
errors
** The extension patches depended on by that change are