[Wikitech-l] Joining Forces for Open Source Cybersecurity Standards

[Federico Leva (Nemo)]

Will we join these efforts?
https://thephp.foundation/blog/2024/04/02/open-source-community-cra-compliance-initiative/

There's a risk that, say, MediaWiki consultants be inundated by 
paperwork in the EU if they suddenly get treated as "manufacturers". 
This can probably be avoided with some shared documentation work 
(handled by WMF?), as long as the ~40 expected upcoming standards do not 
hardcode some FLOSS-hostile methods of doing things.


MediaWiki development and deployment processes tend to be quite 
peculiar, so it would be nice to make sure they're covered. (Some work 
with Debian may also help, as MediaWiki is packaged there and some 
MediaWiki projects are under SPI? Not sure.)


In case you have no idea what it is about:
https://wikimedia.brussels/cyber-resilience-act-its-a-wrap/
https://blog.nlnetlabs.nl/what-i-learned-in-brussels-the-cyber-resilience-act/
https://berthub.eu/articles/posts/eu-cra-what-does-it-mean-for-open-source/

And specifically on standards:
https://fosdem.org/2024/schedule/event/fosdem-2024-3395-cra-40-new-ways-the-cra-can-accidentally-harm-open-source/
https://www.youtube.com/watch?v=jvKvsP6OGKw

Federico
___
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] Matrix.org Foundation and Wikimedia usage

[Federico Leva (Nemo)]

Matrix.org (both the protocol and the home server) are used quite a bit 
by Wikimedia communities:

https://meta.wikimedia.org/wiki/Matrix.org

Currently a number of channels have their primary home on matrix.org and 
we advertise app.element.io as primary client too. This means we're 
currently relying on the resources of a central entity for what is 
supposed to be a decentralised protocol.


Now we know that trouble is brewing: «This is completely unsustainable, 
and Element is now literally unable to fund the entirety of the Matrix 
Foundation on behalf of everyone else - and has had to lay off some of 
the folks working on the core team as a result».

https://matrix.org/blog/2022/12/25/the-matrix-holiday-update-2022
https://matrix.org/blog/2022/12/01/funding-matrix-via-the-matrix-org-foundation

For context, Matrix currently has about the same number of users 
WhatsApp had in 2012; in 2013, WhatsApp had expenses of 150 M$. You know 
what happened next.

https://en.wikipedia.org/w/index.php?title=WhatsApp&oldid=1129148959#cite_ref-69

So the Matrix Foundation is extremely cheap for what it's doing, but 
still it's not gratis. As Wikimedia movement we should at very least 
financially support the parts of Matrix that we use the most, like the 
IRC bridges.* Alternatively, "we" should switch to some collectively 
funded hoster for "our" Matrix presence, like e.g. feneas.org used to 
be, and contribute to that. But that seems more complicated and 
expensive to arrange.


The same argument applies to many of the upstream projects and assorted 
software we rely on https://meta.wikimedia.org/wiki/FLOSS-Exchange , 
especially where it's not realistic to contribute with software 
development and where a managed hosting is preferable, but the Matrix 
case seems to present some urgency.


Best,
Federico

(*) And Libera Chat itself, if a need ever arises. At the moment they 
have practically zero expenses and they mostly ask for borrowed 
hardware, which WMF can't really provide and Wikimedia affiliates 
usually don't have.


https://libera.chat/contributing/sponsor/
https://libera.chat/annual-reports/2021/a1-financial-report/
___
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: [discovery] Upcoming Search Platform Office Hours—July 14th, 2021

[Federico Leva (Nemo)]

Il 07/07/21 22:47, Trey Jones ha scritto:

Google Meet link:https://meet.google.com/vyc-jvgq-dww

Join by phone in the US: +1 786-701-6904 PIN: 262 122 849#


I'm pretty sure it's possible to dial-in by phone from an EU number too, 
I did so in some WMF-hosted meeting only few months ago. I forgot how to 
find the number, despite the instructions:

https://support.google.com/meet/answer/9518557
https://support.google.com/meet/answer/9683440

I think I found it in a Calendar invitation back then, could someone 
maybe share it from there?


Thanks,
Federico
___
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] [Wikisource-l] Systems for proofreading scanned books

[Federico Leva (Nemo)]

Thanks Lars for launching this very important conversation! I think it 
makes us think of an important topic, that is: what is Wikisource (and 
its software) actually for? See also some old iterations:

https://meta.wikimedia.org/wiki/Role_of_Wikisource

I think that some limitations of Wikisource are a natural consequence of 
its flexibility, which in turn is probably necessary to allow an 
unlimited number of people to work on the same works. Individual wikis, 
on Wikisource or elsewhere, can be more opinionated about certain 
things, enforce a single standard way of working and therefore focus on 
making that one very easy/fast (while other ways will become harder or 
even impossible).


For instance, the various attempts at a "book manager" extension to 
solve bug T17071 (MediaWiki knows about single pages but not about books 
as such, except via Wikidata hacks) have failed in part because there is 
too much variance out there and no easy or good way to impose some 
consistency (let alone conduct large data migrations such as "move all 
metadata to Wikidata).

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

Similarly, things like automated OCR and automated page creation (and 
maybe even image fixing à la ScanTailor and unpaper) could be offloaded 
to a custom infrastructure as Internet Archive has recently built, and 
instead of gadgets and bots you could have server-side processes 
handling everything in the same place, if you have less variance in the 
input and you don't have to worry about stepping on some other users' toes.

https://blog.archive.org/2020/11/23/foss-wins-again-free-and-open-source-communities-comes-through-on-19th-century-newspapers-and-books-and-periodicals/

My strong preference would be for a project like Runeberg to try and use 
MediaWiki+ProofreadPage and maybe some custom extensions. I think it 
would be a chance to move our software stack to the next level, making 
it more reusable for third parties so that others can possibly join its 
development in the future. I'd expect such a software migration to 
easily get a Wikimedia Foundation grant, given some past examples.


However, there is some other software being built. Projects based on TEI 
or METS/ALTO tend to look very impressive on paper but not very 
effective in practice, perhaps because they tend to strive to academic 
usage of very few works. The Australian or New Zealand project for the 
collaborative transcription of newspapers was very effective, but I 
can't recall its name and they never made software available. The 
Smithsonian is working on something custom, but it's just a set of 
plugins on top of Drupal so it won't necessarily be cleaner than our own 
MediaWiki stack; they said at Wikimania 2019 that the software would be 
shared.

https://transcription.si.edu/
https://en.wikisource.org/?oldid=9543219#Smithsonian_Transcription_Center

Federico

Lars Aronsson, 26/12/20 20:23:

In 2005, at the first Wikimania in Frankfurt, Germany,
Magnus Manske asked me if I could open up my Scandinavian
book scanning website Project Runeberg to German and
other languages, or release the software as open source.

I refused, as my software is just a rapid prototype that
would need to be rewritten from scratch anyway. But I
said that Wikisource could be used for this purpose. At
the time, Wikisource was only a wiki for e-text. As a
proof of concept, I put up "Meyers Blitz-Lexikon" as
the first book with scanned page images in Wikisource,
https://de.wikisource.org/wiki/Seite:LA2-Blitz-0005.jpg
and soon after the "New Student's Reference Work",
https://en.wikisource.org/wiki/Page:LA2-NSRW-1-0013.jpg

This was the basic inspiration for the "Proofread Page"
extension, now used in Wikisource.

In 2010-2011 I tried to use Wikisource, but I thought
this extension was too hard to work with. From scanner
to finished presentation, Wikisource was so much slower
to work with than my own system. By primary gripes are:
It is too hard to upload PDF files to Commons, it's too
hard to create the Index page, each page is not created
immediately (making the raw OCR text searchable), and
pages hidden in the Page: namespace are not always
indexed by search engines. Unfortunately, the system
hasn't improved much in the last decade.

(My criticism of my own website's system is a lot
harsher, but hits different targets.)

There is also a difference in how we view copyright,
as my own website can cut corners and scan some books
that are "most likely" out of copyright, which is
something Wikimedia's user communities never accept.

In 2012, I thought the time had finally come to rewrite
my software, but I failed to organize a project around
this, and instead I continued to use the existing system,
just adding volume. Indeed, Project Runeberg has grown
from 0.75 million book pages in 2012 to 3.1 million
pages today.

Now in 2020, I'm finally tired of my existing system's
limitations. What should I do? It's not 2005 or 2012
anymore. What has changed in

[Wikitech-l] Fwd: Public Drafting Process for the DMCA Cooperation Pledge

[Federico Leva (Nemo)]

After the recent abuse of DMCA provisions to attack popular free
software projects, the Software Freedom Conservancy has initiated a
discussion on a pledge text whose adoption may reduce such issues.

Some people here may be interested.

https://sfconservancy.org/blog/2020/nov/30/dmca-pledge/
https://sfconservancy.org/blog/2020/nov/13/widevine-dmca-takedown/



DMCA Cooperation Pledge, Version NO-RELEASE-YET
===

We pledge that, regarding any and all alleged copyright infringement and/or
alleged promulgation of circumvention techniques, by any software project
that is licensed in good faith under an OSI-Approved License, that we will
give notice to the project, and take no action of copyright enforcement or
other legal action (including but not limited to DMCA takedown due to
copyright infringement or DMCA §1201 violations), for at least 30 days from
the date of notice of our concerns made to the project.



Federico

 Messaggio inoltrato 
Oggetto:Public Drafting Process for the DMCA Cooperation Pledge
Data:   Mon, 30 Nov 2020 14:23:00 -0500
Mittente:   (Bradley M. Kuhn)



Public Drafting Process for the DMCA Cooperation Pledge

Today, we created a Git repository
 and a mailing list
 to
discuss drafting of a DMCA Cooperation Pledge — based on my proposal two
weeks ago .


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

Re: [Wikitech-l] Allow HTML email

[Federico Leva (Nemo)]

It's fine to allow HTML email, but doing so shifts on the users the
burden of fixing their clients so that they produce suitable multipart
emails before sending them to the list. With some common email clients
and providers (e.g. Gmail webmail) it's surprisingly easy to produce
utterly unreadable HTML which wouldn't pass even the most lenient
accessibility scrutiny.

Federico

___
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

[Federico Leva (Nemo)]

Thanks Amir for having this conversation here.

On Nathan's point: outside the Wikimedia projects, we of the free
culture movement tend to argue for full transparency on the functioning
of "automated decision making", "algorithmic tools" , "forensic
software" and so on, typically ensured by open data and free software.

Wikimedia wikis are not a court system, a block is not jail and so on,
but for instance EFF just argued that in the USA judiciary certain
rights ought to be ensured to respect the Sixth Amendment.
https://www.eff.org/deeplinks/2020/07/our-eu-policy-principles-procedural-justice
https://www.eff.org/deeplinks/2020/08/eff-and-aclu-tell-federal-court-forensic-software-source-code-must-be-disclosed


Federico

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

Re: [Wikitech-l] Moving from Gerrit to GitLab

[Federico Leva (Nemo)]

To understand the parameters of this discussion, it would be useful to
know whether the Wikimedia Technical Committee Charter

is still in force.

Grant, maybe you can answer?

(I also note that the page references something called "OKR" which was
not previously introduced to this list, as far as I know, including a
specific line which is not found in any public document. Can we link a
definition of what OKR means in the context of WMF, and ideally also
some public document containing the referenced line? I suppose it would
be some kind of annual or quarterly plan or something like that.)

Federico

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

Re: [Wikitech-l] Patents on MediaWiki search and WMF v. WordLogic

[Federico Leva (Nemo)]

Now also covered by Techdirt:
<https://www.techdirt.com/articles/20200402/17061944228/predictive-text-patent-troll-tries-to-shakedown-wikipedia.shtml>

Federico

Federico Leva (Nemo), 18/03/20 14:17:
WMF and IA are suing a patent troll which claims to hold a patent 
relevant for MediaWiki search autocomplete:
https://www.infodocket.com/2020/03/13/report-wikimedia-internet-archive-want-patent-infringement-claims-kicked-out/ 



The case is doing the rounds and I've not seen it on CourtListener 
(don't all WMF lawyers use RECAP? :-) ), so I've uploaded the WMF 
complaint to
<https://commons.wikimedia.org/wiki/File:2020-03-11_Wikimedia_Foundation_v._WordLogic.pdf> 



Federico


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

[Wikitech-l] Patents on MediaWiki search and WMF v. WordLogic

[Federico Leva (Nemo)]

WMF and IA are suing a patent troll which claims to hold a patent 
relevant for MediaWiki search autocomplete:

https://www.infodocket.com/2020/03/13/report-wikimedia-internet-archive-want-patent-infringement-claims-kicked-out/

The case is doing the rounds and I've not seen it on CourtListener 
(don't all WMF lawyers use RECAP? :-) ), so I've uploaded the WMF 
complaint to



Federico

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

Re: [Wikitech-l] SQL for reverted and changes

[Federico Leva (Nemo)]

This is not a trivial query to perform. There are various strategies and 
possible data sources:

https://meta.wikimedia.org/wiki/Research:Revert

If you only care about identity reverts, working with rev_sha1 might be 
enough for you.


Federico

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

Re: [Wikitech-l] [Wikimetrics] Sunsetting Wikimetrics

[Federico Leva (Nemo)]

Marcel Ruiz Forns, 22/02/19 21:01:
Wikimetrics  development has been frozen 
since 2017, and we Analytics consider it's time to sunset this tool.


This is sad, for sure. As someone who managed to patch and run the 
original WikiStats scripts despite a limited knowledge of Perl, I think 
it would have been more reasonable than often assumed to continue their 
maintenance. However it's clear that we're well past the time when such 
a decision might have been possible, and it's good to see a growing 
interest in feature parity for the new WikiStats.


I think the purposes of this list can be served by the analytics list 
without too much sweat.


Federico

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

Re: [Wikitech-l] [Wikitech-ambassadors] Changes to the Block paradigm

[Federico Leva (Nemo)]

Moriel Schottlender, 08/01/19 03:53:
The new “Partial Blocks” feature has fundamentally changed the way 
MediaWiki considers what “block” means;


Given this was not fully considered before applying the change, the 
safest way forward is to revert the change and open an RfC to list all 
the considerations you mention *before* applying it again.


Federico

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

Re: [Wikitech-l] status.wikimedia.org?

[Federico Leva (Nemo)]

I guess the best place remains #wikimedia-tech on FreeNode as always.
Cf. https://phabricator.wikimedia.org/T22079

Federico

___
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

[Federico Leva (Nemo)]

Thanks Amir and MZMcBride for disclosing the action.

A volunteer has been punished for speaking up in defense of fellow 
volunteer and paid contributors, whose contribution was being sidelined 
and suffocated by people "in charge" of the specific space, i.e. the 
people they were doing their best to help.


The message which was sanctioned was even of an especially thoughtful 
kind, in my opinion, because it didn't attempt to submerge the other 
users with walls of text, politically correct tirades or otherwise 
charged statements. It was merely a heartfelt interjection to help 
people stop, reconsider their actions and self-improve without the need 
of lectures. Was this peculiar effort at constructive facilitation 
considered? If not, what alternatives or constructive suggestions were 
provided?


After several negative examples discussed in the last few months on this 
list,* this action conclusively proves in my eyes the failure of the 
Code of conduct to be a positive force for our community, at least sso 
far and in the present conditions.


The committee needs to immediately resign or be disbanded, and be 
reformed on a more solid basis.


Federico

(*) And not a single disclosed positive action, as far as I know. But it 
might have been lost due to the lack of a transparency report. If one 
was released or is upcoming, sorry; I'll revise my conclusions accordingly.


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

Re: [Wikitech-l] FW: Warning on behalf of Code of conduct committee

[Federico Leva (Nemo)]

Pointless status changes which don't improve our issue tracking but 
predictably upset people are definitely provocative in nature and 
therefore trolls, whatever the intention behind them (which is not my 
interest to investigate). I suspect there might be some linguistic issue 
here; "troll" is sometimes used to refer to a single post or act, in 
which case the judgement doesn't automatically extend to the author as 
an indication of a general pattern.


That said, it could be worthwhile to go beyond individual incidents and 
listen to people who express discomfort. There is a wide perception that 
WMF employees are the main source of frustration and exclusion of 
contributors in our technical community (probably for mere statistical 
reasons: they spend a lot of hours in them and cannot just walk away 
when their positive energies are exhausted, unlike volunteers). 
Unprofessional and unproductive behaviour can often be caused by stress 
or other problems at work, which everyone in WMF should help their 
colleagues to address. I have a feeling that WMF employees don't get the 
help they need to get better.


The victims are predictably the weakest contributors, mostly volunteers 
like User:Ruakh (Ran), who registered only one week ago. I hope Ruakh 
will be offered an apology for being caught in the crossfire.


Federico

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

Re: [Wikitech-l] FW: Warning on behalf of Code of conduct committee

[Federico Leva (Nemo)]

I agree that reverting a clearly correct task edit with a pointless 
procedural objection is aggressive and not conducive to an inclusive 
environment.


Pointing out trollish brehaviour is positive help for self-correction.

Federico

___
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

[Federico Leva (Nemo)]

Personally I'd like us to explore agnostic and non-invasive solutions.

The subdivision of permissions across more user groups relies on a 
number of assumptions which may not hold. For instance, on thousands of 
MediaWiki wikis there's only one sysop anyway.


Something I would like is the ability to "have" a permission, but only 
"activate" it for limited periods of time when needed. The activation 
could require some extra steps (e.g. inserting the password again). It 
could be logged to Special:Log, which people can then monitor as they 
wish. A separate countermeasure (other than deflag) could inhibit it.


Granular permissions are tricky on MediaWiki, but we might come up with 
simple implementations. Maybe, set a rate limit to 0 and add a special 
page to temporarily increase it for yourself (or others). Something like 
that.


Federico

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

Re: [Wikitech-l] Gerrit as a shared community space

[Federico Leva (Nemo)]

I'll only state the obvious: it's not a community space if the community 
feels forced to walk out of it.


Federico

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

[Wikitech-l] Article 13 and the "censorship machine" for code

[Federico Leva (Nemo)]

I guess this should be mentioned here at some point:
Open Letter to Secure Free and Open Source Software Ecosystem in the EU 
Copyright Review

https://savecodeshare.eu/
«Save Code Share: Current EU Copyright Review threatens Free and Open 
Source Software. Take action now to preserve the ability to 
collaboratively build software online!»


Context on article 13:
* https://saveyourinternet.eu/
* 
https://blog.wikimedia.org/2017/06/06/european-copyright-directive-proposal/


The next vote on the proposed EU copyright directive is on June 20. More 
broadly:

https://meta.wikimedia.org/wiki/EU_policy/Statement_of_Intent

Federico

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

[Federico Leva (Nemo)]

To directly answer the question in the subject: of course Yaron's 
extensions should stay in gerrit.wikimedia.org, without the file in 
question.


We want MediaWiki's main development spaces to be inclusive and able to 
bring developers together. I think we all agree that it's a loss if more 
repositories end up being scattered on third party git servers.


Meddling with the content of repositories we host by forcing 
Wikimedia-specific content is not responsible. For one, it makes it 
impossible to multi-host a repository if such Wikimedia-specific content 
is incompatible with the requirements of other hosts.


Federico

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

Re: [Wikitech-l] Download a wiki?

[Federico Leva (Nemo)]

You're in luck: just now I was looking for test cases for the new 
version of dumpgenerator.py:

https://github.com/WikiTeam/wikiteam/issues/311

I've made a couple changes and for tomorrow you should see a new XML dump at
https://archive.org/download/wiki-meritbadgeorg_wiki
(there's also https://archive.org/download/wiki-meritbadgeorg-20151017, 
not mine )


Federico

___
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

[Federico Leva (Nemo)]

Jargon such as "AFC improvement" would use a link.

Thanks,
Federico

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

Re: [Wikitech-l] Fwd: [Wikimedia-l] Notification about problem identified with a recent CentralNotice banner

[Federico Leva (Nemo)]

It helps if vendors have some understanding of Wikimedia values and if 
centralnotice administrators are not forced to perform tasks they are 
not in the condition to do well.


Federico

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

Re: [Wikitech-l] Proposal for a developer support channel

[Federico Leva (Nemo)]

If the proposal is triggered by technical problems at 
[[mw:Project:Support desk]], a simple solution is to make it a wikitext 
page.


As for the "one place" argument, https://xkcd.com/927/ applies.

Federico

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

Re: [Wikitech-l] 2017-10-25 Scrum of Scrums meeting notes

[Federico Leva (Nemo)]

Thanks. "Procurement for Asia datacenter has started" is big news! Is 
energy efficiency a criterion for the product/supplier selection?


(This needs not be something very complicated. For instance Dell asks a 
small surcharge if you want a more efficient PSU, IIRC. 
)


Nemo

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

[Wikitech-l] Fwd: Update on Artifex v. Hancom GNU GPL compliance case

[Federico Leva (Nemo)]

https://www.fsf.org/blogs/licensing/update-on-artifex-v-hancom-gnu-gpl-compliance-case-1

 Messaggio inoltrato 
Oggetto:Update on Artifex v. Hancom GNU GPL compliance case
Data:   Thu, 12 Oct 2017 03:05:18 -0400

[...]

Hancom here made several arguments against the contract claim, but one 
is of particular interest. Hancom argued that if any contract claim is 
allowed, damages should only be considered prior to the date of their 
initial violation. They argued that since the violation terminated their 
license, the contract also ended at that point. The judge noted that:


/the language of the GPL suggests that Defendant’s obligations
persisted beyond termination of its rights to propagate software
using Ghostscript ... because the source code or offer of the source
code is required each time a “covered work” is conveyed, each time
Defendant distributed a product using Ghostscript there was arguably
an ensuing obligation to provide or offer to provide the source code./

The judge also found that there was insufficient evidence at this point 
to rule on this issue, so we can't read too much into it. [...]


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

Re: [Wikitech-l] 2017-09-27 Scrum of Scrums meeting notes

[Federico Leva (Nemo)]

> Turning off OCG. Investigating using chromium for printing.

The first sentence is unclear. I think it means "We would like to turn 
off OCG" (i.e. "replace OCG"), where the second sentence indicates a 
step to that purpose. Please confirm.


Nemo

___
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)?

[Federico Leva (Nemo)]

The revision hashes are also supposed to be used by at least some of the 
import tools for XML dumps. The dumps would be less valuable without 
some way to check their content. Generating hashes on the fly is surely 
not an option given exports can also need to happen within the time of a 
PHP request (Special:Export for instance).


Nemo

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

[Federico Leva (Nemo)]

-1 to linking any resource which is not itself free software, 
translatable with free software and managed by a privacy-compliant org.


Positive example of what I mean: https://pdfreaders.org/ .

At least until a proper resource exists, just directing people to the 
latest Firefox is probably the most reasonable option (we certainly 
can't support the incumbent).


Nemo

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

Re: [Wikitech-l] Last Call: PostgreSQL schema change for consistency with MySQL

[Federico Leva (Nemo)]

By notifications I don't mean alerts or warnings; just a way to have 
some feedback from real users of the affected "feature", given I see 
little on the task itself.


If someone took the trouble to pick PostgreSQL as their MediaWiki 
database, I expect they have some reason to do so and maybe some opinion 
on how it should be. Hopefully they didn't choose PostgreSQL for the 
specific schema! :-)


Nemo

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

Re: [Wikitech-l] Last Call: PostgreSQL schema change for consistency with MySQL

[Federico Leva (Nemo)]

Thanks. I tried to notify some affected wikis but surprisingly there is 
only one registered on WikiApiary:

https://bucardo.org/wiki/Special:Version

With some very wide Google searches like 'postgresql "powered by 
mediawiki"', I found a few more:

* https://www.alteeve.com/w/Special:Version
* 
https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Special:Version
* https://wiki.mageia.org/en/Special:Version (we know them, they're 
working on upgrades and a Translate installation)

* http://www.pgpool.net/mediawiki/index.php/Special:Version
* https://wiki.koha-community.org/wiki/Special:Version
* http://postgres.cz/wiki/Speci%C3%A1ln%C3%AD:Verze
* https://wiki.mahara.org/wiki/Special:Version

I'll notify these as well if nobody beats me at it, but I assume there 
are more; any idea how to reach them?


Nemo

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

Re: [Wikitech-l] Update to web print styles

[Federico Leva (Nemo)]

I'm confused by this problem statement:
> No branding or indication the content
> came from Wikipedia or sister sites

Are you saying there's currently a lack of attribution?

The example  
includes a "Wikipedia" wordmark, how do you plan to scale that to all 
localised versions of the wordmark and all sister projects?


Once again I recommend to use the global logo for each project if anything.

Nemo

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

[Wikitech-l] Fwd: US court declares GPL is a contract

[Federico Leva (Nemo)]

http://www.technollama.co.uk/us-court-declares-gpl-is-a-contract :

[...]

In a strong declaration that online open source licences are contracts, 
the court declares:


   “Defendant contends that Plaintiff’s reliance on the unsigned GNU
   GPL fails to plausibly demonstrate mutual assent, that is, the
   existence of a contract. Not so. The GNU GPL, which is attached to
   the complaint, provides that the Ghostscript user agrees to its
   terms if the user does not obtain a commercial license. Plaintiff
   alleges that Defendant used Ghostscript, did not obtain a commercial
   license, and represented publicly that its use of Ghostscript was
   licensed under the GNL GPU. These allegations sufficiently plead the
   existence of a contract.”



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

Re: [Wikitech-l] Last Call: ArchCom/TechCom Charter

[Federico Leva (Nemo)]

> This finally gives the committee a clear place in the
> "chain of command", and real authority over software
> development at the WMF, where it formerly had none.

This is a compelling argument, but why not call it Wikimedia Foundation 
Technical Committee then? It would also be easier to clarify that it's 
mostly/only meant for WMF staff and whoever else decides to submit to 
its process (this is already implied by phrases such as "developers or 
teams"), rather than for MediaWiki in general.


I think it's appropriate for the WMF to have some body to take care of 
technology beyond MediaWiki, think for instance 
https://meta.wikimedia.org/wiki/FLOSS-Exchange (still missing a contact 
point since Erik went, btw) and all the cases where disagreements over 
MediaWiki or Wikimedia practices have been worked around by using 
non-MediaWiki solutions.


I'm not sure it was necessary to give up on having a MediaWiki body in 
order to have a Wikimedia Foundation one, but probably two parallel 
systems would have been confusing. Hopefully at some point after this 
repurposing we will be able to afford integrating more third parties 
into the "central" development process and an actual MediaWiki 
governance will be useful/possible/needed (this was the core idea at the 
time of the Architecture summit 2014 etc., IMHO).


Ah, https://www.mediawiki.org/wiki/Gerrit/%2B2#Revocation at some point 
listed the WMF ~CTO and currently contains an unlikely "anyone 
authorized by Wikimedia Foundation's Board of Trustees". Some updates 
might be in order.


Nemo

P.s.: Not commenting is not necessarily a choice. For instance, the talk 
page doesn't use wikitext and therefore creates selection bias for the 
discussion.


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

Re: [Wikitech-l] Changes in the Contributors Team

[Federico Leva (Nemo)]

Who is going to work on MediaWiki internationalisation?

Nemo

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

Re: [Wikitech-l] Update on Discovery Projects

[Federico Leva (Nemo)]

Thanks. It's good that mapframe can follow the usual 
#Wikimedia-Site-requests process! Maybe worth writing down on 
[[mw:Extension:Kartographer]], or at least a code comment above 
wgKartographerEnableMapFrame, so that users know they can ask.


Nemo

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

Re: [Wikitech-l] Chinese conversion, search engines, and auto-detection

[Federico Leva (Nemo)]

Indexing is a known issue, tracked at:
* https://phabricator.wikimedia.org/T93213
* https://phabricator.wikimedia.org/T54429

(Tilman, Kaldari or others with Google Search Console access may quickly 
provide an update on https://phabricator.wikimedia.org/T93213#2518417 .)


Nemo

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

Re: [Wikitech-l] Improvements to developer events in the WMF Annual Plan draft

[Federico Leva (Nemo)]

Thanks Victoria for spelling out this project, which was not clear to me 
from reading the annual plan page (which mostly gives a feeling of 
continuity).


Can you clarify what you mean by "position papers" in this context?

Thanks,
Nemo

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

Re: [Wikitech-l] ArchCom Minutes, News, and Outlook

[Federico Leva (Nemo)]

Why was Google Docs used to keep notes? It seems a stark regression.

Nemo

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

Re: [Wikitech-l] Mediawiki core has reached to its 400th contributor

[Federico Leva (Nemo)]

https://www.openhub.net/p/mediawiki tends to be more accurate (people at 
least can easily de-duplicate email addresses etc.) and says 700+.


Do help https://www.openhub.net/orgs/wikimedia by adding more 
repositories and claiming more email address/commit IDs for yourself. :)


Nemo

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

Re: [Wikitech-l] catching errors in local JavaScript

[Federico Leva (Nemo)]

AFAIK https://www.mediawiki.org/wiki/Extension:Sentry is the way to go, 
perhaps currently blocked on procurement 
(https://phabricator.wikimedia.org/T93138 ).


https://phabricator.wikimedia.org/T106915 or 
https://phabricator.wikimedia.org/T382 might be the main discussions on 
the matter.


Nemo

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

Re: [Wikitech-l] Using OpenStreetMap with Wikipedia account

[Federico Leva (Nemo)]

Yes, the dialog should be made clearer and mention the permissions 
granted before one clicks "Allow". This seems tracked at 
https://phabricator.wikimedia.org/T91825


That said, I don't see any private information being recorded by OSM 
once one clicks "Allow": https://www.openstreetmap.org/user/new is 
opened, where one can see that the form is prefilled with the email 
address, and the account is created only after confirming again.


The feature was requested at 
https://github.com/openstreetmap/openstreetmap-website/issues/1146


Nemo

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

Re: [Wikitech-l] Making Wikipedia speak to you

[Federico Leva (Nemo)]

The goal is certainly worthwhile and I'd certainly support: just think 
how many editor-hours are "wasted" on producing audio files for a 
limited coverage, when the simple cases could be automated and users 
could focus their efforts on the difficult cases.


However, to support a project I need to know what the project actually 
entails and how it will be made viable: 
https://www.mediawiki.org/wiki/Extension_talk:Wikispeech


Nemo

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

Re: [Wikitech-l] What happened to RobLa?

[Federico Leva (Nemo)]

As a reminder on goodbyes, WMF HR used to announce everyone's last day 
at https://identi.ca/wikimediaatwork (can't take more than a couple 
minutes); then the announcements became monthly, then quarterly; then we 
lost this courtesy as well 
https://meta.wikimedia.org/wiki/Talk:Wikimedia_Foundation_reports#Staff .


Nemo

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

[Wikitech-l] MediaWiki code review stats update

[Federico Leva (Nemo)]

For those of you who follow 
http://koti.kapsi.fi/~federico/crstats/extensions.txt or other 
https://www.mediawiki.org/wiki/Development_statistics : I just recloned 
all the MediaWiki extensions and rerun the stats, which were no longer 
correct.


Given that either git pull or the ref/notes/review fails every few 
months, I now also run check-sync.sh from the mediawiki/extensions.git 
repo so that http://koti.kapsi.fi/~federico/crstats/git-sync.log 
(hopefully) tells you whether the data is actually up to date.


I also finally set the character-encoding so that UTF-8 is recognised as 
such in all its glory without browser guesses/instructions. ;-)


Nemo

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

Re: [Wikitech-l] How to find a repository?

[Federico Leva (Nemo)]

To make the links to projects useful, one needs to visit every single 
project's "manage > configure menu" 
https://phabricator.wikimedia.org/project/291/panel/configure/ and click 
"make default" next to "project details" (known nasty bug 
https://phabricator.wikimedia.org/T89865 ).


Nemo

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

Re: [Wikitech-l] Recent authentication session instability (was Re: Update from the Wikimedia Performance Team)

[Federico Leva (Nemo)]

Thanks for pointing out this expectation. Please place this goal 
statement somewhere on the wiki.


I've sent bug reports with HAR files before, but it always proved to be 
a lot of effort for zero gain. Perhaps there are specific tips to debug 
such issues in a way that makes bug reporting effective?


It's of course possible that my browser's settings are interfering, but 
the mentioned hypothesis sound like something that would prevent 
crosswiki login in all cases, not just on some domains.


Nemo

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

Re: [Wikitech-l] Recent authentication session instability (was Re: Update from the Wikimedia Performance Team)

[Federico Leva (Nemo)]

Thanks Brad for the implementation explanatin but I'd rather need a 
document outlining the expectations for user-facing functionality.


I just had to separately and manually login three times (on Meta, then 
on Wikipedia, then on MediaWiki.org) in order to be logged in on most 
wikis. I don't find any page explaining whether it's normal for global 
login to require entering my password 3+ times. If it's expected and 
documented, I can stop worrying.


Nemo

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

[Wikitech-l] CII best practices (for security etc.)

[Federico Leva (Nemo)]

Out of curiosity I've started filling 
https://bestpractices.coreinfrastructure.org/projects/201 for MediaWiki 
(core) in this Linux Foundation project on best practices for FLOSS.


I got the feeling that the criteria still need to be exposed to a bigger 
variety of projects: they don't seem focused, for instance, for web 
applications, multilingual userbases and openness/transparency/community 
health.


I was able to confirm 79 % of the criteria; I've had some troubles with: 
issue reporting SLA, test coverage evolution, static/dynamic analysis 
and cryptography. I suggest that the current status be documented on the 
relevant mediawiki.org pages, as other people may have the same 
questions. Hopefully it's then easy enough to update the "badges" (and 
if not, I see a big delete button).


Nemo

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

Re: [Wikitech-l] Phabricator monthly statistics - 2016-05

[Federico Leva (Nemo)]

We occasionally managed to display a decrease in open reports in the 
bugzilla weekly reports; I remember we did during at least one annual 
hackathon.


Besides, in Phabricator we have no way to tell bugs from feature 
requests from random discussions 
https://phabricator.wikimedia.org/T102#11218 , nor reports/charts like 
https://bugzilla.mozilla.org/reports.cgi?product=Bugzilla&datasets=UNCONFIRMED&datasets=NEW&datasets=ASSIGNED&datasets=REOPENED 
nor a real advanced search for all task metadata and history.


We could maybe produce dumps of Phabricator data and import them in a 
bugzilla instance regularly to ease research, but see 
https://phabricator.wikimedia.org/T108199


Nemo

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

Re: [Wikitech-l] Campaigns extension / ServerSideAccountCreation log - does anyone still use it?

[Federico Leva (Nemo)]

I think it's easier to answer this question by checking the 
corresponding data.


WMIT used this recently (https://phabricator.wikimedia.org/T123059 ; I 
don't know if there will be more) but most potential users probably 
don't know about the possibility (which was never really documented).


Nemo

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

Re: [Wikitech-l] Wikipedia.org article statistics updated

[Federico Leva (Nemo)]

Strainu, the policy is described on Meta 
(https://meta.wikimedia.org/wiki/Project_portals ), where the management 
of the portals belongs.


Nemo

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

Re: [Wikitech-l] Wikipedia.org article statistics updated

[Federico Leva (Nemo)]

FYI there were usually around 50 updates per year on the wiki.
http://vs.aka-online.de/cgi-bin/wppagehiststat.pl?lang=meta.wikimedia&page=Www.wikipedia.org+template

Nemo

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

Re: [Wikitech-l] [Translators-l] update: wikipedia.org portal

[Federico Leva (Nemo)]

Purodha Blissenbach, 21/05/2016 14:13:

On the long run, I think, these portals and their texts should
be translatable. Browser settings determining the target language.
Looking forward to have them on translatewiki.net !


Adding English-only text to the Wikipedia portal is unacceptable. 
Special powers on a Wikimedia domain must not be used to contradict and 
impoverish the Wikimedia mission. The portal seize by a small WMF clique 
has shown its failure and should immediately be reversed, as the 
Meta-Wiki administrators have proven to be more competent.


Nemo

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

Re: [Wikitech-l] Proposal to invest in Phabricator Calendar

[Federico Leva (Nemo)]

> That said, I think we should be careful with our assumptions about how
> much influence we can buy with the money we have.

Sure. Let's not make assumptions at all then: what makes someone think 
that calendar is amenable to WMF-mandated development? Already one year 
ago, I proposed that Phacility be hired to upstream our issues (and 
triage them upstream).

https://lists.wikimedia.org/pipermail/teampractices/2015-March/000642.html

The reason is that so far I'm not aware of a single person in Wikimedia 
being able to talk with upstream (as opposed to talking past each 
other). https://phabricator.wikimedia.org/project/board/6/query/all/ 
seems to prove none exists, as the "Solved upstream" column lists a 
whopping 2 issues out of 500+ upstream issues.


Phacility could file the reports upstream in the way they prefer and 
optionally put a price tag on each request, without continuing to waste 
our reporters' time.


Nemo

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

[Wikitech-l] Phabricator upgrade and UI changes

[Federico Leva (Nemo)]

AFAICT, in the last few days there were two unannounced upgrades of 
Phabricator, to an unspecified version of the software, the second of 
which applied rather radical UI changes, especially to Maniphest.


Initially I wasn't sure most/which UI changes were bad/good or why, but 
now I've observed myself for a few days and I took the time to take 
screenshots and describe my findings. Of course, most are about

* the consistent enlargement of some items to the expense of others,
* the introduction of a sidebar to host an ever-growing amount of buttons,
* the move of most task information under the description or under the 
sidebar.


Please comment on the reports, add your findings and file new reports 
for separate issues (I've not tested areas outside Maniphest, for instance):

* https://phabricator.wikimedia.org/T134393
* https://phabricator.wikimedia.org/T134394
* https://phabricator.wikimedia.org/T134398

It would also be nice to have some precise and authoritative information 
on when Phabricator was upgrade to what version, what the release notes 
and gotchas are, etc. Did I miss such an announcement and if yes where 
is it?


Nemo

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

Re: [Wikitech-l] productivity of mediawiki developers

[Federico Leva (Nemo)]

> I, for example, value better good -1 code reviews

Same here. There are statistics for -1 too, two clicks away from the 
link I provided in the previous message.

https://www.mediawiki.org/wiki/Gerrit/Reports/Code_review_activity

Nemo

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

Re: [Wikitech-l] productivity of mediawiki developers

[Federico Leva (Nemo)]

For statistics, see 
https://www.mediawiki.org/wiki/Development_statistics . As a starting 
point to look into what you call "productivity", I usually use:

* https://www.openhub.net/orgs/wikimedia
* http://koti.kapsi.fi/~federico/crstats/core.txt + 
http://koti.kapsi.fi/~federico/crstats/extensions.txt


Nemo

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

[Wikitech-l] Everything is a wiki page

[Federico Leva (Nemo)]

I started https://www.mediawiki.org/wiki/Everything_is_a_wiki_page

This is a very simple concept which, however, I find is often neglected. 
Some extension developers are conscious about what they do, but there is 
a lot of needless self-inflicted pain that we could do without.


Nemo

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

[Wikitech-l] Fwd: Report from the VMware GPL court hearing

[Federico Leva (Nemo)]

For those who care about our GPL license. :)

http://laforge.gnumonks.org/blog/20160225-vmware-gpl/

Nemo

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

Re: [Wikitech-l] Deployment of GeoGebra MediaWiki Extension

[Federico Leva (Nemo)]

I always found GeoGebra interesting but I'd have trouble articulating 
what it could actually *do* on Wikimedia wikis. I suppose it can help 
fix one of those bugs: https://phabricator.wikimedia.org/T56213

In particular we have:
* https://phabricator.wikimedia.org/T54655
* https://phabricator.wikimedia.org/T45616

It would be great of you could make some Wikimedia-specific examples of 
possible use cases / community-posed problems that GeoGebra would solve. 
For instance, you could take some esoteric visualisation template with 
at least a few hundreds usages on a Wikimedia wiki and show on a test 
wiki how it could be transformed by  GeoGebra.


Nemo

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

Re: [Wikitech-l] [WikimediaMobile] Readership metrics for the two months until February 7, 2016

[Federico Leva (Nemo)]

Oliver Keyes, 19/02/2016 13:51:

a lot of prominent countries were very close to the 50% switchover,
including (interestingly) Italy.


I compiled some links at 
https://meta.wikimedia.org/wiki/Research:The_sudden_decline_of_Italian_Wikipedia#Scratchpad 
on the likely social reasons.


Pew research also had some numbers on the matter for USA, recently.

Nemo

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

Re: [Wikitech-l] Recent authentication session instability (was Re: Update from the Wikimedia Performance Team)

[Federico Leva (Nemo)]

No, this is not what I'm talking about. My problems span multiple weeks 
or months and I reiterate my need for a document outlining the expected 
behaviour.


Nemo

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

Re: [Wikitech-l] Update from the Wikimedia Performance Team

[Federico Leva (Nemo)]

Re "The central login system started to use DB slaves for some actions 
instead of master DB", is there an up to date document explaining what 
is the expected behaviour of login nowadays?


Login pretty much never does what I expect nowadays, but I'm not sure my 
expectations are correct so I can't identify actual bugs.


Nemo

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

Re: [Wikitech-l] Fw: Shutting down persona.org in November 2016

[Federico Leva (Nemo)]

One thing that seemingly supports Persona is Mailman 3. So the Persona 
extension is still worth working on, unless adding OAuth support to 
Mailman 3 is less effort.

https://meta.wikimedia.org/wiki/Talk:Discourse#Wikimedia_account_support

Wikis using it seem to include https://sudoroom.org/ and 
http://arabdigitalexpression.org ; is there a way to know how many 
users? Are private wikis more likely to have an advantage in using 
Persona compared to other methods?


Nemo

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

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

[Federico Leva (Nemo)]

I'm allergic to videos as replacement of data, but does your video 
substantially differ from what tests give us, e.g. 
http://www.webpagetest.org/video/view.php?id=160118_YK_HKT.1.0 ?


It's easy to test multiple speeds (some tests still pending): 
http://www.webpagetest.org/video/compare.php?tests=160118_AZ_JH3,160118_VB_JGH,160118_X6_HM1,160118_KC_HM0,160118_YK_HKT,160118_2W_HKD


Some of the tests show significant CPU usage after the "everything and a 
kitchen sink" ResourceLoader phase in which some stuff for 
CentralNotice, Gather etc. etc. is loaded.


Mainly, the issue is to pick representative connections. There is some 
official data, some of which based on actual tests by probes, although 
it's limited:
* 
https://ec.europa.eu/digital-agenda/en/news/quality-broadband-services-eu (no 
mobile)
* 
https://ec.europa.eu/digital-agenda/en/news/use-commercial-mobile-networks-and-equipment-mission-critical-high-speed-broadband 
(needs some parsing!)


Nemo

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

[Wikitech-l] Google code-in progress statistics; opportunity to join

[Federico Leva (Nemo)]

In addition to 
https://www.mediawiki.org/wiki/File:Wikimedia_at_Google_Code-in_2015.png, which 
shows we've completed more tasks in the first half of the contest than 
in the entire last year, we have some nice statistics about Wikimedia 
compared to other orgs. The best news for me is that not only we 
involved many students with easy beginner tasks, but they go farther 
from there: we're the third org with most students with 3+ tasks completed.


You can still become a mentor, or add new tasks if you're already one: 
https://www.mediawiki.org/wiki/Google_Code-in_2015#Mentors.27_corner
If you don't know what tasks to mentor, I just added ~50 suitable 
reports you can pick from (mostly MediaWiki, so any MediaWiki dev can 
help): https://phabricator.wikimedia.org/tag/google-code-in-2015/


The more mentors we have, the less worries about making the 36 hours 
deadline for reviews. :-)


Nemo

 Messaggio inoltrato 
Il giorno giovedì 7 gennaio 2016 01:42:11 UTC+1, Robert Spier ha scritto:

   Hi Org Admins and Mentors,

  Here are some interesting statistics about task completion counts.

  Thanks to Freso for suggesting some metrics.  Thanks to Google
   Sheets for making the analysis easy.

  As of 1/6/2016 15:47:58 TZ=America/Los_Angeles


#students >= 1 task completed#students >= 3 tasks completed
   #tasks completed by 1st place student#tasks completed by 10th
   place student
   Apertium 20  10  22  3
   Copyleft Games   61  5   7   1
   Drupal   23  4   11  1
   FOSSASIA 286 87  40  21
   Haiku43  10  15  3
   KDE  33  11  19  5
   MetaBrainz Foundation70  11  17  3
   OpenMRS  48  9   16  2
   RTEMS Project47  11  30  3
   Sugar Labs   98  17  38  4
   Sustainable Computing Research Group ( SCoRe )   32  7   14  
2
   Systers, an Anita Borg Institute Community   23  6   13  2
   Ubuntu   194 35  26  6
   Wikimedia91  18  28  8


   -R



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

Re: [Wikitech-l] IRC office hours: Shared hosting

[Federico Leva (Nemo)]

I don't understand the expected audience of this event. mediawiki-l 
wasn't notified, so I suppose you're not trying to reach out to users?


Nemo

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

Re: [Wikitech-l] Ifexists across wikis

[Federico Leva (Nemo)]

Italian projects would also like such a feature, especially for 
(semi)automatic creation of interproject links.

https://it.wikipedia.org/wiki/Discussioni_template:Interprogetto#Interprogetto_a_wikt:_quando_metterlo.3F

(By the way, the lack of Wiktionary on Wikidata even for interwiki links 
is extremely detrimental for a huge pile of things.)


Nemo

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

Re: [Wikitech-l] Peer-to-peer sharing of the content of Wikipedia through WebRTC

[Federico Leva (Nemo)]

On the matter of who has what etc., Brewster Kahle has opinions on 
implementation: 
http://brewster.kahle.org/2015/08/11/locking-the-web-open-a-call-for-a-distributed-web-2/
«Fortunately, the needed technologies are now available in JavaScript, 
Bitcoin, IPFS/Bittorrent, Namecoin, and others.»


Nemo

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

Re: [Wikitech-l] Introducing WikiToLearn to developers

[Federico Leva (Nemo)]

Your code modifications for http://wikitolearn.org/ are interesting. I'm 
pretty sure that KDE policies don't force you to fork MediaWiki 
extensions locally, so your patches are definitely welcome upstream.


I'm not sure what you mean with your point about  being rejected 
by the community; perhaps you refer to some performance decision made by 
WMF. If your modifications to Math are incompatible with some decision 
of the maintainers, you can ask a different repository on gerrit or 
another branch on the same repository, so that non-WMF users can use 
your code.


As for your comments on chapters and drafts, I don't see anything 
incompatible with how Wikibooks and Wikiversity work. If you have a 
solution for what we call "book management" i.e. 
https://phabricator.wikimedia.org/T17071 (worked on by Raylton and 
others with 
https://meta.wikimedia.org/wiki/Category:GSoC_Mediawiki_Book_Experience 
), that's especially interesting.


To reach the Wikibooks and Wikiversity community, the best way is to use 
a medium that can involve their active editors, such as their mailing 
lists (cc'ed here) or wikis.


Nemo


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

Re: [Wikitech-l] Introducing WikiToLearn to developers

[Federico Leva (Nemo)]

To clarify, Wikimedia Italia doesn't financially sponsor this site nor 
contribute content to it. AFAIK our volunteers provided some MediaWiki 
training to the site's users. Wikimedia Italia is always happy when 
MediaWiki usage spreads, but recommends Wikibooks and Wikiversity as 
primary platforms for OER activities.


As for your question, there are a couple useful things you can do:
1) write a document where you explain what makes your platform more 
suitable for your activities and what features Wikibooks/Wikiversity 
lack in your opinion;
2) publish your code in Gerrit: 
https://www.mediawiki.org/wiki/Git/New_repositories/Requests (you made a 
Docker extensiona and the skin, right? 
http://it.wikitolearn.org/Speciale:Versione);

3) report bugs and feature requests http://phabricator.wikimedia.org/ ;
4) (as you use Debian) take ownership of the Debian package, which is 
currently abandoned: https://wiki.debian.org/MediaWiki ; 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728347 .


Nemo

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

Re: [Wikitech-l] is this list's archives searchable?

[Federico Leva (Nemo)]

Mailing list archive search is https://phabricator.wikimedia.org/T19390
There are however multiple specialised search engines for our mailing 
lists out there: https://meta.wikimedia.org/wiki/Mailing_lists/Overview


Nemo

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

Re: [Wikitech-l] Closing wikibugs-l and mediawiki-commits firehoses?

[Federico Leva (Nemo)]

Closing either list would also break our nice replications at Gmane, 
markmail and mail-archive, with their useful full-text and semantic 
searches for commits and bugs: see also links at 
https://meta.wikimedia.org/wiki/Mailing_lists/Overview .


Is there a plan to provide equally good search? I don't see progress on 
https://phabricator.wikimedia.org/T63463 or 
https://phabricator.wikimedia.org/T38467 and even less for Phabricator.


Nemo

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

Re: [Wikitech-l] Need a way to modify text before indexing (was SearchUpdate)

[Federico Leva (Nemo)]

FWIW, we do index the full text of (PDF and?) DjVu files on Commons 
(because it's stored in img_metadata). It's probably the biggest 
improvement CirrusSearch brought for Commons.


Nemo

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

Re: [Wikitech-l] Downloading Wikimedia/Wikipedia image content in bulk

[Federico Leva (Nemo)]

Answers to most of these questions can be found at/from 
https://meta.wikimedia.org/wiki/Mirroring_Wikimedia_project_XML_dumps

You are especially welcome to reseed the Wikimedia Commons tarballs.

Probably of interest for you are also:
* https://commons.wikimedia.org/wiki/Commons:Structured_data
* http://elog.io

Nemo

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

Re: [Wikitech-l] MediaWiki 1.26 release blockers

[Federico Leva (Nemo)]

AFAICS, MediaWiki 1.26 ResourceLoader introduces a bunch of regressions, 
where JavaScript and CSS randomly fails loading. See for instance 
https://phabricator.wikimedia.org/T112047#1623903


I bet the regressions won't be fixed on time for the release, but we 
should at least provide sysadmins (and extension developers) with some 
instructions on how to debug the issues and hopefully work around them.


Nemo

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

Re: [Wikitech-l] thumb generation

[Federico Leva (Nemo)]

Have you looked into what mwoffliner does? 
https://sourceforge.net/p/kiwix/other/ci/master/tree/mwoffliner/mwoffliner.js

Maybe you can even just extract the images from the ZIM files.

Nemo

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

Re: [Wikitech-l] Collaboration team reprioritization

[Federico Leva (Nemo)]

> that only non-Wikimedia developers have maintained LQT
> is false, as a brief review of the commit log will show.

I said "non-Wikimedia users". Not sure what log you've been looking to, 
but I did `git log --no-merges -- . ':(exclude)i18n'` and I confirm what 
I said. The only exception I found so far is T104421 where you fixed a 
fatal (thanks!). Other than that the only bug fixes I see are some in 
Flow migration.


Nemo

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

Re: [Wikitech-l] Collaboration team reprioritization

[Federico Leva (Nemo)]

Thanks. So now we'll have two unmaintained extensions, LQT and Flow. Can 
we reverse the Flow conversion on mediawiki.org now, so that the wiki 
stays on the luckiest side i.e. the extension which has most users and 
is most likely to survive in the future?
(LQT is maintained by its non-Wikimedia users, otherwise it would have 
broken down years ago on all Wikimedia wikis as well.)


Nemo

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

Re: [Wikitech-l] Adding extensions under packagist's "mediawiki" vendor

[Federico Leva (Nemo)]

Gerrit is too unpredictable for users: 
https://phabricator.wikimedia.org/T86476#1462980 .
It's probably easier and more functional to create some 
"mediawiki-users" vendor on packagist and let any MediaWiki sysadmin 
(not developer) join to add the packages they need for whatever reason.


Nemo

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

Re: [Wikitech-l] Phabricator tag for bugs in local projects

[Federico Leva (Nemo)]

It's very simple: this is what #Wikimedia-General-or-Unknown has always 
been used for. Just makes sure there is a way for relevant/interested 
people to eventually find (and understand) the report.


Relevant quip: domas: "who are you, and on what did you base your 
opinion? in the end, everything is a user issue, we shouldn't do anything."

http://bugs.wmflabs.org/quips.cgi?action=show

Nemo

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

Re: [Wikitech-l] Yandex?

[Federico Leva (Nemo)]

FYI https://meta.wikimedia.org/wiki/Wikimedia_projects has a list; it 
means the wikis themselves (MediaWiki), not stuff around them.


Nemo

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

Re: [Wikitech-l] Lists as first class citizens

[Federico Leva (Nemo)]

I hope no 60 storey building is in the making. The bazaar is horizontal, 
a vertical suk is too similar to a cathedral.


Nemo

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

Re: [Wikitech-l] Obfuscating IP addresses on history pages

[Federico Leva (Nemo)]

This has been discussed countless times.
Some links for starters: https://phabricator.wikimedia.org/T20981

Nemo

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

Re: [Wikitech-l] Event organised on Marathi Wikipedia (photothon and edit-a-thon)

[Federico Leva (Nemo)]

Thanks. Is there a link to this Android app?

Nemo

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

Re: [Wikitech-l] Modifications list and automated (cron?) task.

[Federico Leva (Nemo)]

Special:NewPages has a feed too. As for collating recent changes by page 
title, that's called "enhanced recent changes". We could add that as 
option in the feed 
(https://meta.wikimedia.org/w/api.php?action=help&modules=feedrecentchanges 
) and maybe make the timespan configurable.


Special:RecentChanges makes one row for all edits to a page in 1 day, 
but sometimes it's more useful for that to be 7 days etc. So it would be 
a useful patch for core.


Not saying this is necessarily the way to go, but Kelson's proposal is 
definitely implementable.


Nemo

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

Re: [Wikitech-l] Boil the ocean, be silly, throw the baby out with bathwater, demolish silos, have fun

[Federico Leva (Nemo)]

Thanks, MaxSem. I'm looking forward to a skin which only does skinning.

Specific hacks/overrides are indeed best discussed elsewhere, but the 
"last edited [by X] Y ago" is actually a good example. The change was 
tested on desktop and a decision was made to make it permanent. Instead, 
it ended up being applied on MobileFrontend only, morphed into something 
different and died there.

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

Nemo

P.s.: Speaking of ways to achieve concrete results in the immediate 
future, see the community discussion I just opened, "Proposal: restore 
normal editing permissions on all mobile sites". 
https://meta.wikimedia.org/w/index.php?title=Wikimedia_Forum&oldid=11276420#Proposal:_restore_normal_editing_permissions_on_all_mobile_sites


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

Re: [Wikitech-l] Use of hreflang in the

[Federico Leva (Nemo)]

This appears to be tracked at https://phabricator.wikimedia.org/T3433
It was reverted in 2009 for (alleged) l10n issues, which should be 
solvable. FWIW we just saved 4 KB per page with 
https://gerrit.wikimedia.org/r/#/c/177501/


Nemo

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

Re: [Wikitech-l] Extensions licensing

[Federico Leva (Nemo)]

Thanks! This is a nice cleanup. 
https://www.mediawiki.org/wiki/Category:Extensions_with_unknown_license 
has 1379 pages now, is your bot going to continue working there?
	As for the code itself, I count 710 extensions with 
$wgExtensionCredits, of which 127 use license-name. ~600 estensions to 
fix means that most don't have a component in the issue tracker, let 
alone jenkins-bot running; so we have no general way to communicate with 
their authors. Also, SPDX license-name patches don't require specialised 
reviewers.
	So, you can file a report in MediaWiki>General/Unknown, but don't 
expect magical elves to pop up. The best way to "report" the missing 
license-name is still to send a patch in gerrit. For this task, I don't 
see us creating a self-merging account à la l10n-bot; but please file a 
bug if you need extra tools.


Nemo

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

Re: [Wikitech-l] [gerrit] EUREKA!

[Federico Leva (Nemo)]

This issue is tracked at https://phabricator.wikimedia.org/T40100 . Cf. 
https://phabricator.wikimedia.org/T55958 , 
https://phabricator.wikimedia.org/T47267#1017438


Nemo

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

Re: [Wikitech-l] Improving our code review efficiency

[Federico Leva (Nemo)]

> But this doesn't remove it from the projects review queue (or search
> queries, if you just use "project:mediawiki/extensions/MobileFrontend
> status:open").

IMHO the distinction between cleaning up personal and global dashboards 
is not so important. In the end, code review is performed by 
individuals. If each reviewer has a more relevant review queue, all 
reviewers will be more efficient and the backlog will decrease for everyone.


After all, we see from 
https://www.mediawiki.org/wiki/Gerrit/Reports/Code_review_activity that 
20 reviewers do 50 % of the merging in gerrit. Some queries like those 
listed at https://www.mediawiki.org/wiki/Gerrit/Navigation show that 
over ten users have over 100 review requests in their dashboards, among 
those who merged something in the last month. I doubt that's efficient 
for them.


Nemo

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

Re: [Wikitech-l] Improving our code review efficiency

[Federico Leva (Nemo)]

The "remove from code review queue" is not that hard really, you can 
just remove yourself (and reviewers you added) from reviewers. The most 
helpful reviewers also comment on why they've removed themselves. If 
reviewers removed themselves from patches they have no intention 
whatsoever to review (which is fine), things would be much easier.


Other effective ways to effectively remove an open patch from the review 
workflows (and from the korma stats, though not from [[Gerrit/Reports]]) 
is to self-give a -1 and/or slap a "[WIP]" in the first line.


Nemo

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

Re: [Wikitech-l] Performance of parsing links?

[Federico Leva (Nemo)]

As of 
https://gerrit.wikimedia.org/r/#/c/29879/2/utils/MessageTable.php,cm , 
Linker::link took 20 KiB of memory per call. Cf. 
http://laxstrom.name/blag/2013/02/01/how-i-debug-performance-issues-in-mediawiki/
I don't know if such bugs/unfeatures and related best practices were 
written down somewhere.


Nemo

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

Re: [Wikitech-l] Thoughts: stateless services with open servers?

[Federico Leva (Nemo)]

The only true precedent we have here is the public Collection server run 
by PediaPress, which is a wonderful service used by several hundreds 
wikis for years. It ensures a comparatively smooth installation of the 
Collection extension even for the most niche formats.

https://www.mediawiki.org/wiki/Extension:Collection#Generating_PDFs.2C_OpenDocument-_.26_DocBook-Exports

One could perhaps also consider DNSBL services by SpamHaus and others. 
https://www.mediawiki.org/wiki/Manual:Combating_spam#DNSBL But I don't 
know how many are using them and they're not really effective, so we 
don't really have a service comparable to Akismet. The "Antispam" 
extension claims to be one, but at the moment it's used by 3 wikis only.


Nemo

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

Re: [Wikitech-l] Idea for new desktop / mobile kiwix like application

[Federico Leva (Nemo)]

> Ok these are all "planned to be implemented" solutions that do not 
work now


You didn't even read, did you? Let me quote:

> I use this code yes and it works

Nemo

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

Re: [Wikitech-l] Idea for new desktop / mobile kiwix like application

[Federico Leva (Nemo)]

You don't need a new application for this, you just need some upgrades 
to the ZIM generation pipeline. How about sending patches for 
https://sourceforge.net/p/kiwix/other/ci/master/tree/mwoffliner to 
generate category-based ZIM files and the like?


Customisation possibilities used to be better here before 
https://www.mediawiki.org/wiki/Offline_content_generator was deployed on 
Wikimedia projects, as ZIM files of few hundreds pages were very easy to 
make on wiki. Help with the OCG component is also appreciated.


Finally, icnremental ZIM updates are an area of ongoing work. You can 
probably help here as well: https://phabricator.wikimedia.org/T49406#492033


Nemo

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

Re: [Wikitech-l] Fwd: No more Architecture Committee?

[Federico Leva (Nemo)]

Bawolff, I don't think the list of attendees of the current SF meeting 
is indicative of anything other than of the difficulty we have in 
talking with non-Wikimedia people; and even within Wikimedia, between 
WMF and non-WMF. Cf. 
https://www.mediawiki.org/wiki/Talk:MediaWiki_Developer_Summit_2015#Name .


As for «fairly regularly active devs for at least 5 years», we simply 
have no idea how many such persons there are outside our fishbowl. If, 
before even starting, we already exclude the iceberg of invisible people 
and use cases, no wonder we stay where we are. You don't need a 
committee to reinforce and calcify existing trends and structures.


If there is a need to expand/strengthen/diversify the committee, I'd 
rather look for members able to enlarge the MediaWiki contributor base 
in new directions. Mark mentioned some examples. Again, all this in the 
assumption we suffer from disunity, see my previous message.


Nemo

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

Re: [Wikitech-l] New feature in development: collections

[Federico Leva (Nemo)]

From 
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-01-14-21.00.log.html 
:
21:15:49  Is this collections thing the same as 
https://www.mediawiki.org/wiki/Mobile_web_projects/Collections_Backend 
(just came up during the research showcase)?


They look related, so I commented on the talk page there. It seems there 
are parallel discussions in other unknown mailing lists, so it's useful 
to centralise on the wiki.


Nemo

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