[Wikitech-l] Re: End-points for Showing CAPTCHA

[Gergo Tisza]

On Sun, Apr 14, 2024 at 4:01 PM Shashank Kumar via Wikitech-l <
wikitech-l@lists.wikimedia.org> wrote:

> I am contributing to wikimedia-commons android app and we encountered a
> case where we need to show CAPTCHA within the app, is there any end-points
> available for this ? To Complete the CAPTCHA verification when it's
> required ?
>

It's integrated in the endpoints for the actions that involve solving a
captcha. Usually it involves submitting a 'captchaid' and 'captchaword' (or
in some cases 'captchaId' and 'captchaWord') parameters after having
received the captcha ID and the captcha image URL. For the login/signup
apis you can learn those via the authmanagerinfo endpoint, for most other
APIs you need to submit the data without a captcha first, and the error you
get in response will contain those parameters.
See e.g.
https://www.mediawiki.org/wiki/API:Account_creation
https://www.mediawiki.org/wiki/API:Login
https://www.mediawiki.org/wiki/API:Edit
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: API issue

[Gergo Tisza]

On Tue, Jan 9, 2024 at 8:53 PM ovskmendov--- via Wikitech-l <
wikitech-l@lists.wikimedia.org> wrote:

> I am not sending very many requests. I haven’t sent any requests in
> several days and yet I get the error message.
>

Maybe someone else is doing it from the same IP, or maybe it's a bug. You
could file a report
 in
Phabricator with the details of what you are doing and the details from
that error page.
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: API issue

[Gergo Tisza]

You should probably send requests less frequently, you are hitting some
sort of throttling.

(And we should probably show a more comprehensible error page. Filed as
T354718 .)
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: The login intersite mechanism is broken for the last 48 hours.

[Gergo Tisza]

On Fri, Dec 1, 2023 at 3:09 AM Igal Khitron  wrote:

> Well, usually when I tried this, the bugs were instantly closed because
> "they are not reproducible".
>

If the bug is not reproducible or monitorable in some way (which is not the
same thing as you not being able to immediately come up with reproduction
steps), there is not much we can do about it and a mailing list thread
would be "closed" too; so it has no benefits, but it's also less effective
for making sure the right people see the issue, making the discussion
discoverable and cross-referenceable from related discussion, tracking
changes etc.
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: The login intersite mechanism is broken for the last 48 hours.

[Gergo Tisza]

On Thu, Nov 30, 2023 at 2:50 PM Igal Khitron  wrote:

> Hello. Something weird started yesterday. I heavily use the global
> watchlist, and open links in many wikis a couple of times every day.
> Something that never happened before, and happens dozens of times now, in
> about 90% of the cases. If I work with wiki X and open some page on wiki Y,
> I find myself logged out there. I can go back to X and press F5, and still
> be logged in in X, which is the weird part, because I should be logged out
> everywhere simultaneously from any reason. The only thing that helps for Y
> is clicking Log in, then the page makes autorefresh to logged in state.
> Some more people complained about this. I would create a Phabricator
> ticket, but I have no idea how to reproduce this.
>

Phabricator is the best place for discussing ongoing bugs or breakages,
even if they aren't easily reproducible. Just summarize what you know about
it. Thanks!
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Collect telemetry (using WikimediaEvents) for a gadget

[Gergo Tisza]

On Mon, Nov 27, 2023 at 7:36 AM psnbaotg via Wikitech-l <
wikitech-l@lists.wikimedia.org> wrote:

> I *know *this can be very disruptive on UX, so I tend to be careful about
> its negative impact on page views. If the gadget can collect telemetry
> data about the prompt's display frequency and user interactions (using
> e.g. WikimediaEvents), I can know about its possible impact.
>
> Is this possible? It would be much appreciated if anybody could provide
> assistance.
>

Possible but quite complex. You need to define a corresponding event schema
and event stream, send data from the gadget to the event stream, and access
the data (or have some access the data) in the analytics cluster. The
documentation we have is not great but you need roughly these steps:
- request a volunteer NDA (or find someone who has one) [1] for hive access
[2]
- define your event schema (e.g. list of user interactions you are going to
log) in the form of a patch to the schemas/event/secondary [3] repository.
See docs [4][5].
- assign a stream to the schema in the main Wikimedia configuration [6]
- from the gadget, log the event using `mw.eventLog.submit( streamName,
eventObject )`. [7]
- ssh into the statistics server [8], authenticate with Kerberos, run hive,
and you can query the data under event_sanitized.

[1] https://wikitech.wikimedia.org/wiki/Volunteer_NDA
[2]
https://wikitech.wikimedia.org/wiki/Analytics/Data_access#ssh_login_to_analytics_client_servers_(AKA_stat_boxes)_with_Hadoop,_Hive,_Presto_access
[3]
https://gerrit.wikimedia.org/r/plugins/gitiles/schemas/event/secondary/+/refs/heads/master
[4]
https://wikitech.wikimedia.org/wiki/Event_Platform/Schemas#Creating_a_new_schema
[5] https://wikitech.wikimedia.org/wiki/Event_Platform/Schemas/Guidelines
[6]
https://wikitech.wikimedia.org/wiki/Metrics_Platform/Creating_An_Instrument#Deployment
[7]
https://www.mediawiki.org/wiki/Extension:EventLogging/Guide#Underlying_technology
[8]
https://wikitech.wikimedia.org/wiki/SRE/Production_access#Setting_up_your_access
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: partial translation after update

[Gergo Tisza]

On Thu, Nov 2, 2023 at 8:27 AM Peter Radisson  wrote:

> I am willing the help to debug that if somebody is telling me where to
> look.
>

Try running rebuildLocalisationCache.php or rebuildmessages.php.

In general for broken local installs, asking on IRC (e.g. #mediawiki) is
best because people can help you debug the issue in realtime. There's also
https://www.mediawiki.org/wiki/Project:Support_desk which tends to be more
lively than this mailing list.
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: incorrect category entries / German Wikipedia

[Gergo Tisza]

On Fri, Jun 9, 2023 at 9:13 AM Thiemo Kreuz 
wrote:

> Both pages start with , which is a deprecated alias for
> . Replacing it with e.g.  will remove the
> pages from the category.
>

Or just get rid of it. Adding a formatting tag was useful back in 2011 when
that page was created, because MediaWiki did not automatically
syntax-highlight JS pages back then. But it does now, so those tags don't
serve any purpose.
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Proposal: namespace Archived for mediawiki.org

[Gergo Tisza]

On Wed, May 31, 2023 at 3:37 PM Thiemo Kreuz 
wrote:

> Personally I'm really not sure if a namespace is the best possible
> solution. mediawiki.org is more a continuum of content we collected
> over the years. Pages are rarely up to date. It would probably be less
> cumbersome to consider the existing main namespace an "archive" and
> only mark pages that are known to be up to date.
>

I'm also on the skeptical side. I think whether something is relevant is
rarely clear-cut. I think most pages where the information is in some sense
old, and cannot be fixed just by updating the page, fall into one of these
categories:

   - The page documents a thing. The thing still exists, but isn't
   important anymore. Maybe it's not used by Wikimedia, but used by others.
   - The page documents a project. The project is finished. The page is not
   outdated (since the project finished, there is no need to change its
   description) but not that relevant to present-day capabilities.

In both of these situations, it's not that obvious whether the reader would
want the page included in the search results or not.
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: New Codesearch interface in beta testing

[Gergo Tisza]

Great work, thank you, both! The speed upgrade, the new sidebar, the more
manageable repo list, and Phabricator export all fix big pain points.
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Problems with Special:MyLanguage and German

[Gergo Tisza]

Seems to work fine for me:
https://de.wikipedia.org/wiki/Spezial:Letzte_%C3%84nderungen?uselang=de-formal

On Fri, Jul 22, 2022 at 7:05 AM RhinosF1 -  wrote:

> It is probably worth opening a bug on Phabricator. As far as I can tell
> Special:MyLanguage (
> https://github.com/wikimedia/mediawiki/blob/master/includes/specials/SpecialMyLanguage.php)
> does not include any logic for using the fallback languages which for
> de-formal is de.
>

It's right there
.
Of course, that's based on the language you have set on mediawiki.org, not
the linking wiki.

In any case, the SpecialRecentChanges help link is hardcoded

 to https://meta.wikimedia.org/wiki/Special:MyLanguage/Help:Recent_changes ,
language settings have nothing to do with it.
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

Re: [Wikitech-l] TechCom topics 2020-11-04 (fixed)

[Gergo Tisza]

On Tue, Nov 3, 2020 at 1:59 AM Daniel Kinzler 
wrote:

> TemplateData already uses JSON serialization, but then compresses the JSON
> output, to make the data fit into the page_props table. This results in
> binary data in ParserOutput, which we can't directly put into JSON.


I'm not sure I understand the problem. Binary data can be trivially
represented as JSON, by treating it as a string. Is it an issue of storage
size? JSON escaping of the control characters is (assuming binary data with
a somewhat random distribution of bytes) an ~50% size increase, UTF-8
encoding the top half of bytes is another 50%, so it will approximately
double the length - certainly worse than the ~33% increase for base64, but
not tragic. (And if size increase matters that much, you probably shouldn't
be using base64 either.)

* Don't write the data to page_props, treat it as extension data in
> ParserOutput. Compression would become unnecessary. However, batch loading
> of the data becomes much slower, since each ParserOutput needs to be loaded
> from ParserCache. Would it be too slow?
>

It would also mean that fetching template data or some other page property
might require a parse, as parser cache entries expire.
It would also also mean the properties could not be searched, which I think
is a dealbreaker.

* Apply compression for page_props, but not for the data in ParserOutput.
> We would have to introduce some kind of serialization mechanism into
> PageProps and LinksUpdate. Do we want to encourage this use of page_props?
>

IMO we don't want to. page_props is for page *properties*, not arbitrary
structured data. Also it's somewhat problematic in that it is per-page data
but it represents the result of a parse, so it doesn't necessarily match
the current revision, nor what a user with non-canonical parser options
sees. New features should probably use MCR for structured data.

* Introduce a dedicated database table for templatedata. Cleaner, but
> schema changes and data migration take a long time.
>

That seems like a decent solution to me, and probably the one I would pick
(unless there are more extensions in a similar situation). This is
secondary data so it doesn't really need to be migrated, just make
TemplateData write from the new table and fall back to the old one when
reading. Creating new tables should also not be time-consuming.

* Put templatedata into the BlobStore, and just the address into
> page_props. Makes loading slower, maybe even slower than the solution that
> relies on ParserCache.
>

Doesn't BlobStore support batch loading, unlike ParserCache?

* Convert TemplateData to MCR. This is the cleanest solution, but would
> require us to create an editing interface for templatedata, and migrate out
> existing data from wikitext. This is a long term perspective.
>

MCR has fairly different semantics from parser metadata. There are many
ways TemplateData data can be generated for a page without having a
 tag in the wikitext (e.g. a doc subpage, or a template which
generates both documentation HTML and hidden TemplateData). Switching to
MCR should be thought of as a workflow adjustment for contributors, not
just a data migration.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Workflow for updating javascript tools on wiki?

[Gergo Tisza]

On Mon, Oct 26, 2020 at 9:27 AM Roy Smith  wrote:

> I maintain spi-tools.js
> .  The source
> is in github.  At the moment, my "release process" (if you could call it
> that) is to edit
> User:RoySmith/spi-tools.js and copy-paste the new version.  This works,
> but it's clunky.  Is there some pre-existing tool for this?
>

There is some discussion in T71445
 and T187749
 but nothing usable. I think
some frwiki editors had plans for a bot but I don't know if anything came
out of it. The closest tool I'm aware of is Dibabel
 but that copies the code from another
wiki, not Github. (Also, it's meant for Lua code, which does not pose
similar security risks.)

Updating the page from a CI script is not too hard but rather scary
security-wise. Writing a deploy script in Pywikibot or some
similar framework seems pretty straightforward though, reasonably secure,
and not too inconvenient to do an extra CLI command for deploying.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki logo

[Gergo Tisza]

On Mon, Oct 26, 2020 at 5:29 PM Denny Vrandečić 
wrote:

> SInce thanking yourself would be weird, allow me to express my thanks for
> all your work and shepherding during the logo process (and well beyond
> that, but let's keep focus here).
>

Indeed, the width and breadth of your contributions to Wikimedia and
MediaWiki have been nothing short of amazing, Amir. Thank you for
initiating and guiding through this much needed visual update!

Also thanks to everyone who contributed a logo design! We had quite a few
strong contenders.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Ethical question regarding some code

[Gergo Tisza]

On Sun, Aug 9, 2020 at 2:18 AM Nathan  wrote:

> I don't see how any part of it constitutes creating biometric identifiers,
> nor is it obvious to me how it must remove anonymity of users.
>

The GDPR for example defines biometric data as "personal data resulting
from specific technical processing relating to the physical, physiological
or behavioural characteristics of a natural person, which allow or confirm
the unique identification of that natural person" (Art. 4 (14)). That seems
to fit, although it could be argued that the tool would link accounts to
other accounts and not to people so the data is not used for
"identification of a natural person", but that does not sound super
convincing. The GDPR (Art 9) generally forbids processing biometric data,
except for a number of special cases, some of which can be argued to apply:

* processing is carried out in the course of its legitimate activities with
appropriate safeguards by a foundation, association or any other
not-for-profit body with a political, philosophical, religious or trade
union aim and on condition that the processing relates solely to the
members or to former members of the body or to persons who have regular
contact with it in connection with its purposes and that the personal data
are not disclosed outside that body without the consent of the data
subjects;
* processing relates to personal data which are manifestly made public by
the data subject;

but I wouldn't say it's clear-cut.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Request for checking two patches on Gerrit

[Gergo Tisza]

On Mon, Aug 3, 2020 at 7:40 PM Daniel Zahn  wrote:

> With all due respect but i believe it does not scale to use this
> mailing list to ping for individual code reviews.  Yes, we really need
> to fix the issue that getting reviews is too hard and too many users
> seem to filter Gerrit mail but moving that to "everyone gets mail
> about all changes" does not appear to be the solution to me.
>

https://phabricator.wikimedia.org/T200987 has some related discussion.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Extension migration: LinksDeletionUpdate is now a subclass of LinksUpdate

[Gergo Tisza]

On Tue, Jul 14, 2020 at 5:49 PM Mark Clements (HappyDog) <
gm...@kennel17.co.uk> wrote:

> I have an extension that uses the LinksUpdate hook to re-parse the article
> in order to extract meta-data that it then stores in the DB for use
> elsewhere in the extension.
> (...)
> In the light of the above change to the LinksUpdate hook, what changes do
> I
> need to make to my extension?  Shall I simply drop the
> ArticleDeleteComplete
> hook and update LinksUpdate to check whether an article is deleted or not
> (how?) to decide which action is required?  Or is there more to it.
>

That would work; you can check the type of the LinksUpdate object to
determine what kind of action you are handling.


> On a separate note, I also reparse the page when the ArticleUndelete hook
> is
> called.  Is this necessary, or is LinksUpdate also being called for
> undeletes?
>

LinksUpdate is called when a page has new content that needs to be
processed for links (or, more generally, metadata), whether it got created,
edited or restored.


> Finally, I do a similar thing in the TitleMoveComplete hook - I reparse
> both
> the old article and the new article.  Is this also redundant due to
> LinksUpdate calls, or not?
>

LinksUpdate is called in those cases as well.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Service wiring conventions in extensions

[Gergo Tisza]

I'd go for something like

/* TranslateServices.php */
public static function wrap( MediaWikiServices $services ) { return new
self( $services ); }

/* ServiceWiring.php */
'Translate:TranslatablePageParser' => function ( MediaWikiServices
$services ) {
return new TranslatablePageParser(
TranslateServices::wrap( $services
)->getParsingPlaceholderFactory();
};
},
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Hard deprecation of the Revision class

[Gergo Tisza]

The Revision -> RevisionRecord switch was a key part of both making
MediaWiki dependency-injection-friendly and making it aware of multiple
content slots per revision. It's great to see us following through on a
large-scale refactoring like that. Huge thanks to DannyS712 (who as done
awesome work on a number of other deprecations too), the Core Platform
Team, and everyone else who has been working on it!
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Newby dev question: extension configuration variable

[Gergo Tisza]

It should be $services = $config->get( 'ShariffServices' );

The actual error is an unrelated configuration problem with your wiki (or
possibly a MediaWiki core bug where it tries to use a certain type of error
handling too early in the request lifecycle), that's triggered during
rendering the error about configuration not having a Services key.

On Tue, Jun 16, 2020 at 11:30 AM Krabina Bernhard  wrote:

> Hi,
>
> in my first attempt at jumping into improving a mediawiki extension, I am
> failing at a very basic step.
>
> I want to make the extension configurable and followed this advice:
> [ https://www.mediawiki.org/wiki/Manual:Configuration_for_developers |
> https://www.mediawiki.org/wiki/Manual:Configuration_for_developers ]
>
>
> this is my extension.json I added:
>
> "config": {
> "ShariffServices": {
> "value":
> "[twitter,facebook,pinterest]",
> "description": "configuration of available services"
> }
> },
> "ConfigRegistry": {
> "Shariff": "GlobalVarConfig::newInstance"
> },
>
> now in the baisc PHP file of the extension, I am trying
> use MediaWiki\MediaWikiServices;
> $config =
> MediaWikiServices::getInstance()->getConfigFactory()->makeConfig( 'Shariff'
> );
> $services = $config->get ('Services');
>
> but the last line leads to
> [XtqcaewKU0Q3UCukKmZO9BM] /index.php?title=Main_Page Error from line
> 3061 of ../includes/parser/Parser.php: Call to a member function
> matchStartAndRemove() on null
>
> Backtrace:
>
> #0 ..includes/parser/Preprocessor_DOM.php(1277):
> Parser->braceSubstitution(array, PPFrame_DOM)
> #1 ../includes/parser/Parser.php(2942): PPFrame_DOM->expand(DOMElement,
> integer)
> #2 ../includes/parser/Parser.php(701): Parser->replaceVariables(string,
> PPFrame_DOM)
> #3 ../includes/parser/Parser.php(4717): Parser->preprocess(string, Title,
> ParserOptions)
> #4 ../includes/cache/MessageCache.php(1089): Parser->transformMsg(string,
> ParserOptions, Title)
> #5 ../includes/Message.php(1273): MessageCache->transform(string, boolean,
> LanguageEn, Title)
> #6 ../includes/Message.php(874): Message->transformText(string)
> #7 ../includes/Message.php(934): Message->toString(string)
> #8 ../includes/OutputPage.php(902): Message->text()
> #9 /../includes/OutputPage.php(949): OutputPage->setHTMLTitle(Message)
> #10 ../includes/OutputPage.php(2424): OutputPage->setPageTitle(string)
> #11 /../includes/exception/MWExceptionRenderer.php(128):
> OutputPage->prepareErrorPage(string)
> #12 ../includes/exception/MWExceptionRenderer.php(54):
> MWExceptionRenderer::reportHTML(ConfigException)
> #13 ../includes/exception/MWExceptionHandler.php(75):
> MWExceptionRenderer::output(ConfigException, integer)
> #14 ../includes/exception/MWExceptionHandler.php(149):
> MWExceptionHandler::report(ConfigException)
> #15 ../includes/MediaWiki.php(551):
> MWExceptionHandler::handleException(ConfigException)
> #16 ../index.php(42): MediaWiki->run()
> #17 {main}
>
>
> What am I doing wrong?
>
> As far is I understand it, using DefaultSettings.php is outdated, we
> should be using extension.json. But I can't get it to work.
>
> Can anybody point me to a simple extension that uses this mechanism
> correctly?
>
>
> so long,
> Bernhard
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Abstract Schema and Schema changes, request for help

[Gergo Tisza]

Thank you so much for working on this, it was one of the most painful
aspects of core development!

It might be worth using a consistent gerrit topic or hashtag to make
finding the relevant patches easy.

On Sat, May 9, 2020 at 3:21 AM Amir Sarabadani  wrote:

> Hello,
> In case you haven't done any changes on database schema of mediawiki core,
> let me explain the process to you (if you know this, feel free to skip this
> paragraph):
> * Mediawiki core supports three types of RDBMS: MySQL, Sqlite, Postgres. It
> used to be five (plus Oracle and MSSQL)
> * For each one of these types, you need to do three parts: 1- Change the
> tables.sql file so new installations get the new schema 2- Make .sql schema
> change file, like an "ALTER TABLE" for current installations so they can
> upgrade. 3- Wire that schema change file into *Updater.php file.
> * For example, this is a patch to drop a column:
> https://gerrit.wikimedia.org/r/c/mediawiki/core/+/473601 This file touches
> 14 different files, adds 94 lines and removes 30.
>
> This is bad for several reasons:
> * It is extremely complicated to do a even a simple schema change. Usually
> something as simple as adding an column takes a whole day for me. There are
> lots of complicating factors, like Sqlite doesn't have ALTER TABLE, so when
> you want to make a patch for adding a column, you need to make a temporary
> table with the new column, copy the old table data to it, drop the old
> table and then rename the old table.
> ** Imagine the pain and sorrow when you want to normalize a table meaning
> you need to do several schema changes: 1- Add a table, 2- Add a column on
> the old table, 3- make the column not-nullable when it's filled and make
> the old column nullable instead 4- drop the old column.
> * It's almost impossible to test all DBMS types, I don't have MSSQL or
> Oracle installed and I don't even know their differences with MySQL. I
> assume most other developers are good in one type, not all.
> * Writing raw sqls, specially duplicated ones, and doubly specially when we
> don't have CI to test (because we won't install propriety software in our
> infra) is pretty much prone to error. My favourite one was that a new
> column on a table was actually added to the wrong table in MSSQL and it
> went unnoticed for two years (four releases, including one LTS).
> * It's impossible to support more DBMS types through extensions or other
> third party systems. Because the maintainer needs to keep up with all
> patches we add to core and write their equivalents.
> * For lots of reasons, these schemas are diverging, there have been several
> work to just reduce this to a minimum.
>
> There was a RFC to introduce abstract schema and schema changes and it got
> accepted and I have been working to implement this:
> https://phabricator.wikimedia.org/T191231
>
> This is not a small task, and like any big work, it's important to cut it
> to small pieces and gradually improve things. So my plan is first, I
> abstract the schema (tables.sql files), then slowly I abstract schema
> changes. For now, the plan is to make these .sql files automatically
> generated through maintenance scripts. So we will have a file called
> tables.json and when running something like:
> php maintenance/generateSchemaSql.php --json maintenance/tables.json --sql
> maintenance/tables-generated.sql --type=mysql
> It would produce tables-generated.sql file. The code that produces it is
> Doctrine DBAL and this is already installed as a dev dependency of core
> because you would need Doctrine if you want to make a schema change, if you
> maintain an instance, you should not need anything. Most of the work for
> automatically generating schema is already merged and the last part that
> wires it (and migrates two tables) is up for review:
> https://gerrit.wikimedia.org/r/c/mediawiki/core/+/595240
>
> My request is that I need to make lots of patches and since I'm doing this
> in my volunteer capacity, I need developers to review (and potentially help
> with the work if you're excited about this like me). Let me know if you're
> willing to be added in future patches and the current patch also welcomes
> any feedback: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/595240
>
> I have added the documentation in
> https://www.mediawiki.org/wiki/Manual:Schema_changes for the plan and
> future changes. The ideal goal is that when you want to do a schema change,
> you just change tables.json and create a json file that is snapshot of
> before and after table (remember, sqlite doesn't have alter table, meaning
> it has to know the whole table). Also, once we are in a good shape in
> migrating mediawiki core, we can start cleaning up extensions.
>
> Any feedback is also welcome.
>
> Best
> --
> Amir (he/him)
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Change page’s content model

[Gergo Tisza]

Hi Diego!

On Tue, Mar 10, 2020 at 9:28 AM Diego Quintana 
wrote:

> So my question is, could you change my CSS page’s content model to
> sanitized-css, or is there a way to create a new .css page and have it be
> sanitized-css from its creation.
>

The content model is usually determined by the namespace when the page is
created, and stays the same after that (administrators can change it, as
you say). So you can create the page in the Template namespace with a .css
extension, which will make it a sanitized-css page, and then move it
elsewhere.

In my opinion it's better to keep such pages in the template namespace
though. User CSS subpages in particular are not ideal because they are
protected from editing by anyone other than the owner, making it difficult
to collaborate on them.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki API pageview issue

[Gergo Tisza]

On Sun, Feb 23, 2020 at 4:17 PM James Gardner via Wikitech-l <
wikitech-l@lists.wikimedia.org> wrote:

> We attempted to use the wmflabs.org tool, but it only shows data from a
> certain date. (Example link:
>
> https://tools.wmflabs.org/pageviews/?project=en.wikipedia.org=all-access=user=2019-07-01=2020-01-25=2019%E2%80%9320_Hong_Kong_protests|China
> 
> <
> https://tools.wmflabs.org/pageviews/?project=en.wikipedia.org=all-access=user=2019-07-01=2020-01-25=2019%E2%80%9320_Hong_Kong_protests%7CChina
> >
> )
>

There's a redirectview tool (see the "redirects" links at the bottom of the
page you linked) but it can't be filtered by date so it probably can't help
you.


> Then we attempted to use the redirects of a page and using the old page ids
> to grab the pageview data, but there was no data returned. When we
> attempted to grab data for a page that we knew would have a long past, but
> the parameter of "pvipcontinue" did not appear (
> https://www.mediawiki.org/w/api.php?action=help=query%2Bpageviews
> ).
> (Example:
>
> https://www.mediawiki.org/wiki/Special:ApiSandbox#action=query=json=pageviews=MediaWiki=pageviews=60=
> )
>

That API displays a limited set of metrics and is focused on caching and
being backend-agnostic. There is no way to get old data, pvicontinue is for
fetching data about more pages. If you need something more specific, you
should use the Analytics Query Service (which the other APIs rely on)
directly: https://wikitech.wikimedia.org/wiki/Analytics/AQS/Pageviews

I think you'll have to piece the data together using the MediaWiki
redirects API and AQS.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Gerrit +2 for polishdeveloper / pmiazga

[Gergo Tisza]

Please see https://phabricator.wikimedia.org/T243925
(and https://www.mediawiki.org/wiki/Gerrit/Privilege_policy if you are
unfamiliar with the +2 process but curious about it)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] WebTestCase

[Gergo Tisza]

On Thu, Oct 3, 2019 at 5:33 AM Jeroen De Dauw 
wrote:

> The web request case is apparently not as simple as stuffing
> Title::newFromText()->getCannonicalUrl() into Http::get()
>

That's pretty much how I would try it (if I couldn't avoid testing the full
web stack instead of just calling the relevant special page or action
directly).
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] WebTestCase

[Gergo Tisza]

There's ApiTestCase for the action API, and an open patch [1] for providing
similar functionality for the REST API.
I don't think there is anything for web views, and the dispatching
mechanism is fairly messy. (The entry point is MediaWiki::run() but that
has teardown logic that would probably break the next test.) Your best bet
might be making actual web requests. You can use Selenium from PHPUnit, or
a number of similar tools (e.g. Goutte if you want something simple).


[1] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/520066

On Wed, Oct 2, 2019 at 11:56 AM Jeroen De Dauw 
wrote:

> Hey,
>
> > I think selenium is often used for that use case
>
> I'm explicitly looking for a PHPUnit based approach. Similar to what
> Symfony provides. Surely this is possible with MediaWiki, though perhaps
> not as elegantly?
>
> Cheers
>
> --
> Jeroen De Dauw | www.EntropyWins.wtf  |
> www.Professional.Wiki 
> Entrepreneur | Software Crafter | Speaker | Open Souce and Wikimedia
> contributor
> ~=[,,_,,]:3
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Introducing WikiContrib 1.0!

[Gergo Tisza]

On Thu, Sep 5, 2019 at 5:25 AM Rammanoj Potla 
wrote:

> I am happy to introduce you to the first version of WikiContrib
> . WikiContrib is a developer
> metrics tool which can be used to view a developer’s contributions on
> Phabricator and Gerrit. This tool was initially designed keeping a
> Wikimedia Hackathon scholarship committee in mind and with the hope that
> the tool will make it easier for them to decide on a candidate’s
> application. All community members can also use the tool to learn more
> about the contributions of fellow Wikimedians or discover their own!
>

Very cool tool!

IMO the usability could be improved a lot by removing the little red icon
from the first row when it is the only one (it seems like some sort of "the
fields are not filled out correctly" feedback when it is actually just a
"delete row" button which does not make sense with just one row), and
making the search button much more prominent compared to the other
controls. Also maybe making it possible to search by pressing enter in one
of the text fields.

It would be particularly awesome (but maybe hard?) to also count Gerrit
comments/reviews/merges as contributions.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Change to ResultWrapper indexing

[Gergo Tisza]

Hi all,

In the past, iterating ResultWrapper (the object returned by
Database::select() and similar MediaWiki commands) resulted in 1-based
indexes (that is, foreach ( $rw as $i => $_ ) { echo "$i "; } would print 1
2 3 4...). From 1.34 (or since a few weeks ago, if you use the master
version), the indexing will be 0-based. Since there is no way to apply the
usual deprecation process to this type of change, it's being announced here
instead.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 今週あなたを幸せにするものは何ですか？ / What's making you happy this week? (Week of 16 June 2019)

[Gergo Tisza]

Regular practice of gratitude is well-understood to be a key element of
personal well-being (and while community health is a less researched area,
it seems likely that the benefits extend there too). As such these threads
are IMO very useful.

On Mon, Jun 24, 2019 at 6:40 PM Isarra Yos  wrote:

> Mailing lists aren't really a good place to establish consensus, as
> every time someone weighs in, everyone is notified, so 'me too's are
> frowned upon in principle.
>
> Perhaps you might want to create an actual poll about preferred venues
> etc onwiki and then send out a message to wikimedia-l linking to that if
> you want a more meaningful assessment.
>
> -I
>
> On 24/06/2019 01:42, Pine W wrote:
> > Hi,
> >
> > Thank you for the positive comments, Stephan and RhinosF1.
> >
> > I think that there is not a clear public majority opposed or in favor of
> > continuing to have these threads on Wikitech-l in their current form. The
> > relatively small number of people who commented suggests to me that most
> > readers of this list are neutral. I will err on the side of caution and
> > stop sharing the threads to Wikitech-l. I will continue to post these
> > threads to Wikimedia-l. Also, I will share modified versions of the
> content
> > for these threads in *The Signpost*
> > , starting
> with
> > the next issue of that publication. If someone would like to create a
> > Wikitech-specific version of these threads, I think that they are welcome
> > to do that.
> >
> > Pine
> > ( https://meta.wikimedia.org/wiki/User:Pine )
> > ___
> > 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

Re: [Wikitech-l] Content modification no longer possible in PageContentSave hook?

[Gergo Tisza]

I'm guessing you meant to write
$content = $content->getContentHandler()->unserializeContent( $newText
);
since there's no way this could have ever worked otherwise. Filed as
https://phabricator.wikimedia.org/T222413
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Help please! Database::close: mass commit/rollback... on Special Page

[Gergo Tisza]

On Fri, Apr 26, 2019 at 10:19 AM Jim Hu  wrote:

> The code is throwing the mass commit error only if something interrupts
> processing before execution is complete - that includes my testing with
> die() statements or other errors that I’ve been tracking down. So it seems
> like doing execution via the Special page is caching all database
> interactions into some unknown number of transactions that never get
> committed until page execution makes it all the way to the end. If it
> doesn’t, the mass commit error happens.
>

MediaWiki generally wraps database requests in an automatic transaction (at
least when you are in a web request - jobs and maintenance scripts have
somewhat different rules). There are ways to push callbacks into a followup
transaction too, with things like DeferredUpdate or
Database::onTransactionCommitOrIdle. There shouldn't really be a way for a
special page to cause errors with that, other than manually calling
commit/rollback methods in the wrong way. die() would prevent the
transaction from being committed but wouldn't generate an error, I think.


> It looks to me like in the earlier versions of MW creating a page is
> committed during execution, so one can pull a revision for that page and do
> stuff to it in the same pass through the special page execution. Now it’s
> acting like there is not revision to pull after doing
> WikiPage::doEditContent(). When I comment out the right blocks of code, I
> can  see that I create the desired page from my template, but my attempt to
> pull the revision text back out and do something to it blanks the page and
> causes errors from code that expects there to be text in the revision.
>

That sounds like consistent read [1] issues - MySQL transactions don't see
rows that have been newly inserted (in the same transaction) under certain
circumstances. The usual workaround for that is to do a locking read, e.g.
use the 'LOCK IN SHARE MODE' option with Database::select.

[1] https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-read.html
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Help please! Database::close: mass commit/rollback... on Special Page

[Gergo Tisza]

> $dbw = wfGetDB( DB_SLAVE );
> $dbw->insert( 'omp_master.strain', array( 'id' => null, 'name' =>
$formData['strain_name_field'] ) );

You should use wfGetDB( DB_MASTER ) to get a DB handle for writing.


On Tue, Apr 23, 2019 at 9:16 AM Jim Hu  wrote:

> It’s a custom extension used by my lab only, and while a version is on our
> public github, it’s going to be hard to follow because of entanglement with
> some other custom code libraries we use that wrap the WikiPage class to
> accommodate our use of the TableEdit extension. If you want to look anyway,
> it’s here:
>
>
> https://github.com/microbialphenotypes/OMPwiki/blob/master/OMP/specialpages/StrainSpecialPage/SpecialNewPage.php
>
> But it would probably be more useful for you to wait until I can pare it
> down to something that is minimal to see if I can isolate the problematic
> part and then push that to github.
>
> I was hoping someone had seen a similar problem with Special page
> development and had a simpler answer!
>
> Thanks!
>
> Jim
>
> > On Apr 23, 2019, at 10:29 AM, Jaime Crespo 
> wrote:
> >
> >>> For one of our custom wikis we have a Special Page that creates new
> pages
> >>> based on form input. This used to work in MW1.23 but in the long
> overdue
> >>> update to MW1.31 it stopped working.
> >
> > I am not familiar with Special:StrainNewPage, I am guessing that is
> > custom code not available from a standard extension? If it is not
> > private and you could share that custom code (or at least part of it)
> > maybe someone can help you better to see what is the problem in your
> > case. :-)
> >
> > ___
> > 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

Re: [Wikitech-l] Help please! Database::close: mass commit/rollback... on Special Page

[Gergo Tisza]

That means an implicit transaction [1] was started but not
committed/cancelled. For special pages transaction handling is done by the
framework and this should not happen unless you are doing something
strange, like obtaining a connection in a non-standard way.
Application errors (ie. something throwing a non-database-related
exception) sometimes bring the database abstraction layer into an
inconsistent state, so maybe this is a secondary error caused by something
else - check your exception logs.

[1] https://www.mediawiki.org/wiki/Database_transactions#Transaction_scope

On Mon, Apr 22, 2019 at 9:31 AM Jim Hu  wrote:

>
> For one of our custom wikis we have a Special Page that creates new pages
> based on form input. This used to work in MW1.23 but in the long overdue
> update to MW1.31 it stopped working.
>
> The Special Page is supposed to write a record to a shared external
> database and then use the autoincremented row number to set the name of the
> page that will be created. I’m using $dbw->insert to do this. In 1.31 the
> autoincrement index gets bumped but the row doesn’t get written. If I do
> the same insert from a maintenance script, it works, so I’m assuming it
> doesn’t have anything to do with general configurations or other extensions
> (which I’ve inactivated).
>
> After it gets a value for the lastInsertID it tries to make a page from a
> template. That page is never created and I see this in the error logs:
>
> PHP Fatal error:  Uncaught Wikimedia\\Rdbms\\DBUnexpectedError:
> Wikimedia\\Rdbms\\Database::close: mass commit/rollback of peer
> transaction required (DBO_TRX set). in
> /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/database/Database.php:916\nStack
> trace:\n#0
> /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1217):
>
> Wikimedia\\Rdbms\\Database->close()\n#1
> [internal function]:
> Wikimedia\\Rdbms\\LoadBalancer->Wikimedia\\Rdbms\\{closure}(Object(Wikimedia\\Rdbms\\DatabaseMysqli))\n#2
> /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1640):
>
> call_user_func_array(Object(Closure), Array)\n#3
> /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1218):
>
> Wikimedia\\Rdbms\\LoadBalancer->forEachOpenConnection(Object(Closure))\n#4
> /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1208):
>
> Wikimedia\\Rdbms\\LoadBalancer->closeAll()\n#5
> /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/loadbalancer/LoadBal
> in
> /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/database/Database.php
> on line 916,
> referer: http://localhost/omp/wiki/index.php/Special:StrainNewPage
>
> This happens even if comment out the code that accesses the external
> database completely and hard code the ID.
>
> Other Special Page extensions we have that create new pages seem to work
> on 1.31.1. I’m wondering if this is related to the method that now fails
> being a callback from HTMLforms for processing form submission.
>
> Any insight, help in debugging this would be much appreciated. Apologies
> if I’m using some terminology incorrectly (I’m a biologist more than a
> coder).
>
> Jim Hu
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Where should extension default preferences be specified?

[Gergo Tisza]

On Fri, Mar 22, 2019 at 10:41 AM Thomas Eugene Bishop <
thomasbis...@wenlin.com> wrote:

> (3) If DefaultUserOptions and onGetPreferences both specify default
> values, and they differ, onGetPreferences wins. I believe this scenario
> should be avoided. Having an option whose default is “X” before you go to
> the Preferences form, but changes to “Y” when you do go there, could give
> the user the false impression that the value has been “Y” all along, and
> lead to confusion and instability.
>

It probably also means that when you go to your preferences for some
unrelated reason and press save, that setting will change, even if you
never interacted with the field. Definitely not great. (Although this is
being abused for beta feature automatic rollout (T64815) so it's a feature,
sort of.)

(4) If DefaultUserOptions and $wgDefaultUserOptions both specify default
> values, and they differ, $wgDefaultUserOptions wins.
>

That is by design, DefaultUserOptions is just a mechanism to set
$wgDefaultUserOptions.


> A default is NOT required there. If there’s a default in onGetPreferences
> but not in DefaultUserOptions, there’s a bug per (1) above. If a default in
> onGetPreferences agrees with DefaultUserOptions, it’s redundant per (2)
> above. If it disagrees, there’s a bug per (3) above.
>

Also having a 'default' key but not DefaultUserOptions can be actively
harmful (or at least that used to be the case in the past), see T64946.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[Gergo Tisza]

On Wed, Mar 20, 2019 at 2:08 PM Pine W  wrote:

> :) Structured data exists regarding many other subjects such as books and
> magazines. I would think that a similar approach could be taken to
> technical debt. I realize that development tasks have properties and
> interactions that change over time, but I think that having a better
> quantitative understanding of the backlog would be good and would likely
> improve the quality of planning and resourcing decisions.
>

Focusing on metrics is something bad managers tend to do when they don't
have the skills or knowledge to determine the actual value of the work.
It's a famous anti-pattern. I'll refer you to the classic Spolsky article:
https://www.joelonsoftware.com/2002/07/15/20020715/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Read access to patrolled flag in wikimedia API

[Gergo Tisza]

On Wed, Mar 13, 2019 at 10:50 PM Max Semenik  wrote:

> I don't think it's possible to filter by flagged status


Not as such. You can use the list=reviewedpages API module which will list
changes needing review (it should probably get some award for most
confusing module name), starting from most recent. It will not include new
pages which have never been reviewed, though.

On Thu, Mar 14, 2019 at 1:58 AM Сибирев Кирилл 
wrote:

> As far as i understand this flagged data contains stable revision for
> pages, which are have pending changes protection enabled and when flag is
> missing means it is disabled, is that correct?
>

Depends on the wiki, some are configured to have opt-in pending changes
protection and only manually protected pages will have a stable revision;
for some wikis flagged revisions are the default and all pages will have a
stable revision assuming someone did review the page at some point (so
recently created pages might not have a stable version yet). And many wikis
have not enabled flagged/pending changes features at all and the API will
just error out on prop=flagged.

Also is it possible to get all page revisions through this generator, so i
> can find stable content or it can only be acomplished with another page
> revisions query? When i add prop=revisions
> (prop=flagged|revisions=recentchanges) — i get only one latest
> revision.
>

I think your best bet is making a new request for the specified revisions.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Where should extension default preferences be specified?

[Gergo Tisza]

GetPreferences does not set defaults; it provides form elements for the
preferences form. The 'default' field there will be the default value in
the form; it won't actually get added to user preferences until the user
goes there and saves the form. Until then (and for anonymous users) the
value from DefaultUserOptions will be used.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[Gergo Tisza]

On Fri, Mar 15, 2019 at 9:25 AM Strainu  wrote:

> That's an overstatement: 18% (not counting bugs closed as declined) is
> almost double to 11%. If you're going this route, we're doing much
> worse than Chromium.
>

I have a hard time imagining that anyone would be upset that 18% of our
tasks are open but would be fine with that number being 11%. A hundred
times more is significant difference. 60% more, not really.
I just wanted to point out that open bugs being about one magnitude less
than total bugs is fairly normal for an opensource project (possibly closed
projects too, it's just harder to find data there). Just to have some more
data points: Firefox has 1.4M bugs, 140K are open; Debian has 140K active
and 800K archived bugs; PHP has 77K bugs, 37K of which are closed; Apache
has 47K bugs, and 5900 open ones (including LATER).

I'm not sure how you arrived at the $2M figure (even 36 months of dev
> time - 18 teams, 2 man-months/team - only add up to ~$400K, unless
> Glasdoor is waaay off on the salaries there [2]), but presumably going
> down on the list will also surface bugs and not only features, which
> will take less time to solve. Investing an additional 1% of the
> revenue into this seems reasonable to me.
>

I used $200K per year as a rough guesstimate for the total cost of one
man-year of development (which includes salary, taxes, benefits, office
space, event participation costs, salary for administration and management
which has to scale up with the number of developers...), which I think is
on the low end (for a mostly Bay Area based organization, anyway).
Also one month of a team's time is something like 5-6 months on average.

Anyway, the point is that we are talking about fairly large amounts of
donor money here, which should be spent responsibly. Taking community
feedback into account is important, but it's not the only thing that needs
to be taken into account (one should consider how much it impacts
contributors who are for some reason less likely to speak up; how much it
impacts readers; future maintenance costs; how well it matches current
capabilities; how well it fits the roadmap; how it compares in importance
to strategic priorities; etc). The wishlist (or voting in general) is not
an ideal tool for that.

IMO one opportunity for improvement there is having a list of bugs which
are relatively easy to fix (so people can work on them in their free time
or 10% time) but relatively important to (some group of) editors. There are
plenty of developers interested in working on tasks like that. But curating
it would not be a trivial effort. (I tried something similar with the
developer wishlist two years ago (except it wasn't limited to relatively
small issues, which I think is the main reason it wasn't very successful);
that took something like six weekends if I remember correctly. Granted, it
wasn't done in a particularly efficient manner, plus, some of the
infrastructure had to be invented.)

I did not claim (or asked) that it was. What I said is that it is an
> important part of the infrastructure and that it should be maintained
> properly.
>

Are there any components for which that is not true?

At a glance none if the 2019 wishlist requests involved UploadWizard, so it
does not seem like the most pressing concern on editors' mind. And
strategically, doing structured data storage first and fancy contribution
and display features afterwards is a whole lot easier than going the other
way (something we learned at our own expense with MediaViewer).


On Sat, Mar 16, 2019 at 8:23 AM Strainu  wrote:

> A large backlog by itself is not alarming. A growing one for
> components deployed to WMF sites is. It indicates insufficient
> attention is given to ongoing maintenance of projects after they are
> no longer "actively developed", which in turn creates resentment with
> the reporters.
>

It really doesn't. The backlog is the contact surface between stuff that
exists and stuff that doesn't; all the things we don't have but which seem
realistically within reach. As functionality expands, that surface expands
too. It is a normal process.

(We do have projects which are basically unmaintained. Those are not
typically the ones producing lots of new tasks though, since most relevant
issues have been filed already. And realistically the choice is between
having poorly maintained components and having far less components. Would
undeploying UploadWizard, for example, reduce resentment? I don't think so.)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Gerrit privilege policy

[Gergo Tisza]

On Wed, Mar 13, 2019 at 5:33 PM Tim Starling 
wrote:

> File a task in Phabricator under the Gerrit-Privilege-Requests
> project, recommending that the person be given access, giving your
> reasons and mentioning that you are the maintainer of the project in
> question. Wait for at least a week for comments. Then a Gerrit
> administrator should add the person and close the task.
>

Does the policy apply to Toolforge tools at all? The current text says "For
extensions (and other projects) not deployed to the Wikimedia cluster, the
code review policy is up to the maintainer or author of the extension." I'd
assume that by extension managing +2 permissions is also up to them
(although this is not explicitly stated, might be worth clarifying).
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] A potential new way to deal with spambots

[Gergo Tisza]

On Fri, Feb 8, 2019 at 6:20 PM Pine W  wrote:

> I don't know how practical it would be to implement an approach like this
> in the Wikiverse, and whether licensing proprietary technology would be
> required.
>

They are talking about Polyform [1], a reverse proxy that filters traffic
with a combination of browser fingerprinting, behavior analysis and proof
of work.
Proof of work is not really useful unless you have huge levels of bot
traffic from a single bot operator (also it means locking out users with no
Javascript); browser and behavior analysis very likely cannot be outsourced
to a third party for privacy reasons. Maybe we could do it ourselves
(although it would still bring up interesting questions privacy-wise) but
it would be a huge undertaking.


[1] https://www.kasada.io/product/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] What would you like to see in gerrit?

[Gergo Tisza]

Here's a quickie: Alt-Shift+F (or Alt-F or whatever your browser uses for
accesskeys) works in MediaWiki and Phabricator but not in Gerrit.

On Fri, Feb 8, 2019 at 11:35 AM Daniel Kinzler 
wrote:

> * clicking on the name of a repo in a change should take me to a place
> where i
> can browse that repo. It currently takes me to a list of tasks on that
> project,
> which is quite useless. Same for the target branch.
>

You can click on the commit ID (in the new UI it's next to where you select
the patchset version).
If you want the gerrit admin page of the repo (which is fortunately a lot
less often needed), you can switch back to old UI in the footer, and then
click on the cog icon after the project name, instead of the project name
itself.


> * git review: a nice shortcut for "rebase on change number ". Same as
> the
> rebase button in gerrit, but allowing me to resolve conflicts locally.
>

check out the commit to rebase on (git review -d if you really want to
rebase on another changese, although that's almost never needed), then git
review -x 
-X instead of -x if it's going to be a cherry-pick.

On Fri, Feb 8, 2019 at 1:07 PM Stas Malyshev 
wrote:

> One thing still missing for me is better ability to indicate which kind
> of attention the item needs from me.
>

Yeah, that view is not great. Besides review scores, it would be super nice
to be able to see in the list view the number of unresolved comments by me
and by the changeset owner.


> Couple of things for git review command too:
>

On that note (although I think that's a completely different universe,
maintained by the OpenStack community, not the Gerrit one), two small
annoyances I had with git-review:
- When it generates the "multiple changes, Y/N" list, it compares HEAD with
origin/master instead of the actual remote state of master. That can fail
in a number of ways (shows already merged patches, sometimes shows all the
changes which have been merged into core since I last did a git fetch), and
performance-wise it is entirely pointless all the commands which trigger it
involve heavy network traffic anyway.
- When submitting multiple changes from a new repo, it sets up the commit
hook for adding change IDs and adds a change ID to the last patch, but not
the previous ones, so the submit will fail.


> One useful command for me would be "check out a change and put it in a
> branch named after topic of that change, overriding it if it existed".
> This allows easy syncing of patches where more than one person
> contributes to them.
>

Isn't that what git review -d does? The branch name is less useful, but
usually the change id is at hand anyway.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] What would you like to see in gerrit?

[Gergo Tisza]

On Mon, Jan 28, 2019 at 4:26 PM Paladox via Wikitech-l <
wikitech-l@lists.wikimedia.org> wrote:

> Hi, what would you like to see in gerrit or improved?


Thanks for all your work on Gerrit! Some things that IMO would be useful:
* filtering out CI messages from Gerrit comments. This is something the
next version of Gerrit supports (the "Only comments" checkbox), but I
imagine something somewhere must be changed so that it can identify bots.
* making it clearer when CI fails. Currently it's hard to visually
differentiate failed tests from successful tests, and within failed test
logs the exact reason for failure from all the other logs. I guess this is
more of a Jenkins improvement...
* I really miss the Github feature of selecting a line range (as opposed to
a single line) from the gitiles plugin.
* again not really a Gerrit change but our mechanism for linking Gerrit
patches to related Phabricator tasks is rather crude. T95309 has some
related discussion but a nice solution would probably not include
comments/tags and use something more specialized like a custom Maniphest
field type instead. Or maybe a frontend hack like Pherrit [1].

[1]
https://chrome.google.com/webstore/detail/pherrit/polcefipbgcdfkpbmmbdjgkgfgjoebij
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Commons-l] Sunsetting VP8 version of WebM for video playback

[Gergo Tisza]

On Mon, Jan 28, 2019 at 12:22 PM Brion Vibber via Commons-l <
common...@lists.wikimedia.org> wrote:

> IE 11 users will receive low-resolution, slow JavaScript-based video
> playback instead. If you find this is troublesome, the recommended solution
> is to switch to any other browser.
>

Will they get a warning that they should try another browser? This seems
like a sensible limitation, as long as the user has a chance of figuring
out why they are being limited.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Gergo Tisza]

This discussion could do with less theatrics IMO.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Gergo Tisza]

On Fri, Jan 18, 2019 at 6:46 PM Chad  wrote:

> There _must_ be a way to disable this for certain files. Great examples:
>
> site.pp in puppet
> en.json language file in MW core
> CommonSettings or InitialiseSettings in wmf-config
>

There *is* a way to disable it. See plugins docs:
https://gerrit.wikimedia.org/r/plugins/reviewers-by-blame/Documentation/config.md

IMO the two blockers are having the plugin act under its own username and
providing some form of user optout. The other issues are annoying but can
be worked around (or opted out from in the worst case).
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Gergo Tisza]

On Thu, Jan 17, 2019 at 10:58 PM Giuseppe Lavagetto <
glavage...@wikimedia.org> wrote:

> While this gets improved, is there a way to opt-out from the feature
> individually or as a project?
>

Individually, no. On the project level, just set the max number of
reviewers added by the plugin to zero. (It seems that you need to use the
old Gerrit interface to see settings that come from plugins...)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Your Participation Requested - Interview about your local development environment

[Gergo Tisza]

On Tue, Jan 8, 2019 at 4:03 PM Jeena Huneidi  wrote:

> I did consider sending out another survey, but ended up choosing the
> interview method for this step because I’d like to get a deeper look into
> how people work  and the problems they face, which is difficult to glean
> from surveys.
>

To be clear I think a primary focus on interviews as a method that gives
deeper insights than other options makes perfect sense (and I really am
glad that they are happening :). I just think it might be nice to have
something to complement them.

I think it’s unlikely we’ll be able to fully capture every local
> development variation. Still, I’d like to be as inclusive as possible and
> enable anyone who wants to respond to do so. I can definitely consult with
> the team on sending out an additional survey tailored to local development.
> Did you have another method in mind?
>

One option is to just put up a wiki page with some instructions on what
kind of information and insights you are looking for, and then people can
go into whatever level of detail suits them. That requires very little
effort on your side and evaluation can happen collaboratively. (Also it
might be interesting information even apart from this project.) OTOH asking
people to share their answers publicly has its own barriers to inclusion.
The other option would be to do it as a free-form survey, but then you'd be
the only one able to process them, so depending on how many people actually
take the chance to respond, it might not be a realistic workload.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Need Help To Spell4Wiki - Wiktionary Audio App

[Gergo Tisza]

On Wed, Jan 9, 2019 at 10:41 AM Manimaran_K 
wrote:

>- When Uploading audio I got an error message* ->
> *{“error”:{“code”:”permissiondenied”,”info”:”The
>action you have requested is limited to users in one of the groups:
>[[Wikipedia:Autoconfirmed users|Autoconfirmed users]],
>[[Wikipedia:Administrators|Administrators]], [[Wikipedia:User access
>levels#Confirmed|Confirmed users]].”,”*”:”See
>https://en.wikipedia.org/w/api.phpfor API usage. Subscribe to the
>mediawiki-api-announce mailing list at <
>https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce;
>for notice of API deprecations and breaking
> changes.”},”servedby”:”mw1226″}
>

The error message should be self-explanatory. See the linked
https://en.wikipedia.org/wiki/Wikipedia:User_access_levels#Autoconfirmed_users
page for more details.
(You can send an errorformat=html parameter to the API to HTML error
messages, in case you are not familiar with wikitext.)

Given that you were talking about uploading to Commons, seems like you are
sending your requests to the wrong wiki. (Commons does not require users to
be autoconfirmed.)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Your Participation Requested - Interview about your local development environment

[Gergo Tisza]

Great to see this happen!

Given the large variance in people's local development environments, which
is surely impossible to fully capture via interviews, I'm wondering if
there will be some less time-intensive and more inclusive alternative way
for providing input?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Code Health Newsletter - Issue 2 Volume 1

[Gergo Tisza]

Will this also be published on-wiki? Reading it in plain text is kind of
painful.

On Mon, Dec 17, 2018 at 8:26 AM Jean-Rene Branaa 
wrote:

> Code Health Newsletter - Issue 2 Volume 1
>
>
> The Code Health[0a] newsletter is a publication provided by the Code
> Health Group[0b].  The Code Health Group serves as the hub for all
> Code Health topics and activities within the movement.  If you are
> aware or engaged in Code Health activities, we'd love to hear about
> it.
>
> The Code Health Newsletter is a new and hopefully valuable activity.
> If you have feedback about this issue or any past issues[0c], please
> don’t hesitate to share.  You can also submit content that you’d like
> to share through Phabricator (use the Code-Health-Newsletter project).
>
> # Code Health First Responders
>
> After last issue there was some concern voiced about calling this
> "First Responders" as the term is already used within the community.
> As a result, we've tweaked the name a bit to call it "Code Health
> First Responders".
>
> Please remember to share your experiences tackling your Code Health
> challenges.  Become or nominate a First Responder by submitting a task
> in Phabricator in the Code-Health-First-Responder project.
>
> More information available here[1].
>
>
> # Code Stewardship
>
> ## Quarterly Reviews
>
> This quarter's Code Stewardship review cycle is open and ending on
> January 16th.  At the moment we've got three items being reviewed:
> CodeReview extension, UserMerge extension, and Graphoid service.
>
> Join the discussion in Phabricator[2a] or on Wiki[2b].
>
> ## Latest Code Stewardship Coverage
>
>
> Core Components: 63%
>
> Extensions: 74%
>
> Services: 65%
>
>
> Note: these numbers are based on the Developers/Maintainers[2c] page.
>
>
> ## What it means to be a Code Steward
>
>
> Over the course of the last several months, the Foundation has been
> working to close the gap on the number of un/under-funded Components,
> Extensions, and Services deployed to the production environment.  Many
> have already stepped up to become Code Stewards, but outside of some
> aspirational goals about bug resolution rates, and code review
> responsiveness, there hasn't been much guidance. Over the course of
> the next few weeks, we will be attempting to bring more clarity to
> that.
>
>
>
> # Code Health by the Numbers
>
>
> The following are some stats regarding Code Health.  As we are early
> in defining/implementing our Code Health metrics, data is limited.
>
> See the Code Health Metrics project[3a] for more information.
>
> In future issues of the newsletter, we'll expand this section to
> include other metrics as well as trending information.
>
>
> ## Code Coverage
>
>
>   0-50% 51-90% 90-100%
>
>   ___
>
> Extensions  67 16  4
>
> Code Components 511 18
>
> Services Not Available Yet
>
>
> Note: As of 11/30/18[3b].
>
>
> ### Did you know?
>
>
> Coverme[3c], a tool written by legoktm, is a great tool to help
> prioritize areas for additional test coverage.  It helps by
> identifying the code that is most often executed in production and its
> current coverage level. Please note that currently these tools support
> PHP code bases. We are currently investigating what it would take to
> expand into other languages.
>
> Historical coverage charts can been seen here[3d].  These charts can
> be used to gauge the overall trend of test coverage for the 12 months.
> This is an important tool to use for measuring incremental progress
> over time.
>
>
> # Code Health Learning Circles
>
> If you have a topic that you'd like to share, but want a little help
> with organizing, please submit a Phabricator ticket to the
> Code-Health-Learning-Circles project.
>
> Are there some topics that you’d like to see some Learning Circles
> about?  Submit a Phabricator ticket to the
> Code-Health-Learning-Circles project and we’ll do what we can to make
> it happen.
>
> More information about Code Health Learning Circles available here[4].
>
>
> # Help Wanted
>
> ## Memory Profiling/Leak Troubleshooting
>
> Do you have experience/expertise in memory profiling?  We’re trying to
> chase down some memory leaks using Chromium’s profiling tools, but
> we’re running into challenges. Join the conversation in phabricator[5]
> and/or in the wikimedia-codehealth irc channel.
>
> # Code Health Group Activities
>
>
> Although the Code Health Group looks to act as a hub for all code
> health topics, the group also sponsors various broader reaching
> initiatives.
>
> ## Recent Activities
>
> ### Code Health Metrics
>
> The Code Health Metrics Working Group has been busy over the last
> couple of months.  The groups primary focus has been to evaluate some
> of the code metrics frameworks.  These tools provide us with code
> analysis, reporting, and a framework to 

Re: [Wikitech-l] non-obvious uses of in your language

[Gergo Tisza]

On Thu, Oct 4, 2018 at 2:25 PM Daniel Kinzler 
wrote:

> Or how about {{}} for "this is a syntactic element, but it does nothing"?


Just make a template with a nice name ( {{~}} or something) and put the
nowiki in that.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Collecting UI feedback for PolyGerrit - Gerrit

[Gergo Tisza]

On Thu, Oct 4, 2018 at 11:35 AM Paladox  wrote:

> What do you mean by "URLs are hard to get right due to arcane escaping
> rules. I have been completely unable to make search shortcuts that work in
> both the old and new UI."? Upstream have fixed some urls that were breaking
> when switching to the old ui. These fixes are on the master branch.
>

Specifically, saved search queries involving / do not work for me in
Polygerrit (even when I don't care about old UI compatibility). It's poor
user experience in the first place that you need to enter URLs and not
search queries (with + instead of space etc), but slashes seem especially
hard to get right.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Collecting UI feedback for PolyGerrit - Gerrit

[Gergo Tisza]

Thanks for your work on Gerrit, Paladox!

The Polygerrit upgrade looks great; the thread view is especially amazing.
(If you are not familiar with it, check this patch [1] and click "Comment
Threads" near the bottom of the screen.) I mostly have behavior issues (on
gerrit.wikimedia.org; I haven't tested whether they affect 2.16):
* URLs are hard to get right due to arcane escaping rules. I have been
completely unable to make search shortcuts that work in both the old and
new UI.
* Almost impossible to find clone URLs. (T206049, but also in the old UI I
could click through from the patch to the to the repo admin screen and
that's also impossible to find now. I see it's slightly easier in 2.16 but
still annoying.)
* For me the most unintuitive part is the relation chain, especially when
it is nonlinear. A graph view would be handy there, and also making it more
explicit what is the parent and what is the child.
* Probably not a UI thing, but it's very annoying that patch uploaders
cannot edit the description of their own patch (the gerrit patchset
description, not the commit summary).

On the plus side,
* Avatars are really nice and make the whole experience more human. (They
are not enabled on the Wikimedia Gerrit yet, right?)
* At some point search autocomplete switched from prefix-autocompletion to
substring-autocompletion (e.g. for project names). That sounds like a small
thing but it really made life a lot more convenient.

[1] https://gerrit-review.googlesource.com/c/gerrit/+/196470
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] problematic use of "Declined" in Phabricator

[Gergo Tisza]

On Tue, Oct 2, 2018 at 9:57 AM Brion Vibber  wrote:

> *nods* I think the root problem is that the phabricator task system does
> double duty as both an *issue reporting system* for users and a *task
> tracker* for devs.
>

IMO that kind of double duty is normal for all software development project
management systems (and having to track bugs in two separate systems was in
fact rather painful in the dark ages when we had Bugzilla + some
team-specific external task management system). Rather, the problem is that
it's a task management system used by many different groups (including
volunteers) with overlapping scopes. Prioritization decisions are specific
to a team (or an organization at best) while Phabricator task status and
priority are global settings. This problem comes up in non-volunteer
contexts as well, when a task is relevant to two teams and a high priority
for one but low / zero for the other.

So IMO the sanest approach is for all teams to come up with ways to mark
prioritization that are local to their Phabricator projects (which
typically means using a team workboard for prioritization and having some
kind of "we don't intend to work on this" column).

Setting tasks to stalled when no one is planning to work on them would be a
reasonable practice if we decide to consistently use the stalled status
that way, but today it's used as "blocked" instead.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Signature change without deprecation: ContentHandler::getUndoContent

[Gergo Tisza]

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/447099 changes the
signature of ContentHandler::getUndoContent from  to 
(with Revision soft-deprecated). This is a breaking change as
ContentHandler is meant to be subclassed, and any subclass that typehints
Revision will raise a warning at compile-time, and a fatal when called with
Content.

Searching Gerrit, Github and Google only yielded a single instance of a
subclass overriding the method (which is being fixed) and providing
backwards compatibility in a robust way does not seem feasible, so we are
changing the method signature without a deprecation period (in the sense of
subclass compatibility; with respect to calling the method with Revision,
we follow the normal deprecation process).

For more information on the MediaWiki deprecation policy see
https://www.mediawiki.org/wiki/Deprecation_policy#Removal_without_deprecation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Making two factor auth less annoying

[Gergo Tisza]

On Sun, Aug 12, 2018 at 6:47 PM Petr Bena  wrote:

> With two factor authentication it doesn't seem to be possible to make
> session persistent


Two-factor authentication does not affect how the session works. If you
check "Remember me", the login will last for 180 days, whether you use
two-factor authentication or not.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] My Phabricator account has been disabled

[Gergo Tisza]

On Thu, Aug 9, 2018 at 7:41 AM Stas Malyshev 
wrote:

> 1. The account was disabled without any indication (except the email to
> the person owning it, which is also rather easy to miss - not the
> admin's fault, but read on) of what and why happened, as far as I could
> see. Note that Phabricator is a collaborative space, and disabling an
> account may influence everybody who may have been working with the
> person, and even everybody that working on a ticket that this person
> commented once. If they submitted a bug and I want to verify with them
> and the account is disabled - what do I do?
> People are left guessing - did something happen? Did his user leave the
> project? Was it something they said? Something I said? Some bug? Admin
> action? What is going on? There's no explanation, there's no permanent
> public record, and no way to figure out what it is.
>
> What I would propose to improve this is on each such action, to have
> permanent public record, in a known place, that specifies:
> a. What action it was (ban, temporary ban - with duration, etc.)
> b. Who decided on that action and who implemented it, the latter - to be
> sure if somebody thinks it's a bug or mistake, they can ask "did you
> really mean to ban X" instead of being in unpleasant and potentially
> embarrassing position of trying to guess what happened with no information.
> c. Why this action was taken - if sensitive details involved, omitting
> them, but providing enough context to understand what happened, e.g.
> "Banned X for repeated comments in conflict with CoC, which we had to
> delete, e.g. [link], [link] and [link]" or "Permanently banned Y for
> conduct unwelcome in Wikimedia spaces", if revealing any more details
> would hurt people.
>

That proposed solution does not solve the problem you are proposing it for.
If a person I'm interacting with on Phabricator or Gerrit disappears, I'm
not going to look through CoC ban records, even if I know such a thing
exists (which most people wouldn't, even if it's well-publicized). I'll
just assume they are busy or sick or something.

If we really feel people trying to interact with a banned users should find
out the user is banned, it could be displayed in their Phabricator profile
or in the Phabricator calendar (that results in a little notice icon
everywhere the username is used), although I'd hope the banned person can
opt out of that happening as it feels somewhat stigmatizing.


> 2. There seems to be no clearly defined venue to discuss and form
> consensus about such actions. As it must be clear now, such venue is
> required, and if it is not provided, the first venue that looks suitable
> for it will be roped in. To much annoyance of the people that wanted to
> use that venue for other things.
>

I doubt that would have much effect - the person who is objecting about a
CoC action benefits from using the forum that grabs the most attention,
even if there's a more appropriate one. People who are considerate enough
not to do that are typically not the ones who end up getting banned.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] My Phabricator account has been disabled

[Gergo Tisza]

Some thoughts:

- First of all, I'd like to thank the Code of Conduct committee for doing
their job. It's a hard job where they need to make difficult judgement
calls, and are criticized harshly when they make a bad judgement and
ignored at best when they make a good one (although more likely they still
get criticized harshly). It's also a necessary job, so we should be glad
that someone is willing to do it (even if imperfectly, as human beings are
bound to). It's not unlike the role of Wikipedia administrators in that
regard.

- I imagine the CoC committee sees the public announcing of bans as a kind
of public shaming that the banned people might not want and do not deserve.
I appreciate the intent but I think 99% of the time the banned person will
just use the opportunity to make the announcement themselves, frame the
issue to their benefit and maximize drama. (The kind of person who would be
unwilling to do that typically does not give cause for being banned in the
first place.) So it would be better if the committee made the announcement
themselves (maybe not as a rule, but as a default).

- Some people can tell when the use of the word "fuck" is hostile to a
fellow contributor, some people can't (and some can tell very precisely and
pretend not to, but let's not go there). If you are the second type of
person, just don't use it, it's that easy. It's not like you are somehow
handicapped by not being able to swear in public.

- I find all the "why did he get banned over a single WTF comment?"
questions a bit disingenuous. MZMcBride has a long history of hostility and
of trying to apply meanness as a social lever to influence prioritization
decisions. Those who have been around long in Wikimedia technical spaces
are well aware of that, and most people asking these faux-naive questions
*have* been around for long. Please don't set strawmans. If you want to
argue that a pattern of lots and lots of "wtf comments" spanning multiple
years is not something that should ever result in a ban, argue for that. If
you really think the notification about a ban should contain the person's
entire history of abuse, say that. But let's treat this discussion as a
serious thing.

- Also, do consider that MZMcBride had the option to reach out to the CoC
committee and ask their help in understanding exactly which of his comments
were problematic and in what way, and how they could be reframed in a
constructive way. He had the same option the previous time when the
committee merely warned him for a similar infraction. That he chose not to
is hardly the committee's fault.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] How to make oauth authentication with wikipedia?

[Gergo Tisza]

On Mon, Aug 6, 2018 at 12:40 AM rupert THURNER 
wrote:

> interesting, never thought about it. i found an entry on stackexchange
> confirming what you said. additionally it states that oauth is not for
> authenticaiton. oauth's purpose is to access users resources from some
> resource provider, while openid_connect should be used to authenticate.
> does openid_connect work with wikipedia and is it the best option
> currently?
>

OpenID Connect uses OAuth 2 and Wikipedia only supports OAuth 1 currently.
We have a custom authentication endpoint that works in a similar way to
OpenID Connect:
https://www.mediawiki.org/wiki/OAuth/For_Developers#Identifying_the_user
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Documentation for API query/revisions needs an update

[Gergo Tisza]

On Thu, Aug 2, 2018 at 11:22 PM Nicolas Vervelle 
wrote:

> This rvslots is not documented on API:Revisions and I don't find an email
> mentionning a compatibility problem on this subject.
>
> I tried the API Sandbox, but the documentation for rvslots is cryptic for
> me : " Which revision slots to return data for, when slot-related
> properties are included in rvprops. If omitted, data from the main slot
> will be returned in a backwards-compatible format."
>
> Any understandable explanation on this parameter and what value should I
> put, and what difference should I expect in the result ?
>

Oops, sorry. I will fix the docs and send an announcement tomorrow. This is
for new functionality that is being added to MediaWiki incrementally as
part of the Multi-Content Revisions project [1].

You can safely ignore the warning for now. You can specify rvslot=main,
which will give you the same data, but in a slightly different format (and
some deprecated options will trigger an error). At this point in time, no
other slots are supported. Wikimedia Commons will soon have another slot
available, for structured media information - see the Structured Data on
Commons project [2] for details.

[1]
https://www.mediawiki.org/wiki/Requests_for_comment/Multi-Content_Revisions
[2] https://commons.wikimedia.org/wiki/Commons:Structured_data
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Phabricator monthly statistics - 2018-07

[Gergo Tisza]

On Wed, Aug 1, 2018 at 10:42 PM Stas Malyshev 
wrote:

> Yes, it looks more the case of "we thought it's a high priority task but
> turned out it's not" rather than "we take a long time to do high
> priority tasks". I.e. maybe we need to have some rules around removing
> tasks from "High" if it's clear we're not doing it anytime soon.
>

More generally, if 10% of your high priority tasks take a year to finish,
and 90% take a day, the median open task age will be around half a year
(even though the median time to finish a task is a day). It's not really a
useful measure.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Phabricator monthly statistics - 2018-07

[Gergo Tisza]

On Wed, Aug 1, 2018 at 8:14 PM Pine W  wrote:

> Thanks for the updated statistics. I wonder, was there ever an agreement on
> how to standardize the definitions for priorities, such as "unbreak now"
> and "high"? The reason that I ask is that a median age of 738 days for
> "high" priority tasks seems very long. I would hope that we would not take
> two years to complete "high" priority tasks.
>

The median age of open priority X tasks is not the same as the median time
it takes to complete priority X tasks.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] How to make oauth authentication with wikipedia?

[Gergo Tisza]

On Sat, Jul 28, 2018 at 10:37 AM Sam Wilson  wrote:

> I've been wondering about how this sort of thing would work as well, in
> the context of a Piwigo plugin that I've been working on for easily
> uploading photos to Commons (or any MediaWiki site). It seems the
> easiest way to do it is to get users to register their own personal
> (owner-only) OAuth consumer (which I think never requires approval?) and
> then have them enter the consumer token in the app.


I'd say that's the hardest (although it could be made more user-friendly
with some effort).
See https://phabricator.wikimedia.org/T179519#3727899 for other options.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Help remove unused wmf-config code

[Gergo Tisza]

On Sun, Jul 8, 2018 at 5:41 AM Stas Malyshev 
wrote:

> > Open for review:
> >
> https://gerrit.wikimedia.org/r/#/q/project:operations/mediawiki-config+topic:cleanup+is:open
>
> This one produces 404.
>

Unfortunately search URLs are not compatible between the old and new Gerrit
interface. The Polygerrit equivalent for this one is
https://gerrit.wikimedia.org/r/q/project:operations%252Fmediawiki-config+topic:cleanup+is:open
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Please comment on the draft consultation for splitting the admin role

[Gergo Tisza]

On Mon, Jun 11, 2018 at 6:02 PM Steven Walling 
wrote:

> I'm definitely supportive of greater security for sitewide JS/CSS, but
> Bart's proposal is an interesting one. (Sorry for top posting, on mobile)
>
> What if we required review of edits to JS/CSS in the MediaWiki namespace
> (not in other namespaces), ala pending changes or something similar? We
> require code review in Gerrit, so why not sitewide code in the wiki?
>
> I propose this because if we split code editing rights into a separate
> userright, this entails increased process bloat for managing who and who
> doesn't get the right, the criteria for deciding that, and so on. Requiring
> code review would allow for more flexibility while increasing security. It
> would require less process bloat too because the community already has
> mechanisms for requesting edits be confirmed via talk pages and such.
>

That's a good way to improve security, but orthogonal to separating
permissions (it would probably mean that an attacker would have to find two
vulnerable accounts, while this change will reduce the pool of accounts an
attacker could target; both make attacks harder, in different ways). No
reason not to do both, but separating permissions is (relatively) easy and
a review system is more like something on the scale of FlaggedRevs.

If you are interested, https://phabricator.wikimedia.org/T71445 has plenty
of discussion on code review for gadgets;
https://phabricator.wikimedia.org/T187749 is a variant of it I'm working on.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Please comment on the draft consultation for splitting the admin role

[Gergo Tisza]

On Mon, Jun 11, 2018 at 3:28 PM Petr Bena  wrote:

> Is there any historical evidence that sysops being able to edit JS /
> CSS caused some serious issues? Your point that "most of
> administrators don't understand JS / CSS" is kind of moot. They are
> usually trustworth and intelligent people. They don't mess up with
> something they don't understand and therefore it makes little sense to
> restrict them from being able to do that.
>

The primary concern here is someone taking over the account by password
guessing, social engineering, phishing, exploiting some unfixed MediaWiki
vulnerability etc. The secondary concern is admins becoming malicious or
doing something stupid as a way of ragequitting, which is rare but does
happen (for example, not so long ago, someone thought it would be a good
idea to make money by installing a cryptocoin miner on Wikipedia). Admins
making a mistake and breaking the site also happens occasionally, but
that's not a security problem so it's a pretty minor issue in comparison.

I understand your points, but do we really need it? Is it going to
> improve anything?


It reduces the attack surface. Less people with access means less
vulnerable passwords, less people whose system has been infected with the
latest computer virus etc.
Also there are things we might require JS editors to do which might be
inconvenient to some people (e.g. making two-factor authentication
required) so it's good to reduce the number of people who have to be
exposed to that.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can/should my extensions be deleted from the Wikimedia Git repository?

[Gergo Tisza]

On Fri, Jun 8, 2018 at 3:44 PM Yaron Koren  wrote:

> I suppose that one solution which hasn't been discussed yet is to change
> the wording of that file so that it says something more defensible, like
> "This extension is hosted on facilities governed by the Code of Conduct",
> or that kind of thing - that would at least remove the pragmatic objection
> that I (and some others in this thread) have raised.
>

Thanks for the constructive proposal, Yaron. I agree this is an accurate
description of what the code of conduct says now about scope.

I still think limiting scope like that is problematic and in the unlikely
case that someone does abuse or harass community members outside Wikimedia
platforms while simultaneously making use of those platforms, I believe the
CoC committee would leverage that to deter them (threaten to ban or fork if
it comes to that) - that seems like the only morally tenable option. So I
guess the best way to resolve the issue is to make a CoC amendment proposal.

It still leaves open the question of whether the file should be made
> mandatory, and if so, what the mechanism should be to determine that.
>

A CoC committee decision, presumably? They are probably in the best
position to tell whether it would meaningfully help their work or not.

That said, we still haven't solved adding the file to new repos
automatically, or added it to the repos created since last summer, or
determined which non-extension/skin repos makes it sense to add to, all of
which have much more impact than anything that could happen with the
handful of repos where it is actively opposed. So it does not make sense to
invest a lot of energy into this right now, IMO.

As I wrote briefly before, I just don't think the file
> is making an accurate statement, given that it implies that *all*
> development of the extension is governed by the CoC, which is not the case.


I'd still like the understand what the assumed harm is. Is this strictly a
moral issue, where you want to avoid giving misleading information, but
otherwise that information would be harmless? Or a liability issue, where
your clients think that working on / using a CoC-covered extension makes it
more likely that they get sued or publicly attacked? Or do you think you
might work with clients who might be deterred because they do development
in ways that violate the CoC, and would be unwilling to change that? Or
some clients might boycott such extensions for political reasons?


On Fri, Jun 8, 2018 at 8:23 PM Greg Rundlett (freephile) 
wrote:

> I can also (as a consultant) see
> how written policies which my clients see in my code could be construed as
> a possible LIABILITY or RISK on their  part. They'll either want me to
> carry more indemnity insurance, or even be disinclined to do business with
> me. Not because they don't abide by the code of conduct, but because
> there's an explicit notice of some obligation that creates liability.


Thanks for being specific about how the file is a problem for you. It is
important for the health of the MediaWiki ecosystem that we make commercial
MediaWiki development as frictionless as possible and don't create policies
that place an undue burden on it.
That said, code of conduct notices are already abundant in opensource
software; we are not doing some kind of bold new experiment, just following
the standard. Was there a chilling effect for projects that added such a
file? Are you aware of consultants running into problems over that?
How do you handle this issue in your own work in non-MediaWiki code? Do
you, for example, choose between Javascript frameworks or PHP libraries you
include in your extensions based on whether they include a code of conduct?


On Sat, Jun 9, 2018 at 3:28 AM C. Scott Ananian 
wrote:

> My personal opinion is (a) it should be mandatory, but the
> contents not strictly proscribed -- in the same way that github
> loosely-requires an open source license statement in its public repos (ie,
> I think it's in the terms of service but not enforced by code), and (b) the
> proper mechanism is probably techcomm/archcomm.


On reflection, I think trying to involve TechCom would be a bad idea. In a
contentious issue like this, any decision (or even the refusal to make one)
would probably result in a loss of social capital, which is better spent on
getting people on board with transforming MediaWiki architecture. The CoC
committee on the other hand was selected and trained for expertise in
specifically these kinds of social issues, and they don't have much
standing to lose in the eyes of people who are dubious about the CoC anyway.


On Fri, Jun 8, 2018 at 6:13 PM Brian Wolff  wrote:

> * Generally speaking, its usually considered in poorform to have an
> argument about something, lose the argument (or at least not win it), wait
> a year until people forget about it, and then try and do the exact same
> thing.
>

While I disagree that this would be an accurate description of what
happened, in 

Re: [Wikitech-l] Can/should my extensions be deleted from the Wikimedia Git repository?

[Gergo Tisza]

On Fri, Jun 8, 2018 at 8:18 AM Daniel Zahn  wrote:

> But we should not make it mandatory to keep a copy of this file in each and
> every repo.
>

I'd argue we should, but let me say first that if we do make it mandatory,
that should happen via some mechanism that's appropriate for making policy
(RfC, TechCom decree, CoC committee decision, whatever) and not by making
threats in a gerrit comment thread. I don't doubt that everyone involved
had good intentions but the way the patch was merged was unfortunate IMO.

That said:
* The code of conduct is a tool to make contributors feel welcome. For some
of us being welcomed when we contribute our time and knowledge to an
opensource project is so natural that the effort might seem weird. Others
(especially those belonging to a historically oppressed or heavily
stereotyped group) have different experiences and might have become more
cautious about putting time and mental and emotional effort into getting
involved with a project, when such involvement in the past often resulted
in them being criticized or insulted for reasons having nothing to do with
their contributions. We should reach out to those people and tell them that
we care, that the MediaWiki/Wikimedia developer community is a respectful
space and they should feel safe to invest their time energy.
* Site footers are not a good place for that message, because people only
see them when they are fairly involved already. (Realistically, not even
then. Do you use Github? Have you ever read Github's terms of servce? I
didn't think so.) People interact with the files first, so that's the most
obvious place to put such a message. Moreover, CODE_OF_CONDUCT.md is now
the standard way of doing that notice, thanks to Github's efforts to
promote it, so that's where people will look. If we want to signal
something very conspicuously, and there is a standard way of signaling it,
it would be dumb not to make use of that.
* Wikimedia technical spaces are the ones where we can directly enforce the
code of conduct. I don't think this means it ceases to exist at the borders
of those spaces. I stand by the thought experiment I gave when this topic
was discussed last year in the task Yaron linked: "Imagine a contributor
who is very misogynist but also very respectful of social contracts. This
person uses gerrit.wikimedia.org to host their code but runs their own
issue tracker. Female developers get mocked and insulted when they file
bugs, but their code submissions are treated politely because the gerrit
ToU demands that. It seems ridiculous to me to suggest that the Wikimedia
technical community should accept such a situation and not do anything
against it, on the grounds that the abuse happens outside our technical
spaces."
* There can be all kinds of reasons why the CoC file is not appropriate for
some repository (which is why it wasn't added to all repositories, just
MediaWiki and its extensions). But if we let people remove it for the sole
reason that they don't like the code of conduct, what does it say about out
commitment to enforce it? It sends the message "we have a code of conduct,
and we'll use it to protect you, except when the maintainer of some
repository disagrees". I do not think we want that.

I would be more sympathetic if I saw how having the CoC file there might
harm or even just inconvenience maintainers, but removing it just to make
some kind of philosophical point is unhelpful. Yaron, I respect you a lot
as a developer, I think your involvement in the CoC discussions was always
constructive despite clearly not liking the whole idea, and I'm sure you
wouldn't act (inside or outside Wikimedia technical spaces) in ways
inconsistent with the spirit of the code of conduct anyway, but this was a
silly fight to pick and I hope you'll reconsider (or if you have pragmatic
reasons for not wanting the file, you'll explain those).
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Changes to Special:OAuth URL in some languages

[Gergo Tisza]

A few languages (ar, arz, ko, lrc, ur) have localized the special page name
"OAuth", which means that in these languages requests to Special:OAuth
result in redirects. This breaks OAuth-signed requests to
Special:OAuth/identify, unless they use the localized name, and in general
developers shouldn't be expected to be aware of that.

To reduce confusion, starting next week special page name localization will
be disabled for Special:OAuth when the request is OAuth-signed, which means
that sending requests to Special:OAuth/identify will always work, and
sending requests to localized versions (such as 특수:MWO인증/identify on
kowiki) will stop working. If you have been doing the latter, you need to
update your code.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] Announcing the Wikimedia Foundation's Technical Engagement team

[Gergo Tisza]

That is great news, congrats and thanks to all involved! Support of
Wikimedia/MediaWiki developers and software reusers has gone through a
quantum leap in the last year or so, and this is another solid step towards
creating a more healthy FLOSS ecosystem.

I'd also like to echo what Trey said: while some of the largest problems
with our open source ecosystem (such as documentation and the lack of
public roadmaps/guidace) have been settled or are being settled
reassuringly, code review remains a pain point. And while that's something
that will need the support of all Technology/Audiences teams, there is
still need for a team that can push for that; I hope Technical Engagement
will be empowered to do so.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit newcomer bot

[Gergo Tisza]

Awesome, thanks all for working on this!

Would it be possible to also support something like ownerin:volunteers?

On Fri, May 4, 2018 at 8:45 PM Srishti Sethi  wrote:

> *Hello all,A quick update related to Gerrit -- you will notice a small
> change on patches uploaded by new developers. There is a bot now which is
> adding a reviewer (as "Welcome, new contributor!") and a welcome message in
> a comment to a patch submitted by a new developer. You would also be able
> to query patches of new developers by typing in the search term: `ownerin:
> newcomers` (only applicable to new patches).Learn more about the bot, and
> file an issue here: https://github.com/srish/gerrit-newcomer-bot
> OR comment on the related
> Phab task: https://phabricator.wikimedia.org/T192046
> Thanks,Srishti *
>
> --
> Srishti Sethi
> Developer Advocate
> Technical Collaboration team
> Wikimedia Foundation
>
> https://www.mediawiki.org/wiki/User:SSethi_(WMF)
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 2018-05-02 Scrum of Scrums meeting notes

[Gergo Tisza]

On Wed, May 2, 2018 at 8:24 PM, Kunal Mehta  wrote:

> On 05/02/2018 11:02 AM, Grace Gellerman wrote:
> > * Services: If someone maintains/knows JobQueue Job code that posts
> > jobs cross-wiki, please tell us.
>
> MassMessage and GlobalUserPage both post jobs across wikis and rely on
> that functionality. Are there specific questions related to cross-wiki
> jobs?
>

The context is https://phabricator.wikimedia.org/T193471
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki and OpenID Connect

[Gergo Tisza]

On Fri, May 4, 2018 at 10:21 PM Adam Sobieski 
wrote:

> In the scenario, after choosing to verify their name on their Wikipedia
> account, a user logs onto Wikipedia and uses OpenID Connect to link their
> Wikipedia account to multiple verified accounts, for example their Facebook
> and LinkedIn accounts. At the end of the process, we can envision the user
> obtaining a checkmark next to their full name on Wikipedia, their real name
> and a verification icon appearing next to their edits and on their user
> page. There might even be, per user settings, hyperlinks to their Facebook
> and LinkedIn pages on their Wikipedia user page. With such features, we can
> envision allowing groups of users or admins to determine that certain
> articles require a verified account to edit.
>

There has been a fair amount of discussion (mainly after the Essjay affair)
on verified expert accounts on English Wikipedia, but ultimately the idea
has been rejected. You can read about it at [1].
As others have noted, account linking is a fairly minor convenience for
having verified real-life identities; if there was any intent to make that
happen it would have happened regardless of software support.

Having non-public account linking (as an antispam measure that has better
user experience than captchas) is a more feasible idea IMO; I wrote some
thoughts on that at [2].

If you just want public links to verified accounts in MediaWiki (as opposed
to Wikipedia / other Wikimedia projects), there is nothing stopping you;
you should propose a patch to the OpenID Connect maintainer (all it takes
is probably just adding a hook such as GetPreferences to display the
information at the appropriate place) or write your own extension.

[1] https://en.wikipedia.org/wiki/Wikipedia:There_is_no_credential_policy
[2] https://www.mediawiki.org/wiki/User:Tgr_(WMF)/external_login
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Ops] Changes to SWAT deployment policies, effective Monday April 30th

[Gergo Tisza]

On Sat, Apr 28, 2018 at 2:19 AM, Tyler Cipriani 
wrote:

> Looking at this info maybe 6 is the magic number?
>

Other options would be to have more windows (an EU morning SWAT maybe?),
and/or make it less of an expectation to have your patches deployed in the
window you scheduled them for (e.g. not starting deploying new patches
after :45; anything that overflows just gets pushed to next day).

Another thing that could be reconsidered for more even use of SWAT windows
is the requirement that the patch owner has to be present; we could just
request a test plan in the commit summary instead for low-risk patches.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Ops] Changes to SWAT deployment policies, effective Monday April 30th

[Gergo Tisza]

On Fri, Apr 27, 2018 at 7:05 PM, Niharika Kohli 
wrote:

> Also, I think dropping the limit to 4 patches per window is extreme,
> especially if we are asking people to start splitting their patches now.
> Very often we can +2 multiple patches in one go if they don't affect each
> other, or sync out changes together if they happen to the same file. I've
> deployed 8 patches in a window often, with people asking if they can add
> more yet. Due to timezone limitations, most people can only attend one of
> the SWAT windows and if they can't get it out in that window, they have to
> wait a whole day or more to get it out.
>

FWIW, here are some stats on the patch counts for the first three months of
2018 (might contain errors, tried not to spend too much time on it):

EU mid: 8, 6, 2, 10, 1, 6, 1, 2, 1, 2, 2, 6, 2, 9, 6, 10, 2, 1, 1, 8, 7, 5,
5, 5, 2, 7, 6, 8, 4, 7, 4, 4, 4, 1, 1, 4, 3, 3, 2, 4, 4, 5, 5, 1
(average: 4.25, max of 2-week rolling average: 5.7)
Morning: 7, 1, 1, 5, 1, 3, 4, 1, 6, 3, 4, 3, 3, 5, 6, 4, 3, 5, 8, 4, 5, 4,
3, 0, 3, 1, 5, 9, 2, 1, 3
(average: 3.6, max of 2-week rolling average: 5)
Evening: 8, 1, 1, 1, 1, 3, 3, 2, 1, 3, 4, 2, 1, 1, 2, 1, 1, 5, 1, 6, 1, 3,
3, 1, 2, 3, 1, 0, 9, 10, 5, 4, 1, 6, 2, 1, 2, 4, 3
(average: 2.8, max of 2-week rolling average: 4.75)

ie. if the new policy was introduced at the start of the year, it would
have caused at least a two-week delay in all three SWAT windows at one
point at least, and it would have caused an ever-growing backlog of patches
for EU mid-day.
(That's without taking the split patch requirement into account, it's hard
to tell how many patches that would have affected.)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] File upload file in HTMLForm with ooui

[Gergo Tisza]

On Mon, Apr 16, 2018 at 12:40 AM, Brian Wolff  wrote:

> So basically no, its not possible currently without implementing your own
> HTMLFormField subclass.


The task for that is https://phabricator.wikimedia.org/T170263
Should be pretty easy, the OOUI widget exists already.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Dead Links

[Gergo Tisza]

On Mon, Apr 2, 2018 at 4:52 PM, Chad  wrote:

> I removed most of the information about Gmane.


We should provide something else that remotely resembles the twenty-first
century, though. GT (ex gossamer-threads) probably?

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

Re: [Wikitech-l] What ways are there to include user-edited JavaScript in a wiki page? (threat model: crypto miners)

[Gergo Tisza]

On Wed, Mar 14, 2018 at 9:14 AM, Jon Robson  wrote:

> It has always made me a little uneasy that there are wiki pages where
> JavaScript could potentially be injected into my page without my approval.
> To be honest if I had the option I would disable all site and user scripts
> for my account.
>

It's not particularly hard to with a browser extension, you just need to
edit ResourceLoader (load.php) URLs and remove the 'user', 'site',
'ext.gadget.*' modules.

Has this sort of thing happened before?
>

Outside Wikimedia, plenty. http://www.bbc.com/news/technology-43025788 was
one of the more high-profile examples.

On Wikimedia wikis, well-intentioned but misguided uses of external scripts
are not uncommon (back when I was a fairly new admin on the Hungarian
Wikipedia, we included an AWStats counter in the page footer under an, uh,
fairly liberal interpretation of the terms of use... the developers were
not amused). As far as I am aware there was no malicious one.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: ¿Qué te hace feliz esta semana? / What's making you happy this week? (Week of 11 March 2018)

[Gergo Tisza]

On Sat, Mar 10, 2018 at 9:21 PM, Pine W  wrote:

> 2. The opt-in "pingback" telemetry from MediaWiki installations, which is
> available since March 2017, suggests that there are more than 40,000 unique
> installations.
>

Note that pingback only collects data from wikis which were set up with
1.28 or a later version of the installer (and opted in) or where the system
administrator manually enabld it; and that it cannot differentiate between
"real" wikis and throwaway installations (e.g. on developer machines). So
the real number can easily be a lot more or a lot less than that.
(WikiApiary tracks about 20,000 MediaWiki wikis, so that's a reasonable
lower estimate.)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Any way to find the used template from the template itself?

[Gergo Tisza]

On Thu, Mar 1, 2018 at 2:52 PM, Strainu  wrote:

> Say we have an article which includes {{Infobox A}}, which redirects
> to {{Infobox B}}, which in turn transcludes {{Infobox}}, which is
> implemented using [[Module:Infobox]]. Is there a way to know from the
> module (or the {{Infobox}} template) which infobox was actually used
> in the article?
>

Not unless you pass it along as a parameter.
mw.getCurrentFrame().getParent() only goes one level up (so you can tell
Module:Infobox was called from {{Infobox}} but not beyond that).
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] What's making you happy this week? (Week of 11 February 2018)

[Gergo Tisza]

The new  gerrit skin, which is kind of meh on desktop but responsive and
thus actually useful on mobile. (And it's enabled with a cookie so I can
use it on mobile devices and keep the old look on desktop.) Also the new
non-Phabricator-based repo browser linked from it, which has a much more
logical UI and it's crazy fast. Clearly a lot of love went into the
upgrade, thanks Chad for working on it!
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Security question re password resets and Spectre

[Gergo Tisza]

On Thu, Jan 4, 2018 at 9:29 AM, Denny Vrandečić  wrote:

> I often get emails that someone is trying to get into my accounts. I guess
> there are just some trolls, trying to login into my Wikipedia account. So
> far, these have been unsuccessful.
>
> Now I got an email that someone asked for a temporary password for my
> account.
>

User:Denny is generic enough that people might be using it on other sites
and getting confused about their Wikimedia user name. I wouldn't be too
worried.
(That, or they already hacked your email account and are now using that to
take over your wiki account :)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Setting logged in user context on unit tests

[Gergo Tisza]

On Mon, Dec 25, 2017 at 12:00 PM, Tony Thomas <01tonytho...@gmail.com>
wrote:

> Came across a situation similar to [1] where I had to call submit()
> function of a FormSpecialPage during a unit test. We have something going
> on in the background, and $this->getUser() needs to return a valid user.
>
> Is there a way to mimic this context inside the unit test, so that I can
> manually set a $user in the unit test, and this would be used while
> performing inner operations ?
>

No need to mimic, you can just inject it (as long as the special page
correctly uses $this->getUser() & co instead of using globals, which is
usually not a problem with special pages) :

$specialPage = $this->newSpecialPage();
$context = new DerivativeContext( RequestContext::getMain() );
$context->setUser( $user );
$context->setRequest( ... );
$specialPage->setContext( $context );
$res = $specialPage->onSubmit( $input );
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Sunsetting Trending Edits Service before the holiday

[Gergo Tisza]

On Tue, Dec 12, 2017 at 12:12 PM, Jon Robson  wrote:

> This is a little inferior to the production version as it is unable to use
> production kafka and if it has any outages it will lose data.
>

Hopefully that gets fixed soon, Cloud VPS / Toolforge is the foundation for
out volunteer tool developer community who really shouldn't be treated as
second-class citizens.

Other than that, moving to the Cloud is not a bad thing for an experimental
project IMO. It makes it easier to experiment with minimal risk, and it
makes it easy to add co-collaborators to your project without having to get
prod access for them.

I'm hoping to get this onto IFTTT  with help
> from Stephen Laporte in my volunteer time, as I think this feature is a
> pretty powerful one which has failed to find its use case in the wiki
> world. As Kaldari points out it's incredibly good at detecting edit wars
> and I personally have learned a lot about what our editors see as important
> and notable in the world (our editors really seem to like wrestling). I
> think there are ample and exciting things people could build on top of this
> api.
>

Yeah a "give me push notifications about ongoing edit wars" tool for admins
sounds really cool. Although you'd probably want to look at revert trends
(or both edit and revert trends) for that.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Mediawiki-i18n] Language engineering monthly reports for September-November 2017

[Gergo Tisza]

On Tue, Dec 5, 2017 at 1:03 AM, Niklas Laxström 
wrote:

> * There is now a way to link directly to a particular message in
> Special:Translate.
>

That was a small but regular annoyance. Thanks for fixing it!


> * Translatable pages are now editable with the 2017 wikitext editor.
>

Also thanks! I had to stop using the new wikitext editor on mediawiki.org
due to this, it will be nice to be able to turn it back.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 2017-12-06 Scrum of Scrums meeting notes

[Gergo Tisza]

On Wed, Dec 6, 2017 at 11:15 AM, Grace Gellerman 
wrote:

>  Reading Infrastructure 
> ** ReadingLists performance improvements
> ** Wrapping up media + summary endpoints
> ** References needs a bit more design work
>

Also, I'm planning to deploy the ReadingLists extension to production
tomorrow [1][2]. Sorry, I forgot completely to add that.

[1] https://phabricator.wikimedia.org/T181107
[2]
https://wikitech.wikimedia.org/w/index.php?title=Deployments=1777474=1777458
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [AI] New ORES FAQ

[Gergo Tisza]

On Tue, Nov 21, 2017 at 4:20 PM, Aaron Halfaker 
wrote:

> I thought Wikitech makes sense for a wikimedia-specific initiative.
>

A documentation SIG is not really Wikimedia-specific though (or did you
mean "ORES documentation SIG" specifically?).
Also, most Wikimedia-specific technology initiatives are on mw.org (all the
Audiences projects, for example).

Wikitech was originally a place for ops documentation. (It has its own
infrastructure and deploy cadence, so it's unaffected by most failures;
also it's small enough for static HTML dumps. When the site is down and you
are scrambling to bring it back, it's a good thing when your operations
docs aren't also down.) Later Labs needed a management interface which got
tucked onto Wikitech (this was one of those "do everything inside
MediaWiki" eras), so it made sense to put all Labs-related documentation on
wikitech as well. Most other things are on mediawiki.org. There were
various proposals over the years to change that (move wikitech content to
mediawiki.org, move all WMF stuff to wikitech, move all WMF stuff to meta,
move all non-MediaWiki-documentation stuff to a new developer wiki etc.)
but none of them gained much momentum.

Due to being managed differently, wikitech is not a great work environment
IMO. There is no unified login, no page translation support, no structured
discussion support, no pageview metrics, the registration process is tied
to creating LDAP and shell accounts... There are plans to improve this
eventually [1], but between that and the audience differences, I'd stay
away for now.

Btw you are probably aware of the past discussion on a documentation SIG,
but just in case: [2]


[1] https://phabricator.wikimedia.org/T123425
[2] https://phabricator.wikimedia.org/T156301
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [AI] New ORES FAQ

[Gergo Tisza]

Hi Sarah,

thanks for working on this!

On Tue, Nov 21, 2017 at 2:31 PM, Sarah R  wrote:

> Documentation like this is critical for our open software environment to
> work.  I'm organizing a special interest group[4] to address
> documentation needs. If you have any questions or comments, please dont
> hesitate to reach out and share!
> [4] https://wikitech.wikimedia.org/wiki/SIGDOCS
>

Is there any particular reason to do it on wikitech? Most of the other SIGs
[1] and most of our documentation is on mediawiki.org (which is in general
a better maintained place). The ORES docs live there too, apart from a few
pages that are concerned with operations issues.

[1] https://www.mediawiki.org/wiki/Special_Interest_Groups
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Thoughts for handy features

[Gergo Tisza]

As it happens, the yearly feature wishlist collection process is taking
proposals right now; you might want to check it out. [0]

On Thu, Nov 16, 2017 at 10:15 PM, John Elliot V  wrote:

> 1. For links to articles in sections on the same page it would be really
> handy if we had syntax like: [[#unity|]] which would auto-complete to
> [[#unity|unity]] for you.
>

If you feel like writing a patch, this kind of thing is called a pre-save
transform, and handled in Parser::pstPass2().


> 2. For duplicated content it would be handy if you could define a bunch
> of "variables" down the bottom of a page and then reference them from
> elsewhere. I am aware of templates, but those are overkill and difficult
> to maintain per my use case (my use case is documenting the "purpose" of
> a computer, I duplicate this in various places, but don't want to
> maintain templates for that).
>

That's the Variables extension [1] if you want to use it on the same page,
or the Labeled Section Transclusion extension [2] if you want to reference
it elsewhere. I doubt you end up with something that's easier to maintain,
though.


> 3. It would be cool if for any given wiki page an "estimated reading
> time" could be provided. Along with maybe a word count, character count,
> etc.
>

https://tools.wmflabs.org/wikipedia-readability/ provides Flesch-Kincaid
scores, although not inside the page.


[0] https://meta.wikimedia.org/wiki/2017_Community_Wishlist_Survey
[1] https://www.mediawiki.org/wiki/Extension:Variables
[2] https://www.mediawiki.org/wiki/Extension:Labeled_Section_Transclusion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Simple overview image about how MW loads resources in clients

[Gergo Tisza]

Nice! Can you put it on Commons under a free license?

debug=1 in the URL query disables the bottom third of the image; scripts
are loaded via direct source URLs. Not sure if that's worth mentioning.
Also IIRC there are some other magic modules beyond startup where the URL
does not contain the module names (such as the code for the gadgets the
user has enabled). And the page-specific settings (via
the MakeGlobalVariablesScript hook) just get inlined in the initial HTML.
Again not sure if that's worth mentioning.


On Mon, Nov 6, 2017 at 10:39 AM, Joaquin Oltra Hernandez <
jhernan...@wikimedia.org> wrote:

> Hi,
>
> We were having a session where we talked about resource loading, code entry
> points for the front-end, and how things work on MediaWiki, and we came up
> with a small pic to explain the lifecycle for people newer to MediaWiki.
>
> Maybe it could help some people get a better grasp about where files are
> coming from and what why the load.php urls are as they are.
>
> Please, forgive any missing details, and if there is something very wrong
> I'd love to correct it, please let me know.
>
> Also to clarify, "Magic" is used as "Dynamic, runtime based, dependent on
> the state of your code/client cache/server state & extensions" to shorten
> things and in a humorous key.
>
> Links:
>
>- Phab: https://phabricator.wikimedia.org/M232
>- Imgur: https://i.imgur.com/DYLqtQf.png
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] New Developers Quarterly Report's first edition

[Gergo Tisza]

Thanks Srishti & DevRel team, that was interesting, and it's great to see
that developer retention gets the organizational focus it deserves.

Some comments on the document:

We currently struggle to keep track of information about new developers
> such as project they worked on, their contact details (e.g., Phabricator,
> Gerrit, and Github username), etc.


FWIW this is a problem with all developers, not just new ones. For example
after I find out who is the best person to ask about something, there isn't
really way to find out their IRC account. (Or vice versa, know who I've
just talked with on IRC.) Phabricator can be linked to mediawiki.org and
wikitech but few people do both. And so on. The WMF has its private contact
list, but even that is not always updated, and it's unaccessible to
volunteers. It would be great to have a proper, public contact info
management system somewhere.


Re: surveys, it would be a missed opportunity to only survey new
developers. The limitation in that is that only a small fraction of them
become regulars, and it would be great to understand better what
personality trait or circumstance determines whether a given person stays
or leaves, but the only way to find that out is to survey people whom we
already know remained (or left) about their experiences as new developers.

Re: retention (the raw numbers for which can be found in T160430#3395405),
apparently year-on-year for Q3 2017 is interpreted as "(developers who
started in 2016 Q3 and were still active in 2017 Q3 / all developers who
started in 2016 Q3) / (developers who started in 2015 Q3 and were still
active in 2016 Q3 / all developers who started in 2015 Q3)" which is a
weird definition. YoY should be the difference in retention between two
full years, not between two quarters spaced one year apart.

One thing that jumps out looking at the list of retained developers is how
many of them are experienced Wikipedians (at a glance, something like
two-thirds?). Which I guess is not that surprising, but I wonder to what
extent is it reflected in the outreach strategy?


On Tue, Oct 17, 2017 at 12:03 PM, Srishti Sethi 
wrote:

> Hello everyone,
>
> I would like to share the first edition of the New Developers Quarterly
> Report 
> that the Developer Relations team has produced. This report covers metrics,
> survey analysis and lessons learned from new developers focused activities
> in the previous quarter (July-September 2017).
>
> If you have questions and feedback that you would like to share with us,
> please add them on the discussion
> 
> page.
>
> To receive a notification when a new report is published, subscribe here
> .
>
> We plan to release a report every quarter and take action items identified
> from the key findings for improving our existing methods and processes. The
> next release will be in January 2018.
>
> If you have any questions, comments, and concerns, we will be more than
> happy to hear them!
>
>
> Thanks,
>
> Srishti
>
>
> --
> Srishti Sethi
> Developer Advocate
> Technical Collaboration team
> Wikimedia Foundation
>
> https://www.mediawiki.org/wiki/User:SSethi_(WMF)
>
> ___
> Wmfall mailing list
> wmf...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wmfall
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] need a URL encoding expert

[Gergo Tisza]

It would be easier to comment if either the pull request or this thread
explained what the patch is trying to do (XY problem etc) but in general:

- the URI spec defines ? as the separator character between the path and
the query part, but it doesn't say much about what the path and query part
*are* (except that the path specifies a resource in a hierarchical manner,
and the query specifies it in a non-hierarchical manner). So a web
application using something other for separating the query part will
violate the spirit of the spec but probably won't experience any problems.
Haven't heard of anything doing that before; this display.w3p thing seems
like some super-obscure web framework only used by Australian and
Singaporean government web pages.

- the URI spec does not say anything about the contents of the query part.
It specifies ;/!?:@&=+*$,'[]() as the set of reserved characters, so those
are the only sane choices for separating sub-arguments (as everything else
might get percent-encoded by the browser, but reserved characters are
guaranteed to be preserved). The choice of & and = as argument separator
and key-value separator are a common convention, and used by some standards
such as x-www-form-urlencoded, but a web application is free to choose
something else in theory. In practice I think only very old and fringe ones
do.

- the URI spec allows parameters in path segments (sometimes called matrix
parameters). https://www.w3.org/DesignIssues/MatrixURIs.html has some
examples. The older URI RFC, 2396, prescribed the semicolon as the
parameter separator; RFC 3986 allows any reserved character; but in
practice usually it's a semicolon. These are used a fair bit in RESTish
URLs; Angular uses them, for example. When only the last path segment has
parameters, the URL has the same structure as the one in the pull request.



On Fri, Oct 20, 2017 at 1:07 PM, Ryan Kaldari 
wrote:

> Could someone knowledgeable about URL encoding take a look at this pull
> request? Thanks!
> https://github.com/wikimedia/DeadlinkChecker/pull/26/files
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can we drop revision hashes (rev_sha1)?

[Gergo Tisza]

On Thu, Sep 21, 2017 at 6:10 AM, Daniel Kinzler  wrote:

> Yes, we could put it into a separate table. But that table would be
> exactly as
> tall as the content table, and would be keyed to it. I see no advantage.


The advantage is that MediaWiki almost would never need to use the hash
table. It would need to add the hash for a new revision there, but table
size is not much of an issue on INSERT; other than that, only slow
operations like export and API requests which explicitly ask for the hash
would need to join on that table.
Or this primarily a disk space concern?

> Also, since content is supposed to be deduplicated (so two revisions with
> > the exact same content will have the same content_address), cannot that
> > replace content_sha1 for revert detection purposes?
>
> Only if we could detect and track "manual" reverts. And the only reliable
> way to
> do this right now is by looking at the sha1.


The content table points to a blob store which is content-addressible and
has its own deduplication mechanism, right? So you just send it the content
to store, and get an address back, and in the case of a manual revert, that
address will be one that has already been used in other content rows. Or do
you need to detect the revert before saving it?

SHA1 is not that slow.
>

For the API/Special:Export definitely not. Maybe for generating the
official dump files it might be significant? A single sha1 operation on a
modern CPU should not take more than a microsecond: there are a few hundred
operations in a decently implemented sha1 and processors are in the GHz
range. PHP benchmarks [1] also give similar values. With the 64-byte block
size, that's something like 5 hours/TB - not sure how that compares to the
dump process itself (also it's probably running on lots of cores in
parallel).


[1] http://www.spudsdesign.com/benchmark/index.php?t=hash1
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] HHVM vs. Zend divergence

[Gergo Tisza]

On Tue, Sep 19, 2017 at 9:40 AM, C. Scott Ananian 
wrote:

> Fair enough.  My point is just that we should stop and reflect that this is
> a major inflection point.  Language choices are sticky, so this decision
> will have significant long-term implications.  We should at least stop to
> evaluate PHP7 vs Hack and determine which is a better fit for our codebase,
> and do due diligence on both sides (count how many engineers, how many open
> source contributors, commit rates, etc).  HHVM has been flirting with a
> LLVM backend, and LLVM itself has quite a large and active community.  The
> PHP community has had issues with proper handling of security patches in
> the past.  I'm suggesting to proceed cautiously and have a proper
> discussion of all the factors involved instead of over-simplifying this to
> "community" vs "facebook".
>

PHP is an open-source language with mature tooling and major community
buy-in. Facebook has *promised* to turn Hack into an open-source language
with mature tooling and community buy-in; almost none of that exists
currently. Once it already does, a worthwhile discussion might be had about
switching to Hack. Right now it would be incredibly irresponsible.

Also, making PHP a viable language for third parties is the core business
model of Zend. Making Hack a viable language for third parties has
absolutely nothing to do with the business model of Facebook. At any point
they might decide it is a distraction they don't need. Comparing commit
numbers is not really meaningful without knowing what fraction of those
committers can disappear overnight if Facebook reconsiders its priorities.

IMO the more interesting discussion to be had is how little we invest into
the technology our whole platform is based on. You'd think the largest
production user of PHP would pay at least one part-time PHP developer, or
try to represent itself in standards and roadmap discussions, but we do
not. Is that normal?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can we drop revision hashes (rev_sha1)?

[Gergo Tisza]

On Tue, Sep 19, 2017 at 6:42 AM, Daniel Kinzler  wrote:

> That table will be tall, and the sha1 is the (on average) largest field.
> If we
> are going to use a different mechanism for tracking reverts soon, my hope
> was
> that we can do without it.
>

Can't you just split it into a separate table? Core would only need to
touch it on insert/update, so that should resolve the performance concerns.

Also, since content is supposed to be deduplicated (so two revisions with
the exact same content will have the same content_address), cannot that
replace content_sha1 for revert detection purposes? That wouldn't work over
large periods of time (when the original revision and the revert live in
different kinds of stores) but maybe that's an acceptable compromise.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] How to add custom styles to a page?

[Gergo Tisza]

On Sat, Sep 16, 2017 at 7:46 AM, Brian Wolff  wrote:

> What you are looking for is TemplateStyles. This is not enabled on english
> wikipedia yet, but should be coming there soon (I think). It would allow
> you to use @media styles for your pages. See
> https://www.mediawiki.org/wiki/Help:TemplateStyles for more details.
>
> Templatestyles does not let you use css variables (the properties starting
> with -- and the var() css function), but the example css you used could
> easily be rewritten to not use that feature.
>

You could also just put it into User:Kaartic/common.css and wrap it in a
.page-User_Kaartic selector, that is less restrictive.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can we drop revision hashes (rev_sha1)?

[Gergo Tisza]

At a quick glance, EventBus and FlaggedRevs are the two extensions using
the hashes. EventBust just puts them into the emitted data; FlaggedRevs
detects reverts to the latest stable revision that way (so there is no
rev_sha1 based lookup in either case, although in the case of FlaggedRevs I
could imagine a use case for something like that).

Files on the other hand use hash lookups a lot, and AIUI they are planned
to become MCR slots eventually.

For a quick win, you could just reduce the hash size. We have around a
billion revisions, and probably won't ever have more than a trillion;
square that for birthday effect and add a couple extra zeros just to be
sure, and it still fits comfortably into 80 bits. If hashes only need to be
unique within the same page then maybe 30-40.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Web application to upload csv file to wiktionary

[Gergo Tisza]

On Thu, Sep 14, 2017 at 12:16 PM, Shrinivasan T 
wrote:

> My CSV file has 1000 lines as word, meaning.
>
> Like to create 1000 pages in Wiktionary.
> The mentioned python script in my previous query will do this.
>
> But, need a web application for this do that any newbie can use it easily.
>

A web version of the command-line tool you wrote probably won't just
magically exist; if you don't have the time to write it, you can direct
people to PAWS which provides a browser-based console for running scripts.
Not as nice but still easier than setting up Python locally.
Pywikipediabot has a tutorial which probably applies for running other
python scripts as well: https://www.mediawiki.org/wiki/Manual:Pywikibot/PAWS
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Recommending Firefox to users using legacy browsers?

[Gergo Tisza]

On Mon, Sep 4, 2017 at 6:13 PM, Bryan Davis  wrote:

> In my personal past experience,
> Firefox crashes were almost always correlated with buggy user
> installed, community developed extensions.
>

Which are going to be axed in the next release and replaced with a
Chrome-like limited-but-safe API for extensions, and that has everyone up
in arms. It's hard to please users :)

In any case I would care more about linking to a user-friendly and
well-maintained landing page (e.g. does it offer useful choices if you
visit it from a mobile device?) than the specific selection of browsers
offered - given the relatively small ratio of grade C visits, we are
unlikely to alter the browser landscape much either way. And I doubt we
want to deal with maintaining such a page ourselves.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Recommending Firefox to users using legacy browsers?

[Gergo Tisza]

On Thu, Aug 31, 2017 at 1:37 PM, bawolff  wrote:

> I'm concerned this would be seen as an inapropriate bias.
>

We could send them to something like https://whatbrowser.org/ or
https://browsehappy.com/
Motivating users to update their outdated browsers would definitely be a
good idea. It has the usual problem of notifications though: prompting the
user repeatedly with the same message gets annoying quickly, and we cannot
easily rely on the browser to remember whether it has already seen the
message in the past as the browser could have cookies disabled etc.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l