Wikipedia:De kroeg/Archief 20100702

Vacature checkuser(s)

Op de mededelingenpagina van de arbitragecommissie is een vacature geplaatst voor één of meerdere nieuwe checkusers. Aanmelden kan tot 14 juli 2010.

Mvg,

Fontes 23 jun 2010 22:12 (CEST)

Ik heb de voorwaarden en eisen eens doorgenomen. Klinkt goed. Na vier jaar meedoen lijkt het mij tijd om mijn verantwoordelijkheid te nemen en mij kandidaat te stellen voor deze post. Ik ben geen leider van aard maar meer een facilitator, iemand die graag helpt om andere mensen hun werk goed te laten doen. Check user past daarbij. Eddy Landzaat 24 jun 2010 12:10 (CEST)

Mag ik even in zijn algemeenheid hier iets over opmerken. Jaren lang hadden we slechts twee oude rotten (dit is niet onvriendelijk bedoeld - integendeel: vol respect zelfs) nu vijf. Moeten het er zes of meer worden en waar ligt de grens?
Bijkomende vraag: Kunnen we ze als gemeenschap zelf democratisch kiezen of worden ze weer door het moderatorapparaat en andere wibo's benoemd?
Met lichtkritische bezorgdheid, Patio 24 jun 2010 14:39 (CEST)

Checkusers worden conform het door de gemeenschap vastgestelde arbcomreglement en in overeenstemming met de meta-policy benoemd door de ArbCom. In principe worden ook democratische verkiezingen toegestaan door de meta-policy: er staat wel On wikis with an Arbitration Committee (ArbCom) whose members have been elected with the support of at least 25-30 members of the local community, CheckUsers can be appointed by the Arbitrators only maar in de zin daarna wordt weer gesproken over or where the community prefers independent elections. We hebben er destijds echter voor gekozen om deze taak bij de ArbCom te leggen (en dus heeft het moderatorenapparaat er in ieder geval niets mee te maken). Dat kan aangepast worden, maar dat vereist aanpassingen aan reglementen. paul b 24 jun 2010 14:47 (CEST)

Volgens mij is de arbcom beter in staat goede checkusers aan te stellen dan dat de hele gemeenschap dat is in een stemming. Ik ben ook wel benieuwd waarom er 2 checkusers bij moeten komen. Overigens is één van die vijf checkusers volgens mij zeer inactief? Mvg, Bas 24 jun 2010 17:09 (CEST)

Ik vind dit een functie waar er niet te veel van moeten zijn. Je IP-nummer met alle gegevens die je eruit kunt halen blijft toch een privacy-ding. Het moeten dus buitengewoon betrouwbare gebruikers zijn en ik vind dat de arbcommers er hier veel te makkelijk mee omspringen, door nog maar eens een vacature te stellen. Op dit moment hebben ze meer dan genoeg aan het huidige aantal checkusers. Ik krijg hier geen goed gevoel bij. Davin 24 jun 2010 19:54 (CEST)

Ik speel hier graag de rol van echo van Davin.--Kalsermar 24 jun 2010 20:01 (CEST)

Recentelijk is er een discussie geweest over de resultaten van checkusers, dat lijkt mij voor deze discussie irrelevant, ook al zou het goed zijn als daar meer helderheid/oplossing over zou komen. Toch lijkt die discussie hier op te spelen, wat hier in deze geheel onterecht is. Het uitvoeren van een checkuser is aan vrij strikte regels gebonden en er is geen enkele reden waarom dat in de toekomst anders zou zijn bij een nieuwe aanstelling. De arbitragecommissie heeft mijn inziens de vorige keer prima gebruikers tot checkuser benoemt en ik verwacht dat ze met deze aanstelling net zo zorgvuldig zijn als eerder. Ik kan me goed voorstellen dat er van de huidige checkusers een of meerdere aangegeven hebben er mee te willen stoppen en dat men het aantal checkusers op peil wil houden, of de werkdruk van de bestaande checkusers wil beperken. De angstvisioenen hierboven lijken mijn inziens nergens op gebaseerd en de conclusie dat er meer dan genoeg checkusers zouden zijn is zeer sterk te betwijfelen (lijkt ook puur en alleen op angst voor niets gebaseerd) als de arbitragecommissie tot een dergelijke conclusie komt! Romaine (overleg) 24 jun 2010 20:15 (CEST)

Mocht het te grote aantal checkusers een probleem zijn, dan kan dat ook opgelost worden door bestaande checkusers van hun functie te ontheffen. Gpvos heeft intern aangegeven zijn CU-schap binnenkort zelf te willen neerleggen, terwijl Hardscarf, Erwin en ondertekende allen gemeld hebben dat we, mocht dat gewenst zijn, hiertegen geen bezwaar hebben. Het aantal bestaande checkusers zou dus, zonder enige vertrouwensvraag te stellen, tot 4 of zelfs tot 1 kunnen worden ingeperkt. - André Engels 25 jun 2010 11:03 (CEST)

1 kan niet :p, minstens 2 of geen. Ze moeten elkaar kunnen controleren. -- Taketa (overleg) 25 jun 2010 17:37 (CEST)

Ze kunnen toch ook door een van de nieuwe checkusers gecontroleerd worden? - André Engels 26 jun 2010 14:45 (CEST)

Zie ook hier. _LolSimon -?- 25 jun 2010 17:30 (CEST)

Dank voor het linkje, Simon. Dank voor je voorbeeldige openheid, André. Het lijkt mij dat een oneven aantal checkusers handig is, zodat in geval van twijfel bij meerderheid beslist kan worden. Drie maximaal dus? Patio 26 jun 2010 11:30 (CEST)

Beslissingen bij meerderheid hebben we als CUs nog nooit gedaan, dus dat hoeft geen reden te zijn. Zelf vind ik 3 aan de lage kant, en zou ik op 4 of 5 willen blijven zitten. - André Engels 26 jun 2010 14:57 (CEST)

Bedankt voor jullie aanvulling André en Simon. Dat checkusers elkaar kunnen controleren wist ik overigens niet en stelt me gerust. Ik hoop dat zich een onomstreden kandidaat aanmeldt. Davin 26 jun 2010 19:55 (CEST)

Ondergetekende kopieert Kalsermar 201006242001 - Amen -
Patio 27 jun 2010 12:46 (CEST)

Vreemd gedrag in IE7

Via OTRS werd ik geattendeerd op dit artikel: Embargo (SAS). De link naar protagonist zou volgens de inzender op Oostenrijk uitkomen. En jawel, hij/zij heeft gelijk, althans voor IE7 (zowel 32 bit als 64 bit versie). De HTML source in de buurt van de link lijkt ok.

Enige experimenten uitgevoerd met een merkwaardige uitkomst. Het vreemde gedrag treedt alleen maar op bij de meest recente versie van het artikel. De inmiddels naar onderen gezakte versie van 9 aug 2008 vertoont dit gedrag niet meer. Vergelijking van de HTML van de huidige en vroegere qua wikitekst identieke versie leerde mij dat er op diverse plaatsen verschillen zijn, maar ik heb nu even geen tijd dat verder uit te zoeken.

Bij Firefox en Opera treedt het probleem niet op. Mijn vraag is of iemand met IE8 en/of IE6 (of IE7, misschien een iets andere versie dan ik hier heb) ook even kan kijken wat er gebeurt. - mvg RonaldB 24 jun 2010 00:58 (CEST)

Oostenrijk is in de tekst het volgende woord dat je als link kunt aanklikken. (Bij mij gaat het wel goed. Ik geloof IE8.)) - Maiella 24 jun 2010 01:08 (CEST)

Firefox en IE8 geven deze problemen ook bij mij niet. In de broncode heb ik net als jij geen fouten of bijzonderheden kunnen vinden. Mogelijk zit de fout in een scriptje die iets met een linkje met class="mw-redirect" doet in IE7 in een bepaald geval (bij span dir='ltr' ?) of zo, maar ik zou werkelijk niet weten hoe of waar. _LolSimon -?- 24 jun 2010 01:26 (CEST)

IE6 doet het bij mij gewoon zoals je mag verwachten, evenals mijn echte browsers. Ik geloof ook eigenlijk niet dat dit aan IE7 zou kunnen liggen. Vraagje: gaat het ook mis als je uitgelogd bent of een andere skin gebruikt ? Zo niet, zou het probleem in je monobook.js kunnen schuilen... De URL is zowel bij de huidge als bij de oude versie van dat artikel "/wiki/Protagonist", dus dat kan het ook niet zijn. - Erik Baas 24 jun 2010 02:26 (CEST)

Ik durf het haast niet te vragen, maar... heb je de cache en de history van je browser al eens grondig leeg gemaakt ? - Erik Baas 24 jun 2010 02:50 (CEST)

Andere machine geprobeerd, uitgerust met IE6. Zelfde probleem (ingelogd met monobook en oningelogd met vector) en uiteraard alle temporary files een keer verwijderd.

@Erik: een willekeurige bezoeker van WP meldt dit probleem via OTRS aan. Dat sluit dus uit dat het aan mijn systemen zal liggen. Nu heb ik een dag of twee geleden wel gemerkt dat er een fout zat in wikibits.js, die na ruim 24 uur weer verdween. Misschien dit probleem ervoor terug gekregen. - RonaldB 24 jun 2010 11:53 (CEST)

Als ik die pagina oningelogd bekijk met IE 8 dan zijn de drie links protagonist, Oostenrijk en prins zelfs niet klikbaar! De rest van de links zijn wel aanklikbaar. Als ik de pagina bekijk met monobook-skin (door &useskin=monobook in de url te zetten) is er ook niets aan de hand. Dit lijkt een probleem specifiek voor de combinatie Vector en IE. (In oudere versies van de pagina gaat het wel goed en gaat Protagonist naar de goede pagina) MrBlueSky 24 jun 2010 17:42 (CEST)

Ook met Safari gaat het goed. Lijkt dus ( ik zou bijna zeggen weer ) een typisch Microsoftdingetje. Ik zou zeggen: Stap af van IE en ga naar de downloadpagina van om het even welke andere webbladeraar... Patio 24 jun 2010 14:47 (CEST)

En da's nou typisch de arrogante houding die al menig softwareproject de kop heeft gekost. Met het marktaandeel dat IE heeft, kunnen we het ons niet permitteren om al die gebruikers een dikke middelvinger te geven en te zeggen "Niet ons probleem, zoek het maar uit". Ter overweging: het was Microsoft (jawel) die speciale code in de eerste Windowsversies stopte om specifieke MS-DOS-programma's te laten werken die strikt genomen onjuist gebruik maakten van ongedocumenteerde DOS-bibliotheekfuncties (in plaats van te zeggen: "Uw software is fout, niet ons probleem, zoek het maar uit.") En waarom? Omdat ze het zich niet konden permitteren om die programma's gewoon stuk te laten gaan op hun nieuwe systeem. (Ik kan niet instaan voor wat ze hadden gedaan als ze het zich wel hadden kunnen permitteren, maar dat is een ander onderwerp ;)). Het lijkt mij geen goed idee om zo'n grote groep gebruikers gewoon in de stront te laten zakken (en ja, ik weet dat dat als "opvoeden" wordt gezien door sommigen, maar dat is hetzelfde soort belerende toontje dat we al veel te vaak hier aantreffen). paul b 24 jun 2010 16:50 (CEST)

Heeft niets met arrogantie te maken. Zelfs Microsoft had vorig jaar al een Friends don't let friends use IE6 campagne. En statistieken tonen gelukkig aan dat privé ook bijna niemand meer IE6 gebruikt. Datzelfde zou eigenlijk voor IE7 moeten gelden. IE8 is nog te doen maar zelfs dat raad ik niemand in mijn omgeving aan (IE9 lijkt trouwens daadwerkelijk bruikbaar te gaan worden). Dat betekent natuurlijk niet dat we het niet tot ons uiterste moeten ondersteunen, maar dat is toch echt heel wat anders dan het aanraden. Ik heb het Usability project veel gevolgd, en ik vermoed dat misschien wel 50% van de tijd (bij het implementeren) is gaan zitten in het ondersteunen van IE. Dat is serieus te idioot voor woorden. Het allergrootste probleem is dat er echt de meest vage bugs in IE zitten. IE heeft nogal es de neiging tot: "Dit lijnt rechts uit. Behalve in deze en deze en deze combinatie met deze en deze opties, dan is er een bug waardoor het links uitlijnt."-gedrag waarbij je dat laatste deel enkel in een paar weblog posts van andere ontwikkelaars kan terugvinden. Mensen hebben geen idee hoe moeilijk dat het maakt om software te bouwen. De frustratie van veel mensen omtrent IE is duidelijk en heeft duidelijk oorzaken. Dat iedereen het gebruikt is een kwestie van de marktpositie van MS en de luiheid/gemakzucht van mensen, maar het is en blijft een brak product. TheDJ 25 jun 2010 00:50 (CEST)

Die marktpositie is een gegeven, en daar zullen we het mee moeten doen. Onze taak is informatie ontsluiten, niet het opvoeden van computergebruikers. Er komt een moment dat je ondersteuning van verouderde software moet opgeven, maar IE6+IE7 lijken samen nog steeds goed voor 30% marktaandeel. paul b 27 jun 2010 13:07 (CEST)

We moeten die arme mensen die nog steeds IE gebruiken zeker niet in de steek laten, ze hebben het al zo moeilijk. ;-) Maar ze aanmoedigen om een echte browser te downloaden is altijd goed. :-p - Erik Baas 24 jun 2010 16:59 (CEST)

Nog een leuke voor mensen die denken dat foute weergaven e.d. niet aan IE liggen: Acid3. Jcb - Amar es servir 25 jun 2010 00:58 (CEST)

Het commentaar hier wil ik de Microsoftsceptici niet onthouden. Wat mij en andere MacFans vermoedelijk ook betreft: Smullen maar Patio 26 jun 2010 12:02 (CEST)

Een stapje verder

Heb de complete pagina (met alle hulppagina's) opgeslagen op mijn PC en die dan weer geopend in IE. Via stapje voor stapje elimineren van suspect code kunnen vaststellen dat de boosdoener het bestand main.css is. Als ik die outcomment ziet de lay-out er natuurlijk niet uit, maar zijn de links wel ok.

Kijkend naar de inhoud van dat css bestand zie ik een aantal selectors die eruit zien als:

* > HTML #bodyContent

Nu gaat mijn CSS2 kennis zover dat ik *, > en # wel kan plaatsen, maar de combinatie niet, zeker niet met de toevoeging HTML. Is dat soms CSS3? Iemand die daar goed in thuis is? - RonaldB 25 jun 2010 00:53 (CEST)

Dit ging toch over vector ? Daar behoort geen main.css in te zitten. Dat is nl een bestand van de monobook skin volgens mij. TheDJ 25 jun 2010 01:06 (CEST)

Inderdaad. - Erik Baas 25 jun 2010 01:33 (CEST)

HTML is de container voor alle elementen, te beginnen met "body", die op zijn (haar?) beurt weer verschillende div's bevat. Maar de constructie die jij citeert kom ik alleen tegen onder kopjes als "IE/Mac fixes" e.d., en ik begrijp 'm niet... ;-) Misschien is dit een hack, waar alleen IE 5 en IE/Mac op reageren ? Brrr... :-( - Erik Baas 25 jun 2010 01:05 (CEST)

Heel misschien heeft het te maken met de volgende bug, welk deze week een probleem was bugzilla:24083. TheDJ 25 jun 2010 01:43 (CEST)

Nee, die heb ik vorige week wel gedurende een dag of zo ook regelmatig gezien, maar dat is toen weer verdwenen. Hier nog het stukje dat ik van html comment tags heb voorzien, waarna e.e.a. wel de goede links gaf.

LINK media=print href="Embargo%20(SAS)%20-%20Wikipedia_files/commonPrint.css" type=text/css rel=stylesheet>
<!--
<LINK media=screen href="Embargo%20(SAS)%20-%20Wikipedia_files/main.css" type=text/css rel=stylesheet>
-->
<LINK media=handheld href="Embargo%20(SAS)%20-%20Wikipedia_files/main(1).css" type=text/css rel=stylesheet>

Dit was wel met monobook, maar het probleem was ook te reproduceren in vector (oningelogd). Dan zal het wel een ander css bestand zijn met dezelfde bug.

Overigens zojuist getracht opnieuw in te loggen op mijn stokoude servertje (W2kServer met IE6). Het laden van de initiele vector pagina's duurt een virtuele eeuwigheid en gedurende die periode is het complete window non responsive (kan alleen via taskmanager de zaak killen). Die machine heeft van alles te weinig (vnl. geheugen), maar is wel in staat om een tiental wiki's te monitoren op proxy bewerkingen (dwz een half miljoen records per etmaal) en om bovendien nog eens meer dan 64 IP's in parallel te testen op proxy eigenschappen. Ik begin het donkerbruine vermoeden te krijgen dat verbeteringen niet getest worden m.b.v. wat oudere systemen en denk dat zoiets niet goed is voor een high ranking site als Wikipedia.

Btw zie ook w:en:Usage_share_of_web_browsers - RonaldB 25 jun 2010 02:08 (CEST)

Revert stats

In vervolg op eerder gepubliceerde edit trends hoop ik op Wikimania revert trends te annonceren. Hierbij alvast een preview. Momenteel online staan Nederlanse, Engelse en Duitse revert stats. Graag jullie feedback: is het duidelijk, is het nuttig, is het teveel, mis je iets, .... ? Erik Zachte 24 jun 2010 10:15 (CEST)

Ik hoop dat die vrije val aan het einde van de tweede grafiek wordt veroorzaakt doordat het jaar nog niet zo oud is, en niet om andere redenen :-) Sjorskingma vraagje? 24 jun 2010 11:22 (CEST)

Dank. Ik was er zelf al aan gewend, maar het staat inderdaad raar, grafiek moet eigenlijk stoppen waar revert stats nog niet bepaald zijn. Het kost bijvoorbeeld 20 dagen om ze uit de Engelse Wikipedia dump te peuren. Zal dus altijd wat achter lopen. Zie overigens voor link die je opneemt ook hier. Erik Zachte 24 jun 2010 12:29 (CEST)

Zou het mogelijk zijn ook trendlijnen toe te voegen? Waar de pieken en dalen dus gedempt zijn? Ik kan me namelijk voorstellen dat niet iedereen even makkelijk door een grasveld heenkijkt :) (zo zie je bij revert ratios rond de zomer (en in mindere mate rond de kerst) een ernstige terugval, dit zegt natuurlijk niet heel veel over de langetermijn trend. Effeietsanders 24 jun 2010 12:39 (CEST)

• Voor mij was het feit dat er een sterk seizoenspatroon in zit op zich een openbaring. In de zomer wordt er niet alleen minder gerevert, maar vooral ook verhoudingsgewijs veel minder. En dat is niet omdat er minder geregistreerde gebruikers actief zijn. Dus of vandal fighters zien het zomers zonniger in en zien meer door de vingers, of er is minder vandalisme. Ik neem aan het laatste. Zou dat allemaal van scholieren komen? Zijn IP's van scholen dan toch niet allemaal gebokkeerd?
• Met seizoensinvloeden filteren ben ik bezig. Ben er nog niet uit hoe dat het beste te doen. Ik werk sinds kort met R, er zijn daar meerdere functies om uit een time serie seasonality, trend en cruft te distilleren. Echter de seizoenscomponent is dan per definitie elk jaar identiek in vorm en amplitude. Vooral dat laatste zit ik nog mee, want als er een dip is in de schoolvakanties is die natuurlijk groter in recente jaren nu we meer bezoekers trekken. Ik neem aan dat daar methodes voor zin, ook binnen R. Ik studeer verder. Erik Zachte 24 jun 2010 14:58 (CEST)

Ben zelf al een tijdje bezig met iets soortgelijks, maar dan startend vanuit het perspectief van "trends in de community". Een paar belangrijke concepten om de uitkomsten meer betekenis te geven:

• Een edit zegt nog niet zoveel. Denk aan de beginner die 20 edits nodig heeft om een begin van een artikel neer te zetten (of een edit-war). Vandaar dat ik het begrip PageEdit heb geintroduceerd, d.i. alle edits van eenzelfde gebruiker op dezelfde pagina in een bepaalde maand worden als 1 PageEdit geteld. Dat geeft per saldo een reductie van ongeveer een derde.
• Voor het uiteindelijke resultaat zijn niet alleen edits in de hoofdnaamruimte van belang, maar ook die op templates, etc. Vandaar dat ik onderscheid maak tussen Content en Non-Content edits. Content edits zijn alle edits in de even naamruimtes, m.u.v. 4 (Wikipedia:xx). Het enige twijfelgeval is ns:2 (Gebruiker:xx), maar dat zijn er op het totaal relatief weinig, zeker omdat het aantal PageEdits relatief klein is (telkens zelfde gebruiker).

Mijn ervaring (inhakend op de suggestie van effeietsanders) is ook dat het inzicht in de trends verbeterd wordt door de grafieken weer te geven op jaarbasis. De onderliggende gegevens zijn bij mij ook op maandbasis, maar daar zitten niet alleen verstoringen in als gevolg van vakantie e.d., maar ook door andere effecten als grootschalige "opstootjes". - mvg RonaldB 24 jun 2010 13:16 (CEST)

• Trendline of aparte grafiek op jaarbasis toevoegen. Beide kan. Nog even over dubben. Zie ook antwoord aan Effe.
• Wikistats richt zich van oudsher voor de basisgetallen op artikelen, niet op andere namespaces. Dat is inmiddels al genuanceerd: voor sommige projecten (b.v. Commons, Strategy, Wikisource) is een andere namespace the real thing. Uiteraard zijn templates ook van belang. Maar waar trek je de grens, portal pages ook, image upload pages. Het is een subjectieve keuze, ik denk niet dat er hier één optimaal antwoord is. En ook: maakt het veel uit op het toaal aantal edits?
• Edits per gebruiker per maand combineren is een interessante gedachte. Je zou zelfs kunnen denken aan het wegen van edits per namespace: een template edit heeft doorgaans meer gevolgen. Er leiden vele wegen naar Rome, maar ook naar Constantinopel, ik bedoel dit lijkt me een aanpak die tot heel andere, op zichzelf even interessante, resultaten leidt. Erik Zachte 24 jun 2010 14:58 (CEST)

Bewerkingen per jaar geven een te globaal beeld waar je juist de invloed van vakanties, bijzondere gebeurtenissen als hete hangijzers niet terug kan vinden. Welke aanpak je ook kiest uit de diverse suggesties, je zult altijd verschillende uitkomsten krijgen. Als je de laatste tijd naar het gediscuzeur hier en in de andere overlegstructuren kijkt proef je de sfeer een beetje van "ik weet er alles van dus mijn mening telt" of "ik ben moderator dus de 'gewone' gebruiker mot z'n bek houwe of zij/hij krijgt een blok aan haar/zijn rok/broek" en een terugdraiing van een bewerking is zo gemakkelijk en snel dat er maar al te vaak naar gegrepen wordt zonder de betreffende goedwillende collega of anoniem op haar/zijn OP te verwittigen. Patio 24 jun 2010 15:11 (CEST)

Zeer interessant.

Wat ik me afvraag is of niet het aantal bewerkingen, maar het aantal toegevoegde kilobyte per tijdsinterval in kaart gebracht kan worden. Dat lijkt me een veel betere maat voor de groei van het project dan het aantal bewerkingen. Vr. groet, Woudloper _overleg 24 jun 2010 16:11 (CEST)

@Woudloper, het nadeel daarvan is dat plaatjes en andere mediabestanden dan een onevenredig deel uitmaken van de geleverde prestaties qua uitbreiding. Wanneer iedereen niet-tekst-inhoud op Commons zou zetten valt dit bezwaar weg. Helaas is dit nog niet het geval, omdat de regels (nog?) verschillen per project en ook per taal Patio 24 jun 2010 16:52 (CEST)

Regelmatig zie ik anonieme gebruikers interwiki's aanpassen omdat ze op een ander project hun hoofdaccount hebben. Het alleen aanpassen van interwiki's lijkt mij een vervuiling te kunnen geven van gebruikers die wel hier actief zijn in de inhoud in de statistieken. Romaine (overleg) 24 jun 2010 16:59 (CEST)

Volgens mij kun je eruit opmaken dat veruit meer dan 75% van de anonieme bijdragen waardevol genoeg is om niet (meteen) te reverten. Dat zegt wel iets over het belang van die bijdragen. Het gaat namelijk op 12% van de encyclopedie-opbouw, aldus de statistieken. Een dikke 8% van de totale opbouw die de gemeenschap waardevol laat lijken (en je mag aannemen dat dat grotendeels wel klopt, ervan uitgaande dat het vrije karakter van dit project een belangrijk speerpunt is) is dus volkomen anoniem gepleegd.  —  „Jaspər Kloekmoed”  ^[ ! ? ]  24 jun 2010 18:41 (CEST)

@Patio: ik bedoel het aantal kb in de diff, daarin worden plaatjes niet meergerekend.

@Mark: dat het percentage lager ligt dan in mijn eigen steekproef, interpreteer ik juist als dat niet alle verslechteringen worden teruggedraaid. Ik zie dat als een bewijs voor mijn hypothese van geleidelijke wiki-erosie. Woudloper _overleg 24 jun 2010 20:38 (CEST)

Niet alle bewerkingen worden met de revert knop teruggedraaid. Soms bewerk ik een oude versie en sla die op als er 4x vandalisme is geweest. Dat lijken in deze statistiek 4 goede wijzigingen. Ook bewerkingen die aangepast worden worden hier niet meegenomen denk ik. Dus ook de meettechniek verklaard een lagere uitval denk ik. Mvg, Bas 24 jun 2010 23:46 (CEST)

Natuurlijk, en niet al die gevallen zijn met een script te achterhalen. Ik heb wel een poging gewaagd: in de tabellen vind je een categorie 'unknown': dat zijn edits die wegens commentaar als (waarschijnlijk) reverts zijn aangemerkt maar niet het exact terugzetten van een versie behelsden (geen md5 match). De grafiek toont alleen 'harde' reverts, maar de tabel geeft je indruk van hoeveel 'zachte' reverts er zijn geweest. Als zodanig zijn edits aangemerkt die in het commentaar /(?:\brvv?\b|\brev\b|\brevert|herstel|undo|spam|vandal|vandaal|terug|ongedaan)/i hadden (\b betekent op word boundary) En natuurlijk zitten hier weer false positives tussen. Het gaat om de orde van grootte. Erik Zachte 25 jun 2010 11:30 (CEST)

Er zit iets van een fout in de namespaces van de Nederlandse statistieken. In de laatste tabel gaat het over Portail ipv Portaal en de link gaat naar 100: ipv Portaal: TheDJ 25 jun 2010 00:24 (CEST)

@Erik Zachte: Het aantal kb per versie wordt in de geschiedenis weergegeven. Is het mogelijk verandering (toevoeging/verwijdering) in het aantal kb te meten i.p.v. in aantal bewerkingen? Woudloper _overleg 26 jun 2010 07:02 (CEST)

Zou dat niet sterk overgewicht geven aan bijdragen van vandalen, die een heel artikel vervangen door één schuttingwoord. Zowel dat als het herstel zou zwaar meewegen in de stats. Aan de andere kant van het spectrum zouden verbeteringen van bijv. een jaartal helemaal genegeerd worden. Erik Zachte 27 jun 2010 12:27 (CEST)

Nederlanse, Engelse en Duitse revert stats zijn nu ook beschikbaar met trend lines, dat wil zeggen ontdaan van seizoensinvloeden en random fluctuaties met R decompose().