Bruker:Rcpatrol

Fra Wikipedia, den frie encyklopedi

Rcpatrol er en bot-konto for Jeblad.

Andre aktuelle sider på norsk wikipedia

Denne kontoen vil bli brukt for en bot som gjør rcpatrol og whitelister og blacklister større bidragsytere, og som analyserer gjennstående bidrag som ikke er sjekket og deretter samler disse i en liste kalt Wikipedia:PatrolTicker.

Boten bruker et rammeverk som er felles med xmlupload.pl og xmlinterwiki.pl, to perl-baserte boter som bruker Net::IRC [1] og LWP::UserAgent [2] fra CPAN. Funksjonelt består boten av to script; A – ett som bruker IRC-loggen til no.wikipedia.org for å monitorere endringer og whiteliste brukere i henhold til etablert policy, og B – ett som bruker recent changes fra no.wikipedia.org som utgangspunkt for å lage oppføringer på Wikipedia:PatrolTicker.

Boten har ikke administratorrettigheter og bot-flagg er ikke satt så kun begrenset testing er mulig. Fortsatt drift på kontoen Jeblad er antatt å være uaktuell etter at avstemminger er gjennomført.

Hvis du ikke blir godkjent

Alle endringer blir merket med et flagg som angir at dette er en redigering som er gjort av en person som ikke selv kan velge å autogodkjenne sine endringer. Dette har ingenting med whitelisting å gjøre, det er en metode som ble lagt inn i motoren som surkler og går i bunnen av Wikipedia. For å fjerne disse flaggene må en administrator merke redigeringene som godkjent, og da merker han ikke alle tidligere redigeringer men en for en av alle redigeringene. Vi har en del gode bidragsytere som over tid har vist at de gjør godt arbeid. Disse redigeringene blir godkjent av boten, dels ved å analysere deres bidrag og dels ved å bruke en egen liste av kjente gode bidragsytere.

Rundt halvparten av de som er logget er på denne lista over kjente gode bidragsytere, resten er godkjent som følge av analysen som er gjort. Analysen sjekker for tiden 500 bidrag tilbake i tid. Hver gang boten startes vil den generere nye analyseresultater, noe som gjør at en bruker kan bli godkjent i en kjøring og forkastet i neste. Den andre halvparten av de som er logget er med på grunn av slik midlertidig godkjenning. I tillegg til disse blir brukerredigeringer godkjent på grunn av at de er fulgt opp av at andre brukere som selv er godkjent. Ta med at administratorer kan la være å autogodkjenne, at boter ikke godkjennes, at enkelte artikler ikke godkjennes, at enkelte navnerom ikke behandles overhodet, at enkelte brukere er satt til å ikke bli godkjent, osv.

Det som er lagt ut i /logg er noen av de som på ett eller annet tidspunkt er godkjent av boten, det vil si som har hatt mer enn 500 gode bidrag, startende fra en gang i vår. Grunnen er at det er kommet en del spørsmål, og de som spør mener seg forulempet fordi de ikke er på lista til boten. Stort sett er dette feil. Hvis du vil vite om du er med så kan du gjøre følgende sjekk; finn ut om du har mer enn 1000 bidrag, eventuelt 1000 bidrag siden du var blokkert, og om du mener det er sannsynlig at du ville blitt stemt frem til administrator. Da er du sannsynligvis på whitelist fordi analysen med stor sikkerhet kan droppes. Hvis du ikke er det så er det fordi jeg ikke har oppdatert lista siden en gang tidlig i sommer, blant annet fordi gjennomgang av denne lista er en prosess hvor flere administratorer blir trukket inn.

Finner du at bidragene dine ikke blir godkjent? For å effektivisere og senke lasten på serverene har boten en forsinkelse. Selv med forsinkelse er det ikke alltid at dataene på plass når boten spør, og en del redigeringer vil aldri bli godkjent på grunn av dette. Hvis den ikke klarer å godkjenne av en eller annen grunn vil bidraget aldri bli godkjent av boten, og må håndteres manuelt. Legg til at boten lett ramler av RC-kanalen når det er mye trafikk.

Løpende monitorering

Brukere og artikler kan listes manuelt på to lister; Bruker:Rcpatrol/whitelist og Bruker:Rcpatrol/blacklist. På listene vil det være brukere med generelle oppføringer, brukere med føringer på enkeltartikler og enkelt artikler. Det er også mulig å liste brukere og artikler lokalt i en konfigurasjonsfil. Lista Bruker:Rcpatrol/logg angir de som på ett eller annet tidspunkt er blitt whitelista elelr har blitt autogodkjent.

De offentlige listene brukes ikke for øyeblikket

Boten vil også laste ned to automatisk genererte lister; boter og administratorer. Disse brukes som lister over brukere som skal ignoreres. Whitelisting av etablerte boter ville skape en unødig stor ekstralast, og administratorer kan i utgangspunktet selv velge om de ønsker en egengodkjenning.

Boten produserer en liste av brukere på bakgrunn av en analyse som indikerer hvorvidt brukere er «kjente gode bidragsytere» eller om de ikke har nådd en slik status. Denne lista kan brukes for å lage en offisiell liste av whitelistede brukere.

Scriptet trenger ikke å kjøre som noen spesiell bruker på IRC-kanalen, men den må være administrator for å kunne godkjenne endringer.

Boten tar ikke hensyn til meldinger på #vandalism-no-wp, noe som gjør at en del viktig informasjon om mulige problembrukere og –artikler går tapt.

Generering av ticker

Analysen som fører frem til generering av ticker-meldingen baserer seg på tidligere aktivitet av brukeren kombinert med resultater fra IRC-boten. Listen inneholder et antall redigeringer som bør etterses da de enten ikke er godkjent eller det ikke er senere redigeringer som løser problempunkt. Scriptet er sentralt for å fremtvinge en shunting av vandalisme som overlever en initiell fase.

Metodikken i analysen er at om en redigering eksplisitt blacklistes så vil en artikkel alltid listes som redigert, foran eventuell whitelisting. En usjekket RC-patrol anføres på greylist og kan fremheves eller modereres. En senere sjekket redigering kan fjerne en oppføring på greylist hvis ikke en oppføring på blacklist fremhever (forsterker) oppføringen. Hvis oppføringen whitelistes kan den bli fjernet.

Dette scriptet må kjøre som admin for å kunne lese datagrunnlaget for statistikken, mens opplastingen av resultatet kan kjøre som en alminnelig bruker.

Dette scriptet er ikke aktivt.

Statistikk

Det er mulig å bruke boten til å generere rådata som kan brukes for å genere statistikk for errosjonsrate knyttet til upatruljerte endringer. Dette er redigeringer hvor endringer ikke er patruljert og uten at det finnes noen etterfølgende whitelistet redigering. Upatruljerte endringer vil være en indikasjon på vandalisme som overlever og en slik statistikk gir derfor en god indikasjon på hvor effektiv vandalismebekjempelsen er til enhver tid.

Rådata for å lage en slik statistikk er revisjonsid for de artikler som ikke er patruljert. En slik logg vil kontrolleres hver time eller hver dag og vil over tid suksessivt få færre og færre oppføringer, typisk faller antallet eksponensielt. Sammenholdes dette tallet fortløpende med antallet redigeringer en passende tidsenhet tidligere vil det fremkomme en errosjonsrate.

Normal last på de som rydder er en konstant innenfor en tidsluke, og da tidsluken forskyver seg vil en konstant andel av vandalismen passere. En mindre andel brukere vil observere i en lengre tidsluke noe som gjør at det kan beregnes konstanter som beskriver errosjonen av vandalismen som en serie linjære fragmenter, som igjen vil anta noe som ligner en eksponentialkurve. Kurven blir glattet en del av forhold som har med hvordan brukere leser innen settet. Bidrag i starten av lista er det mer sannsynlig at blir revertert.

Hvis en introduserer en merking av artikler som har vandalisme, eller som er ryddet for slikt, så går funksjonen over fra å være en enkel ekspontalfunksjon til å bli en dobbelt eksponentialfunksjon. Resultatet er en dramatisk shunting av vandalisme. Forskjellige strategier for merking av vandalisme vil gi forskjellige overgangsformer.

I noen tilfeller har jeg hatt mulighet til å observere hvordan scriptet påvirker levetiden til vandalisme, og en grov tommelfingerregel er at 1 av 50 overlever når scriptet står. Når scriptet går synker tallet til 1 av 200 eller mindre, muligens helt ned mot 1 på 500. det er vanskelig å tallfeste dette uten å metodisk gå gjennom store mengder bidrag.

Det er mulig å kompensere for scriptet ved å merke kjente gode brukere, men dette er i praksis det brukere gjør automatisk ved å gjenkjenne brukere. I ytterste konsekvens vil brukere gå etter «registrert» vs «uregistrert» bruker. Uten noen form for merking av bidrag vil dette kun skalere funksjonene med en konstant, bidragene må merkes om det skal ha noen reell effekt ved at en skifter fra den enkle til den doble eksponentialfunksjonen.

Probability of Detection – PoD

Sannsynligheten for at brukere skal oppdage vandalisme er beskrevet av probability of detection. Denne er beskrevet ved flere faktorer, men hovedsaklig er den en funksjon av antall brukere og tiden de observerer det aktuelle forholdet. Sterkt forenklet er dette anatll aktive på Spesial:Siste endringer og hvor mange oppføringer de har oppe i dette vinduet. Normalt er det 50 linjer så dette beskriver grovt sett observasjonstiden.

Når en går ut av lukene hvor bidrag blir metodisk observert, så må en ta i bruk andre metoder for å fange opp det gjenværende av vandalisme. Det er ukjent hvordan det eksisterende noe mer optimaliserte brukergrensesnittet for siste endringer vil påvirke vandalismenivået, men da dette har et antall oppføringer som listes og deretter komprimeres de som er innenfor et tidsvindu, så virker det sannsynlig at situasjonen er uforandret. En annen måte er å lage egne tickers som samler opp det gjenværende og presenterer dette på en kompakt måte. En tredje mulighet er å lage en modifisert utgave av Lupins Anti-vandal script som suksessivt fjerner løste «problemer» mens det akkumulerer gjenværende «problemer».

Torblokkeringsboten

Her er det vandalisme som raskt skyves ut av «deteksjonsvinduet» på grunn av botaktivitet. Oppføringene henviser til tre tilfeller av tildels grov vandalisme.

Torblokkeringsboten påvirker vandalismesituasjonen negativt da den driver bidrag ut av observasjonsvinduet på kortere tid enn normalt. Desto større andel meldinger fra torblokkeringsboten i dette vinduet desto mindre andel observerbare redigeringer. Det gjør at brukere har kortere tid tilgjengelig for å observere vandalisme og igangsette mottiltak. Grovt anslått med dagens trafikk representerer torblokkeringsboten et merarbeid tilsvarende 10-15 administratorer med dagens gjennomsnittlige aktivitetsnivå. Uten disse propagerer vandalisme ut i artikkelbasene.

Satt på spissen fjerner Rcpatrol vandalisme ved å øke PoD, mens torblokkeringsbot øker vandalisme ved å senke PoD.

Det må også tas med at en del vandalisering kommer via tor-nettverket, men utfra de sparsomme tallene som finnes så virker det som åpne proxyer er en adskillig større kilde til vandalisme enn tor-nettverket.

Div

Residue når boten går er dominert av iw-lenking som ikke blir godkjent tilfeldige smårettinger og kategorisering. Den første gruppen kan påvises ved å gjøre to tester; følge iw-lenken for å se om det finnes en backlink hvis den er lagt til og om det mangler backlink hvis den er fjernet, eller ved å se på om det finnes andre iw-lenker med samme tittel. Den andre gruppen kan detekteres ved å se på om antall skrivefeil synker etter endringen. Muligens er andel skrivefeil et bedre mål. Hvis det skjer så er sannsynligvis endringen en korrekt retting. Kategoriseringer er vanskelig å teste da det ligger mye tolkinger til grunn for dette.

Kortversjonen er at residue faller til en femtedel eller mindre når boten går, og av tidligere tall er det tydelig at rundt 2% av dette residuet representerer vandalisme som har overlevd ryddeprosessene. Andelen svinger noe med ukedag. Angitte cvn-problemer kommer av en endring i kanalstrukturen til Counter Vandalism Network som gjorde at vandalismebotene og rcpatrol ikke lengre kunne rapportere aktiviteten.

søndag  23. sep 232 bot står (Det er i underkant av 2000 entries i hovedrommet denne dagen, det var 299 uregistrerte bidrag)
lørdag  22. sep 221 bot står
fredag  21. sep  62 startet på formiddagen, stoppet sent på kvelden (Det var 326 uregistrerte bidrag denne dagen)
torsdag 20. sep 250 nettutfall, cvn-problemer
onsdag  19. sep 258 nettutfall, cvn-problemer
tirsdag 18. sep 256 nettutfall, cvn-problemer