Wikipedia:De kroeg/Archief/20200703

Tijdgebruik (van tabula rasa naar encyclopedist)

In zeven kwartier van dit regeltje over Cooper Barnes naar deze versie van mij (275 woorden), inclusief het natrekken van de gegevens, waarbij ik de filmografie alleen steekproefsgewijs gecontroleerd heb. De overname van de Duitse Wikipedia betreft alleen die filmografie; de lopende tekst is van mijn hand en ik heb er een stuk of twintig webpagina's voor gescand. Ik kijk geen jeugdseries, heb geen tv en had nog nooit van Cooper Barnes of Henry Danger gehoord.

Is dat nou snel of langzaam? Ik vind het zelf snel, maar ik heb het idee dat collega's het veel vlugger doen. Het meest nieuwsgierig ben ik natuurlijk naar de ervaringen van collega's als Erik Wannee, die net als ik graag schrijven over dingen die ze een kwartier tevoren nog niet kenden.

In dit geval vraagt het onderwerp alleen opzoekwerk, geen inzicht. Dat was anders voor Algemeen verbindend voorschrift (100 uur voor 770 woorden) en Strengpers (meer dan 100 uur voor 2089 woorden). Dubbellucht 60 uur voor 2663 woorden) valt dan nog mee. Alles inclusief onderschriften, maar zonder bronvermelding en allemaal geschreven zonder noemenswaardige voorkennis. Hoe kijken anderen tegen zulk tijdgebruik aan? Zijn er trouwens mensen die hun tijdgebruik voor Wikipedia nauwkeurig bijhouden? — bertux 21 jun 2020 22:06 (CEST)

Ik hou het niet bij, maar denk dat het wel aardig overeenkomt. Ik probeer ook nog wel eens dit soort eenzinnertjes of andersoortige beginnetjes op te knappen. Heb net Nordenau afgerond, en dat was slechts een simpele vertaling en een infobox, dus met 30 minuten is het wel in orde. Net als bij de jeugdacteurs die regelmatig op TBP langskomen: met een paar standaard bronnen kom je binnen een half uur al vrij ver. Maar met Thelonious ben ik denk ik toch al gauw twee uurtjes zoet geweest: zoeken naar bronnen, een tijdslijn opzetten, tekst schrijven, en dan nog wat aanpassingen doen. Noch Nordenau noch Thelonious waren voor mij bekende onderwerpen. Thieu1972 (overleg) 21 jun 2020 22:35 (CEST)

Is er nergens een bron te vinden die de Thelonious Monk aanwijst als de oorspronkelijke naamgever van dat café? Milliped (overleg) 26 jun 2020 14:18 (CEST)

Het leek me zo voor de hand liggen, dat ik er eigenlijk niet naar gezocht heb. Maar ja, wie weet, is de achtergrond van die naam toch anders :-)Thieu1972 (overleg) 26 jun 2020 15:38 (CEST)

Voor mij is Wikipedia niet alleen iets om informatie in te stoppen, maar ook om er zelf heel veel van te leren: zaaien en oogsten. Het schrijven of redigeren van een artikel is een prachtige manier om iets te leren, met als leuk bijproduct dat anderen er daarna ook wat aan hebben. Ik herinner me nog goed het artikel Anahimhotspot, waaraan ik menige dag heb zitten schaven, en waaraan ik uiteindelijk aardig wat kijk op geologie heb overgehouden. Omdat ik dit soort dingen altijd 'tussendoor' doe, houd ik nooit de tijd bij die ik eraan besteed.

je kunt altijd om raad vragen in het Wikipedia:Geologiecafé Hans Erren (overleg) 22 jun 2020 12:53 (CEST)

Dat brengt me op de bespiegeling wat Wikipedia in geld waard zou zijn, als alle uren die erin zijn gestopt (minus de tijd van vandalen), uitbetaald zouden zijn geworden (pakweg tegen het minimumloon). Ik denk dat we dan van een miljardenproject mogen spreken. Erik Wannee (overleg) 21 jun 2020 22:48 (CEST)

Wikiwix VS IABOT

My native language is French, automatic translation into English.

Small details concerning the archiving service of Wikiwix ( https://nl.wikipedia.org/wiki/Wikipedia:De_kroeg#Internet_Archive_Bot )

It is based solely on this Javascript to be implemented since 2008 in French Wikipedia: https://fr.wikipedia.org/wiki/MediaWiki:Gadget-ArchiveLinks.js

The advantage of this solution makes it possible to add other archiving sources, and does not modify the content of Wikipedia articles.

New links are detected by 3 different means:

• Annual recovery: https://dumps.wikimedia.org/backup-index.html,
• Recovery on IRC and on the WEB of Recents Changes.

And we also recommend clicking on the archive link as soon as the source is added by a contributor, this immediately generates storage of the link and allows you to test the rendering of the archived page.

In addition to fighting 404 errors, this solution also offers the advantage of protecting against changes in content that may appear in the pages to be archived.

Wikiwix strictly respects copyright, archiving is only done with the author's approval using the noarchive tag.

Since 2015, I have been alerting about the deployment of the AI robot: 2015: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2015/Bots_and_gadgets: the bot solution with modification of the template cache is currently exclusive to WayBackMachine, 2017: fr:Discussion_utilisateur:Pmartin#I_left_you_a_message! : attempted collaboration abort by the bot trainer and bot stopped following numerous false detections on page 404.

The role of IABOT is to detect the links present in Wikipedia which are in errors 404, to find an archive in priority on the WayBack Machine, and to modify the articles to replace the dead link there.

This process is not good because IABOT only allows one archive url to be stored on all the languages, which greatly favors the Wayback Machine, to the detriment of the different versions of the page. While the template should link to a page that would list all of the possible archives for a 404 page.

A week has been planned for the end of July 2020 to resolve the few stabilization problems that Wikiwix currently encounters, linked to the new solution which consumes only 30 euros of electricity per month, we can also support this week for a deployment of the solution on the NL part of Wikipedia.

Pmartin (overleg) 23 jun 2020 10:21 (CEST)

Klinkt goed. Wat hebben de Nederlandse Wikipedianen met technische kennis hierover te melden? — bertux 23 jun 2020 11:02 (CEST)

Ik zag dit bericht ook op wikimedia-l voorbijkomen en zag effeietsanders daar opperen dat de problemen komen door een zekere blacklisting van de bot. Daarop kwam geen reactie meer, maar misschien is het gesprek off-list verder gegaan. Ciell 26 jun 2020 16:34 (CEST)

Ook bdijkstra noemde dat al, maar Wikiwix is blijkbaar opgezet om het archiveren helemaal in te richten naar de behoeften van Wikipedia. Daar is een hoop voor te zeggen, ongeacht eventueel herstel van de IA-bot. Wie kan beide systemen in een sterkte-zwakte-analyse tegenover elkaar zetten? — bertux 26 jun 2020 18:07 (CEST)

Nieuwe artikelen die niet verschijnen in 'Nieuwe artikelen'

1. Als je een artikel eerst aanmaakt op je kladblokpagina of vanuit een andere naamruimte (voorbeeld: vertaalproject), en daarna hernoemt naar de hoofdnaamruimte, dan verschijnt het niet in het overzicht 'Nieuwe artikelen'; wat toch de beste controle is op het verschijnen van ongewenste artikelen.
2. Als je een redirect zo herschrijft dat het een zelfstandig artikel is geworden, is het wel een nieuw artikel maar verschijnt het ook niet op de 'Nieuwe artikelen'.
3. Als je een artikel anoniem (ip) of vanuit een sokpop aanmaakt, en dan vervolgens inlogt en het markeert als 'gecontroleerd', verschijnt het wel op die lijst, maar als gemarkeerd, zodat weinigen er acht op zullen slaan.

Alle drie de situaties zijn niet verzonnen maar komen echt voor. Uiteraard hebben we hier een ijsbergfenomeen, want we weten niet hoeveel artikelen er ongemerkt door de controles heen slippen. De derde geschetste situatie is een duidelijk voorbeeld van kwaadaardige opzet, maar de andere twee situaties heb ik zelf (zonder kwade opzet) ook wel eens veroorzaakt. Ik vind dat ongewenst, en ik vraag me af of dit lek niet eens gedicht zou moeten worden. Technisch gezien lijkt me dat ook wel haalbaar:

• Bij optie 1. zou de software kunnen kijken naar alle artikelen die de hoofdnaamruimte binnen komen;
• Bij optie 2. zou een artikel op de lijst kunnen worden gezet zodra een artikel niet meer de code '#Doorverwijzing' (of synoniemen) bevat;
• Bij optie 3 - misschien de lastigste - zou de software een goedkeuring moeten weigeren als degene die het artikel goed wil keuren hetzelfde ip-adres heeft als de aanmaker, los van de vraag of hij ingelogd is of niet.

Ik ben benieuwd wat anderen hiervan vinden. En of er nog meer van dit soort lekken bestaan. Erik Wannee (overleg) 24 jun 2020 13:31 (CEST)

Terzijde: voor situatie 1 kun je de volledige ijsberg zien op Gebruiker:Bitbotje/Logboek verplaatsingen naar de hoofdnaamruimte. Encycloon (overleg) 24 jun 2020 13:40 (CEST)

Ik ben het volledig met je eens dat alle nieuwe artikelen, ongeacht hoe ze in de hoofdnaamruimte terechtkomen, gecontroleerd moeten worden. Logisch dus dat ze ook op 'Nieuwe artikelen' verschijnen. Bij punt 1 zou je eventueel in de richtlijnen nog kunnen opnemen dat hernoemen vanuit het kladblok naar de hoofdnaamruimte niet is toegestaan, maar ik denk dat de software-optie beter is. Dan glippen er in ieder geval geen artikelen tussendoor. Bij punt 2 zie ik ook geen andere oplossing, immers voor zover ik weet is de andere weg eerst een verzoek indienen om de redirect te verwijderen en daarna het artikel aan te maken. De kwaadaardige opzet van punt 3 afvangen via de software lijkt mij een hele goede oplossing. Mvg, Royalty & Nassau Expert (overleg) 24 jun 2020 13:42 (CEST)

Voor situatie 2 hebben we een label waar je op kan filteren in de recente wijzigingen, zie hier. –bdijkstra (overleg) 24 jun 2020 13:46 (CEST)

Ik help soms nieuwkomers met hun kladblokartikel en gezien de licentievoorwaarden is hernoeming naar de hoofdnaamruimte dan de beste optie; je kunt natuurlijk ook de kant en klare tekst naar een nieuw artikel kopiëren en dan een moderator vragen om er de oude geschiedenis onder te plakken, maar ik krijg de indruk dat dat veel gedoe is voor de mods. Voorlopig nomineer ik dergelijke artikelen standaard op TBP, dat lost de boel ook op; een enkele keer sla ik die stap over wegens de kans op een sneeuwbal in de hel. Voor de aanmaker is dat natuurlijk het fijnste, maar twee weken een slabloon is geen drama als je het van tevoren uitlegt. Zijn technische ingrepen de moeite waard? Zijn er werkelijk aanwijzingen dat er minderwaardige artikelen onder de radar blijven?

Optie 3 helpt alleen tegen heel onervaren gebruikers. Als ik overschakel van wifi naar 4G of even naar de bieb fiets, heb ik al een ander IP en bij veel IPv6-adressen hoef je alleen maar uit- en in te loggen bij je provider, bijvoorbeeld door de computer even uit te zetten, om een ander adres te krijgen.

• IPv6 lijkt me een veel lastiger wespennest — bertux 24 jun 2020 13:50 (CEST)
  • Inderdaad: zie bijv. 2001:1C04:431F:5600:0:0:0:0/64. Wikiwerner (overleg) 24 jun 2020 18:33 (CEST)

Optie drie is trouwens een geval van sokpop-misbruik. De straf daarvoor is bekend. Edoderoo (overleg) 24 jun 2020 17:01 (CEST)

Probleem is dat die straf alleen kan worden uitgedeeld aan het puntje van de ijsberg dat boven water uit steekt; geen idee wat er 'onder water' gebeurt. Erik Wannee (overleg) 24 jun 2020 23:28 (CEST)

Situatie 1 geldt niet alleen voor verplaatsingen vanuit een andere naamruimte naar de hoofdnaamruimte, maar voor verplaatsingen in het algemeen als de doorverwijzingen vervolgens wordt verwijderd. Zie het door mij aangemaakte artikel Fietsnietje, dat per ongeluk met een verkeerde titel is aangemaakt en daardoor is verplaatst (waarna de redirect dus is verwijderd). Het bestaat al langer dan een halfjaar, maar het is nooit gecontroleerd. AnarchistiCookie Overleg 25 jun 2020 00:39 (CEST)

(niet op iemand specifiek reagerend) Ter verduidelijking: Is er enige indicatie dat mensen actief de controle proberen te omzeilen? Ik ga op zich graag uit van goede wil, en zou geen ingewikkelde procedures willen opstellen omdat er een ingewikkeld scenario denkbaar is dat in de praktijk eigenlijk niet voorkomt. (dit geldt zeker voor 'optie 3'; bij 'optie 1' en 'optie 2' zou je nog kunnen beargumenteren dat ook artikelen aangemaakt met goede wil, voordeel hebben van kwaliteitscontrole) Effeietsanders 25 jun 2020 01:32 (CEST)

Of de pagina ooit gecontroleerd is, valt nu niet meer met zekerheid te zeggen, deze gegevens vervallen na 30 dagen. Hernoemingen binnen dezelfde naamruimte hebben geen effect op het logboek van nieuwe pagina's. –bdijkstra (overleg) 25 jun 2020 09:52 (CEST)

In dit verband wijs ik graag even op het beleid dat als iemand om een terugplaatsing van een artikel vraagt, dat door de moderatoren wordt geplaatst in de gebruikersnaamruimte. Dat is mij meerdere keren overkomen. Als de persoon het artikel dan verbeterd heeft, moet het wel via een verplaatsing weer in de hoofdnaamruimte gezet worden, anders zouden de auteursrechten geschonden worden van de eerdere bewerkers. Dan verschijnt het ook niet meer op enige beoordelingslijst. Het lijkt mij beter om zo een artikel terug te plaatsen in de hoofdnaamruimte en direct opnieuw op TBP te zetten, zodat de verbeteringen na twee weken ook opnieuw worden beoordeeld. Met vriendelijke groet, Elly (overleg) 25 jun 2020 10:00 (CEST)

Volgens mij valt het wel degelijk terug te halen of een pagina ooit gecontroleerd is. Het eerste niet-botmatige aangemaakte artikel dat ik met 'Willekeurige pagina' vind stamt uit 2009 en is inderdaad toen gecontroleerd. AnarchistiCookie Overleg 25 jun 2020 14:44 (CEST)

Oh inderdaad. Omdat de mogelijkheid tot markeren vervalt na 30 dagen, dacht ik dat de markeergegevens zelf ook vervielen. –bdijkstra (overleg) 25 jun 2020 15:19 (CEST)

Kunnen alle artikelen die niet gecontroleerd worden na 30 dagen op de TBP komen want door de vele biologie artikels verdwijnen die snel naar onder, door ze op de TBP te zetten kan je een deel slechte artikels voorkomen in de Wikipedia. Themanwithnowifi (overleg) 25 jun 2020 17:55 (CEST)

Als je naar Nieuwe pagina's gaat, drukt op 'gecontroleerde bewerkingen: verbergen' en vervolgens op 'oudste', heb je een goed overzicht. Zie hier. In mijn ervaring zijn de artikelen daar nooit ouder dan 20 dagen, dus ik denk dat het wel meevalt. AnarchistiCookie Overleg 25 jun 2020 18:55 (CEST)

Aanleiding

Ik zet mijn vraag nog maar eens onder een subkopje:

(niet op iemand specifiek reagerend) Ter verduidelijking: Is er enige indicatie dat mensen actief de controle proberen te omzeilen? Ik ga op zich graag uit van goede wil, en zou geen ingewikkelde procedures willen opstellen omdat er een ingewikkeld scenario denkbaar is dat in de praktijk eigenlijk niet voorkomt. (dit geldt zeker voor 'optie 3'; bij 'optie 1' en 'optie 2' zou je nog kunnen beargumenteren dat ook artikelen aangemaakt met goede wil, voordeel hebben van kwaliteitscontrole) Effeietsanders 25 jun 2020 01:32 (CEST)

Als er misbruik wordt gemaakt, zou dat de prioriteit verhogen. Anders is het wat mij betreft een stuk minder urgent (houdt discussie verder niet tegen, maar dan focus ik even op iets anders). Effeietsanders 25 jun 2020 19:33 (CEST)

Inderdaad heb ik voorbeelden gezien van actieve omzeiling van de controle, zelfs met blokkades tot gevolg, maar helaas kan ik je daar helaas geen voorbeeld van noemen. Een voorbeeld waarvan ik niet weet hoe opzettelijk het is gedaan is te lezen op Wikipedia:Te beoordelen pagina's/Toegevoegd 20200621#Benjamin Heine. Waar ik met name beducht voor ben, is mensen die reclame willen maken; zeker als ze al een keer een verwijdering meegemaakt hebben, en dan dit soort listen bedenken om de controle te omzeilen. Het is mooi om uit te gaan van goede wil, maar als we dat altijd konden doen dan hadden we geen vandalismecontroles nodig gehad.

Een grotere groep zal zich niet actief aan de controle onttrekken maar onbedoeld. Elly gaf een duidelijk voorbeeld van zo'n situatie die nogal eens voorkomt: artikelen die aangemaakt of (na een WP:terug-verzoek) ter verbetering teruggezet zijn in de eigen naamruimte, en die vervolgens - hopelijk na verbetering - naar de hoofdnaamruimte worden hernoemd. Juist voor die artikelen die niet goed genoeg waren is een controle zeer wenselijk. En je kunt er niet van uit gaan dat zo iemand - vaak onervaren wikipedianen - hun (hopelijk) verbeterde en teruggeplaatste versie zelf zullen aanmelden op WP:TBP.

Artikelen die aangemaakt worden in het vertaalprogramma worden standaard naar de hoofdnaamruimte hernoemd (voorbeeld), en komen zo ook nooit in Nieuwe artikelen terecht. Maar dat zal maar zelden een probleem zijn, omdat er meestal al veel gecontroleerd is. Erik Wannee (overleg) 26 jun 2020 18:08 (CEST)