Forord

Karl Fogel

Chicago, 14. mars 2004

En dårlig FAQ (Ofte stilte spørsmål) er en som ikke er satt sammen av spørsmål brukere faktisk stiller, men det som forfatterne ønsker at de ville spørre om. Du har kanskje sett noe lignende som dette før:

Spm.: Hvordan kan jeg bruke Glorbosoft XYZ til å øke lagproduktiviteten?

Sv.: Mange av våre kunder vil vite hvordan de kan maksimere produktiviteten gjennom våre patenterte kontor-gruppevareløsninger. Svaret er enkelt: Først, klikk på “Fil”-menyen, rull ned til “Øk produktiviteten”, deretter …

Problemet med slike FAQ-er er at de er, bokstavelig talt, ikke FAQ-er i det hele tatt. Ingen ringer teknisk support og spør: “Hvordan kan vi øke produktiviteten?” Istedenfor spør folk høyst spesifikke spørsmål som for eksempel: “Hvordan kan vi forandre kalendersystemet til å sende påminnelser to dager i forveien istedenfor en?” og så videre. Men det er er mye lettere å lage spørsmål istedenfor å oppdage de spørsmålene som egentlig blir stilt. Det å sette sammen en FAQ må være en sammenhengende og organisert prosess som varer hele levetiden til programmet, innkommende spørsmål må bli lagret, responsen fulgt, og alt dette må samles i en fyldig, søkbar helhet som avspeiler den kollektive opplevelsen for brukerne ute i det fri. Det krever en tålmodig og observant innstilling hos en som befinner seg i felten. Ingen store hypoteser, ingen visjonære uttalelser her – åpne øyne og nøyaktige notater er det som trengs mest.

Det jeg liker med denne boka er at den vokste fram nettopp gjennom en slik prosess, og dette vises på hver eneste side. Den er det direkte resultatet av forfatterens møter med brukerne. Det begynte med Ben Collins-Sussmans observasjon av at folk spurte de samme enkle spørsmålene om og om igjen på mailinglisten til Subversion: Hva er standard fremgangsmåte for å bruke Subversion? Virker forgreninger og merker på samme måte som i andre versjonskontrollsystemer? Hvordan kan jeg finne ut hvem som gjorde en spesiell forandring?

Frustrert over å se de samme spørsmålene dag etter dag, jobbet Ben intenst over en måned sommeren 2002 for å skrive The Subversion Handbook, en 60-siders håndbok som tok for seg all grunnleggende bruk av Subversion. Håndboka tok ikke mål av seg å være komplett, men den ble distribuert med Subversion og hjalp brukere over den innledende humpen i lærekurven. Da O’Reilly and Associates bestemte seg for å publisere en fullversjon av Subversion-boka, var minste motstands vei opplagt: Å utvide håndboka.

De tre medforfatterne av den nye boka ble dermed presentert for en uvanlig mulighet. Offisielt var deres oppgave å skrive ei bok ovenfra og ned, å starte med innholdet og et innledende utkast. Men de hadde også tilgang til en jevn strøm – faktisk en ukontrollerbar geysir – av materiale som kom fra gressrotplan. Subversion var allerede i hendene på tusenvis av tidlige brukere, og disse brukerne ga tonnevis med tilbakemeldinger, ikke bare om Subversion, men om den eksisterende dokumentasjonen.

Gjennom hele tiden de skrev denne boka, trålte Ben, Mike og Brian konstant malilinglisten til Subversion og fulgte med i snakkerom mens de nøye skrev ned problemer brukere hadde i virkelige situasjoner. Å holde øye med slike tilbakemeldinger er en del av deres arbeidsoppgaver hos CollabNet uansett, og det ga dem en stor fordel når de satte i gang med å dokumentere Subversion. Boka de produserte er fast forankret i erfaringens grunnfjell, ikke i den skiftende sanden av ønsketenkning; den kombinerer de beste aspektene av en brukerhåndbok og en liste over ofte spurte spørsmål. Denne tosidigheten er kanskje ikke så merkbar ved første gjennomlesing. Tatt i rekkefølge, forside til bakside, er boka rett og slett en likefrem beskrivelse av et stykke programvare. Oversikten finnes der, den obligatoriske guidede gjennomgangen, kapittelet om administrativ konfigurasjon, noen avanserte tema, og selvfølgelig en referanse over kommandoer og problemer som kan dukke opp. Bare når du kommer tilbake til den senere, når du vil lete opp løsningen på et spesifikt problem, da viser det seg: Detaljene i fortellingen kan bare være resultatet av møter med det uventede, eksemplene finslipt av virkelige bruksmåter, og mest av alt forståelsen av brukerens behov og hvordan situasjonen tar seg ut fra brukerens ståsted.

Selvfølgelig, ingen kan love at denne boka vil kunne svare på hvert eneste spørsmål du har om Subversion. Noen ganger vil presisjonen i hva den forventer av spørsmål være uhyggelig telepatisk; andre ganger kan du finne et hull i fellesskapets kunnskap, og du står tomhendt tilbake. Når dette skjer, er den beste tingen du kan gjøre å sende en epost til og legge fram problemet ditt. Forfatterne er fortsatt der, de følger fortsatt med, og disse består ikke bare av de tre på forsiden, men også mange andre som har bidratt med korreksjoner og originalt materiale. Fra fellesskapets synspunkt er det å løse problemet ditt bare en behagelig bieffekt av et mye større prosjekt – det å sakte tilpasse boka, og aller helst Subversion selv, til å samsvare mer med hvordan den faktisk brukes. De er ivrige etter å høre fra deg, ikke bare fordi de kan hjelpe deg, men fordi du kan hjelpe dem. Det er med Subversion som med alle aktive prosjekter innen fri programvare, du er ikke alene.

La denne boka bli din første ledsager.