Re: [Wikitech-l] Opening up MediaWiki dev summit in January?

[Chad]

On Wed, Sep 14, 2016 at 4:01 PM MZMcBride  wrote:

> >>* how can we improve the quality of our software, and pay down the
> >> technical debt we've accumulated over the years?
> >
> >Pro: again, a favorite topic of talk-over-beers among developers.  One
> >could imagine a whole summit devoted to going through our software stack
> >component by component, identifying the cruft hidden in each, and making
> >concrete plans to banish it.
> >Con: this opinion might be controversial, but my impression is that we're
> >actually pretty good at low-level refactoring.  There are plenty of things
> >we are hesitant to change (say, wikitext syntax!), but I don't get the
> >feeling that the barrier is in engineering.  The problem is mostly a
> >management one: how can engineering communicate the time spend and value
> >added by "invisible" maintenance and refactoring; how can we get
> >management to allocate more dedicates resources to this?  I don't think
> >there's much technical debate about what to work on, if we had the
> >resources to do so.
>
> I think this problem exists in most companies/organizations. Nobody wants
> to pay down technical debt; building new features is a lot more exciting.
>

Bummer. I think paying down tech debt is fun and way more rewarding
than making shiny new things.

But I'm also weird as hell...


>
> >Ok, so what have we learned from this?  Even if others have different
> >opinions about each of Rob's proposed topics, which are the *sort* of
> >things we'd like the dev summit to be about?  Radical ideas?  Stuff
> >developers bitch over beers about?  Vague umbrella topics ("make wiki
> >easier to use") that we can crowd a bunch of stuff under?  Something else
> >entirely?
>
> In my experience, the greatest value derived from these types of events
> (summits, hackathons, unconferences, whatever other cutesy word) is having
> unstructured time to explore and think and poke and discuss with people
> about pet projects and other neat ideas. The structured and more formal
> sessions, with their broad themes for whatever year it is, are usually
> boring and ill-fitting.
>
>
This. I usually find myself skipping most sessions. One of two things
happen:

1) You sit there and listen to someone else talk to you, or
2) It's ostensibly a group discussion, but the group is too big and nothing
useful gets discussed because you spend too much time listening to 30
different voices.

(1) bores me to tears. (2) is basically useless.

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

Re: [Wikitech-l] Opening up MediaWiki dev summit in January?

[MZMcBride]

C. Scott Ananian wrote:
>On Thu, Sep 8, 2016 at 1:57 PM, Rob Lanphier  wrote:
>>Let's say that we had to pick only one of these questions to answer
>>at WikiDev17.  Which would you choose?
>
>All of them!  But since no one else bit Rob's bait, let me try to give a
>pro/con for each.

I considered taking the bait. I read the questions, but my primary thought
was "man, this guy seems way overdue to submit a Gerrit patch or do
something less highfalutin."

>>* how can we better distribute the information on our websites?
>
>Pro: invites radical thought disconnected from monetary/fundraising needs!
>How can we get everyone to use our stuff?  We collectively probably
>haven't thought hard about this recently.

Plenty of people have given this thought. Offline reading, printed
editions, putting Wikipedia on the Moon, Wikipedia Zero, etc. We can do
more, of course, but that's true of everything.

>> * how can we help our software development community be more inclusive
>>and productive (and attract many more people)?
>
>Pro: again, big thoughts, on a topic which deserves attention.  Can drill
>down into nitty-gritty like, "why not github?" and "can we make the review
>process more friendly?" which are favorite topics for fat-chewing among
>developers.

Wikimedia-related Git repositories are on GitHub. If we want to attract
more people, that requires figuring out how to scale up the already shaky
code review process.

>>* how can we improve the quality of our software, and pay down the
>> technical debt we've accumulated over the years?
>
>Pro: again, a favorite topic of talk-over-beers among developers.  One
>could imagine a whole summit devoted to going through our software stack
>component by component, identifying the cruft hidden in each, and making
>concrete plans to banish it.
>Con: this opinion might be controversial, but my impression is that we're
>actually pretty good at low-level refactoring.  There are plenty of things
>we are hesitant to change (say, wikitext syntax!), but I don't get the
>feeling that the barrier is in engineering.  The problem is mostly a
>management one: how can engineering communicate the time spend and value
>added by "invisible" maintenance and refactoring; how can we get
>management to allocate more dedicates resources to this?  I don't think
>there's much technical debate about what to work on, if we had the
>resources to do so.

I think this problem exists in most companies/organizations. Nobody wants
to pay down technical debt; building new features is a lot more exciting.

>>* how can we make our websites better learning environments?
>
>Pro: another radical idea, and I like radical ideas. ;)
>Con: We have wikiversity for this.  Yes, it has its problems.  But
>wouldn't this topic be better phrased as, "how can we better support
>wikiprojects other than wikipedia?"

Yes, that's better phrasing. But it's still too vague to be useful. As I
read this question, I hear your comments about "strategy" v. "dev" echoing
around in my head. How we can better support non-Wikipedia projects might
mean setting them free/abandoning them.

>Ok, so what have we learned from this?  Even if others have different
>opinions about each of Rob's proposed topics, which are the *sort* of
>things we'd like the dev summit to be about?  Radical ideas?  Stuff
>developers bitch over beers about?  Vague umbrella topics ("make wiki
>easier to use") that we can crowd a bunch of stuff under?  Something else
>entirely?

In my experience, the greatest value derived from these types of events
(summits, hackathons, unconferences, whatever other cutesy word) is having
unstructured time to explore and think and poke and discuss with people
about pet projects and other neat ideas. The structured and more formal
sessions, with their broad themes for whatever year it is, are usually
boring and ill-fitting.

MZMcBride



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

[Wikitech-l] Upgrade of 1.28.0-wmf.19 to group 1 is on hold

[Antoine Musso]

Hello,

We are holding the deployment of MediaWiki version 1.28.0-wmf.19 due to 
a couple of bugs that have surfaced.


The first one is that renaming a user was blocked [T145596]. Reported by 
K6ka, triaged by MarcoAurelio.  The issue is fixed now thanks to Aaron 
Schulz and Kunal Mehta.


The second blocker is way nastier. I have pushed the upgrade to group1. 
matanya (a long volunteer with a lot of technical patches) immediately 
reported the infoboxes on the Hebrew Wiki were on the wrong side, which 
prompted a rollback.  [T145673].


Timo Tijhof and Kunal Mehta have found the root cause.  I can speak for 
them as to who/when we will get a solution.



For now. I am holding the train.  Will reassess tomorrow and ideally 
push group1 at 19:00 UTC then follow with group2 at 20:00UTC.



Stay tuned!



Up-to-date status:
https://tools.wmflabs.org/versions/

MW-1.28.0-wmf.19 deployment blockers
https://phabricator.wikimedia.org/T143328


[T145596] Renames getting stuck on mediawiki.org (Sept 13, 2016)
   https://phabricator.wikimedia.org/T145596

[T145673] 1.28.0-wmf.19 broke template RTL placement
https://phabricator.wikimedia.org/T145673

--
Antoine "hashar" Musso


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

Re: [Wikitech-l] Opening up MediaWiki dev summit in January?

[C. Scott Ananian]

On Thu, Sep 8, 2016 at 1:57 PM, Rob Lanphier  wrote:

> Good point.  Let's say that we had to pick only one of these questions to
> answer at WikiDev17.  Which would you choose?
>

All of them!  But since no one else bit Rob's bait, let me try to give a
pro/con for each.

* how do we make manipulating the information on our websites easier and
> more useful? (both for humans and computers)
>

Pro: a very broad topic, most reasonable subjects of discussion could fit
under this umbrella.  CF Cite, multilingual support, wikidata-in-commons,
etc.
Con: a very broad topic, would this even be a useful frame?


> * how can we better distribute the information on our websites?
>

Pro: invites radical thought disconnected from monetary/fundraising needs!
How can we get everyone to use our stuff?  We collectively probably haven't
thought hard about this recently.
Con: not related to most of the other proto-topics I've heard floated.
Maybe more of a "strategy" topic than a "dev" topic.


> * how can we help our software development community be more inclusive and
> productive (and attract many more people)?
>

Pro: again, big thoughts, on a topic which deserves attention.  Can drill
down into nitty-gritty like, "why not github?" and "can we make the review
process more friendly?" which are favorite topics for fat-chewing among
developers.
Con: again maybe more "strategy" than "dev"; doesn't help us discuss
wikidata or refactoring the front-end.  Also, why "software development
community more inclusive" and not "editor community more inclusive"?  The
sharp division there might be a real issue.


> * how can we improve the quality of our software, and pay down the
> technical debt we've accumulated over the years?
>

Pro: again, a favorite topic of talk-over-beers among developers.  One
could imagine a whole summit devoted to going through our software stack
component by component, identifying the cruft hidden in each, and making
concrete plans to banish it.
Con: this opinion might be controversial, but my impression is that we're
actually pretty good at low-level refactoring.  There are plenty of things
we are hesitant to change (say, wikitext syntax!), but I don't get the
feeling that the barrier is in engineering.  The problem is mostly a
management one: how can engineering communicate the time spend and value
added by "invisible" maintenance and refactoring; how can we get management
to allocate more dedicates resources to this?  I don't think there's much
technical debate about what to work on, if we had the resources to do so.

* how can we make our websites better learning environments?
>

Pro: another radical idea, and I like radical ideas. ;)
Con: We have wikiversity for this.  Yes, it has its problems.  But wouldn't
this topic be better phrased as, "how can we better support wikiprojects
other than wikipedia?"


> * how can we make our websites better support languages other than English
> (and character sets other than Latin)?
>

Pro: I feel like this was deliberately aimed at me, and I like it. ;)  It
would serve as a concrete frame to recruit new participants from outside
enwiki/SFO.
Con:  Do I have to argue against my own pander?

...

Ok, ok.

Con: the typical attendees of a SFO dev summit are not really the best
folks to discuss non-English/non-Latin issues.  It might be worthwhile
doing as an "educate SFO developers about the issues" training summit, but
if you actually wanted to set goals/make progress you should really host
this topic at a non-North-American Wikimania.

=

Ok, so what have we learned from this?  Even if others have different
opinions about each of Rob's proposed topics, which are the *sort* of
things we'd like the dev summit to be about?  Radical ideas?  Stuff
developers bitch over beers about?  Vague umbrella topics ("make wiki
easier to use") that we can crowd a bunch of stuff under?  Something else
entirely?

  --scott

-- 
(http://cscott.net)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2016-09-14 Scrum of Scrums notes

[Grace Gellerman]

https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-09-14

= 2016-09-14 =
== Product ==

=== Reading ===

 Reading Web 
Current sprint:
* Related pages preparation for mobile web deployments
* Shipped wikidata descriptions in mobile web to all but top 6 wikis

 Mobile Content Service 
* Working on follow-up tasks from last week's Android app outage:
*
https://wikitech.wikimedia.org/wiki/Incident_documentation/20160907-Android

   - * Set up monitoring tests for individual feed endpoints
   https://phabricator.wikimedia.org/T145223


   - * Communicate steps on how to switch the app to use different backend
   servers.


   - * Investigate Icinga alert setup if the app experiences unusually high
   crash rates.

* Heads-up: New service developement starting soon for new RESTBase service
to get Trending edits:
https://phabricator.wikimedia.org/tag/reading_web_trending_service/

 Android native app 
Current sprint: 91 https://phabricator.wikimedia.org/project/view/2216/
* navigation overhaul: primary dev work is complete; now updating per
design feedback.
* beta release this week (probably)

 iOS native app 
Current release board: https://phabricator.wikimedia.org/project/view/2150/
* 5.2
* Adding iOS 10 Support
** Today Widgets - Top Read & Continue Reading and basic iOS 10
compatibility
* Dropping iOS 8 support
* Released to beta, releasing with iOS 10 Tuesday September 13

Next release board: https://phabricator.wikimedia.org/project/view/2188/
* Bug fix release for 5.2, scope still in discussion

 Reading Infrastructure 
* no blocking/blocked

=== Community Tech ===
* Blocking: none
* Blocked: none
* Working with Performance team to optimize refreshLinks job for
PageAssessments roll-out to enwiki (
https://phabricator.wikimedia.org/T145473)
* Finished work on Google OCR tool for WikiSource:
https://wikisource.org/wiki/Wikisource:Google_OCR
** Web interface: https://tools.wmflabs.org/ws-google-ocr/
** Gadget: https://wikisource.org/wiki/MediaWiki:GoogleOCR.js
* Working with DBAs on improving CentralAuth for cross-wiki watchlists (
https://phabricator.wikimedia.org/T141951)
* Working on Education Program Dashboard
https://phabricator.wikimedia.org/T125546

=== Editing ===
 Collaboration 
* Blocking
** Continuing work on Flow caching rewrite
* Blocked
* Updates
** Major work on seen time for Echo notifications.  It is now a single
global time, so when you open any notification popup, the time is updated
globally.
** Continued work on using MessagePoster to allow for posting to wikitext
or Flow boards more easily.  NewUserMessage updated to use this, PageTriage
is next.

 Language 
* Blocking: None
* Blocked: None
* Updates:
** Content Translation work continue.
** Apertium ready for Jessie migration, test this week, deployment likely
next week.

=== Analytics ===
* Blocking: None
* Blocked: None
* Updates:
** Kasocki : Working on automating tests with jenkins
** New AQS cluster data is loaded, load-tests still to be run, then
production integration
** Edit reconstruction: data for simplewiki is ready to be sent to Erik
(not perfect, still improving), performance optimisations on the go for big
wikis to run
** Pivot (druid based UI) is being productionized to be accessible for WMF
staff (LDAP)
** Participation in A/B testing design - Looking good


=== Services ===
* Blocking: none
* Blocked: none
* Updates:
** Services config deploys via scap3 on the way
** Depooling and repooling services during deployment, instructions would
be sent soon
** Change Propagation replaced RESTBaseUpdateJobs, extension undeployed
** EventBus deprecated events are not produced any more

=== Technical Operations ===
* '''Blocking''': none
** none
* '''Blocked''':
** none
* '''Updates''':
** Migrated to a new puppetmaster infrastructure for production, should
make next DC switchover easier (among other things)
*** TechOps offsite happening week of Sept 25 (last week of quarter),
please work around this for deployments*
** wikitech features will get a deprecation announcement soon
** Partial traffic to thumbor to be enabled this week
** apertium reviews for LE are done. Migration of apertium service to SCB
to happen next week.
** appserver migration to jessie ongoing. CODFW done, EQIAD to happen next
** New DBA, Manuel onboarded.

 === Discovery ===
* No blockers
* BM25 A/B test is turned off, preliminary results ok, waiting for analysis
* Working on multiwiki indexes, public comments sought at:
** https://www.mediawiki.org/wiki/Cross-wiki_Search_Result_Improvements
**
https://www.mediawiki.org/wiki/Cross-wiki_Search_Result_Improvements/Design
* Added ASCII-folding for French (https://phabricator.wikimedia.org/T144429)
* Had SPARQL workshop, materials at
https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/2016_SPARQL_Workshop
* Had Discernatron lunch, a lot of useful feedback
* Working on deploying codfw servers for WDQS

 Interactive team 
*  to 

[Wikitech-l] Recently proposed patchsets by new contributors awaiting code review

[Andre Klapper]

Your help is welcome to provide feedback and guidance:

== All in "mediawiki/core": ==

since 2016-08-01:
Incorrect redirect for titles starting with '/' in special cases
https://gerrit.wikimedia.org/r/#/c/302088/

since 2016-08-02:
Fix to incorrect calls of header () breaking saving some pages and login
https://gerrit.wikimedia.org/r/#/c/302430/

since 2016-08-11:
Change wording, change grammar in lang/en.json
https://gerrit.wikimedia.org/r/#/c/304329/

since 2016-08-11:
Cleaned up some unneeded wording in the english lang file, as well as minor 
wording changes.
https://gerrit.wikimedia.org/r/#/c/302061/

since 2016-08-11:
Add Localisation to the links, add the link to Localisation in 
Languages/Language.php
https://gerrit.wikimedia.org/r/#/c/304153/


Thanks in advance for your reviews.

andre
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/

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

Re: [Wikitech-l] No ArchCom IRC office hour planned for this week (2016W37)

[Daniel Kinzler]

Am 14.09.2016 um 07:25 schrieb Rob Lanphier:
> Rob
> [1]: https://www.mediawiki.org/wiki/Multi-Content_Revisions

If you thinnkt that's TLTR, please at least have a look at the bit that is about
the conceptual data model and necessary DB schema changes:


-- 
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

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

[Wikitech-l] RfC: Future of magic links

[Legoktm]

Hi,

I wrote an RfC to determine the future of the ISBN/PMID/RFC magic links
feature (spoiler: I propose getting rid of them). Comments on the talk
page would be appreciated!



-- Legoktm

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