diff options
Diffstat (limited to 'debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2.default~da.sst')
| -rw-r--r-- | debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2.default~da.sst | 504 |
1 files changed, 504 insertions, 0 deletions
diff --git a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2.default~da.sst b/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2.default~da.sst new file mode 100644 index 00000000..83b7a689 --- /dev/null +++ b/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2.default~da.sst @@ -0,0 +1,504 @@ +% SiSU 0.38 + +@title: Debians vedtægter + +@subtitle: Debian-projektets vedtægter (v1.2) [This Document has been Superseded by v1.3] + +@creator: Debian Project + +@type: information + +@subject: debian policy + +@date.created: 1998-12-03 + +@date.issued: 1998-12-03 + +@date.valid: 2003-10-29 + +@date.available: 2003-10-29 + +@date.modified: 2003-10-29 + +@date: 2003-10-29 + +@language.document: Danish + +@language.original: English + +@level: new=C; num_top=1 + +@skin: skin_debian + +@bold: Debian; DPL + +% @italics: + +@rights: http://www.debian.org/license.da.html Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/ <br>Dette materiale må kun distribueres i henhold til vilkårene beskrevet i Open Publication License, udkast (draft) v1.0 eller senere (du kan læse vores lokale kopi http://www.debian.org/opl, den seneste version er normalt tilgængelig på http://www.opencontent.org/openpub/ ).<br>"Debian" og Debians logo http://www.debian.org/logos/ er varemærker tilhørende Software in the Public Interest, Inc.<br>Dette er en oversættelse af det originale engelsksprogede dokument http://www.debian.org/license.en.html. + +@links: {Authoritative Source Document}http://www.debian.org/devel/constitution +{SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2.default/sisu_manifest.html +{SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2.default/sisu_manifest.html +{Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html +{About Debian}http://www.debian.org/intro/about +{News}http://www.debian.org/News/ +{Getting Debian}http://www.debian.org/distrib/ +{Support}http://www.debian.org/support +{Developer's Corner}http://www.debian.org/devel/ +{Sitemap}http://www.debian.org/sitemap +{Search}http://search.debian.org/ + +@prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.<br>Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2.default/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original + +@rcs: $Id: debian_constitution_v1.2.default~dk.s3,v 1.7 2006/02/28 12:11:55 ralph Exp $ + +:A~ Debians vedtægter + +:B~ Debian-projektets vedtægter (v1.2) [This Document has been Superseded by v1.3] + +1~pre [Prefix]-# + +Version 1.2 blev godkendt den 29. oktober 2003. Erstatter version 1.1 som blev godkendt den 21. juni 2003, der erstattede version 1.0 som blev godkendt den 2. december 1998. + +1~1 §1. Introduktion + +Debian-projektet er en sammenslutning af personer, som har det fælles mål at udvikle et frit tilgængeligt styresystem. + +Dette dokument beskriver organisationsstrukturen for formelle beslutninger i projektet. Det beskriver ikke projektets mål eller hvordan vi opfylder disse, og indeholder ingen retningslinier, bortset fra de retningslinier som direkte vedrører beslutningsprosessen. + +1~2 §2. Beslutningsdygtige organer og -personer + +Enhver beslutning i projektet er omfattet af en eller flere af følgende: + +# Udviklerne, via en fælles resolution eller et valg; + +# Projektlederen; + +# Den tekniske komité og/eller dennes formand; + +# Den individuelle udvikler som arbejder med en bestemt opgave; + +# Delegater udnævnt af projektlederen til at varetage særlige opgaver; + +# Projektsekretæren. + +Resten af dette dokument vil primært beskrive disse organers fuldmagter, deres sammensætning og udnævnelse, og procedurer for vedtagelser. En persons eller et organs fuldmagt kan i visse tilfælde blive genstand for gennemsyn af andre; i så fald vil det fremgå af afsnittet om det organ, der står for dette. I listen ovenfor er hver person eller hvert organ stort set anført før de personer eller organer de kan (hjælpe til med at) udnævne, og hvis beslutninger de kan ophæve - men ikke alle, der er anført tidligere, kan ophæve beslutninger fortaget af alle som er anført senere. + +2~2.1 §2.1. Generelle regler + +# Intet i disse vedtægter forpligter nogen til at arbejde for projeket. En person, der ikke vil udføre en opgave, som er blevet uddelegeret eller pålagt vedkommende, behøver at gøre det. Derimod kan man ikke aktivt modarbejde regler eller beslutninger, som er foretaget korrekt i henhold til reglerne. + +# En person kan bestride flere hverv, bortset fra at projektlederen, projektsekretæren og formanden for den tekniske komité skal være forskellige personer, og lederen kan ikke udnæve sig selv, som sin egen delegat. + +# En person kan til enhver tid forlade projektet eller fratræde et særskilt hverv vedkommende har, ved offentligt at erklære dette. + +1~3 §3. Individuelle udviklere + +2~3.1 §3.1. Fuldmagt + +En individuel udvikler kan + +# tage tekniske og ikke-tekniske beslutninger med hensyn til sit eget arbejde; + +# foreslå og støtte udkast til generelle resolutioner; + +# foreslå sig selv som kandidat til projektleder i valg; + +# stemme på generelle resolutioner og i ledervalg. + +2~3.2 §3.2. Sammensætning og udnævnelse + +# Udviklere er frivillige som er enige om at fremme projektets mål for så vidt som de deltager i det, og som vedligeholder pakke(r) for projektet eller gør andet arbejde, som projeketlederens delegater anser for værdifuldt. + +# Projektlederens delegater kan vælge ikke at optage nye udviklere, eller at ekskludere nuværende udviklere. Hvis udviklerne mener at delegaterne misbruger deres autoritet, kan de selvfølgelig ophæve en beslutning via en generel resolution - se §4.1(3) og §4.2. + +2~3.3 §3.3. Fremgangsmåder + +Udviklerne kan foretage disse beslutninger efter eget skøn. + +1~4 §4. Udviklerne via generel resolution eller et valg + +2~4.1 §4.1. Fuldmagt + +Udviklerne kan sammen: + +# Udnævne eller afsætte projektlederen. + +# Ændre disse vedtægter med et 3:1-flertal. + +# Ophæve enhver beslutning taget af projektlederen eller en delegat. + +# Ophæve enhver beslutning taget af den tekniske komité, såfremt de er enige med et 2:1-flertal. + +# Udgive, erstatte og tilbagetrække ikke-tekniske retningslinier og erklæringer. + +Dette inkluderer dokumenter som forklarer projektmål, dets forhold til andre organer indenfor fri software, samt ikke-tekniske vejledninger som de fri software-licensbetingelser, som Debians programmel skal leve op til. + +Det kan også være stillingtagen til aktuelle emner. + +_# Et grundlæggende dokument er et dokument eller en bekendtgørelse, der betragtes som kritisk for projekts arbejde og formål. + +_# De grundlæggende dokumenter er det arbejde som er udmundet i Debian sociale kontrake og Debians retningslinier for fri software. + +_# Et grundlæggende dokument kræver et 3:1-flertal for dets erstatning. Nye grundlæggende dokumenter udgives og eksisterende dokumenter trækkes tilbage ved at føje til listen over grundlæggende dokumenter i disse vedtægter. + +# Træffe beslutninger sammen med projektlederen og SPI om forvaltede ejendele til formål der har relation til Debian. (Se §9.1). + +2~4.1 §4.2. Fremgangsmåde + +# Udviklerne følger de generelle resolutionsprocedurer beskrevet nedenfor. En resolution eller ændring betragtes som introduceret, hvis den er foreslået af en hvilken som helst udvikler og mindst K andre udviklere støtter den, eller hvis den er foreslået af projektlederen eller den tekniske komité. + +# Udsættelse af en resolution foretaget af projektlederen eller dennes delegater: + +_# Hvis projektlederen, dennes delegater eller den tekniske komité har truffet en beslutning, kan udviklerne ophæve denne ved at vedtage en resolution derom, se §4.1(3). + +_# Hvis en sådan resolution støttes af mindst 2K udviklere eller hvis den er foreslået af den tekniske komité, vil resolutionen omgående tilsidesætte beslutningen (såfremt resolutionen selv siger dette). + +_# Hvis den oprindelige beslutning var at ændre en diskussionsperiode eller en stemmeperiode, eller hvis resolutionens formål er at ophæve en beslutning foretaget af den tekniske komité, behøver kun K udviklere at støtte resolutionen, for omgående at kunne tilsidesætte beslutningen. + +_# Hvis beslutningen er tilsidesat, holdes omgående en afstemning for at afgøre om beslutningen skal opretholdes indtil en fuldstændig afstemning om beslutningen kan holdes, eller om udførslen af den oprindelige beslutning skal udsættes indtil da. Der findes ikke et beslutningsdygtigt antal stemmer i denne omgående, proceduriske afstemning. + +_# Hvis projektlederen (eller dennes delegater) trækker den oprindelige beslutning tilbage, bliver det uaktuelt at holde afstemningen og den vil ikke blive afholdt. + +# Stemmer indsamles af projektsekretæren. Stemmerne og afstemningsresultatet offentliggøres ikke i stemmeperioden; efter afstemningen opremser projektsekretæren alle de afgivne stemmer, Afstemningsperioden er to uger, men projektlederen kan tilføje eller fjerne op til en uge. + +# Minimumstiden for diskussion er to uger, men projektlederen kan tilføje eller fjerne op til en uge. Projektlederen har den afgørende stemme. Det beslutningsdygtige antals stemmer er 3Q. + +# Forslag, støtte, ændringer, stemmeopråb og andre formelle handlinger foregår via erklæringer på en offentlig tilgængelig elektronisk postliste udvalgt af projektlederens delegat(er); alle udviklere har skriveadgang til den. + +# Stemmer afgives via e-mail på en måde der bestemmes af sekretæren. Sekretæren bestemmer for hver afstemning hvorvidt vælgerne kan ændre deres stemmer. + +# Q er halvdelen af kvadratroden af antallet af udviklere. K er den mindste af Q og 5. Q og K behøver ikke at være heltal, og de afrundes ikke. + +1~5 §5. Projektlederen + +2~5.1 §5.1. Fuldmagt + +Projektlederen kan: + +# Udnævne delegater eller uddelegere beslutninger til den tekniske komité. + +Lederen kan beskrive en opgave med løbende ansvar eller en særskilt beslutning. I begge tilfælde overføres denne til en anden udvikler eller til den tekniske komité. + +Efter en særskilt beslutning er blevet uddelegeret og afgjort, kan projektlederen ikke trække uddelegeringen tilbage. derimod kan en løbende uddelegerning til en bestemt opgave trækkes tilbage. + +# Give hjemmel til andre udviklere. + +Projektlederen kan udgive støtteerklæringer til andres synspunkter eller andre projektmedlemmer, uden at være blevet bedt om det. Disse støtteerklæringer er gyldige, hvis, og kun hvis, lederen ville have haft fuldmagt til at træffe den foreliggende beslutning. + +# Foretage beslutninger som kræver omgående handling. + +Dette gælder ikke beslutninger som gradvist er blevet påtrængende på grund af manglende, relevant handling, med mindre der er en fastsat frist. + +# Foretage beslutninger som ingen andre har ansvaret for. + +# Fremstille udkast til generelle resolutioner og ændringsforslag. + +# Sammen med den tekniske komité udpege nye medlemmer til komitéen. (Se §6.2.) + +# Afgive en afgørende stemme i udviklernes afstemninger. + +Projektlederen har også almindelig stemmeret i sådanne afstemninger. + +# Ændre diskussionsperioden for udviklernes afstemninger (som beskrevet ovenfor). + +# Lede diskussioner blandt udviklerne. + +Projektlederen bør prøve at deltage i diskussioner blandt udviklerne på en hjælpsom måde, som søger at bringe diskussionen på rette kurs mod sagens kerne. Projektlederen bør ikke bruge lederpositionen til at fremme sine egne personlige synspunkter. + +# Tage beslutninger sammen med SPI, der vedrører ejendele som administreres til formål der vedrører Debian. (Se §9.1.) + +2~5.2 §5.2. Udnævnelse + +# Projektlederen vælges af udviklerne. + +# Valget begynder ni uger før lederpositionen bliver ledig eller (hvis det ikke allerede er for sent) omgående. + +# I de følgende tre uger kan enhver udvikler nominere sig selv som projektlederkandidat. + +# I de efterfølgende tre uger kan der ikke nomineres flere kandidater; kandiaterne bør anvende dette tidsrum til deres valgkamp (for at gøre opmærksom på sig selv og sine synspunkter). Hvis der ikke er nogen kandidater efter nomineringsperioden er slut, bliver perioden udvidet med yderligere tre uger, om nødvendigt gentagne gange. + +# De næste tre uger er valgperioden, hvori udviklerene kan stemme. Afstemningen i ledervalg er hemmelig, selv efter afstemningen er afsluttet. + +# Valget vil være mellem de kandidater, der har nomineret sig selv og som ikke har trukket sig tilbage, samt Ingen af de nævnte ("None of the Above"). Hvis Ingen af de nævnte vinder valget, bliver denne procedure gentaget, om nødvendigt mange gange. + +# Beslutningen træffes ved hjælp af den metode, som er beskrevet i afsnit §A.6 i de generelle resolutionsprocedurer. Det beslutningsdygtige antal er det samme, som ved en generel resolution (§4.2), og standardvalget er Ingen af de nævnte. + +# Projektlederen vælges for et år ad gangen. + +2~5.3 §5.3. Fremgangsmåde + +Projektlederen bør prøve at træffe beslutninger som er i tråd med konsensus blandt udviklerne. + +Hvor det er praktisk bør projektlederen på en uformel måde bede om udviklernes synspunkter. + +Projektlederen bør undgå at lægge for megen vægt på sine egne synspunkter, når der træffes beslutninger i vedkommendes egenskab af leder. + +1~6 §6. Teknisk komité + +2~6.1 §6.1. Fuldmagt + +Den tekniske komité kan: + +# Træffe beslutninger om tekniske retningslinier. + +Deriblandt også indholdet af de tekniske retningslinier, udviklernes håndbogsmateriale, pakkeeksempler og hvordan ikke-eksperimentelle pakkeopbygningsværktøjer skal fungere. (I hvert tilfælde træffer den almindelige pakkevedligeholder af programmellet eller dokumentationen, de første beslutninger; se §6.3(5).) + +# Afgøre tekniske spørgsmål hvor udviklernes ansvarsområder overlapper. + +I tilfælde hvor udviklere skal implementere kompatible tekniske retningslinier eller holdninger (for eksempel hvis de ikke er enige om prioriteringerne ved uforenlige pakker, eller om ejerskab af et kommandonavn, eller om hvilken pakke der er ansvarlig for en fejl som begge pakkevedligeholdere er enige om er en fejl, eller om hvem der bør være vedligeholder af en pakke), kan den tekniske komité afgøre sagen. + +# Træffe en beslutning når den bliver bedt om at gøre dette. + +Enhver person og ethvert organ kan uddelegere en af sine egne beslutninger til den tekniske komité eller bede om råd fra den. + +# Tilsidesætte en udviklers beslutning (kræver et 3:1-flertal) + +Den tekniske komité kan bede en udvikler om at benytte en bestemt fremgangsmåde, selvom udvikleren ikke ønsker det; dette kræver et 3:1-flertal. For eksempel kan komitéen komme frem til at en klage fremsat i en fejlrapport er gyldig og at indsenderens foreslåede løsning bør iværksættes. + +# Give råd. + +Den tekniske komité kan give formelle erklæringer om sit syn på enhvert emne. Individuelle medlemmer kan selvfølgelig give uformelle erklæringer om deres synspunkter og om komitéens sandsynlige synspunkter. + +# Sammen med projektlederen udnævne nye medlemmer til sig selv eller fjerne nuværende medlemmer. (Se §6.2.) + +# Udnævne formanden for den tekniske komité. + +Komitéen vælger formand blandt sine medlemmer. Medlemmerne af komitéen nomineres automatisk; valget starter en uge før stillingen bliver ledig (eller omgående, hvis det allerede er for sent). Medlemmerne kan stemme via offentlig tilkendegivelse for hvilket som helst komitémedlem, også sig selv. Der er intet standardvalg. Valget afsluttes når alle medlemmerne har stemt eller stemmeperioden er afsluttet. Resultatet afgøres ved hjælp af den metode, som er angivet i §A.6 i de generelle resolutionsprocedurer. + +# Formanden kan vikariere for lederen, sammen med sekretæren + +Som beskrevet i §7.1(2), kan formanden for den tekniske komité og projektsekretæren i fællesskab vikariere for lederen, hvis der ikke er en leder. + +2~6.2 §6.2. Sammensætning + +# Den tekniske komité består af op til otte udviklere og bør normalt have mindst fire medlemmer. + +# Hvis det er mindre end otte medlemmer, kan den tekniske komité anbefale ny(e) medlem(mer) til projektlederen, som (på egen hånd) kan vælge at udnævne dem eller ej. + +# Hvis der er fem eller færre medlemmer, kan den tekniske komité udnævne ny(e) medlem(mer) indtil antallet af medlemmer når seks. + +# Når der har været fem eller færre medlemmer i mindst en uge, kan projektlederen udnævne nye medlem(mer) indtil antallet af medlemmer når seks, med mindst en uges mellemrum for hver udnævnelse. + +# Hvis den tekniske komité og projektlederen er enige kan de fjerne eller erstatte et nuværende medlem af den tekniske komité. + +2~6.3 §6.3. Fremgangsmåde + +# Den tekniske komité anvender den generelle resolutionsprocedure. + +Et udkast til en resolution eller ændring kan framsættes af ethvert medlem af den tekniske komité. Det er ingen minimumstid for diskussion; valgperioden varer i op til en uge eller indtil der ikke længere kan være nogen tvivl om resultatet. Medlemmerne kan ændre deres stemmer. Det beslutningsdygtige antal er to. + +# Detaljerede afstemningoplysninger + +Formanden har den afgørende stemme. Når den tekniske komité stemmer for at afgøre, om de skal tilsidesætte en afgørelse taget af en udvikler, der også er et medlem af komitéen, kan dette medlem ikke stemme (med mindre det er formanden, som i dette tilfælde kun kan benytte sin afgørende stemmeret). + +# Offentlig diskussion og afgørelser + +Diskussioner, udkast til resolutioner og ændringer og komitemedlemmernes stemmer offentliggøres på den tekniske komités offentlige diskussionsliste. Der er ikke en særskilt sekretær for komitéen. + +# Fortrolighed ved udnævnelser + +Den tekniske komité kan holde fortrolige diskussioner via privat e-mail eller en privat postliste, eller på andre måder diskutere udnævnelser til komitéen. Derimod skal stemmerne ved udnævnelser offentliggøres. + +# Ikke et detaljeret udviklingsarbejde + +Den tekniske komité giver sig ikke i kast med fremstilling af nye forslag og retningslinier. Sådant udviklingsarbejde bør foretages privat af personer eller grupper, og diskuteres i almindelige tekniske og udviklingsfora. + +Den tekniske komité begrænser sig selv til at vælge blandt, eller vælge et kompromis mellem, løsninger og afgørelser, der er blevet foreslået og er blevet drøftet tilpas meget andre steder. + +Medlemmer af den tekniske komité kan selvfølgelig deltage på egne vegne i alle aspekter af udviklings- og retningsliniearbejde. + +# Den teknisk komité træffer kun afgørelser som en sidste udvej + +Den tekniske komité træffer ikke en teknisk afgørelse før der uden held har været gjort forsøg på at løse problemet ved konsensus, med mindre den er blevet bedt om at træffe en afgørelse af personen eller organet, der normalt ville have haft ansvar for at gøre dette. + +1~7 §7. Projektsekretæren + +2~7.1 §7.1. Fuldmagt + +Sekretæren: + +# Indsamler stemmer fra udviklerne, finder ud af hvor mange udviklere der er og hvem de er, når dette kræves af vedtægterne. + +# Kan vikariere for lederen, i fællesskab med formanden for den tekniske komité. + +Hvis der ikke er en projektleder, kan formanden for den tekniske komité og projektsekretæren træffe afgørelser ved enighed, hvis de mener at det er vigtigt at gøre dette. + +# Dømmer i stridigheder om tolkning af vedtægterne. + +# Kan uddelegere dele af eller hele sin fuldmagt til andre, eller til enhver tid trække en sådan uddelegering tilbage. + +2~7.2 §7.2. Udnævnelse + +Projektsekretæren udnævnes af projektlederen og den forrige projektsekretær. + +Hvis projektlederen og den forrige projektsekretær ikke kan blive enige om en ny udnævnelse, skal de bede SPI's bestyrelse (se §9.1) om at udnævne en ny sekretær. + +Hvis der ikke er en projektsekretær eller den forrige sekretær ikke kan træffes og ikke har uddelegeret sin fuldmagt til en sådan beslutning, kan beslutningen træffes eller uddelegeres af formanden for den tekniske komité, som fungerende sekretær. + +Projektsekretæren er valgt for et år ad gangen, hvorefter en ny (gen)udnævnelse er nødvendig. + +2~7.3 §7.3. Fremgangsmåde + +Projektsekretæren bør træffe afgørelser som er retfærdige og rimelige, og helst i overensstemmelse med konsensus blandt udviklerne. + +Når projektsekretæren og formanden for den tekniske komité i fællesskab vikarierer for en projektleder som ikke kan træffes, bør de kun træffe beslutninger som er helt nødvendige og kun når det er i overensstemmelse med konsensus blandt udviklerne. + +1~8 §8. Projektlederens delegater + +2~8.1 §8.1. Fuldmagt + +Projektlederens delegater: + +# har fået uddelegeret en fuldmagt fra projektlederen; + +# kan træffe visse afgørelser som lederen ikke kan tage på egen hånd, deriblandt optagelse eller afvisning af udviklere, eller udnævne folk der ikke håndterer pakker, som udviklere. Dette er for at undgå en magtkoncentration hos projektlederen, særligt med hensyn til udviklermedlemskab. + +2~8.2 §8.2. Udnævnelse + +Delegaterne udnævnes af projektlederen, og lederen kan udskifte dem, som han finder det passende. Projektlederen kan ikke gøre udnævnelse betinget af at delegaten træffer bestemte afgørelser, lederen kan heller ikke ophævne en beslutning truffet af en delegat. + +2~8.3 §8.3. Fremgangsmåde + +Delegater kan til enhver tid træffe afgørelser, men bør prøve at opnå gode tekniske vilkår og/eller følge konsensus. + +1~9 §9. Software in the Public Interest ("Software i offentlighedens interesse") + +SPI og Debian er adskilte organisationer, der har nogle fælles mål. Debian er taknemlig for det juridiske støtteapparat, som SPI tilbyder. Debians udviklere er pt. medlemmer af SPI i kraft af deres hverv som udviklere. + +2~9.1 §9.1. Fuldmagt + +# SPI har ingen fuldmagt hvad angår Debians tekniske eller ikke-tekniske beslutninger, bortset fra at ingen beslutninger foretaget af Debian som vedrører ejendele der administreres af SPI, kan kræve at SPI handler udenfor sin juridiske fuldmagt, og Debians vedtægter kan af og til gøre SPI til en afgørende myndighed, som en sidste udvej. + +# Debian har ingen bestemmende kontrol over SPI, bortset fra anvendelse af visse ejendele som beskrevet nedenfor, selvom Debians udviklere kan få fuldmagt indenfor SPI efter SPI's regler. + +# Debians udviklere er ikke repræsentanter for, eller ansat af, SPI, eller af personer med fuldmagt i Debian-projektet. En person der handler som udvikler, gør dette som et individ på egne vegne. + +2~9.2 §9.2. Administration af ejendele til formål som vedrører Debian + +Da Debian ikke har fuldmagt til at forvalte penge eller ejendele, skal donationer til Debian-projektet gives til SPI, som håndterer den slags. + +SPI har påtaget sig følgende: + +# SPI vil forvalte penge, varemærker, andre konkrete ejendele og forretninger til formål som vedrører Debian. + +# Sådanne ejendele vil der blive holdt særskilt regnskab for og blive indsat i en fond med det formål, udvalgt af Debian og SPI i henhold til denne paragraf. + +# SPI vil ikke afhænde eller anvende ejendele, de administrerer for Debian, uden samtykke med Debian, som kan gives af projektlederen eller via en generel resolution blandt udviklerne. + +# SPI vil overveje anvendelse og/eller afhændelse af ejendele de administrerer for Debian, når de bliver bedt om det af projektlederen. + +# SPI vil anvende eller afhænde ejendele som administreres for Debian når de bliver bedt om at gøre dette, via en generel resolution blandt udviklerne, såfremt dette er foreneligt med SPI's juridiske fuldmagt. + +# SPI vil via elektronisk post til en af Debian-projektets postlister, gør opmærksom på når ejendele, der administreres for Debian, anvendes eller afhændes. + +1~a A. Generel resolutionsprocedure + +Disse regler gælder fælles beslutninger truffet af komitéer og ved afstemninger, som beskrevet ovenfor. + +2~a1 A.1. Forslag + +Den formelle procedure begynder når et udkast til en beslutning er foreslået og støttet, som krævet. + +2~a1a A.1. Diskussion og ændring + +# Efter forslaget er fremsat, kan resolutionen diskuteres. Ændringsforslag kan gøres formelle ved at fremsætte dem og skaffe støtter jævnfør kravene for nye resolutioner, eller direkte af forslagsstilleren af det oprindelige forslag. + +# Et formelt ændringsforslag kan accepteres af resolutionens forslagsstiller, hvorved det formelle resolutionsudkast omgående ændres. + +# Hvis et formelt ændringsforslag ikke accepteres, eller en af støtterne til resolutionen ikke er enig med forslagsstillerens accept af et formelt ændringsforslag, holdes en særskilt afstemning om dette. + +# Hvis andre ikke kan lide et ændringsforslag, som er accepteret af den oprindelige forslagsstiller, kan de foreslå en anden ændring for at fjerne den tidligere ændring (igen skal de leve op til kravene om forslagsstiller og støtte(r).) + +# Forslagsstilleren af en resolution kan foreslå revideringer af formuleringen af ændringensforslaget; disse træder i kraft hvis forslagsstilleren af ændringsforslaget er enig og ingen af støtterne protesterer. I så fald stemmes der om det reviderede ændringsforslag i stedet for det oprindelige. + +# Forslagsstilleren af en resolution kan foretage ændringer for at rette mindre fejl (for eksempel stavefejl eller selvmodsigelser) eller ændringer som ikke forandrer meningen, såfremt ingen protesterer indenfor 24 timer. I disse tilfælde starter minimumsdiskussionsperioden ikke igen. + +2~a2 A.2. Afstemning + +# Forslagsstilleren eller en støtte til en resolution eller et ændringsforslag kan bede om afstemning efter at minimumstiden for diskussion (hvis en sådan findes) er gået. + +# Foreslagsstilleren eller en støtte til en resolution kan bede om en afstemning vedrørende resolutionen eller alle beslægtede ændringsforslag. + +# Personen, der beder om en afstemning, fremsætter hvad vedkommende mener resolutionens og alle relevante ændringsforslags ordlyd skal være, og dermed hvilken udformning afstemningen skal have. Dog er det projektsekretæren som træffer den endelige beslutning - se §§ 7.1(1), 7.1(3), og A.3(4). + +# Den minimale diskussionsperiode regnes fra det tidspunkt, det sidste formelle ændringsforslag blev accepteret eller fra det tidspunkt hele resolutionen blev fremsat, hvis ingen ændringer er blevet foreslået og accepteret. + +2~a3 A.3. Afstemningsprocedure + +# Der stemmes på hver resolution og dennes beslægtede ændringsforslag i en enkelt afstemning, der indeholder en valgmulighed som er den originale resolution, hvert ændringsforslag, samt et standardvalg (hvor det er muligt). + +# Standardvalget må ikke have krav om et absolut flertal. Valgmuligheder som ikke eksplicit har krav om absolut flertal, har et 1:1-krav. + +# Stemmerne tælles jf. reglerne i A.6. Standardvalget er "Yderligere diskussion" ("Further Discussion"), med mindre andet er angivet. + +# I tvivlstilfælde skal projektsekretæren afgøre procedurespørgsmål. + +2~a4 A.4. Tilbagetrukne resolutioner og ikke-accepterede ændringsforslag + +Foreslagsstilleren af en resolution eller et ændringsforslag som ikke er accepteret, kan trække disse tilbage. I så fald kan andre foreslagsstillere overtage og holde resolutionen eller ændringsforslaget i live, dermed bliver den første person der gør dette, den nye foreslagsstiller og de andre bliver støtter, hvis de ikke allerede er det. + +En støtte til en resolution eller en ændring kan trække sig tilbage (med mindre resolutionen allerede er blevet accepteret). + +Hvis foreslagsstillers og/eller støttes tilbagetrækning betyder at resolutionen ikke har en foreslagsstiller eller der ikke er støtter nok, holdes der ikke en afstemning, med mindre dette udredes før resolutionen udløber. + +2~a5 A.5. Udløb + +Hvis en foreslået resolution ikke er blevet diskuteret, ændret, stemt på eller på anden måde taget hånd om i fire uger, kan sekretæren udsende en besked om, at den betragtes som tilbagetrukket. Hvis ingen af foreslagets støtter har indvendiger, trækkes foreslaget tilbage. + +Sekretæren kan også vedlægge forslag til hvordan man fortsætter, hvis det er relevat. + +2~a6 A.6. Stemmeoptælling + +# Hver vælgers stemme prioriterer valgmulighederne. Man behøver ikke at prioritere alle valgmulighederne. Prioriterede valgmuligheder betragtes som foretrukne fremfor valgmuligheder, der ikke er prioriteret. Vælgere kan give valgmuligheder samme prioritet. Valgmuligheder, der ikke er prioriteret, betragtes som ligestillede med hinanden. Nærmere oplysninger om hvordan stemmesedlerne skal udfyldes, vil være vedlagt valgindkaldelsen. + +# Hvis det beslutningsdygtige antal er R, vil enhver valgmulighed som ikke er standardvalget og som ikke modtager mindst R stemmer, der prioriterer den mulighed højere end standardvalget, vil ikke blivetaget i betragtning. + +# Alle (ikke-standard-) valgmuligheder, der ikke overgår standardvalgmuligheden med dens krævede flertalsgrad, tages ikke i betragtning. + +_# Med de to valgmuligheder A og B, er V(A,B) antallet af vælgere der foretrækker mulighed A fremfor mulighed B. + +_# Valgmulighed A overgår standardvalgmulighed D med flertalsgraden N, hvis V(A,D) er større end N * V(D,A). + +_# Hvis et absolut flertal på S:1 er krævet af A, er dennes flertalsgrad S; ellers er flertalsgraden 1. + +# Ud fra listen over valgmuligheder der tages i betragtning, genereres en liste over parvise nederlag. + +_# Valgmulighed A overgår mulighed B, hvis V(A,B) er større end V(B,A). + +# Ud fra en liste over parvise nederlag (som tages i betragtning), genereres en liste over transitive nederlag. + +_# Valgmulighed A overgår transitivt mulighed C, hvis A overgår C eller hvis der er en en mulighed B, hvor A overgår B OG B transitivt overgår C. + +# Ud fra sættet af transitive nederlag konstruere et Schwartz-sæt. + +_# Valgmulighed A er i Schwartz-sættet hvis, for alle B-muligheders vedkommende, A transitivt overgår B, eller B ikke overgår A transitivt. + +# Hvis der er nederlag mellem valgmuligheder i Schwartz-sættet, ses der bort fra de svageste af sådanne nederlag i listen over parvise nederlag, og man springer tilbage til trin 5. + +_# Nederlaget (A,X) er svagere end nederlaget (B,Y), hvis V(A,X) er mindre end V(B,Y). Hvis (A,X) desuden er svagere end (B,Y), hvis V(A,X) er lig med V(B,Y) og V(X,A) er større end V(Y,B). + +_# Et svageste nederlag, er et nederlag hvortil der ikke er et svagere nederlag. Der kan være mere end et af sådanne nederlag. + +# Hvis der ikke nogen nederlag i Schwartz-sættet, tages vinderen fra valgmulighederne i Schwartz-sættet. Hvis der kun er en af disse valgmuligheder, er den vinderen. Hvis der er flere valgmuligheder, afgørerer vælgeren med den afgørende stemme, hvem af disse valgmuligheder, der er vinderen. + +Bemærk: Valgmuligheder, som vælgerne prioriterer over standardvalgmuligheden, er muligheder de betragter som acceptable. Valgmuligheder, der prioriteres under standardvalgmuligheder, er muligheder, der betragtes som uacceptable. + +Når den generelle resolutionsprocedure anvendes, skal teksten som henviser til denne, fastsætte hvad der er tilstrækkeligt for at få et udkast til en resolution foreslået og/eller støttet, hvad minimumstiden for diskussion er, og hvad afstemningsperioden er. Den skal også fastsætte det eventuelle kvalificerede flertal og beslutningsdygtige antal, som skal anvendes. + +1~b B. Brug af sprog og typografi + +Nutid ("er", for eksempel) betyder at udtrykket er en regel i disse vedtægter. "Kan" og "skal" indikerer at personen eller organet kan anvende skøn. "Bør" betyder at det vil anses som en god ting om hvis sætningen følges, men den er ikke bindende. Tekst markeret som et citat, som dette, er baggrundsmateriale og udgør ikke en del af vedtægterne. Den kan kun anvendes til at hjælpe med at tolke teksten i tvivlstilfælde. + +Bemærk: Dette er en oversættelse af det originale engelsksprogede dokument. Brug altid originalen i diskussioner om vedtægterne, da denne dansksprogede udgave er oversætterens fortolkning, som desuden kan indeholde fejl og misforståelser. + +%% SiSU markup sample Notes: +% SiSU http://www.jus.uio.no/sisu +% SiSU markup for 0.16 and later: +% 0.20.4 header 0~links +% 0.22 may drop image dimensions (rmagick) +% 0.23 utf-8 ß +% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title) +% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6 +% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html +% markup in this document is 0.38, (rad) experimental |