https://www.mediawiki.org/wiki/Scrum_of_scrums/2018-06-13
= 2018-06-13 =
== Callouts ==
* SRE and Services on Readers Web: Proton times out way too often to be put
into production https://phabricator.wikimedia.org/T186748#4275727
* SRE summit next week. SREs/Ops people across the organization will be
unavailable. Also deployment pause because of this.
https://wikitech.wikimedia.org/wiki/Deployments#Week_of_June_18th
* Wikidata/WMDE: If you use Wikidata's wb_terms database table replicas
(tool, script, anything), please let us know what data you use and how, as
we're considering phasing out the table:
https://phabricator.wikimedia.org/T197161
* Special thanks to Performance, Analytics, and Readers Web for reviewing
the CitationUsage schema instrumentation code.
* Security: Security review for Wikidata queries data release proposal
https://phabricator.wikimedia.org/T190875
* Please take the beta cluster survey:
https://goo.gl/forms/XgIxXiSi1G5eVHbp2
* Scoring platform: Discussion about peformance impact of deploying JADE on
prodcution wikis: https://phabricator.wikimedia.org/T196547 Please chime in
and take a look
== Audiences ==
=== Readers ===
==== iOS native app ====
* Blocked by:
* Blocking:
* Updates:
** 5.8.2 w/ event logging analytics and bug fixes in public beta, looks
good so far ( https://phabricator.wikimedia.org/project/view/3358/ )
** Continuing work on next major release, 6.0 - Feed customization and
design updates ( https://phabricator.wikimedia.org/project/view/3238/ )
==== Android native app ====
* Blocked by:
* Blocking:
* Updates:
==== Readers Web ====
* Blocked by:
** Ruby to JS Cucumber refactor needs help from the RelEng team to fix our
flaky Ruby tests: https://phabricator.wikimedia.org/T190710
* Blocking:
* Updates:
** Mobile website page issues improvements and A/B test framework continues
https://phabricator.wikimedia.org/T159262
** Mobile website gallery and table of contents bug fixes
https://phabricator.wikimedia.org/T196911https://phabricator.wikimedia.org/T193517
** Invest in the MobileFrontend & MinervaNeue frontend architecture
planning and tasking https://phabricator.wikimedia.org/T195473
** Catching up on code review
*Quarterly goal dependency update:
**[[metawiki:Wikimedia_Foundation_Annual_Plan/2017-2018/Draft/Programs/Product#Program_2:_Better_Encyclopedia|Outcome
1, Objective 4]]: Continue improving the ways that users can download
articles of interest for later consumption
*** Reading Web depends on SRE, RelEng, Reading Infra
==== Readers Infrastructure ====
* Blocked by:
* Blocking:
* Updates:
** Safari Reading List extension coming soon, awaiting final QA signoff.
** Two new engineers.
** Supporting lang variants in MCS: Passing Accept-Language header to
Parsoid. Soon: sending the uselang parameter to MW API requests.
===== Maps =====
* Blocked by:
* Blocking:
* Updates:
==== Multimedia ====
* Quarterly goal dependency update
** Prepare for launch of the first Structured Data on Commons feature
(multilingual file captions)
*** SDC depends on Multimedia, SRE, WMDE, Search Platform, MediaWiki
Platform, Research
*** Preparations continue - MCR and other dependencies are well tracked for
this
*** OOUI work now implicates some of our fine friends in Contributors -
esp. Collaboration - been talking with Moriel to get a good high-level view
of what's needed
** Integrate structured file captions into search
*** SDC depends on Search Platform, Multimedia
*** Cormac (our lead on the search work) is out until next week, but our
work on search is well ahead of schedule to my knowledge
** Assess user needs for contributors to Structured Data on Commons with
interviews and surveys - T171252
*** Research depends on Multimedia
*** As far as I know, Pam has been supporting this work, but no engineering
time is needed?
=== Contributors ===
==== Community Tech ====
* Blocked by:
* Blocking:
* Updates:
* Working on PageTriage improvements
** GlobalPreferences and CodeMirror are still upon us
==== Anti-Harassment Tools ====
* Blocked by:
* Blocking:
* Updates:
** Start work on Partial Blocks (quarterly goal)
https://phabricator.wikimedia.org/T196578
*** Special thanks to Jaime Crespo and Brad Jorsch for their help on
drafting an SQL schema change
** Fixing Bugs with the Takedown Tools
https://phabricator.wikimedia.org/project/board/2949/
==== Editing ====
* Blocked by:
* Blocking:
* Updates:
==== Parsing ====
* Blocked by:
**No blockers known
* Blocking:
**No blocking known
* Updates:
** Poem extension integrated into parsoid, reviewed, waiting for merge
** Cite extension work is done and waiting for review
** Tidy to Remex switch over nearly complete
** We are planning to do the final switch from Tidy -> RemexHtml for all
wikis on the wikimedia cluster on July 5th
** C Scott' s work on language subsystem just beginning review
==== Collaboration ====
* Blocked by:
* Blocking:
* Updates:
==== Language ====
* Blocked by:
* Blocking:
* Updates:
** ContentTranslation Version 2 work continue; We are inviting some users
to try it out!
** Draft purge script in progress. Thanks to suggestions from DBAs.
=== Audiences Design ===
==== UI Standardization ====
** OOUI – v0.27.3 special release last Thu
https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/History.md;v…
*** 4 style/code improvement/regression fixes.
** v0.27.4 in preparation for next Tue
** Continuing work on Design Style Guide
== Technology ==
=== Analytics ===
* Blocked by:
* Blocking:
* Updates:
** Discussion with coms and site and measuring pageviews for new
wikimediafoundation site.
** Ops goals for quarter done. Others still in progress.
** Working with security and legal on data map, should be done by end of
quarter.
** Old geowiki system completely shut down (removing puppet code), we put
the new data in superset (dashboard being vetted).
** Changes continue to selectively purge data in hadoop for eventlogging
backend.
** Adding "permalinks" to Wikistats2.
=== Cloud Services ===
* Blocked by:
* Blocking:
* Updates:
=== Fundraising Tech ===
* Blocked by:
* Blocking:
* Updates:
** DonationInterface: working through bugs revealed in 1 hr trial of main
CC processor's new API
=== MediaWiki Platform ===
* Blocked by:
* Blocking:
* Updates:
=== Performance ===
* Blocked by:
* Blocking:
* Updates:
=== Release Engineering ===
* Blocked by:
* Blocking:
** Ruby to JS Cucumber refactor needs help from the RelEng team to fix our
flaky Ruby tests: https://phabricator.wikimedia.org/T190710
* Updates
** Please take the Beta Cluster survey:
*** https://lists.wikimedia.org/pipermail/wikitech-l/2018-May/090049.html
*** https://goo.gl/forms/XgIxXiSi1G5eVHbp2
** Heads up: There will be more people in the normal MW Train deployment
rotation (namely: Antoine, Zeljko, and Dan to start) and we'll be doing
some Train deployments during EU hours some weeks. Exact timing TBA (soon).
* Quarterly cross-dependencies
=== Research ===
* Blocked by: None
* Blocking: None
* Updates:
** Adding UI translations to the Gapfinder tools project:
http://gapfinder-tools.wmflabs.org/
** Training models for recommending translation suggestions:
https://github.com/wikimedia/research-translation-recommendation-models/
=== Scoring Platform ===
* Blocked by:
* Blocking:
* Updates:
**Draft topic is deployed!
***Deployed drafttopic in production, try it out like:
https://ores.wikimedia.org/v3/scores/enwiki/123456?models=drafttopic
** bswiki & srwiki have advanced support --> Collab
** Fixed ORES extension bugs for services and analytics
** Discussion about peformance impact of deploying JADE on prodcution wikis:
https://phabricator.wikimedia.org/T196547 Please chime in and take a look
=== Search Platform ===
* Blocked by:
** Security: Security review for Wikidata queries data release proposal
https://phabricator.wikimedia.org/T190875
* Blocking:
* Updates:
** Fixed prefix: to not override chosen namespaces:
https://phabricator.wikimedia.org/T195815
** Created analysis chains for Croatian, Serbo-Croatian, and Bosnian,
reindex next: https://phabricator.wikimedia.org/T192395
** Reindexed Slovak and Serbian wikis for new analyzers:
https://phabricator.wikimedia.org/T191545
** Added Lexeme terms to source text:
https://phabricator.wikimedia.org/T195912
** Added RDF export for Wikibase constraints:
https://phabricator.wikimedia.org/T194762
** Working on Lexeme fulltext search:
https://phabricator.wikimedia.org/T196188
** Working on fixing Geodata issues:
https://phabricator.wikimedia.org/T196526
** Working on query parsing refactoring:
https://phabricator.wikimedia.org/T185108
** Working on fixing namespace/redirect mixup in search:
https://phabricator.wikimedia.org/T115756
=== Security ===
* Blocked by:
* Blocking:
* Updates:
=== Services ===
* Blocked by:
** Readers web on Proton times out way too often to be put into production
https://phabricator.wikimedia.org/T186748#4275727(from SRE)
** EchoNotificationJob being non JSON serializable
https://phabricator.wikimedia.org/T192945#4278916
** Parsing on deploying the language conversion API at least t
deployment-prep
* Blocking:
* Updates:
** Groundwork in RESTBase to prepare for language variants support
** Tweaking the kafka job queue for cirrus search jobs
=== Site Reliability Engineering ===
* Blocked by:
** No longer blocked by collaboration on Flow dumps. The move to php7 made
it faster, it's not an issue currently, it can be put on the back burner
** Readers web on Proton times out way too often to be put into production
https://phabricator.wikimedia.org/T186748#4275727
* Blocking:
** None
* Updates:
** An outbound email outage was experienced on June 6th,
https://wikitech.wikimedia.org/wiki/Incident_documentation/20180606-mx
** videoscalers/jobrunners clusters merged increasing available
videoscaling capacity
** tin has been replaced (but you should anyway use deployment.eqiad.wmnet
** Upgrade to 3.24 HHVM started
** Proton (chromium-render) has been deployed and is timeouting way too
often even on basic monitoring traffic.
https://phabricator.wikimedia.org/T186748#4275727
== Wikidata ==
* Blocked by:
** No longer blocked on hard-to-track browser failures:
https://phabricator.wikimedia.org/T191537 Thanks Hashar, Anomie and Zeljko!
* Blocking:
** None (that we know of)
* Updates:
** Investigating ways of migrating away from the unmaintainable wb_terms
database table
** Improving editor experience of the recently launched lexemes on Wikidata
** Prototyping a mobile user interface for editing labels, descriptions,
etc of items and properties
== German Technical Wishlist ==
* Blocked by:
* Blocking:
* Updates:
== SoS Meeting Bookkeeping ==
* Updates:
Sorry for cross-posting!
Reminder: Technical Advice IRC meeting again **tomorrow, Wednesday 3-4 pm
UTC** on #wikimedia-tech.
The Technical Advice IRC meeting is open for all volunteer developers,
topics and questions. This can be anything from "how to get started" over
"who would be the best contact for X" to specific questions on your project.
If you know already what you would like to discuss or ask, please add your
topic to the next meeting: https://www.mediawiki.org/wiki
/Technical_Advice_IRC_Meeting
Hope to see you there!
Michi (for WMDE’s tech team)
--
Michael F. Schönitzer
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
http://spenden.wikimedia.de/
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
Regarding "Mandatory code review (especially with a required waiting time) and mandatory reauthentication are far more invasive than removing JS editing permissions from administrators who don't want them.": I think that mandatory code review and mandatory authentication would be far less costly and far faster to implement in terms of volunteer time spent redesigning social processes and managing permissions. These options both sound good to me.
In the longer term, I am thinking about how to implement a new permission as you suggest. The more that I think about it, the more that I believe that it could be done with less time cost to volunteers than I originally was dreading. For example, the new permission could be locally assignable by stewards upon community request, similar to bureaucrat permissions. A month-long RFC with adequate translations would likely be sufficient to surface most major unintended side effects and to surface suggestions for design modifications.
Regarding "I feel most people don't appreciate how *extremely* scary the current situation is. The public backlash around the Seigenthaler affair was sparked by Wikipedia carelessly causing harm to a single individual. It would be child's play compared to what would happen if a few ten thousand people had their bank accounts cleaned, or a few dozen opposition members arrested by the secret police, or something like that, because Wikipedians decided security improvements were not worth the effort of moving users from one group to another.": unless I have overlooked something, there seems to be consensus in this thread that changes are worth considering, and people are discussing which changes to make and in what order. People are trying to be helpful, and please keep that in mind.
Pine
( https://meta.wikimedia.org/wiki/User:Pine )
null
Sending a copy to wikitech-l, because this is a little bit more generic
than "just" MediaWiki.
Hello,
the first one means you have something in /etc/git-review/git-review.conf,
which is probably unneeded. I suggest you to delete that file. On my
system, it doesn't exist.
The second one is caused by Gerrit update. Upstream kept refs/publish/*
working, because they know git-review is using that ref. I think that as
soon as git-review developers fixes this and you will upgrade, the warning
will disappear.
Best,
Martin
út 12. 6. 2018 v 0:51 odesílatel Huji Lee <huji.huji(a)gmail.com> napsal:
> Every time I submit a patch to gerrit using the git review command, I get
> two warning messages that I ignore. I just want to make sure that I can
> continue to safely ignore them (or else, how to get rid of them).
>
> The first one says:
> Using global/system git-review config files
> (/etc/git-review/git-review.conf) is deprecated
>
> The second one says:
> remote: Pushing to refs/publish/* is deprecated, use refs/for/*
> instead.
>
> Thanks,
> Huji
> _______________________________________________
> MediaWiki-l mailing list
> To unsubscribe, go to:
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
Hi,
CODE_OF_CONDUCT.md is a file that was added to most MediaWiki extensions
almost exactly a year ago. It reads, in full:
"The development of this software is covered by a [Code of Conduct](
https://www.mediawiki.org/wiki/Code_of_Conduct)."
This file was added on the grounds that "Now that we have a Code of Conduct
we need to advertise it." You can see the Phabricator task for adding the
file everywhere, including a lot of debate over whether it's a good idea,
here:
https://phabricator.wikimedia.org/T165540
I removed these files from all my extension directories pretty soon after
they were added, on the grounds that I just think it's false information -
the development of my extensions happens mostly on my and others' laptops,
in private emails and so forth - not "Wikimedia spaces", and thus not
covered by the Code of Conduct, according to the CoC. Some corporate
person, for example, downloading my software, could see that file and think
that they're bound by the Code of Conduct when sending me a patch, when in
fact (for better or worse) they're not.
That's how it went until two days ago, when Antoine Musso submitted a patch
for my Site Settings extension (I don't know why that one specifically),
re-adding the file. I rejected the patch, on the same grounds as before,
but another developer, Chad Horohoe, overrode me and merged it in. That led
to a discussion featuring Antoine, Chad, a few other WMF developers, and
me, which you can find here:
https://gerrit.wikimedia.org/r/#/c/437555/
Some of the (unbelievable) highlights:
- From Antoine: "Well then can we just archive this repository please?"
- From Chad: "Yeah no that's not how it works. If it's being hosted on
gerrit.wikimedia.org, it needs a CoC file. If you object to that, you can
find hosting elsewhere."
- From Amir Sarabadani: "Having CoC removed seems violation of CoC itself."
That last one is interesting, because the Code of Conduct doesn't mention
CODE_OF_CONDUCT.md at all. Which I would have thought Amir would know,
given that he's now a member of the "Code of Conduct Committee". (!)
Actually, CODE_OF_CONDUCT.md isn't really mentioned anywhere - it was never
voted on, and I don't believe it was even a directive from WMF management.
As far as I know, this was the work of a few solitary (can I say "rogue"?)
WMF developers who happen to have the ability to modify all the
repositories - and, I guess, are into advertising.
Now, we could talk about whether the CODE_OF_CONDUCT.md file is a good idea
- or whether it's even accurate - but I'd rather talk about the most
pressing issue, which is that a few developers have seemingly threatened to
delete my extensions from the Wikimedia Git repository.
That leads me to a few questions:
- Do developers like Chad Horohoe have the right to delete my extensions
from the repository? (I'm guessing they have the ability.)
- Is CODE_OF_CONDUCT.md now really mandatory?
- Is there some kind of chain of command, or process, for determining these
things, or are we in sort of a Wild West situation where whoever has the
ability to modify or delete other people's extensions can do so without
consequences?
Any thoughts or insight on these questions are welcome. There are some
disturbing implications to that thread, that I'd like to see resolved.
-Yaron
Hi all,
per the discussion on Phabricator, I'd like to split the administrator
("sysop") user group into two parts - one which can edit sitewide CSS/JS,
and one which can not. You can find the details and detailed rationale in
the task:
https://phabricator.wikimedia.org/T190015
To inform the editor communities, and to make sure we can accommodate their
needs, I plan to run a community consultation; I'll probably kick it off on
Friday and have it run for two weeks. You can find the draft here:
https://meta.wikimedia.org/wiki/User:Tgr/Create_separate_user_group_for_edi…
I would appreciate if folks who are knowledgeable about the use of CSS/JS
editing and user rights management in various parts of the community could
look at it and add their concerns or suggestion to the talk page (or
Phabricator if that's more appropriate). Suggestions for a better group
name are especially welcome.
(As I wrote it in the FAQ on the consultation page, I think making sure
that MediaWiki is secure and at the same time empowers its users falls
under the authority of the developer community, and so the normal code
review process is appropriate for this change. Thus the consultation is not
intended to be an RfC or other discussion/veto type process. If you
disagree about the change in general, please discuss that on Phabricator,
or the linked Gerrit patches.)
Thanks!
Yaron,
By deciding to not allow the coc.md in your extension repositories at
gerrit, some people have publicly stated they won't contribute. You choose
a position, others have decided it's not worth the trouble. If you updated
your readme.md to be hostile, that is your own fault and would be advised
to remove such text. This is regardless of if the coc.md file is useful in
repositories. The coc does cover gerrit but as others have noted, the
method of forcefully adding to hundreds of repositories without discussions
was horrible judgement. Now can we please move on from that? pretty sure
the +2 devs learned to not repeat this in future
Kevin
On Mon, Jun 11, 2018, 2:55 PM <wikitech-l-request(a)lists.wikimedia.org>
wrote:
> Send Wikitech-l mailing list submissions to
> wikitech-l(a)lists.wikimedia.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> or, via email, send a message with subject or body 'help' to
> wikitech-l-request(a)lists.wikimedia.org
>
> You can reach the person managing the list at
> wikitech-l-owner(a)lists.wikimedia.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Wikitech-l digest..."
>
>
> Today's Topics:
>
> 1. Re: Making PolyGerrit the default ui for gerrit (Paladox)
> 2. Re: Gerrit as a shared community space (Yaron Koren)
> 3. Escaping wikitext to JSON-valid string in templates (Tom Schulze)
> 4. Re: Gerrit as a shared community space (Moriel Schottlender)
> 5. Re: Gerrit as a shared community space (Moriel Schottlender)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 11 Jun 2018 17:55:59 +0000 (UTC)
> From: Paladox <thomasmulhall410(a)yahoo.com>
> To: Wikimedia Developers <wikitech-l(a)lists.wikimedia.org>
> Subject: Re: [Wikitech-l] Making PolyGerrit the default ui for gerrit
> Message-ID: <1404388831.6108064.1528739759020(a)mail.yahoo.com>
> Content-Type: text/plain; charset=UTF-8
>
> The date to switch the default ui is next monday (18/06/18) which will
> give users plenty of time to give there opinion.
> Users can still switch back to the old ui just the new ui is secure.
> https://phabricator.wikimedia.org/T196812#4273184
>
>
>
>
> On Monday, 11 June 2018, 13:38:20 BST, Paladox <
> thomasmulhall410(a)yahoo.com> wrote:
>
> Hi, i have created this task [1] with i have uploaded this patch [2] to
> make polygerrit the default ui.
> The reason why is upstream are preparing to remove the gwtui very soon. In
> matter of fact upstream have disabled the gwtui on *.googlesource.com.
> Upstream already have this change [3] to remove the ui. Making PolyGerrit
> the default ui will get new users use to the new ui.
> GWTUI will still be available with ui switcher in the footer or you can
> append the url like https://gerrit.wikimedia.org/r/?polygerrit=0
>
> PolyGerrit is stable, secure and also fast. It also has features that you
> cannot see in gwtui like user status, naming your patchiest (description),
> cc feature and also being able to tell who added you as a reviewer.
> This email is advanced notice before we change the default ui.
> any bugs todo with polygerrit / gerrit can be filled at
> https://phabricator.wikimedia.org/project/view/330/ and we can forward it
> upstream.
>
>
> [1] https://phabricator.wikimedia.org/T196812
> [2] https://gerrit.wikimedia.org/r/c/operations/puppet/+/439444
> [3] https://gerrit-review.googlesource.com/c/gerrit/+/116790
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 11 Jun 2018 14:05:11 -0400
> From: Yaron Koren <yaron(a)wikiworks.com>
> To: Wikimedia developers <Wikitech-l(a)lists.wikimedia.org>
> Subject: Re: [Wikitech-l] Gerrit as a shared community space
> Message-ID:
> <CAGmQEQGor=heXkofgoCH7MO_GLZvqce5nwo=
> KHjVgrbBDpbjuw(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> Moriel Schottlender <mschottlender at wikimedia.org> wrote:
> > Quite frankly, I don't blame people who regularly experience harassment
> > online to avoid spaces where the code of conduct is consciously only
> > enforced in parts of the space.
> > I, too, don't feel comfortable in joining that space, even for
> considering
> > potential interactions that I might encounter, and knowing that these
> > interactions, depending where they happen, may not be dealt with to my
> > personal ideal of what such space should be.
>
> Neither I nor any other extension developers are "enforcing" the code of
> conduct - that's up to a committee to do.
>
> > You stated that as far as you're concerned, there are interactions you
> > purposefully don't see as being governed by the CoC.
>
> I don't know what "purposefully" means there. There are interactions that
> are not governed by the CoC - how's that?
>
> > Some developers decide that they purposefully, in their repos, assume it
> > governs all interactions related to to work on the repo, and some,
> > apparently, do not.
>
> If anyone is "deciding" that, they're making an incorrect decision.
> Meaning, you can certainly say that you will not tolerate harassment,
> discrimination, etc. in personal emails as specified by the Wikimedia Code
> of Conduct - but as far as enforcement, you're on your own, unlike with the
> real CoC.
>
> Also, given that every extension had this file added in, how is a potential
> contributor to know who "decided" to embrace this file's statement and who
> didn't? Given the threat of harassment, it seems awfully risky to assume
> that everyone who didn't delete the file supports it.
>
> -Yaron
>
> On Mon, Jun 11, 2018 at 1:23 PM Yaron Koren <yaron(a)wikiworks.com> wrote:
>
> > Hi,
> >
> > Moriel Schottlender <mschottlender at wikimedia.org> wrote:
> > > This isn't a personal attack, it's a consequence to your earlier email.
> > >
> > > You stated yourself, that one of the reasons you don't think a COC.md
> > file
> > > should exist in your repository is because not all interactions are
> > covered
> > > by it. While that might be true technically-speaking, it does make a
> > > statement to potential contributors about what they might expect in
> > terms
> > > of feeling safe and secure with a CoC in place.
> > >
> > > For those of us who "bad interaction online" are a norm rather than an
> > edge
> > > case, a statement that the CoC is not fully covering a space means we
> > don't
> > > go to that space if we can help it.
> > >
> > > Saying that one does not intend on touching a space where the
> > maintainer
> > > clearly stated the CoC is only partially in effect is not a personal
> > attack
> > > -- it's a consequence of what you said.
> > > A consequence that is also shared by others who may feel less
> > comfortable
> > > speaking up on public threads, but would avoid going into such spaces
> > all
> > > the same. Not because of who you are personally, but because of what
> > your
> > > statement about how your space is governed means.
> > >
> > > Whatever other claims and discussion is going on in this and the other
> > > thread, let's not try to make it sound like there's a personal attack
> > going
> > > on here.
> >
> > No, I still think it's a personal attack. I think we've already
> > established that the CoC does not cover all interactions, and that the
> > CoC.md file is thus giving false information. Some people have stated
> that
> > clearly, some have grudgingly admitted it, but no one has really argued
> > against it. Even you note that it's "technically" true, whatever exactly
> > that means.
> >
> > And of course, this file was put in place by a few developers - it wasn't
> > an opt-in choice. (It's still not 100% clear that it's even an "opt-out"
> > choice, though at this point it seems to be.)
> >
> > Given those two things, the presence of a CoC.md file in an extension
> > directory tells a potential contributor nothing - nothing about
> additional
> > security they're getting, and nothing really about the extension's
> > developers. Actually, it's worse than nothing, because it gives potential
> > contributors false comfort as far as the protections they'll have. If, as
> > you say, some people face a real danger of harassment everywhere not
> > covered by a code of conduct, then it's all the more reason to either
> > remove that file, or reword it, everywhere - so people know what they're
> > actually getting into.
> >
> > So, why should Amir want to avoid dealing with my code specifically? Is
> it
> > because he would have fewer protections? Clearly, no. It must be
> something
> > about me personally that would make him treat my code differently from
> > everyone else's.
> >
> > -Yaron
> >
>
>
> --
> WikiWorks · MediaWiki Consulting · http://wikiworks.com
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 11 Jun 2018 20:06:59 +0200
> From: Tom Schulze <t.schulze(a)energypedia-consult.com>
> To: wikitech-l(a)lists.wikimedia.org
> Subject: [Wikitech-l] Escaping wikitext to JSON-valid string in
> templates
> Message-ID:
> <a2f5efc4-b746-b9ae-1750-445f973d272c(a)energypedia-consult.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hello everyone,
>
> I am having trouble escaping and displaying wikitext in a way that is
> JSON-safe. I did some research but none of the provided
> MagicWords/ParserFUnctions/etc seem to be suited for this purpose.
> Please refer to my gitLab snippet <https://gitlab.com/snippets/1723632>
> to see the sample code of the query, template and widget.
>
> My goal is to build up a structure like this using a widget (to load my
> custom JS), a cargo query and finally a template to display the items
> row by row:
>
> <div class="item" data-item='{"content":"data from a mediawiki form
> field"}'>Description</div>
> <div class="item" data-item='{"content":"data from a mediawiki form
> field"}'>Description</div>
>
> The data is taken from a PageForms textarea form field (the user can
> enter any data she wants). This piece of HTML gets parsed by a custom
> Java Script on page load for further processing. As soon as characters
> like single (') or double quotes (") appear, the whole JSON string gets
> messed up and the JavaScript JSON parser throws errors. Even worse, the
> DOM structure becomes fragmented when single quotes appear. So
> client-side fixing w/ JavaScript is impossible/tedious.
>
> Any solution is welcome, also restricting the types of characters used.
> Ideally, I would just need to wrap the parameter passed from the query
> to the template in some kind of Magic Word which escapes/strips out
> unwanted characters.
>
> What options do I have ? I am open for different approaches...
>
> Kind regards,
>
> Tom
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 11 Jun 2018 11:37:39 -0700
> From: Moriel Schottlender <mschottlender(a)wikimedia.org>
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> Subject: Re: [Wikitech-l] Gerrit as a shared community space
> Message-ID:
> <CAG7VCKJeOfEfssuq2Rj94iUGVF+ezsp+4kkt=
> 6PQ+rNiFNEn9A(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> I'm not going to get into the minutia and details of how the code of
> conduct is or isn't good to work in your repo, that's a separate discussion
> that I won't participate in by choice right now.
>
> I am simply pointing out that your own points made a declaration about how
> working in the space you are in looks like.
>
> In the gerrit commit that started this thing, you, yourself, publicly wrote
> this:
>
>
> *"The Site Settings extension uses a bunch of WMF tools and services for
> its development, including hosting. If some random person sends me a patch
> for Site Settings by email, and I email them back and say "Your code sucks,
> you nitwit" (or worse), am I violating the Wikimedia Code of Conduct?"*
>
> https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/SiteSettings/+/4375…
>
> This statement, the question itself, and the fact you are asking whether
> this violates the CoC means, to me, and others who are unwilling to work in
> a hostile environment, that you're unsure whether this is acceptable at
> all.
> You might see this question as an innocent attempt to nitpick over the
> specific details of whether by regulation something needs to happen.
> I see it as a hint that you might **actually** think this is an acceptable
> thing to do.
> I don't know if you do. You might think it's not a bad response, but rather
> a funny one. You might think it's acceptable because the original code
> **was** stupid. I know people who think that, and that, for *their* spaces,
> is valid.
>
> But then I choose not to spend time in that space. That's valid too.
> Which is why when Amir said he won't get near your code, he wasn't making a
> personal attack. He was making a conclusion based on what you wrote about
> the way your space operates.
>
> That's not a personal attack no matter how much you try to shift the goal
> post and talk about red herrings.
> That's a consequence, and a reason of why the code of conduct was needed to
> begin with.
>
> You might accept this consequence as acceptable. That's your choice in your
> space.
> But don't throw that on others as if by making a conscious choice to avoid
> spaces that have a danger of being toxic, they're personally attacking you.
>
> Let's go back to the actual discussion at hand, instead.
>
> Moriel
>
> On Mon, Jun 11, 2018, 11:05 AM Yaron Koren <yaron(a)wikiworks.com> wrote:
>
> > Hi,
> >
> > Moriel Schottlender <mschottlender at wikimedia.org> wrote:
> > > Quite frankly, I don't blame people who regularly experience harassment
> > > online to avoid spaces where the code of conduct is consciously only
> > > enforced in parts of the space.
> > > I, too, don't feel comfortable in joining that space, even for
> > considering
> > > potential interactions that I might encounter, and knowing that these
> > > interactions, depending where they happen, may not be dealt with to my
> > > personal ideal of what such space should be.
> >
> > Neither I nor any other extension developers are "enforcing" the code of
> > conduct - that's up to a committee to do.
> >
> > > You stated that as far as you're concerned, there are interactions you
> > > purposefully don't see as being governed by the CoC.
> >
> > I don't know what "purposefully" means there. There are interactions that
> > are not governed by the CoC - how's that?
> >
> > > Some developers decide that they purposefully, in their repos, assume
> it
> > > governs all interactions related to to work on the repo, and some,
> > > apparently, do not.
> >
> > If anyone is "deciding" that, they're making an incorrect decision.
> > Meaning, you can certainly say that you will not tolerate harassment,
> > discrimination, etc. in personal emails as specified by the Wikimedia
> Code
> > of Conduct - but as far as enforcement, you're on your own, unlike with
> the
> > real CoC.
> >
> > Also, given that every extension had this file added in, how is a
> potential
> > contributor to know who "decided" to embrace this file's statement and
> who
> > didn't? Given the threat of harassment, it seems awfully risky to assume
> > that everyone who didn't delete the file supports it.
> >
> > -Yaron
> >
> > On Mon, Jun 11, 2018 at 1:23 PM Yaron Koren <yaron(a)wikiworks.com> wrote:
> >
> > > Hi,
> > >
> > > Moriel Schottlender <mschottlender at wikimedia.org> wrote:
> > > > This isn't a personal attack, it's a consequence to your earlier
> email.
> > > >
> > > > You stated yourself, that one of the reasons you don't think a COC.md
> > > file
> > > > should exist in your repository is because not all interactions are
> > > covered
> > > > by it. While that might be true technically-speaking, it does make a
> > > > statement to potential contributors about what they might expect in
> > > terms
> > > > of feeling safe and secure with a CoC in place.
> > > >
> > > > For those of us who "bad interaction online" are a norm rather than
> an
> > > edge
> > > > case, a statement that the CoC is not fully covering a space means
> we
> > > don't
> > > > go to that space if we can help it.
> > > >
> > > > Saying that one does not intend on touching a space where the
> > > maintainer
> > > > clearly stated the CoC is only partially in effect is not a personal
> > > attack
> > > > -- it's a consequence of what you said.
> > > > A consequence that is also shared by others who may feel less
> > > comfortable
> > > > speaking up on public threads, but would avoid going into such
> spaces
> > > all
> > > > the same. Not because of who you are personally, but because of what
> > > your
> > > > statement about how your space is governed means.
> > > >
> > > > Whatever other claims and discussion is going on in this and the
> other
> > > > thread, let's not try to make it sound like there's a personal
> attack
> > > going
> > > > on here.
> > >
> > > No, I still think it's a personal attack. I think we've already
> > > established that the CoC does not cover all interactions, and that the
> > > CoC.md file is thus giving false information. Some people have stated
> > that
> > > clearly, some have grudgingly admitted it, but no one has really argued
> > > against it. Even you note that it's "technically" true, whatever
> exactly
> > > that means.
> > >
> > > And of course, this file was put in place by a few developers - it
> wasn't
> > > an opt-in choice. (It's still not 100% clear that it's even an
> "opt-out"
> > > choice, though at this point it seems to be.)
> > >
> > > Given those two things, the presence of a CoC.md file in an extension
> > > directory tells a potential contributor nothing - nothing about
> > additional
> > > security they're getting, and nothing really about the extension's
> > > developers. Actually, it's worse than nothing, because it gives
> potential
> > > contributors false comfort as far as the protections they'll have. If,
> as
> > > you say, some people face a real danger of harassment everywhere not
> > > covered by a code of conduct, then it's all the more reason to either
> > > remove that file, or reword it, everywhere - so people know what
> they're
> > > actually getting into.
> > >
> > > So, why should Amir want to avoid dealing with my code specifically? Is
> > it
> > > because he would have fewer protections? Clearly, no. It must be
> > something
> > > about me personally that would make him treat my code differently from
> > > everyone else's.
> > >
> > > -Yaron
> > >
> >
> >
> > --
> > WikiWorks · MediaWiki Consulting · http://wikiworks.com
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 11 Jun 2018 11:55:11 -0700
> From: Moriel Schottlender <mschottlender(a)wikimedia.org>
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> Subject: Re: [Wikitech-l] Gerrit as a shared community space
> Message-ID:
> <
> CAG7VCK+Pu149uCipWLA-21uCH1PZsHgmok3uN44D7g6CJAD4CQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Heh, an apology here, my autocorrect "fixed" your name, Yaron. I apologize
> for that and should have caught it.
> ... The trouble of multilingual corrections.
>
> Moriel
>
> On Mon, Jun 11, 2018, 11:37 AM Moriel Schottlender <
> mschottlender(a)wikimedia.org> wrote:
>
> > I'm not going to get into the minutia and details of how the code of
> > conduct is or isn't good to work in your repo, that's a separate
> discussion
> > that I won't participate in by choice right now.
> >
> > I am simply pointing out that your own points made a declaration about
> how
> > working in the space you are in looks like.
> >
> > In the gerrit commit that started this thing, you, yourself, publicly
> > wrote this:
> >
> >
> > *"The Site Settings extension uses a bunch of WMF tools and services for
> > its development, including hosting. If some random person sends me a
> patch
> > for Site Settings by email, and I email them back and say "Your code
> sucks,
> > you nitwit" (or worse), am I violating the Wikimedia Code of Conduct?"*
> >
> >
> https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/SiteSettings/+/4375…
> >
> > This statement, the question itself, and the fact you are asking whether
> > this violates the CoC means, to me, and others who are unwilling to work
> in
> > a hostile environment, that you're unsure whether this is acceptable at
> all.
> > You might see this question as an innocent attempt to nitpick over the
> > specific details of whether by regulation something needs to happen.
> > I see it as a hint that you might **actually** think this is an
> acceptable
> > thing to do.
> > I don't know if you do. You might think it's not a bad response, but
> > rather a funny one. You might think it's acceptable because the original
> > code **was** stupid. I know people who think that, and that, for *their*
> > spaces, is valid.
> >
> > But then I choose not to spend time in that space. That's valid too.
> > Which is why when Amir said he won't get near your code, he wasn't making
> > a personal attack. He was making a conclusion based on what you wrote
> about
> > the way your space operates.
> >
> > That's not a personal attack no matter how much you try to shift the goal
> > post and talk about red herrings.
> > That's a consequence, and a reason of why the code of conduct was needed
> > to begin with.
> >
> > You might accept this consequence as acceptable. That's your choice in
> > your space.
> > But don't throw that on others as if by making a conscious choice to
> avoid
> > spaces that have a danger of being toxic, they're personally attacking
> you.
> >
> > Let's go back to the actual discussion at hand, instead.
> >
> > Moriel
> >
> >
> > On Mon, Jun 11, 2018, 11:05 AM Yaron Koren <yaron(a)wikiworks.com> wrote:
> >
> >> Hi,
> >>
> >> Moriel Schottlender <mschottlender at wikimedia.org> wrote:
> >> > Quite frankly, I don't blame people who regularly experience
> harassment
> >> > online to avoid spaces where the code of conduct is consciously only
> >> > enforced in parts of the space.
> >> > I, too, don't feel comfortable in joining that space, even for
> >> considering
> >> > potential interactions that I might encounter, and knowing that these
> >> > interactions, depending where they happen, may not be dealt with to my
> >> > personal ideal of what such space should be.
> >>
> >> Neither I nor any other extension developers are "enforcing" the code of
> >> conduct - that's up to a committee to do.
> >>
> >> > You stated that as far as you're concerned, there are interactions you
> >> > purposefully don't see as being governed by the CoC.
> >>
> >> I don't know what "purposefully" means there. There are interactions
> that
> >> are not governed by the CoC - how's that?
> >>
> >> > Some developers decide that they purposefully, in their repos, assume
> it
> >> > governs all interactions related to to work on the repo, and some,
> >> > apparently, do not.
> >>
> >> If anyone is "deciding" that, they're making an incorrect decision.
> >> Meaning, you can certainly say that you will not tolerate harassment,
> >> discrimination, etc. in personal emails as specified by the Wikimedia
> Code
> >> of Conduct - but as far as enforcement, you're on your own, unlike with
> >> the
> >> real CoC.
> >>
> >> Also, given that every extension had this file added in, how is a
> >> potential
> >> contributor to know who "decided" to embrace this file's statement and
> who
> >> didn't? Given the threat of harassment, it seems awfully risky to assume
> >> that everyone who didn't delete the file supports it.
> >>
> >> -Yaron
> >>
> >> On Mon, Jun 11, 2018 at 1:23 PM Yaron Koren <yaron(a)wikiworks.com>
> wrote:
> >>
> >> > Hi,
> >> >
> >> > Moriel Schottlender <mschottlender at wikimedia.org> wrote:
> >> > > This isn't a personal attack, it's a consequence to your earlier
> >> email.
> >> > >
> >> > > You stated yourself, that one of the reasons you don't think a
> COC.md
> >> > file
> >> > > should exist in your repository is because not all interactions are
> >> > covered
> >> > > by it. While that might be true technically-speaking, it does make
> a
> >> > > statement to potential contributors about what they might expect in
> >> > terms
> >> > > of feeling safe and secure with a CoC in place.
> >> > >
> >> > > For those of us who "bad interaction online" are a norm rather than
> >> an
> >> > edge
> >> > > case, a statement that the CoC is not fully covering a space means
> we
> >> > don't
> >> > > go to that space if we can help it.
> >> > >
> >> > > Saying that one does not intend on touching a space where the
> >> > maintainer
> >> > > clearly stated the CoC is only partially in effect is not a
> personal
> >> > attack
> >> > > -- it's a consequence of what you said.
> >> > > A consequence that is also shared by others who may feel less
> >> > comfortable
> >> > > speaking up on public threads, but would avoid going into such
> spaces
> >> > all
> >> > > the same. Not because of who you are personally, but because of
> what
> >> > your
> >> > > statement about how your space is governed means.
> >> > >
> >> > > Whatever other claims and discussion is going on in this and the
> >> other
> >> > > thread, let's not try to make it sound like there's a personal
> attack
> >> > going
> >> > > on here.
> >> >
> >> > No, I still think it's a personal attack. I think we've already
> >> > established that the CoC does not cover all interactions, and that the
> >> > CoC.md file is thus giving false information. Some people have stated
> >> that
> >> > clearly, some have grudgingly admitted it, but no one has really
> argued
> >> > against it. Even you note that it's "technically" true, whatever
> exactly
> >> > that means.
> >> >
> >> > And of course, this file was put in place by a few developers - it
> >> wasn't
> >> > an opt-in choice. (It's still not 100% clear that it's even an
> "opt-out"
> >> > choice, though at this point it seems to be.)
> >> >
> >> > Given those two things, the presence of a CoC.md file in an extension
> >> > directory tells a potential contributor nothing - nothing about
> >> additional
> >> > security they're getting, and nothing really about the extension's
> >> > developers. Actually, it's worse than nothing, because it gives
> >> potential
> >> > contributors false comfort as far as the protections they'll have. If,
> >> as
> >> > you say, some people face a real danger of harassment everywhere not
> >> > covered by a code of conduct, then it's all the more reason to either
> >> > remove that file, or reword it, everywhere - so people know what
> they're
> >> > actually getting into.
> >> >
> >> > So, why should Amir want to avoid dealing with my code specifically?
> Is
> >> it
> >> > because he would have fewer protections? Clearly, no. It must be
> >> something
> >> > about me personally that would make him treat my code differently from
> >> > everyone else's.
> >> >
> >> > -Yaron
> >> >
> >>
> >>
> >> --
> >> WikiWorks · MediaWiki Consulting · http://wikiworks.com
> >> _______________________________________________
> >> Wikitech-l mailing list
> >> Wikitech-l(a)lists.wikimedia.org
> >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> >
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
> ------------------------------
>
> End of Wikitech-l Digest, Vol 179, Issue 27
> *******************************************
>
Hi,
Moriel Schottlender <mschottlender at wikimedia.org> wrote:
> This isn't a personal attack, it's a consequence to your earlier email.
>
> You stated yourself, that one of the reasons you don't think a COC.md file
> should exist in your repository is because not all interactions are
covered
> by it. While that might be true technically-speaking, it does make a
> statement to potential contributors about what they might expect in terms
> of feeling safe and secure with a CoC in place.
>
> For those of us who "bad interaction online" are a norm rather than an
edge
> case, a statement that the CoC is not fully covering a space means we
don't
> go to that space if we can help it.
>
> Saying that one does not intend on touching a space where the maintainer
> clearly stated the CoC is only partially in effect is not a personal
attack
> -- it's a consequence of what you said.
> A consequence that is also shared by others who may feel less comfortable
> speaking up on public threads, but would avoid going into such spaces all
> the same. Not because of who you are personally, but because of what your
> statement about how your space is governed means.
>
> Whatever other claims and discussion is going on in this and the other
> thread, let's not try to make it sound like there's a personal attack
going
> on here.
No, I still think it's a personal attack. I think we've already established
that the CoC does not cover all interactions, and that the CoC.md file is
thus giving false information. Some people have stated that clearly, some
have grudgingly admitted it, but no one has really argued against it. Even
you note that it's "technically" true, whatever exactly that means.
And of course, this file was put in place by a few developers - it wasn't
an opt-in choice. (It's still not 100% clear that it's even an "opt-out"
choice, though at this point it seems to be.)
Given those two things, the presence of a CoC.md file in an extension
directory tells a potential contributor nothing - nothing about additional
security they're getting, and nothing really about the extension's
developers. Actually, it's worse than nothing, because it gives potential
contributors false comfort as far as the protections they'll have. If, as
you say, some people face a real danger of harassment everywhere not
covered by a code of conduct, then it's all the more reason to either
remove that file, or reword it, everywhere - so people know what they're
actually getting into.
So, why should Amir want to avoid dealing with my code specifically? Is it
because he would have fewer protections? Clearly, no. It must be something
about me personally that would make him treat my code differently from
everyone else's.
-Yaron