[Wikimedia-l] Re: We need more interactive content: we are doing it wrong

[Felipe Schenone]

Very well, I just deactivated the gadget from the Spanish Wikipedia and
removed the now broken template from the two articles that used it, until
some decision is made about it. I shared my views at
https://meta.wikimedia.org/wiki/Talk:OWID_Gadget#Three_ideas, in case
anyone's interested. Kind regards,

On Sat, Apr 27, 2024 at 2:50 PM James Heilman  wrote:

> The other option would be to have a copy of the OWID software on our own
> servers (it is all openly licensed). We tried this sort of with the OWID
> mirror which you can see here on the wmcloud
>
> https://owidm.wmcloud.org/
>
> And functional within a mediawiki install here
>
> https://mdwiki.org/wiki/WikiProjectMed_talk:OWID/Archive_1
>
> From what I understand moving in this direction would require the software
> running on production servers with WMF staff support and maintance.
>
> We have already uploaded all the data that makes these graphs to Commons
> by the way.
>
> James
>
> On Sat, Apr 27, 2024 at 11:11 AM Amir Sarabadani 
> wrote:
>
>> (Not Andy, but a global interface admin in my volunteer capacity)
>> Hi,
>> The difference is that here the third party code is being run under the
>> context of Wikipedia. That means even with sandboxing mitigation such as
>> iframe (which has been broken before), it's much easier to break out and
>> collect user credentials such as session information or run any arbitrary
>> action on behalf of the users. While, opening a link explicitly is
>> protected by browsers to make sure they won't be able to access cookies in
>> wikimedia or run arbitrary code on behalf of the user targetting wikimedia
>> projects. That's not impossible to break but it's much much harder (and
>> zero day bugs of this type are in range of millions of dollars). That's why
>> it's recommended to avoid opening unknown links or if you really have to,
>> open them in services such as "Joe's sandbox". What I'm saying is that it's
>> making it easier and cheaper to attack users.
>>
>> The second aspect is trust. Users understand links go to external website
>> we don't control but a dialog is not enough to convey wikimedia's lack of
>> control. People might assume the code or security has been vetted by
>> wikimedia which is not the case. It's worth noting that the click through
>> rate for SSL/TLS security warnings for Chrome was 70% (
>> https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_akhawe.pdf).
>> Even in many cases where it was a legitimate "man in the middle attack". It
>> got better since 2013 but it's still quite high.
>>
>> Another aspect is that, it basically this turns OWID into a target for
>> what's called "watering hole attacks" (
>> https://en.wikipedia.org/wiki/Watering_hole_attack). This is similar to
>> what happened to MeDoc, a tax helper app where it got compromised to launch
>> NotPetya, one of the most devastating cyber attack ever recorded (
>> https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed-the-world/
>> ).
>>
>> It also brings to question of users data being transferred. As far as I
>> know (I might be very wrong), we instruct browsers not to provide referer
>> information to target websites (via noreferrer attribute) so they can't see
>> any information that the user has clicked on Wikipedia while that's no
>> longer the case here and no way to prevent that from happening (I might be
>> wrong again. Writing this on phone).
>>
>> Last but not least, I'm seriously worried about the impact of this change
>> on wikis where editors are in countries that don't have a good track record
>> of respecting human rights. Breaking iframe or compromising OWID is not
>> something a basic hacker can do but it's not hard to do for an APT or a
>> government with deep pockets. That's why I urge you (as a fellow volunteer)
>> to remove this.
>>
>> Hope that helps,
>> Obviously my own ideas and limited knowledge. Not on behalf of WMF or the
>> security team.
>>
>> Best
>>
>> James Heilman  schrieb am Fr., 26. Apr. 2024, 22:16:
>>
>>> Hey Andy
>>>
>>> How is the risk any different than having a reference for a graph that
>>> includes a url which links to OWID? When one clicks on such a url it brings
>>> you to OWID and shares your IP address with them. We have millions of
>>> references that include urls without warnings or consent before loading.
>>>
>>> James
>>>
>>> On Fri, Apr 26, 2024 at 1:44 PM Galder Gonzalez Larrañaga <
>>> galder...@hotmail.com> wrote:
>>>
 Hello Andy,
 There was a solution involving adding the software to our own platform
 instead of loading it. It was dismissed by the Wikimedia Foundation. It's
 not disappointment the word I'm looking for.

 Best

 Galder

 2024(e)ko api. 26(a) 21:38 erabiltzaileak hau idatzi du (
 acoo...@wikimedia.org):

 Hello everyone,

 I’m Andy Cooper, the Director of Security at the Wikimedia Foundation.
 Over the past week, teams within the Wikimedia Foundation 

[Wikimedia-l] Re: The Book Creator

[Felipe Schenone]

Hi again, Galder!
I just "globalized" the template gadget for downloading PDFs, so now it can
be easily installed in the Basque Wikipedia if you feel like it.
See https://www.mediawiki.org/wiki/Template:Download_PDF for the
documentation.
Cheers!
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/DRKIFYGQUBMQC5YOTYUJQXCGCFVMMMAY/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: We need more interactive content: we are doing it wrong

[Felipe Schenone]

Amazing work, James and Galder!

Today I was bold, made it fully multilingual and generalized it so that it
can be easily installed in any wiki (Wikimedia or not).
See https://www.mediawiki.org/wiki/Template:OWID for the documentation
and https://www.mediawiki.org/wiki/MediaWiki:Gadget-OWID.js for the code
and https://www.mediawiki.org/wiki/Template_gadgets for more context

Galder, perhaps you'd like to update the usage at the Basque Wikipedia (see
https://www.mediawiki.org/wiki/Template:OWID) so as to help centralize and
coordinate our efforts?
Some technical notes:
- I simplified the code considerably using the pre-built methods
OO.ui.alert and OO.ui.confirm rather than those complicated (and
unnecessary, in this case) OOUI classes. I hope you like it.
- I wrapped the code with an "OWID" object to keep it out of the global
space and make sure the 'oojs-ui-windows' dependency is always loaded.
- The localized messages should probably be moved to their own JSON file
and loaded from there, but I'm not sure about the best way to do that while
keep it template gadgets centralized at MediaWiki.org, and possibly having
the strings translated by translatewiki.net. Perhaps we can set up a call
to discuss some options?

PS, I enabled the template on the Spanish Wikipedia (see
https://es.wikipedia.org/wiki/Plantilla:OWID) but we're having some local
trouble with template gadgets so it's not working right now. I should be
able to fix it in the next few hours.

On Tue, Apr 16, 2024 at 6:34 PM Galder Gonzalez Larrañaga <
galder...@hotmail.com> wrote:

> Thanks, James, for all the work done,
> We now have 14 articles with interactive graphs, as we are exploring this
> new feature:
> https://eu.wikipedia.org/wiki/Kategoria:Our_World_in_Data_grafikoak_dituzten_artikuluak.
> The deployment is pretty easy, it took around 10 minutes with only four
> things: a template, a css, a js and a gadget definition. This is so simple,
> that I think it should be implemented by everyone.
>
> We should think on how we make it multilingual.
>
> Thanks again to all the members of WikiProject Med for the step forward.
>
> Galder
> --
> *From:* James Heilman 
> *Sent:* Tuesday, April 16, 2024 11:14 PM
> *To:* Wikimedia Mailing List 
> *Subject:* [Wikimedia-l] Re: We need more interactive content: we are
> doing it wrong
>
> We have Interactive graphs from OWID working on Basque Wikipedia,
> following a consent popup.
>
> https://eu.wikipedia.org/wiki/Haurdunaldi#Nerabezaroa
>
> Still need to figure out a way to make them multilingual.
>
> --
> James Heilman
> MD, CCFP-EM, Wikipedian
> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/MFERHIM5S5BNJCM52YYB2Q6T7FO3ZLAL/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
>
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/RKXWQ2QVN6XMFBKHFYDXUWO4SXRL64LK/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: We need more interactive content: we are doing it wrong

[Felipe Schenone]

Hi Galder, I just did this fix
<https://eu.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition=prev=9637458>
and
your Vivarium seems to be working now. The documentation was ok, but a bit
confusing, so I improved it too. Soon I'll send a patch to make those
"special categories" unnecessary. In the meantime, they're a necessary
annoyance, I'm afraid. Cheers!

On Sat, Mar 23, 2024 at 5:37 AM Galder Gonzalez Larrañaga <
galder...@hotmail.com> wrote:

> Thanks Felipe, that's a really great move. I looked to these examples a
> couple o years ago, and this seems that a good option to add some
> interactive content. Anyway, I have tried to replicate it and can't make it
> work (https://eu.wikipedia.org/wiki/Txantiloi:Vivarium). Is the
> documentation right?
>
> Best
>
> Galder
> --
> *From:* Felipe Schenone 
> *Sent:* Friday, March 22, 2024 10:39 PM
> *To:* Wikimedia Mailing List 
> *Subject:* [Wikimedia-l] Re: We need more interactive content: we are
> doing it wrong
>
> Hi everyone, good news!
>
> Thanks to this humble change
> <https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092> 
> (deployed
> today) it is now possible to load a specific gadget when a specific
> template is used in a page. This opens the door (or perhaps a window?) to
> interactive content using JavaScript. See for example this article in the
> Spanish Wikipedia <https://es.wikipedia.org/wiki/Juego_de_la_vida> for an
> interactive instance of Conway's Game of Life, and scroll down for more
> instances!
>
> I started documenting the system at MediaWiki.org, under the title template
> gadgets <https://www.mediawiki.org/wiki/Template_gadgets>, and included
> many working examples. Check it out!
>
> Perhaps the system isn't as friendly or powerful a solution as some might
> hope. But it's very real, and it only depends on us now. Next week, when
> the documentation and examples are a bit more cooked, I'll propose adding a
> few "template gadgets" to the English Wikipedia, since my experience has
> taught me that when something hits the English Wikipedia, it quickly
> spreads elsewhere. I'll link to the proposal when I do, in case you want to
> participate.
>
> There's so much more that could be said about this, but I'd rather keep it
> short. If you have questions or ideas, feel free to write them here or at the
> relevant talk page <https://www.mediawiki.org/wiki/Talk:Template_gadgets>.
>
> Kind regards,
> Felipe (User:Sophivorus)
>
> On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui 
> wrote:
>
> Hi everyone,
>
> I agree that Wikipedia needs to spend a few quarters spending time on our
> main product. The website is very impressively still the top result of a
> huge number of searches and in this new AI age; despite the controversy
> around it, wikipedia is the top source for many LLMs. Therefore while it
> doesn't need to be the only focus or even *the* focus most of the time it
> does need to be kept working but not just kept as is, it needs to be
> innovative and continue to meet the growing demands of a "modern" and
> "useable" site that allow users to get the information they need as fast
> and effectively as possible, these days that means interactivity.
>
> I feel I'm repeating others but a quick burst of very serious investment
> into the site and its many sister pages needs to happen sooner rather than
> later.
> Finally I'd like to thank Marshall again for his remarkable comments. It's
> good to see that this issue is clearly a priority that foundation staff are
> already looking at.
>
> - Daniel.
>
> -
>
>
>
> On Wed, Feb 7, 2024, 09:17 Gnangarra  wrote:
>
> Hi
>
> I just like to highlight one point, that raises concerns;
>
>
> perhaps enabling other platforms/apps to use our content to make
> interactive or video materials there.
>
>
> While this sounds like an easy solution we run into a number of hidden
> costs.  These are significant when we push for reusers to present what we
> are doing in better ways we lose the movement's revenue stream as less
> people see our donation banners.  With less direct traffic we also
> sacrifice the ability to convert readers into contributors which has always
> been our primary source of community sustainability and growth.   I know
> other providers will find different ways to present our efforts in part or
> in whole that is part of our purpose, to do our mission and achieve our
> goals we need prioritise internal solutions.
>
> This also leads us to a related issue that our mission is to make the sum
> of all knowledge freely available. When we look to outs

[Wikimedia-l] Re: We need more interactive content: we are doing it wrong

[Felipe Schenone]

Hi everyone, good news!

Thanks to this humble change

(deployed
today) it is now possible to load a specific gadget when a specific
template is used in a page. This opens the door (or perhaps a window?) to
interactive content using JavaScript. See for example this article in the
Spanish Wikipedia  for an
interactive instance of Conway's Game of Life, and scroll down for more
instances!

I started documenting the system at MediaWiki.org, under the title template
gadgets , and included
many working examples. Check it out!

Perhaps the system isn't as friendly or powerful a solution as some might
hope. But it's very real, and it only depends on us now. Next week, when
the documentation and examples are a bit more cooked, I'll propose adding a
few "template gadgets" to the English Wikipedia, since my experience has
taught me that when something hits the English Wikipedia, it quickly
spreads elsewhere. I'll link to the proposal when I do, in case you want to
participate.

There's so much more that could be said about this, but I'd rather keep it
short. If you have questions or ideas, feel free to write them here or at the
relevant talk page .

Kind regards,
Felipe (User:Sophivorus)

On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui 
wrote:

> Hi everyone,
>
> I agree that Wikipedia needs to spend a few quarters spending time on our
> main product. The website is very impressively still the top result of a
> huge number of searches and in this new AI age; despite the controversy
> around it, wikipedia is the top source for many LLMs. Therefore while it
> doesn't need to be the only focus or even *the* focus most of the time it
> does need to be kept working but not just kept as is, it needs to be
> innovative and continue to meet the growing demands of a "modern" and
> "useable" site that allow users to get the information they need as fast
> and effectively as possible, these days that means interactivity.
>
> I feel I'm repeating others but a quick burst of very serious investment
> into the site and its many sister pages needs to happen sooner rather than
> later.
> Finally I'd like to thank Marshall again for his remarkable comments. It's
> good to see that this issue is clearly a priority that foundation staff are
> already looking at.
>
> - Daniel.
>
> -
>
>
>
> On Wed, Feb 7, 2024, 09:17 Gnangarra  wrote:
>
>> Hi
>>
>> I just like to highlight one point, that raises concerns;
>>
>>
>> perhaps enabling other platforms/apps to use our content to make
>> interactive or video materials there.
>>
>>
>> While this sounds like an easy solution we run into a number of hidden
>> costs.  These are significant when we push for reusers to present what we
>> are doing in better ways we lose the movement's revenue stream as less
>> people see our donation banners.  With less direct traffic we also
>> sacrifice the ability to convert readers into contributors which has always
>> been our primary source of community sustainability and growth.   I know
>> other providers will find different ways to present our efforts in part or
>> in whole that is part of our purpose, to do our mission and achieve our
>> goals we need prioritise internal solutions.
>>
>> This also leads us to a related issue that our mission is to make the sum
>> of all knowledge freely available. When we look to outside parties to share
>> our efforts we lose our ability to ensure that the information is neutral,
>> and that it's freely accessible.  Butch is right in noting that when we put
>> funding into third party sites it is taking resources away from the
>> movement, yet those same funds were donated to us on the basis of
>> maintaining and building our infrastructure.  It would be a wise investment
>> to enable some of those much needed interactive and video content here
>> through purchasing rights.
>>
>> On Wed, 7 Feb 2024 at 12:20, Butch Bustria  wrote:
>>
>>> Hi Everyone,
>>>
>>> My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual
>>> Financial Plan prioritize and I mean put first among all is the technical
>>> infrastructure among all its budgetary items. We can scale down budgets to
>>> 3rd party organizations like the Knowledge Equity Fund, Movement Strategy
>>> Governance funding, campaign grants, and other "wants" to accomodate a
>>> highly technically reliable and stable Wikimedia online projects ("needs"),
>>> future proof, and user friendly experience which require investments on
>>> quality manpower, hardware, applications and the like. We love open source
>>> but we also be pragmatic and wise on selection of choices because we want
>>> our content be conveniently available and reliable to our readers, users,
>>> consumers and also editors.
>>>
>>> A welcome development is the 

[Wikimedia-l] Re: Mopping with the tap open

[Felipe Schenone]

Thanks Benoit, I'm so happy to see the Editing Team and the WMF are working
on this! I think it will be another great success, just like the talk pages
project. Keep up the good work !!

El sáb., 9 de mar. de 2024 9:43 a. m., Galder Gonzalez Larrañaga <
galder...@hotmail.com> escribió:

> Hello,
> When I was born, I didn't know how to speak or walk. When I started in the
> school, I didn't know how to multiply 2x2. When I started in the
> University, I didn't know how to research a topic within academy standards.
> When I first drove a car in the driving school, I didn't know how to drive
> properly. In everyone of these learning steps, I had someone helping me: my
> parents, my teachers, my professors, my driving-teacher(?). When I started
> writing in Wikipedia, I didn't know what a template was, how to make a
> redirect, what to link or not and how to properly add a reference. Instead
> of just deleting things, we (the community) should help newbies. You can
> learn with a text written inside a box or whatever, but way better is if we
> help them, take what they did and correct it and let them improve. Could
> the editing platform be better designed? For sure. But we are a community.
> It is in our hands to be rude with the newbies or welcoming. I try to chose
> the second one.
>
> Best,
>
> Galder
>
>
>
>
>
> --
> *From:* Gnangarra 
> *Sent:* Saturday, March 9, 2024 1:18 PM
> *To:* effeietsand...@gmail.com ; Wikimedia
> Mailing List 
> *Subject:* [Wikimedia-l] Re: Mopping with the tap open
>
> could there be message box that asks a simple question like "thank you for
> the contribution, where did you get this information from?" with a text
> field, it just adds it to the edit description. so something is captured in
> the edit history.
>
> On Sat, 9 Mar 2024 at 10:25, effe iets anders 
> wrote:
>
> Thanks Benoit,
> This sounds like a good step in the right direction. We'll need to try out
> several of these approaches, but also improve our own documentation on
> nl.wikipedia. My impression is that it is currently far too hard to add a
> reference, to expect that this is done by most new contributors.
>
> Do we know more about:
> * How many new contributors know they should add a reference, e.g. when
> writing a new article
> * If they know that they should add a reference, how many know how to
> recognize a good reference from a poor one
> * How many new contributors, if they know that they should add a
> reference, can figure out how to actually make this happen (assuming they
> know the url already)
> * Assuming that they can find the reference button, and know their URL, in
> how many cases does the auto-convert feature work? (we could test this by
> taking a random sample of reference URLs, and entering them in the
> reference insertion tool)
>
> These are not just technical problems - some of them are more about
> awareness (we can focus for example a little less on copyright, and more on
> other quality aspects) or good documentation (how to recognize a good
> source?). I also suspect that these numbers might vary quite a bit across
> communities/countries.
>
> In my personal experience, it is hard to add references to articles even
> if all the 'social' steps work smoothly (they often dont!). Maybe my sample
> is biased, but it feels like I get much more often an error in nlwiki when
> I try to convert a url to a citation, than in enwiki. Does anyone know if
> this is indeed the case? Is anyone tracking statistics on this?
>
> Best,
> Lodewijk
>
> On Wed, Mar 6, 2024 at 4:03 PM  wrote:
>
> Hello
>
> Some wikis have added the requirement to add citations at the edit summary
> step. But it is clearly too late in the process, as users just want to
> publish. Some users will add citations as a second step, but it might be
> too late, as the edit has a great chance of being reverted meanwhile.
>
> You might be interested in the Editing team's current project, Edit check <
> https://www.mediawiki.org/wiki/Edit_check>.
>
> This project aims to provide in-context help by checking on the edit. The
> first iteration is "Reference Check": if a user adds a paragraph with zero
> source, they are encouraged to add one. We are currently testing it at 22
> Wikipedias, to verify if the prompt to add citations is not blocking users.
>
> You can test it at your wiki using an URL parameter:
> 1. Edit any article in the main namespace using the VisualEditor.
> 2. Add =1 to the URL in your browser. -- For example in Dutch, as
> Romaine started the thread:
> https://nl.wikipedia.org/w/index.php?title=Zon=edit=1
> 3. Reload the page with the new URL.
> 4. Create a new paragraph, that is at least 50 characters long without
> adding a citation
> 5. Press the Publish… Notice the prompt that appears
> 6. Test is completed, don't save your edit unless you know what you are
> doing.
>
> All edits are tagged, so that you can find them in Recent Changes or in
> your Watchlist. If a user selects 

[Wikimedia-l] Re: Mopping with the tap open

[Felipe Schenone]

I couldn't agree more, it reminds me of a principle in UX/UI (can't recall
its "name" or exact wording) that emphasises the importance of giving help
exactly when it's needed, not before nor after.

On Wed, Mar 6, 2024 at 10:59 AM Romaine Wiki  wrote:

> In the past days, a new Wikipedia contributor edited Wikipedia and made a
> great contribution, except... This user added zero sources, and the article
> in what the edit was made was about a living person. So the verifiability
> is a problem and in conflict with the policy Biographies of living persons.
> This was just one example of thousands that have to be dealt with every day
> in Wikimedia. And every day the community tries to maintain the quality of
> Wikipedia and has to deal with this kind of edits.
>
> I asked myself the question: why did this new contributor not add any
> sources?
>
> I logged out, went to an article and clicked edit. Made some modifications
> (in the Visual Editor), and then clicked Publish changes. In the steps I
> took to edit the article, I got nowhere a message that Wikipedia wants to
> have sources for the information I added. Nowhere!
>
> I hope that every experienced user by now understands the importance of
> adding sources. But we cannot expect from new contributors to already know
> this. They need to be informed that adding sources is needed. They do not
> go first read the manual of Wikipedia with all the help and project pages,
> they just start editing right away. They think, link in many other
> platforms, that if they do something wrong, they get a message while
> editing/uploading/etc.
>
> For some strange reason, if you edit Wikipedia, you get no notification at
> all that you need to add sources, even while this is one of the most
> important pillars of Wikipedia. The result is that a lot of work of these
> new contributors gets lost, because the information is removed from the
> articles because of a lack of sources. If those new users would have got a
> message in the Visual Editor during the editing, a lot more contributions
> would be able to stay in Wikipedia, less new contributors would get
> demotivated, and it would reduce the workload of existing users who do the
> maintenance every day.
>
> As with the influx of edits without sources nothing is done, the Dutch
> expression "mopping with the tap open" (Dutch: dweilen met de kraan open)
> applies here.
>
> Romaine
>
>
>
>
>
> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/2J32V233R72OWB5W2DKGXIGBPVC6Y75B/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/QPP55RJYYLOTONO4HENABWMYKIFT5YP2/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: Disparity of official statistics: Stats vs Pageviews

[Felipe Schenone]

Hi! I think the discrepancy is because Wikimedia Stats counts all views by
default, whereas Siteviews only counts User views (excluding Bots and
Spiders) by default. Once you exclude Bots and Spiders from Wikimedia
Stats, or include them in Siteviews, the figures match.

On Thu, Feb 15, 2024 at 9:30 AM F. Xavier Dengra i Grau via Wikimedia-l <
wikimedia-l@lists.wikimedia.org> wrote:

> Bon dia / Hi,
>
> I would like to ask around about the fact that we have very significant
> imbalances of official statistics when it comes to the traffic in our wiki
> projects.
>
> Let's look at the reading gross value for the English Wikipedia on January
> 2024. Without applying any kind of filtering to their searching method, the
> website Wikimedia Stats shows 12.697.373.117 visits, while the Pageviews
> tool from the WikimediaCloud in Toolforge yields 8.864.755.474 visits.
>
> This is a huge figure disparity, and both data repositories are hosted
> "under the same roog" and most likely are the two more widely used tools
> for this purpose. Am I wrong? For a smaller project, like the Catalan
> Wikipedia, there is a 19.5M vs 64.5M inconsistency... Which changes a lot
> our conclusions in a tech situation in which we are socially dealing with
> Google hiding results in our language from its search engine since a couple
> of years ago. What am I missing about these value differences? As an
> experienced editor, I have been regularly digging in our available data
> tools for several years. But it's difficult not to encounter frequent
> problems of comparability, false positives, and reliability. Not only for
> my personal pleasure, but when it comes to easily explain our projects'
> data to the outside world via referring to a trustworthy portal.
>
> That adds up to the fact that we are not able to see itemised statistics
> for some small countries in Wikimedia Stats. We can filter how many
> millions of visits does the Dutch Wikipedia get in Belgium or in the
> Netherlands, but we cannot see which is the language use of each Wikipedia
> in Belgium (% of readers that accesses it in French, Dutch, German,
> Walloon, Picard, English, etc). That feature disappeared in 2018 with the
> last update of the dismantled WiViVi portal. Altogether, it makes it
> impossible to tackle biases or plan actions by chapters, user groups or
> even academic policies regarding awareness or revitalization of minoritized
> and endangered languages.
>
> I am afraid that, this being my experience as a long-term editor, the ones
> of newcomers, journalists, or even scientists may still be much more
> uncertain and confusing. Hopefully someone can help to figure out some of
> these questions.
>
> Salutacions / Best regards,
>
> Xavier Dengra
>
> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/JBLMMPOU57YE27VD7QFFQB2UQCPX7VOF/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/PKWEDUKAVDH6VUZ2YQTSS3LMXORJ6FOU/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: We need more interactive content: we are doing it wrong

[Felipe Schenone]

Well, perhaps you'll be elated to know then that the grants for tech seem
to have been removed
<https://meta.wikimedia.org/w/index.php?title=Grants:Start=prev=26136082>
after
many months of waiting for them
<https://meta.wikimedia.org/wiki/Grants_talk:Start#Timeline_for_%22Wikimedia_Technology_Fund%22>
.
We're doing it wrong, indeed.

El mié., 31 de ene. de 2024 11:02 p. m., Gnangarra 
escribió:

> Before the WMF starts hiring, we need to be very clear exactly what
> pathways and objectives we want to pursue, along with what functions should
> be internally maintained. With that what happens with community built tools
> that cross over from great tools to essential community infrastructure that
> needs continued updates.  Perhaps part of the "hiring" option is rewarding
> volunteers who create them to help transition the tool to the internal
> system.
>
> On Thu, 1 Feb 2024 at 01:35, Felipe Schenone  wrote:
>
>> I also think the WMF should prioritize hiring more developers over other
>> roles and expenditures. The WMF has only a few hundred developers while
>> other top sites have many thousands. While this efficiency is something to
>> be proud of, it evidently comes at a cost.
>>
>> El mié., 31 de ene. de 2024 4:08 a. m., rupert THURNER <
>> rupert.thur...@gmail.com> escribió:
>>
>>> On Wed, Jan 31, 2024 at 1:27 AM Gergő Tisza  wrote:
>>>
>>>> On Tue, Jan 30, 2024 at 1:57 PM Ori Livneh 
>>>> wrote:
>>>>
>>>>> If we're collecting exemplars, I'd like to add Bartosz
>>>>> Ciechanowski's superlative articles <https://ciechanow.ski/archives/>,
>>>>> like the ones on bicycles <https://ciechanow.ski/bicycle/> and sound
>>>>> <https://ciechanow.ski/sound/>. His articles are the best examples I
>>>>> know of interactive content that complements long-form text content.
>>>>>
>>>>
>>>> This concept was popularized by Bret Victor under the name "explorable
>>>> explanations <http://worrydream.com/ExplorableExplanations/>". There
>>>> is a whole Wikipedia article
>>>> <https://en.wikipedia.org/wiki/Explorable_explanation> on it. There
>>>> are some great examples on his website, and there are some websites for
>>>> collecting similar content, such as explorabl.es and an awesome list
>>>> <https://github.com/blob42/awesome-explorables>. I agree they are
>>>> really cool but...
>>>>
>>>>
>>>>> The critical issue is *security*. Security is the reason the graph
>>>>> extension is not enabled. Security is the reason why interactive SVGs are
>>>>> not enabled. Interactive visualizations have a programmatic element that
>>>>> consists of code that executes in the user's browser. Such code needs to 
>>>>> be
>>>>> carefully sandboxed to ensure it cannot be used to exfiltrate user data or
>>>>> surreptitiously perform actions on wiki.
>>>>>
>>>>
>>>> I think it's fundamentally a human scaling problem. Being able to
>>>> create good interactive content is just a much more niche skill than being
>>>> able to create good text content. Interactive animations were very much
>>>> part of Yuri's vision
>>>> <https://meta.wikimedia.org/wiki/User:Yurik/I_Dream_of_Content> for
>>>> the Graph extension, but during the decade Graph was deployed in production
>>>> the number of such animations made was approximately zero. Granted Vega is
>>>> probably not the easiest framework for creating animations, but I don't
>>>> think there are other tools which would make it much easier. You could just
>>>> write arbitrary Javascript and package it as a gadget; but no one did that
>>>> either. Instead, both gadgets and Graph usage are mostly focused on very
>>>> basic things like showing a chess board or showing bar charts, because
>>>> those are the things that can be reused across a large number of articles
>>>> without manually tailoring the code to each, so the economics of creating
>>>> them work out.
>>>>
>>>
>>>> Security is a challenge but could be worked around via iframes. But
>>>> it's hard to justify the effort required for doing that when there is no
>>>> community of animation makers interested in it - there are plenty of
>>>> volunteers who want to *have* animations, but it's not very clear that
>>>> there are any who 

[Wikimedia-l] Re: We need more interactive content: we are doing it wrong

[Felipe Schenone]

I also think the WMF should prioritize hiring more developers over other
roles and expenditures. The WMF has only a few hundred developers while
other top sites have many thousands. While this efficiency is something to
be proud of, it evidently comes at a cost.

El mié., 31 de ene. de 2024 4:08 a. m., rupert THURNER <
rupert.thur...@gmail.com> escribió:

> On Wed, Jan 31, 2024 at 1:27 AM Gergő Tisza  wrote:
>
>> On Tue, Jan 30, 2024 at 1:57 PM Ori Livneh  wrote:
>>
>>> If we're collecting exemplars, I'd like to add Bartosz
>>> Ciechanowski's superlative articles ,
>>> like the ones on bicycles  and sound
>>> . His articles are the best examples I
>>> know of interactive content that complements long-form text content.
>>>
>>
>> This concept was popularized by Bret Victor under the name "explorable
>> explanations ". There is
>> a whole Wikipedia article
>>  on it. There are
>> some great examples on his website, and there are some websites for
>> collecting similar content, such as explorabl.es and an awesome list
>> . I agree they are really
>> cool but...
>>
>>
>>> The critical issue is *security*. Security is the reason the graph
>>> extension is not enabled. Security is the reason why interactive SVGs are
>>> not enabled. Interactive visualizations have a programmatic element that
>>> consists of code that executes in the user's browser. Such code needs to be
>>> carefully sandboxed to ensure it cannot be used to exfiltrate user data or
>>> surreptitiously perform actions on wiki.
>>>
>>
>> I think it's fundamentally a human scaling problem. Being able to create
>> good interactive content is just a much more niche skill than being able to
>> create good text content. Interactive animations were very much part of
>> Yuri's vision
>>  for the
>> Graph extension, but during the decade Graph was deployed in production the
>> number of such animations made was approximately zero. Granted Vega is
>> probably not the easiest framework for creating animations, but I don't
>> think there are other tools which would make it much easier. You could just
>> write arbitrary Javascript and package it as a gadget; but no one did that
>> either. Instead, both gadgets and Graph usage are mostly focused on very
>> basic things like showing a chess board or showing bar charts, because
>> those are the things that can be reused across a large number of articles
>> without manually tailoring the code to each, so the economics of creating
>> them work out.
>>
>
>> Security is a challenge but could be worked around via iframes. But it's
>> hard to justify the effort required for doing that when there is no
>> community of animation makers interested in it - there are plenty of
>> volunteers who want to *have* animations, but it's not very clear that
>> there are any who want to *make* animations. This is the same problem
>> geni mentioned for videos - a lot of people say "we should have more
>> videos", but it's not very clear who would make them. If platform support
>> were the bottleneck here, I think the platform support would happen. But as
>> things look now, it would just be a poor investment of resources IMO
>> (compared to e.g. the Gadgets extension or Toolforge or Scribunto which do
>> sustain vibrant volunteer ecosystems which are significantly held back by
>> the limitations of these platforms).
>>
>
> thank you for sharing ori and gergo. coming from i opened the page "how to
> tune a guitar": https://mathisonian.github.io/idyll/how-to-tune-a-guitar/,
> and the readings about "reinventing human explanations" and so on:
> https://explorabl.es/reading/. the sheer number of examples is saw out of
> these links does not sound like there is a lack of persons who love to do
> that.
>
> rupert
> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/7A6223FVC4SRJQSPZQLO5EILX7N7HZEG/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/WJHXZMUH7QRMYU5SR5HU5OZNN7SD7M5D/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: The Book Creator

[Felipe Schenone]

Hi! Today I coded a simple template that is able to generate something like
a book and prompt the user to print or download it.
See https://en.wikiversity.org/wiki/Template:Download_PDF for usage and
https://en.wikiversity.org/wiki/MediaWiki:TemplateScript-DownloadPDF.js for
the code.
As you can see, I put it on the English Wikiversity rather than the Basque
Wikipedia. This is because template scripts
 are not yet enabled on the
Basque Wikipedia.
If you see potential in this approach, you may want to write to your
community and have template scripts enabled there. Then you can copy-paste
the template and code and improve upon it.
I too miss the Collection extension, but it's been too long to hope for a
fix. Perhaps this approach holds more water, at least in the short/mid
term. There's quite a lot that can be done via JavaScript like this.
Cheers!

On Wed, Dec 27, 2023 at 4:01 PM Galder Gonzalez Larrañaga <
galder...@hotmail.com> wrote:

> Dear all,
> Some years ago, when we started the Education Program at the Basque
> Wikipedia, we used a lot the Book Creator (or Collections) extension. It
> allowed to bind some articles and download them in PDF or DOC/ODT formats
> for further editing (https://en.wikipedia.org/wiki/Special:Book). This
> was a great feature, as it allowed us to send the teachers and students a
> collection of articles they had created. The teacher could create free
> learning materials from the articles created by their students, and
> download them in DOC/ODT format allowed to edit them, rearrange and add
> other materials. Some teachers said us that they have created learning
> materials using Wikipedia articles created by their students.
>
> Anyway, in 2017 the Wikimedia Foundation decided to break the book
> creator, because there were some errors in the PDF creator. So they
> disabled the book creator and added a note saying that the system is
> "Undergoing changes". The message is still visible, but no changes are
> being done. (You can follow the last messages of redesigning the book
> creator here:https://phabricator.wikimedia.org/T175681).
>
> I know that this is not the most important feature that is broken. There
> are many other broken things. But creating materials for students, and
> being able to read them offline or edited by teachers is a feature that
> aligns with our mission and vision. As always happens, no one is
> accountable for having something broke for six years. And it doesn't seem
> that this feature will return in the future. At least, the PediaPress link
> is still working, but there you can't edit your book, only pay for have it
> printed.
>
> I think no one knows what will happen with this feature. I write this
> message simply to say that I miss it a lot.
>
> Thanks
>
> Galder Gonzalez
> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/4SYP6PBBRPJUGKAJ6S4MMEPNJHMEI2A7/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
>
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/3FSWVVHPBXENYOISFW2VFXR65YQ4PAS6/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: Wikimedia Hackathon 2024: Register and Apply for Scholarships Now!

[Felipe Schenone]

Hi!
I'm a MediaWiki developer from Argentina and I've refrained from going to
any more Wikimedia Hackathons since Vienna 2017, because of the high carbon
emissions that my participation would cause. I'd also love to see a
solution that allows me to participate without having to travel half the
world.
Kind regards,

On Mon, Dec 11, 2023 at 7:12 PM Onyinyechi Onifade 
wrote:

> Hi tim.h...@gmx.de,
>
> Thank you for sharing your perspective on the Wikimedia Hackathon 2024. We
> appreciate your preference for virtual or decentralized events, especially
> considering the environmental impact of long-distance travel.
>
> We'll keep your thoughts in mind as we continue to evolve and improve the
> format of the Wikimedia Hackathon in the coming years. If you have any
> further suggestions or specific ideas, feel free to share them. Your input
> is crucial in shaping the direction of our events.
>
> Best regards,
>
> On Tue, Nov 28, 2023 at 9:56 PM  wrote:
>
>> Hello,
>>
>> I think it is great that there will be no fee to attend at the Wikimedia
>> Hackathon 2024. I prefer virtual events or visiting a decentralized event
>> nearby if an onsite attendence likely requires long distance travelling. At
>> the moment I dont like to use a plane to travel to a place. From my point
>> of view the enviromental impact of the Wikimedia Hackathon is very high. As
>> I come from Germany I have the regular opportunity to meet other people who
>> are participating in the Wikimedia projects and so this has an influence on
>> my point of view. There are other chances to meet people who are involved
>> in the Wikimedia projects. What do you think about the enviromental impact
>> of the Wikimedia Hackathon. As you have announced it already I have no
>> problem if the next Wikimedia Hackathon happens as an onsite event. For
>> further editions of the Wikimedia Hackathon I hope that there will be a
>> more decentralized version of it that helps to avoid long distance
>> travelling where it seems to be possible.
>> ___
>> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
>> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
>> https://meta.wikimedia.org/wiki/Wikimedia-l
>> Public archives at
>> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/QN5J4C6STD2OQVVFJTEOT7Y2FKA2BRWY/
>> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
>>
> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/5ZE3HRZWEFPWDPMFYD6HL7PXNTX4ASHE/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/3S52BWBDTJ3WUUVC3IF5XO6Z72NZS74E/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: ChatGPT as a reliable source

[Felipe Schenone]

FYI, yesterday I stumbled upon Perplexity , an
AI that cites its sources for its answers. After a couple tests, I'm not
convinced on how tight the connection is between the generated text and the
sources, but they seem at least to broadly support the claims.

On Thu, May 18, 2023 at 8:30 AM Peter Southwood <
peter.southw...@telkomsa.net> wrote:

> It depends on how much you know about the topic, Both methods have their
> advantages.
>
> Cheers,
>
> Peter
>
>
>
> *From:* Todd Allen [mailto:toddmal...@gmail.com]
> *Sent:* 17 May 2023 20:10
> *To:* Wikimedia Mailing List
> *Subject:* [Wikimedia-l] Re: ChatGPT as a reliable source
>
>
>
> Though, this does run the risk of encouraging people to take the
> "backwards" approach to writing an article--writing some stuff, and then
> (hopefully at least) trying to come up with sources for it.
>
>
>
> The much superior approach is to locate the available sources first, and
> then to develop the article based upon what those sources say.
>
>
>
> Todd
>
>
>
> On Wed, May 17, 2023 at 12:06 PM Samuel Klein  wrote:
>
>
>
> First: Wikipedia style for dense inline citations is one of the most
> granular and articulate around, so we're pushing the boundaries in some
> cases of research norms for clarity in sourcing.  That's great; also means
> sometimes we are considering nuances that may be new.
>
>
>
> Second: We're approaching a topic close to my heart, which is
> distinguishing reference-sources from process-sources.  Right now we often
> capture process sources (for an edit) in the edit summary, and this is not
> visible anywhere on the resulting article.  Translations via a translate
> tool; updates by a script that does a particular class of work (like
> spelling or grammer checking); applying a detailed diff that was
> workshopped on some other page.  An even better interface might allow for
> that detail to be visible to readers of the article [w/o traversing the
> edit history], and linked to the sections/paragraphs/sentences affected.
>
>
>
> I think any generative tools used to rewrite a section or article, or to
> produce a sibling version for a different reading-level, or to generate a
> timeline or other visualization that is then embedded in the article,
> should all be cited somehow.  To Jimbo's point, that doesn't belong in a
> References section as we currently have them.  But I'd like to see us
> develop a way to capture these process notes in a more legible way, so
> readers can discover them without browsing the revision history.
>
>
>
> People using generative tools to draft new material should find reliable
> sources for every claim in that material, much more densely than you would
> when summarizing a series of sources yourself.
>
> However, as we approach models that can discover sources and check facts,
> a combination of those with current generative tools could produce things
> closer to what we'd consider acceptable drafts, and at scale could generate
> reference works in languages that lack them.  I suggest a separate project
> for those as the best way to explore the implications of being able to do
> this at scale, and should capture the full model/tuning/prompt details of
> how each edit was generated.  Such an automatically-updated resource would
> not be a good reliable source, just as we avoid citing any tertiary
> sources, but could be a research tool for WP editors and modelers alike.
>
>
>
> SJ
>
>
>
> On Wed, May 17, 2023 at 9:27 AM Jimmy Wales 
> wrote:
>
> One way I think we can approach this is to think of it as being the latest
> in this progression:
>
> spellchecker -> grammar checker -> text generation support
>
> We wouldn't have any sort of footnote or indication of any kind that a
> spellchecker or grammar checker was
> used by an editor, it's just built-in to many writing tools.  Similarly,
> if writing a short prompt to generate a longer
> text is used, then we have no reason to cite that.
>
> What we do have, though, is a responsibility to check the output.
> Spellcheckers can be wrong (suggesting the correct
> spelling of the wrong word for example).  Grammar checkers can be wrong
> (trying to correct the grammar of a direct quote
> for example).  Generative AI models can be wrong - often simply making
> things up out of thin air that sound plausible.
>
> If someone uses a generative AI to help them write some text, that's not a
> big deal.  If they upload text without checking
> the facts and citing a real source, that's very bad.
>
>
>
> On 2023-05-17 11:51, The Cunctator wrote:
>
> Again at no point should even an improved version be considered a source;
> at best it would be a research or editing tool.
>
>
>
> On Wed, May 17, 2023, 4:40 AM Lane Chance  wrote:
>
> Keep in mind how fast these tools change. ChatGPT, Bard and
> competitors understand well the issues with lack of sources, and Bard
> does sometimes put a suitable source in a footnote, even if it
> (somewhat disappointingly) 

[Wikimedia-l] Re: [Wikitech-l] Re: Reflecting on my listening tour

[Felipe Schenone]

Just to put things into perspective, in Argentina, earning USD 4000 a month
means you're the fucking king. You can rent almost any place you want, buy
food and all necessities, eat out everyday, and have enough left over to
buy some land or a house in a few years. By contrast, a quick Google search
suggests that renting a 1-bedroom apartment in NYC costs around USD 4000,
while in Silicon Valley costs around USD 2500. I may be wrong, but judging
from https://meta.wikimedia.org/wiki/Wikimedia_Foundation_salaries I can
see that nowadays, WMF salaries don't go below USD 200,000 per year, or USD
16,000 a month.

Rather than morally bankrupt, I'd argue that bringing salaries of even USD
5000 per month to people in countries like mine would be an economic
bonanza and a smart use of resources, a win-win situation. Regarding labor
laws, many non-US countries, like mine, have quite stringent labor laws
(such as Argentina, due to a long history of syndicalism). Perhaps it's
just a matter of finding countries that balance both criteria. I'm not sure
that expanding development to cheaper countries is the solution to all of
WMF software problems, but I think it could help a lot.

On Tue, Apr 18, 2023 at 8:55 AM Gnangarra  wrote:

> or the 3am meetings
>
> On Tue, 18 Apr 2023 at 19:49, Gnangarra  wrote:
>
>> Hiring people because they are in such countries as the basis for saving
>> money is morally bankrupt,  yet we'll happily draw from the pool of
>> donations that primarily come from those more expensive countries.  Much
>> like we talk about equity but decide that some places arent worth engaging
>> in because its too far to travel leaving others to shoulder the burden of
>> travel.
>>
>> On Tue, 18 Apr 2023 at 19:35, Felipe Schenone 
>> wrote:
>>
>>> Yet in some countries, like mine, paying for food, renting a place,
>>> buying a house, etc. is far cheaper than in the US, so paying a lower
>>> salary (in USD) wouldn't amount to a lower standard of living at all, and
>>> doesn't feel immoral, at least to me.
>>>
>>> On Tue, Apr 18, 2023 at 8:00 AM Gnangarra  wrote:
>>>
>>>>  Either we make software development cheaper somehow (move the WMF to
>>>>> Romania or something)
>>>>
>>>>
>>>> Hiring in countries with the worst labour laws and cheapest minimum
>>>> wages is totally immoral. Especially in a community where equity is part of
>>>> our culture we must endeavour to ensure that employees/contractors
>>>> regardless of where they live paid fairly and equally subject to skills and
>>>> responsibilities of the role.  WMF already has many employees that are
>>>> based in countries where such immoral employment conditions dominate.
>>>>
>>>>>
>>>> On Tue, 18 Apr 2023 at 05:49, Dan Garry (Deskana) 
>>>> wrote:
>>>>
>>>>> I agree with much of what Amir has said here, except one little bit...
>>>>>
>>>>> On Mon, 17 Apr 2023 at 20:52, Amir Sarabadani 
>>>>> wrote:
>>>>>
>>>>>> And even if a software would have an owner, it used to be that the
>>>>>> team was under so much pressure to produce new things instead of
>>>>>> maintenance that the software would practically be without a maintainer 
>>>>>> (or
>>>>>> worse, as even volunteers couldn't unofficially take the role). I can
>>>>>> example a few.
>>>>>>
>>>>>
>>>>> I think pressure on a team to deliver new things is *one* reason why
>>>>> this situation has come about, but it's far from being the only one. 
>>>>> Here's
>>>>> a few others off the top of my head:
>>>>>
>>>>>- Owning so many things that even if there was zero pressure to
>>>>>deliver new features, the team still couldn't maintain everything that 
>>>>> they
>>>>>own.
>>>>>- Incredibly powerful and incredibly complex features that teams
>>>>>are afraid of touching lest they break them and make community members
>>>>>angry.
>>>>>- Conservatism and fear of community outrage causing reluctance to
>>>>>deprecate functionality.
>>>>>- Lack of understanding of the impact of the feature.
>>>>>- Lack of a clear roadmap (a list of bug reports and feature
>>>>>requests is not a roadmap).
>>>>>
>>>>> There's more but those are some that co

[Wikimedia-l] Re: [Wikitech-l] Re: Reflecting on my listening tour

[Felipe Schenone]

Yet in some countries, like mine, paying for food, renting a place, buying
a house, etc. is far cheaper than in the US, so paying a lower salary (in
USD) wouldn't amount to a lower standard of living at all, and doesn't feel
immoral, at least to me.

On Tue, Apr 18, 2023 at 8:00 AM Gnangarra  wrote:

>  Either we make software development cheaper somehow (move the WMF to
>> Romania or something)
>
>
> Hiring in countries with the worst labour laws and cheapest minimum wages
> is totally immoral. Especially in a community where equity is part of our
> culture we must endeavour to ensure that employees/contractors regardless
> of where they live paid fairly and equally subject to skills and
> responsibilities of the role.  WMF already has many employees that are
> based in countries where such immoral employment conditions dominate.
>
>>
> On Tue, 18 Apr 2023 at 05:49, Dan Garry (Deskana) 
> wrote:
>
>> I agree with much of what Amir has said here, except one little bit...
>>
>> On Mon, 17 Apr 2023 at 20:52, Amir Sarabadani 
>> wrote:
>>
>>> And even if a software would have an owner, it used to be that the team
>>> was under so much pressure to produce new things instead of maintenance
>>> that the software would practically be without a maintainer (or worse, as
>>> even volunteers couldn't unofficially take the role). I can example a few.
>>>
>>
>> I think pressure on a team to deliver new things is *one* reason why
>> this situation has come about, but it's far from being the only one. Here's
>> a few others off the top of my head:
>>
>>- Owning so many things that even if there was zero pressure to
>>deliver new features, the team still couldn't maintain everything that 
>> they
>>own.
>>- Incredibly powerful and incredibly complex features that teams are
>>afraid of touching lest they break them and make community members angry.
>>- Conservatism and fear of community outrage causing reluctance to
>>deprecate functionality.
>>- Lack of understanding of the impact of the feature.
>>- Lack of a clear roadmap (a list of bug reports and feature requests
>>is not a roadmap).
>>
>> There's more but those are some that come to the top of my head. And, not
>> everyone one of those always applies to every situation, e.g. I definitely
>> don't think all of the items in your list should be deprecated!
>>
>> This causes the path of least resistance to be, for everyone involved, to
>> leave things in limbo and hope for the best.
>>
>> Dan
>> ___
>> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
>> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
>> https://meta.wikimedia.org/wiki/Wikimedia-l
>> Public archives at
>> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/Y4YKOLNJKWAUQFNOVMZSKDSZRORSWFNB/
>> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
>
>
>
> --
> Boodarwun
> Gnangarra
> 'ngany dabakarn koorliny arn boodjera dardoon ngalang Nyungar
> koortaboodjar'
>
> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/P2JSB3JJ6ZOLPMBYV3EPYDP5RALWN7O6/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/OSWIMESHLJQ57TRBXAIEYTW7YLSDKX7V/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: Bing-ChatGPT

[Felipe Schenone]

FYI, there's an open letter requesting a 6-month pause on AI development
, with
reasonable arguments (in my opinion) and signed by several big names too.
The basic rationale, as I understand it, is that similar to human
cloning, human germline modification, gain-of-function research and other
world-changing and potentially dangerous technologies, there should be some
kind of procedure to ensure that safety keeps pace with development, which
the current AI race is not allowing.

On Sun, Mar 19, 2023 at 5:20 AM Kimmo Virtanen 
wrote:

> Or, maybe just require an open disclosure of where the bot pulled from and
>> how much, instead of having it be a black box? "Text in this response
>> derived from: 17% Wikipedia article 'Example', 12% Wikipedia article
>> 'SomeOtherThing', 10%...".
>
>
> Current (ie. ChatGPT) systems doesn't work that way, as the source of
> information is lost in the process when the information is encoded into the
> model. The model is just a network of probabilities, and it is highly
> compressed compared to the original data. We are missing the point if we
> believe it is a copy of source data and not a tool to interact with
> information using natural languages.
>
> Soon, tools can retrieve data from external sources and write answers
> based on them[1]. For example, in the Wikipedia context, this would be to
> use a search engine to find information automatically, summarize findings,
> and generate references for the results. Or vice versa, retrieve
> information from Wikipedia or Wikidata. Then we will get source data, too,
> but the LLM model's internal reasoning will still be fuzzy.
>
> [1] https://interconnected.org/home/2023/03/16/singularity
>
> Br,
> -- Kimmo Virtanen
>
>
> On Sun, Mar 19, 2023 at 8:24 AM Todd Allen  wrote:
>
>> Or, maybe just require an open disclosure of where the bot pulled from
>> and how much, instead of having it be a black box? "Text in this response
>> derived from: 17% Wikipedia article 'Example', 12% Wikipedia article
>> 'SomeOtherThing', 10%...".
>>
>> On Sat, Mar 18, 2023 at 10:17 PM Steven Walling 
>> wrote:
>>
>>>
>>>
>>> On Sat, Mar 18, 2023 at 3:49 PM Erik Moeller 
>>> wrote:
>>>
 On Fri, Mar 17, 2023 at 7:05 PM Steven Walling <
 steven.wall...@gmail.com> wrote:

 > IANAL of course, but to me this implies that responsibility for the
 *egregious* lack
 > of attribution in models that rely substantially on Wikipedia is
 violating the Attribution
 > requirements of CC licenses.

 Morally, I agree that companies like OpenAI would do well to recognize
 and nurture the sources they rely upon in training their models.
 Especially as the web becomes polluted with low quality AI-generated
 content, it would seem in everybody's best interest to sustain the
 communities and services that make and keep high quality information
 available. Not just Wikimedia, but also the Internet Archive, open
 access journals and preprint servers, etc.

 Legally, it seems a lot murkier. OpenAI in particular does not
 distribute any of its GPT models. You can feed them prompts by various
 means, and get responses back. Do those responses plagiarize
 Wikipedia?

 With image-generating models like Stable Diffusion, it's been found
 that the models sometimes generate output nearly indistinguishable
 from source material [1]. I don't know if similar studies have been
 undertaken for text-generating models yet. You can certainly ask GPT-4
 to generate something that looks like a Wikipedia article -- here are
 example results for generating a random Wikipedia article:

 Article: https://en.wikipedia.org/wiki/The_Talented_Mr._Ripley_(film)
 GPT-4
 
 run 1: https://en.wikipedia.org/wiki/User:Eloquence/GPT4_Example/1
 (cut off at the ChatGPT generation limit)
 GPT-4 run 2:
 https://en.wikipedia.org/wiki/User:Eloquence/GPT4_Example/2
 GPT-4
  run
 3: https://en.wikipedia.org/wiki/User:Eloquence/GPT4_Example/3

 It imitates the form of a Wikipedia article & mixes up / makes up
 assertions, but I don't know that any of its generations would meet
 the standard of infringing on the Wikipedia article's copyright. IANAL
 either, and as you say, the legal landscape is evolving rapidly.

 Warmly,
 Erik
>>>
>>>
>>> The whole thing is definitely a hot mess. If the remixing/transformation
>>> by the model is a derivative work, it means OpenAI is potentially violating
>>> the ShareAlike requirement by not distributing the text output as CC. But
>>> on other hand the nature of the model means they’re combining CC and non
>>> free works freely / at random, unless a court would interpret whatever % of
>>> training data 

[Wikimedia-l] Wikivideos - New project proposal

[Felipe Schenone]

Hi! I just proposed https://meta.wikimedia.org/wiki/Wikivideos

This project proposal is based on an extension I developed recently called
https://www.mediawiki.org/wiki/Extension:WikiVideos that basically
introduces a  tag that generates videos with a syntax quite
similar to  tags.

I also already secured https://wikivideos.org, where you can test the
extension.

Cheers!

PS: Please comment at https://meta.wikimedia.org/wiki/Wikivideos or at
https://wikivideos.org (depending on the nature of your comment) to try to
keep the discussion together.
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/GGEME3ETBIWY2V3B2QAE6ZWEHOZU6352/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: Wikimedia Foundation Inc. design staff

[Felipe Schenone]

Hi Andreas, fair points!

Just to clarify, my suggestion is a community process to decide how to
allocate the extra resources. I do agree with you and Galder that not
nearly enough resources are spent on MediaWiki, automatic translation tools
being one of many weak points. Another one that to my mind is unforgivable
is that after 10+ years of needing and requesting, there's still no
centralized system for templates, or even Lua modules.

However, we could argue or even agree all day about this and other worthy
causes (within or beyond Wikimedia, within or beyond open-knowledge), but
in the end I think nothing will change unless a big community process
happens (perhaps something similar to the Movement Strategy one).

Lastly, MZMcBride, for what it's worth, the design team seems to at least
be working actively in the Vector skin, but you may not have noticed if you
haven't enabled the Vector 2022 skin in your preferences.

Cheers,
Felipe
User:Sophivorus

On Fri, Jun 17, 2022 at 9:36 PM Andreas Kolbe  wrote:

> Hi Felipe,
>
> Funding open knowledge projects beyond Wikimedia, or other altruistic
> projects that have nothing to do with Wikimedia at all (the Knowledge
> Equity Fund is a case in point, of course ...) doesn't seem right to me.
>
> The WMF has been fundraising in India (as well as in Latin America and
> South Africa) this month, telling people there:
>
> – that "a lot" of the money Wikimedia raises is flowing into the Global
> South[1] (according to the WMF tax return, it's about 2.5% of the money
> raised)
> – to donate because it will "keep Wikipedia online, ad-free and growing
> for years to come" (India emails)
> – "We request you to sustain Wikipedia's independence. 98% of our readers
> don't donate ..." (India fundraising banners)
>
> Leaving aside what "keeping Wikipedia online" and "sustaining Wikipedia's
> independence" actually mean in this context, given that Wikimedia is richer
> than it has ever been and last year alone brought in about $90 million more
> than it spent – leaving that aside, you cannot beg a people earning a
> fraction of what you make on average for money as if Wikipedia's survival
> depended on it and then go and give their money away to some completely
> different cause.
>
> Just for reference, according to the India FoodBanking Network[1],
>
> – India is home to the largest undernourished population in the world
> – 189.2 million people i.e. 14% of India's population is undernourished
> – 20% of children under 5 are underweight
> – 34.7% of children under 5 years of age are stunted
> – 51.4% women in the reproductive age (15-49 years) are anaemic
>
> Reading such statistics one wonders whether Wikipedia's Indian fundraising
> banners wouldn't be more appropriately used if they advertised some
> charities that will improve the quality of life of some of the most
> vulnerable people in India, instead of asking people there to send money to
> the US.
>
> Should the WMF still find itself saddled with an embarrassment of riches:
> I recall that the other day we were encouraged here on this list to endorse
> a Discourse forum for Wikimedia strategy discussions – because it has good
> machine translation capabilities that MediaWiki lacks. If there is such a
> big surplus, wouldn't it be better to use it to incorporate similar
> translation capabilities in MediaWiki? MediaWiki is woefully obsolete in
> this respect, and in Wikimedia's case international communication across
> language barriers is arguably more important than it is in the case of
> sites like Facebook, which incorporated automatic translation a fair while
> ago.
>
> This still wouldn't be about "keeping Wikipedia online and ad-free" or
> "sustaining Wikipedia's independence", but at least it would help the
> volunteers who actually write Wikipedia.
>
> Best,
> Andreas
>
> [1] https://www.indiafoodbanking.org/hunger
>
> On Fri, Jun 17, 2022 at 1:18 PM Felipe Schenone 
> wrote:
>
>> I agree with the diagnosis, but maybe not with the solution. If Wikimedia
>> is getting "overfunding" and doesn't quite know what to so with it, there's
>> probably plenty of good things to do. We could start a community process to
>> decide it, because as you say, reducing funding efforts or saving
>> indefinitely for the future isn't likely to happen or even desirable,
>> considering the alternatives.
>>
>> Here are some ideas:
>>
>> * Investing in clean energy sources for Wikimedia servers.
>> * Funding of external developers and libraries on which MediaWiki depends.
>> * Funding of open knowledge projects beyond Wikimedia, to not stray too
>> far the original intentions of donors and vol

[Wikimedia-l] Re: Wikimedia Foundation Inc. design staff

[Felipe Schenone]

I agree with the diagnosis, but maybe not with the solution. If Wikimedia
is getting "overfunding" and doesn't quite know what to so with it, there's
probably plenty of good things to do. We could start a community process to
decide it, because as you say, reducing funding efforts or saving
indefinitely for the future isn't likely to happen or even desirable,
considering the alternatives.

Here are some ideas:

* Investing in clean energy sources for Wikimedia servers.
* Funding of external developers and libraries on which MediaWiki depends.
* Funding of open knowledge projects beyond Wikimedia, to not stray too far
the original intentions of donors and volunteers.
* Funding of other non-knowledge altruistic projects (like buying land for
a natural reserve). I'm sure the funding team could rethink and generalize
the campaign to justify this use for future donations.

On Fri, Jun 17, 2022, 4:47 AM  wrote:

> The question of you is important. The Wikimedia Foundation hired a lot of
> people in the last years and I do not see so big change in the output. It
> is a question that is from my point of view relevant for different areas at
> the Wikimedia Foundation. I dont support a too big focus on efficiency that
> needs a lot of metrics to measure and to create these metrics needs then a
> lot of staff. What is needed and what not is not easy to measure. With
> increasing available resources the staff will probably increase. This is an
> usual behaviour of humans that they try to use resources if available and
> do not only allocate them for the future or say no and try to reduce the
> needed resources if not neccessary. From my point of view the Wikimedia
> Foundation should reduce the Fundraising acitivities and try to reduce in
> the next years the yearly expenses or pay at least attention that they do
> not increase further. The salaries at the Wikimedia Foundation are
> currently from my point of view in relation to Germany based NGOs high. I
> think interesting documents to get an overview about the work of the
> Wikimedia Foundation are the quaterly tuning sessions.
> https://commons.wikimedia.org/wiki/Category:Wikimedia_Foundation_tuning_sessions,_FY2021-22
>
> Hogü-456
> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/LL7NEZZNI7QBLBXDCKFFBVYHBJCDRMXX/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/6O6D2LNXVVJR4TQFMFMZM4YHL2ISS6NQ/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: Collection / Special:Book usage

[Felipe Schenone]

At appropedia.org I developed a simple but effective JS script that:

1. Gathers all links in the current page
2. Transcludes them all though an API call
3. Replaces the content of the current page for the transcluded content
4. Calls window.print() so that the user can download or print the
transcluded content
5. Restores the content of the original page

See https://www.appropedia.org/MediaWiki:Book.js for the script and
https://www.appropedia.org/Solar_book for an example.
We're quite happy with the script. Easy, simple, maintainable, versatile,
etc.
Maybe someone wants to adapt it to the Wikibooks use case?

El mar, 19 abr 2022 a la(s) 06:04, Galder Gonzalez Larrañaga (
galder...@hotmail.com) escribió:

> The problem is not that it was "Just one of the things that died out
> because no-one could be bothered to maintain it", it is worse: it was
> broken on purpose, and not recovered, because the WMF decided that no one
> cares about it.
>
> You can read about the process here:
> https://phabricator.wikimedia.org/T186740
>
> 2022(e)ko api. 19(a) 09:00 erabiltzaileak hau idatzi du (Peter Southwood <
> peter.southw...@telkomsa.net>):
>
> I used to use it, but then it broke so I stopped using it. Just one of the
> things that died out because no-one could be bothered to maintain it.
> Cheers, Peter
>
>
>
> *From:* Galder Gonzalez Larrañaga [mailto:galder...@hotmail.com]
> *Sent:* 17 April 2022 17:47
> *To:* Wikimedia Mailing List
> *Subject:* [Wikimedia-l] Re: Collection / Special:Book usage
>
>
>
> No one or very few use it, because you can't save a book. I had some
> teachers in our university courses who used it to download what their
> students did, but since the WMF decided to break it, evidently they are not
> using it anymore. I repeat: it worked and it was broken in purpose. So now
> we have an option to create a book but no actual book can be created,
> besides printing it with PediaPress.
>
>
>
> 2022(e)ko api. 17(a) 09:59 erabiltzaileak hau idatzi du ("Amir E. Aharoni"
> ):
>
> > On Sun, Apr 17, 2022, 09:29 Strainu  wrote:
> > >
> > > The correct question is: does it still do anything of value?
> > ‫בתאריך יום א׳, 17 באפר׳ 2022 ב-10:42 מאת ‪Jan Ainali‏ <‪
> ainali@gmail.com‏>:
> >
> > Even with all output options broken it is still a decent user interface
> for creating and organizing collections of articles.
>
> This may well be true, but I'm wondering how much is it *actually* used. I
> know I never use it, but it's possible that thousand of other people do. If
> it's true, then everything is fine. I can't find a log of its usage, or a
> statistics page that shows how often do people use this feature.
>
>
>
> It currently appears in at least two prominent places:
>
> 1. "Create a book" link in the desktop sidebar (in some wikis; I don't see
> it in the English Wikipedia, but I do see it in Swedish and Basque).
>
> 2. "Extensions used by Wikimedia - Main" group in translatewiki.net,
> which means that volunteer localizers are asked to translate it with
> (relatively) high priority.
>
>
>
> If only, say, five people use it in the whole Wikimedia universe, then
> perhaps someone should consider downgrading its prominence or maybe
> removing it entirely.
>
>
>
> On translatewiki, I can move it from "Extensions used by Wikimedia - Main"
> to "Extensions used by Wikimedia - Advanced" or even to "Extensions used by
> Wikimedia - Legacy", but again, before I do this, I'd like to make sure
> that it's not actually used by a lot of people.
>
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore
>
>
>
>
> --
>
> [image: AVG logo] 
>
> This email has been checked for viruses by AVG antivirus software.
> www.avg.com 
>
>
>
>
> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/I4Y5UHLEVIE2CWDOU4DOXB4UZNYSXWLV/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/NJ5UDEXPUC4BYOCRPY6PUZJ7EJ2PPMJA/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Wikidebate: from the existence of God to the legality of polygamy

[Felipe Schenone]

Hi all!

For some time now there's been a project called Wikidebate on Wikiversity:
https://en.wikiversity.org/wiki/Wikidebate

The project has matured over the years, receives occasional contributions,
drives some 7000+ views a month and ranks first on some search keywords
like "objective reality" and "subjective reality".

I feel it has potential, but the truth is it hasn't been growing much
lately. So today I thought I could ask others for their wisdom: do you have
any ideas on how to help it grow? Maybe doing something to the home page,
the flow for creating new debates, or the title conventions?

Feel free to reply here or at the main talk page of the project:
https://en.wikiversity.org/wiki/Talk:Wikidebate

Thanks !!
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/OLZJXICHYUIJD2MBZCIU22I73KMAURY6/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Using excerpts to reduce maintenance and foster collaboration

[Felipe Schenone]

Hi all! I would like to share a simple editing technique that's in use on
the Spanish Wikipedia and I think should be in use on other Wikipedias and
Wikimedia projects.

It's basically a template
 that
transcludes the lead section (or any section) of a page into another page.

So for example, the Spanish article on Science
 transcludes the lead section of the
more specific articles on the scientific method, the history of science,
scientific laws, etc. Check it out!


Currently there're 380 articles using excerpts

and
counting, on topics as diverse as science, philosophy, architecture,
history, countries, sports and TV shows.

Using excerpts could save tremendous amount of work, avoid inconsistencies,
funnel collaboration, and other benefits.

I created an English version of the template
 but I never got to use it.
There's also some English documentation on the technique
, for anyone
interested.

Kind regards,
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] WikiJournal project

[Felipe Schenone]

Awesome advice Brad, I can't think of a better solution than that, thanks!

On Wed, Mar 15, 2017 at 12:26 PM Brad Jorsch (Anomie) <bjor...@wikimedia.org>
wrote:

> On Tue, Mar 14, 2017 at 10:45 PM, Felipe Schenone <scheno...@gmail.com>
> wrote:
>
> > If we migrate the content we currently have (on Meta and
> > Wikiversity) to wikijournal.org, and the project grows, and eventually
> > gets
> > accepted as a sister-project (as we hope), how will we merge the user
> > accounts? Should we not worry about it, and we'll figure it out when the
> > time comes? Or should we totally worry about it, and adopt some strategy
> > about it now? What's your advice on this issue?
>
>
> Note: This post is my personal view and in no way represents any official
> WMF position.
>
> My personal guess is that it would wind up being done something like how
> accounts on WikiVoyage were handled: people who used the same username on
> both WikiVoyage and Wikimedia wikis were able to merge those accounts,
> people whose usernames weren't already in use on Wikimedia wikis were able
> to claim those names, and other people had to be renamed. Or at least it
> seems that's what was done based on the plan document on mediawiki.org[1]
> and the process page on en.wikivoyage.org.[2]
>
> To reduce the number of people who would need renaming should the time
> come, you might start using an extension like OAuthAuthentication[3] to
> authenticate against Meta, and disable any further local account creations.
>
> [1]: https://www.mediawiki.org/wiki/Wikivoyage_migration/Accounts
> [2]: https://en.wikivoyage.org/wiki/Wikivoyage:User_account_migration
> [3]: https://www.mediawiki.org/wiki/Extension:OAuthAuthentication
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

[Wikimedia-l] WikiJournal project

[Felipe Schenone]

Hi! So there's a sprouting project called WikiJournal
, the basic idea of
which is to develop an open peer-reviewed academic journal, where we can
all publish our research, and also, maybe, permalinks to Wikipedia articles
that have been peer-reviewed (featured articles) together with the names of
the main author(s), so as to give some well-deserved credit.

Anyway, the thing is that recently, we've been talking to the owner of
wikijournal.org, a fairly similar project with the perfect domain name, and
he has agreed to a merge. So now we're all excited trying to figure out the
details of the merge, and there's one particular issue I'd like to ask
about. If we migrate the content we currently have (on Meta and
Wikiversity) to wikijournal.org, and the project grows, and eventually gets
accepted as a sister-project (as we hope), how will we merge the user
accounts? Should we not worry about it, and we'll figure it out when the
time comes? Or should we totally worry about it, and adopt some strategy
about it now? What's your advice on this issue? I've been looking around
for documentation but the most relevant one
 seems to have no
advice on this point.

Thanks for any input!
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,