Vi är grymma på faktagranskning på J++. Trodde vi åtminstone. I början av juni höll det nämligen på att gå rejält snett, och vi insåg att vår faktagranskning hittills varit mer baserad på känsla än metod.
I korthet hände följande: Strax efter att vi lanserat studien ”Där bor journalisterna”, där vi för Institutet för mediestudier kartlagt var och i vilka typer av områden Sveriges journalister bor, frågade en person oss på Facebook om vi verkligen menade att skriva ”utrikes födda” i vår rapport. Det menade vi inte. Det skulle stå ”utländska medborgare” (siffrorna var per valdistrikt, och kom från valmyndigheten). Efter att ha rättat bildtexterna på webben (boken hade ännu inte gått till tryck), kunde vi konstatera att vi klarat oss ganska lindrigt undan. Vi gjorde kontrollkörningar på äldre siffror över utlandsfödda och utländska medborgare per valdistrikt i de städer där vi använt fel beteckning, och kunde konstatera att siffrorna följdes åt. Vi kontrollerade de analyser som gjorts på felaktiga premisser, och kunde konstatera att de fortfarande höll. Men det var ren tur. Felet hade lika gärna kunnat smyga sig in på ett ställe där det verkligen betytt något.
Skärrad gick jag igenom all mejlkonversation, alla arbetsdokument, för att se hur felet kunnat uppstå, och varför det inte upptäckts. Den första frågan gick lätt att svara på. Det var ett ganska ointressant misstag, urtypen för ett ”mänskliga faktorn”-fel. Ett sådant som hänt tidigare, och kommer att hända igen. Och igen. Den andra frågan var värre: Varför hade ingen upptäckt det? Det var när vi inte lyckades svara på den frågan, som vi insåg att vi behövde tydligare rutiner för faktagranskning. Vi behövde hitta datajournalistikens motsvarighet till ”line-by-line”-metoden.
Efter att ha läst in oss på metoder och riktlinjer som används vid andra datajournalistik-redaktioner, satte vi ihop ett utkast till en sådan metod för J++. Det är ett utkast, men vi börjar använda den från och med i dag. Sedan tror vi att vi kommer att hitta skäl att skruva på den, och skära i den, i takt med att vi använder den, och vi hoppas få kloka synpunkter från andra redaktioner. Många av er som läser det här har arbetat med datadriven journalistik innan J++ var påtänkt, och sitter säkert på tonvis med erfarenhet av vad som fungerar och inte. Utkastet finns också på Github, om du vill föreslå ändringar, eller forka det där.
J✓✓
Disputation
vad?
En person i redaktionen ska hållas helt utanför researchen. Hen är vår ”opponent”. Opponenten kallar till ett slags intern disputation i slutet av projektet.
varför?
Med en disputation upptäcker vi fler svagheter själva.
hur?
Opponenten ska:
- Ifrågasätta definitioner
- Kontrollera mot dataregistret att rätt data används till rätt sak
- Fråga hur uträkningar gjorts
- Bedöma om slutsatserna är rimliga
- Göra flera stickprov
- Göra en formmässig korrläsning: sifferformat, enheter, skalor etc
Centralt register med ursprungsdata
vad?
I början av varje projekt ska all originaldata samlas på ett ställe.
varför?
Med ett centralt dataregister undviker vi att data om- och feldefinieras på vägen.
hur?
- All originaldata samlas (och skrivskyddas) i en mapp
- Där ska också finnas en textfil med källförteckning
- Notera gärna antalet rader (eller relationer, eller motsvarande beroende på datatyp) för varje dataset i textfilen, för att kunna dubbelkolla att ingen data trunkerats under projektets gång.
- Alla nya datakällor som tillkommer ska föras in här.
Inledande datakoll
vad?
När projektet inleds, och när ny data hämtas in, ska det finnas tid avsatt att kontrollera datakvaliteten.
varför?
Med en inledande datakoll kan vi upptäcka export- och importfel, och fel som begåtts av avsändaren
hur?
- Pivotera på nyckelkolumner för att se att där inte finns olika stavningar av samma namn.
- Kontrollera att alla [kommuner/länder/personer/sjukdomar/etc] finns med.
- Kontrollera nollvärden. Ska det vara 0, eller är det tomma rutor som blivit kodade som nollor på vägen?
- Kontrollera tomma rutor. Ska de vara tomma?
- Är värdena rimliga?
- Visualisera, för att få syn på märkliga mönster, extremt avvikande punkter, etc.
Versionshantering
vad?
För att kunna spåra eventuella fel måste vi kunna se vilka bearbetningar som gjorts, och av vem.
varför?
Med versionshantering upptäcker vi misstag enklare
Med versionshantering ser vi enklare om ett fel fått följdeffekter
hur?
- Sträva efter att göra all databearbetning i kod.
- Om databearbetning görs i kalkylprogram eller liknande, spara varje ny version under ett nytt namn. Varje datafil får en egen mapp, som döps efter originaldatafilen. Versionsfilerna namnges sedan enligt konventionen
YYMMDDxx - ändringsbeskrivning. Till exempel:sverigekarta/15060401 - Lade till postnummergränser.shp - Eller versionshantera ännu hellre med Git.
- När vi samarbetar med andra, kan vi arbeta med en Dropbox-mapp, synkad till Github, eller testa någon av alla lösningar för att synka Google Docs med Github.
Standardformat för data på fil
vad?
Vi använder alltid samma format för data på fil.
varför?
Enhetliga filformat minskar risken för att fel införs i samband med konverteringar.
hur?
- CSV-filer för tabeller (kommaseparerade kolumner, citattecken som strängcontainer)
- XLSX-filer for tabeller med formler
- JSON för hierarkisk data
- Shapefiler för geodata
- ...och alltid UTF-8
Line-by-line för artiklar
vad?
Artikeltexter faktagranskas påstående för påstående.
hur?
- Den som inte själv varit aktiv i research leder line-by-line-läsningen av artiklar.
- Tänk på att påståenden inte bara finns i text, utan också i illustrationer. Även en koroplet-karta är en utsaga!
Öppenhet
vad?
Ett öppet Github-repo är i sig ingen garant för att någon kommer att gå in och granska vår data. Fundera i varje projekt på vad vi kan bjuda kollegor och andra intresserade på, som hjälper oss att få fler ögon på datan. Har vi tagit fram något unikt, som andra är intresserade av? Bjussa på det!
varför?
Med öppenhet upptäcker vi svagheterna tidigare
hur?
- Öppet Github-repo, så ofta det går
- ...med en README-fil som dokumenterar
- Identifiera något i projektet som andra kan ha nytta av, och dela det, i första hand via Google Sheets
- Github-repot ska om möjligt innehålla originaldata
Den sista punkten, öppenhet, är viktig. Ett av våra interna mål på J++ är att alla projekt vi tar oss an ska innehålla något nytt. Något som är nyskapande i genren, eller något moment som vi själva inte behärskar sedan tidigare. Det gör det extra viktigt för oss att få hjälp utifrån att kontrollera det vi gör. Hjälp oss gärna! Om inte annat genom att tala om vad som saknas och vad som kan tas bort i den här metodskissen!