Best practice for dokumentversionsstyring
Best practice for dokumentversionsstyring til teams med et eksisterende nummereringssystem: hold det stabilt, vis version og godkender fast på siden, undgå parallelle redigeringer, og log hvert review uden ændringer.
Sådan fungerer det
Frys nummereringssystemet, når rigtige dokumenter afhænger af det
Behandl en ændring af selve systemet (at gå fra hele tal til semantisk versionering, eller at omdefinere, hvad et decimaltal betyder) som et projekt, ikke en justering: det ugyldiggør hver eksisterende krydshenvisning, oplæringsregistrering og tidligere auditcitat. Dukker en fejl op, så dokumentér undtagelsen fremadrettet i stedet for at omnummerere biblioteket.
Sæt version, dato og godkender ét fast sted på hver skabelon
Vælg én position (sidehoved eller sidefod) og bag den ind i dokumentskabelonen, så hver forfatter bruger den uden at skulle beslutte det. Et versionsnummer i et filnavn eller i dokumentets egenskaber overlever ikke en udskrift, et skærmbillede eller en videresendt mail; ét trykt på siden gør.
Giv den »gældende« version en lås- eller checkout-konvention
Beslut, hvem der må have den gældende version åben til redigering ad gangen, og hvordan en anden forfatter finder ud af, at nogen allerede har den: et checkout-flag i registret, en låst fil, eller én kanonisk, levende kopi, hvor kun én gemning kan vinde ad gangen. Uden dette er to godkendte redigeringer, der lander på samme version, ikke en hypotese.
Skriv reglen om hovedversion over for mindre version ned, før det første dokument har brug for den
Angiv, i det samme dokument, der definerer nummereringssystemet, præcis hvad der udløser et hele-tal-trin: formel godkendelse alene, eller godkendelse plus en væsentlig omskrivning. Et team, der beslutter dette fra sag til sag, ender med to forskellige dokumenter, der begge hedder version 2.0.
Registrér hvert periodisk review, også dem, der ikke ændrer noget
Giv reviewtrinnet en Beslutning-figur med en navngiven »ingen ændring«-udgang, der skriver en dateret post i registret, på samme måde som »Ønskes der ændring efter publicering?« når frem til »Aktuel version forbliver gældende« i stedet for blot ikke at gøre noget. En manglende post bør betyde, at reviewet ikke fandt sted, ikke at der ikke skete noget under det.
Lad én kanonisk, levende kopi fjerne låseproblemet helt
Åbn dokumentet som et QueryChart-diagram i stedet for et sæt filer, der sendes rundt over mail, og der er kun én gældende version at redigere: hver gemning fanges automatisk som en ny post i ændringsloggen, så en checkout-konvention ikke har noget tilbage at håndhæve. Se /features/version-control.
Ofte stillede spørgsmål
Hvad er den enkelt største fejl at undgå i dokumentversionsstyring?
At behandle systemet som fast kun indtil, nogen finder en grund til at ændre det. At omnummerere et eksisterende bibliotek (selv for at rette en reel fejl) ødelægger hver krydshenvisning, oplæringsregistrering og auditcitat, der navngav de gamle numre, og den omkostning overstiger næsten altid omkostningen ved at leve med et ufuldkomment system. Ret problemer fremadrettet med en dokumenteret undtagelse, ikke ved at røre det, der allerede er udstedt.
Hvordan stopper jeg to personer i at redigere den samme »gældende« version samtidig?
Enten tilføj en eksplicit checkout-konvention (et flag i registret, der viser, hvem der har dokumentet åbent, så en anden forfatter ved, at de skal vente) eller fjern muligheden strukturelt ved at holde præcis én kanonisk, levende kopi i stedet for filer, der sendes rundt over mail eller et fælles drev. QueryChart gør det sidste: hvert dokument er ét levende diagram, hver gemning versioneres automatisk, og der er ingen anden kopi at forgrene. Se /features/version-control.
Hvad bør tælle som en hovedversion over for en mindre version?
Der findes ingen universel regel, hvilket er præcis grunden til, at det skal skrives ned, før det første dokument har brug for det, frem for vurderet fra sag til sag. En almindelig konvention binder hele-tal-trinnet, hovedversionen, til formel godkendelse alene (hver udkastrevision imellem, uanset hvor omfattende, forbliver et decimaltal), så »hvor stor var ændringen« aldrig skal diskuteres i det øjeblik, et versionsnummer tildeles.
Skal jeg logge et periodisk review, der ikke fandt nogen ændringer nødvendige?
Ja: et uregistreret review er umuligt at skelne fra et review, der aldrig fandt sted. Giv reviewtrinnet i jeres proces en Beslutning-figur med en navngiven udgang for »ingen ændring nødvendig«, der stadig skriver en dateret post i registret, på samme måde som en diagram-beslutningsrække registrerer hver gren, den tager, ikke kun dem, der fører et nyt sted hen.