path: root/danish/devel/constitution.wml

#use wml::debian::template title="Debians vedtægter" BARETITLE="true"
#use wml::debian::translation-check translation="fc833cc9f6e2802eb17b3bcad31adb85cb69a260" mindelta="1" maxdelta="1"
#use wml::debian::toc

<h1>Debian-projektets vedtægter (v1.8)</h1>

<p>Version 1.8 godkendt den 28. janunar 2022.</p>

<p>Erstattede
<a href="constitution.1.7">version 1.7</a> godkendt den 14. august 2016, 
<a href="constitution.1.6">version 1.6</a> godkendt den 13. december 2015, 
<a href="constitution.1.5">version 1.5</a> godkendt den 9. januar 2015, 
<a href="constitution.1.4">version 1.4</a> godkendt den 7. oktober 2007, 
<a href="constitution.1.3">version 1.3</a> godkendt den 24. september 2006, 
<a href="constitution.1.2">version 1.2</a> godkendt den 29. oktober 2003, 
<a href="constitution.1.1">version 1.1</a> godkendt den 21. juni 2003 og
<a href="constitution.1.0">version 1.0</a> godkendt den 2. december 1998,
</p>

<toc-display/>

<toc-add-entry name="item-1">§ 1. Introduktion</toc-add-entry>

<p><cite>Debian-projektet er en sammenslutning af personer, som har det fælles 
mål at udvikle et frit tilgængeligt styresystem.</cite></p>

<p>
  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.
</p>


<toc-add-entry name="item-2">§ 2. Beslutningsdygtige organer og -personer</toc-add-entry>

<p>
  Enhver beslutning i projektet er omfattet af en eller flere af følgende:
</p>

<ol>
  <li>Udviklerne, via en fælles resolution eller et valg;</li>
  <li>Projektlederen;</li>
  <li>Den tekniske komité og/eller dennes forperson;</li>
  <li>Den individuelle udvikler som arbejder med en bestemt opgave;</li>
  <li>Delegater udnævnt af projektlederen til at varetage særlige opgaver;</li>
  <li>Projektsekretæren.</li>
</ol>

<p>
  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.
  <cite>
    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.
  </cite>
</p>


<h3>§ 2.1. Generelle regler</h3>

<ol>
  <li>
    <p>
      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.
    </p>
  </li>

  <li>
    <p>
      En person kan bestride flere hverv, bortset fra at projektlederen, 
      projektsekretæren og forperson for den tekniske komité skal 
      være forskellige personer, og lederen kan ikke udnæve sig selv, som sin 
      egen delegat.
    </p>
  </li>

  <li>
    <p>
      En person kan til enhver tid forlade projektet eller fratræde et særskilt 
      hverv vedkommende har, ved offentligt at erklære dette.
    </p>
  </li>
</ol>


<toc-add-entry name="item-3">§ 3. Individuelle udviklere</toc-add-entry>

<h3>§ 3.1. Fuldmagt</h3>

<p>En individuel udvikler kan</p>

<ol>
  <li>
    tage tekniske og ikke-tekniske beslutninger med hensyn til sit eget 
    arbejde;
  </li>

  <li>
    foreslå og støtte udkast til generelle resolutioner;
  </li>

  <li>
    foreslå sig selv som kandidat til projektleder i valg;
  </li>

  <li>
    stemme på generelle resolutioner og i ledervalg.
  </li>
</ol>


<h3>§ 3.2. Sammensætning og udnævnelse</h3>

<ol>
  <li>
    <p>
      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.
    </p>
  </li>

  <li>
    <p>
      Projektlederens delegater kan vælge ikke at optage nye udviklere, eller 
      at ekskludere nuværende udviklere.
      <cite>
        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.
      </cite>
    </p>
  </li>
</ol>


<h3>§ 3.3. Fremgangsmåder</h3>

<p>Udviklerne kan foretage disse beslutninger efter eget skøn.</p>


<toc-add-entry name="item-4">§ 4. Udviklerne via generel resolution eller et valg</toc-add-entry>

<h3>§ 4.1. Fuldmagt</h3>

<p>Udviklerne kan sammen:</p>

<ol>

  <li>
    <p>
      Udnævne eller afsætte projektlederen.
    </p>
  </li>

  <li>
    <p>
      Ændre disse vedtægter med et 3:1-flertal.
    </p>
  </li>

  <li>
    <p>
      Træffe eller ophæve enhver beslutning autoriseret af projektlederen eller 
      en delegat.
    </p>
  </li>

  <li>
    <p>
      Træffe eller ophæve enhver beslutning autoriseret af den tekniske komité, 
      såfremt de er enige med et 2:1-flertal.
    </p>
  </li>

  <li>
    <p>
      Udgive, erstatte og tilbagetrække ikke-tekniske retningslinier og 
      erklæringer.
    </p>

    <p>
      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.
    </p>

    <p>
      Det kan også være stillingtagen til aktuelle emner.
    </p>

    <ol style="list-style: decimal;">
      <li>
	Et grundlæggende dokument er et dokument eller en bekendtgørelse, der
        betragtes som kritisk for projekts arbejde og formål.
      </li>

      <li>
	De grundlæggende dokumenter er det arbejde som er udmundet i 
        <q>Debian sociale kontrake</q> og <q>Debians retningslinier for fri
	software</q>.
      </li>

      <li>
	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.
      </li>
    </ol>
  </li>

  <li>
    <p>
      Træffe beslutninger om forvaltede ejendele til formål med relation til
      Debian. (Se § 9.1).
    </p>
  </li>

  <li>
    <p>
      I tilfælde af uenighed mellem projektlederen og den nuværende sekretær,
      udnævne en ny sekretær.
    </p>
  </li>
</ol>


<h3>§ 4.2. Fremgangsmåde</h3>

<ol>
  <li>
    <p>
      Udviklerne følger de generelle resolutionsprocedurer beskrevet nedenfor.
      En resolution eller stemmeseddels valgmulighed 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é.
    </p>
  </li>

  <li>
    <p>
      Udsættelse af en resolution foretaget af projektlederen eller dennes
      delegater:
    </p>

    <ol>
      <li>
	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).
      </li>

      <li>
        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).
      </li>

      <li>
        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.
      </li>

      <li>
	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.
      </li>

      <li>
        Hvis projektlederen (eller dennes delegater) trækker den oprindelige
        beslutning tilbage, bliver det uaktuelt at holde afstemningen og
        den vil ikke blive afholdt.
      </li>
    </ol>
  </li>

  <li>
    <p>
      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.
    </p>
  </li>

  <li>
    <p>
      Projektlederen har den afgørende stemme.  Det beslutningsdygtige antals 
      stemmer er 3Q.  Standardvalgmuligheden er <q>Ingen af ovenstående</q>
      (<q>None of the above</q>).
    </p>
  </li>

  <li>
    <p>
      Forslag, støtte, stemmesedlers valgmuligheder, 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.
    </p>
  </li>

  <li>
    <p>
      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.
    </p>
  </li>

  <li>
    <p>
      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.
    </p>
  </li>
</ol>


<toc-add-entry name="item-5">§ 5. Projektlederen</toc-add-entry>

<h3>§ 5.1. Fuldmagt</h3>

<p><a href="leader">Projektlederen</a> kan:</p>

<ol>
  <li>
    <p>
      Udnævne delegater eller uddelegere beslutninger til den tekniske
      komité.
    </p>

    <p>
      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é.
    </p>

    <p>
      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.
    </p>
  </li>

  <li>
    <p>
      Give hjemmel til andre udviklere.
    </p>

    <p>
      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.
    </p>
  </li>

  <li>
    <p>
      Foretage beslutninger som kræver omgående handling.
    </p>

    <p>
      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.
    </p>
  </li>

  <li>
    <p>
      Foretage beslutninger som ingen andre har ansvaret for.
    </p>
  </li>

  <li>
    <p>
      Fremstille generelle resolutioner og stemmesedlers valgmuligheder til 
      generelle resolutioner.  Når foreslået af projektlederen, er sponsorer til 
      den generelle resolution eller stemmeseddels valgmulighed ikke krævet; se 
      § 4.2.1.
    </p>
  </li>

  <li>
    <p>
      Sammen med den tekniske komité udpege nye medlemmer til komitéen. (Se 
      § 6.2.)
    </p>
  </li>

  <li>
    <p>
      Afgive en afgørende stemme i udviklernes afstemninger.
    </p>

    <p>
      Projektlederen har også almindelig stemmeret i sådanne
      afstemninger.
    </p>
  </li>

  <li>
    <p>
      Ændre diskussionsperioden for udviklernes afstemninger (som beskrevet 
      ovenfor).
    </p>
  </li>

  <li>
    <p>
      Lede diskussioner blandt udviklerne.
    </p>

    <p>
      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.
    </p>
  </li>

  <li>
    <p>
      I konsultation med udviklerne, træffe beslutninger der vedrører 
      forvaltede ejendele i forbindelse med Debian. (Se § 9.).  Sådanne
      beslutninger kommunikeres til medlemmerne af projektlederen eller dennes
      delegat(er).  Større udgifter skal foreslås og diskuteres på postlisten før
      beløbet erlægges.
    </p>
  </li>

  <li>
    <p>
      Tilføje eller fjerne organisationer fra listen over betroede 
      organisationer (se § 9.3) som er autoriserede til at modtage og være i
      besiddelse af ejendele for Debian.  Evaluering og diskussion førende til
      sådanne beslutninger finder sted på en elektronisk postliste udpeget af
      projektlederen eller denne delgat(er), på hvilken alle udviklere må skrive.
      Der er en minimal diskussionstid på to uger før en organisation må blive
      føjet til listen over betroede organisationer.
    </p>
  </li>
</ol>


<h3>§ 5.2. Udnævnelse</h3>

<ol>
  <li>
    Projektlederen vælges af udviklerne.
  </li>

  <li>
    Valget begynder seks uger før lederpositionen bliver ledig eller (hvis det 
    ikke allerede er for sent) omgående.
  </li>

  <li>
    I den første uge kan enhver udvikler nominere sig selv som 
    projektlederkandidat og opsummere deres planer for valgperioden.
  </li>

  <li>
    I de følgende tre uger kan der ikke nomineres flere kandidater;
    kandiaterne bør anvende dette tidsrum til deres valgkamp.  Hvis der ikke er nogen 
    kandidater efter nomineringsperioden er slut, bliver perioden udvidet med 
    yderligere en uge, om nødvendigt gentagne gange.
  </li>

  <li>
    De næste to uger er valgperioden, hvori udviklerene kan stemme.  
    Afstemningen i ledervalg er hemmelig, selv efter afstemningen er 
    afsluttet.
  </li>

  <li>
    Valget vil være mellem de kandidater, der har nomineret sig selv og som ikke 
    har trukket sig tilbage, samt <q>Ingen af ovenstående</q> (<q>None of the 
    Above</q>). Hvis <q>Ingen af ovenstående</q> vinder valget, bliver denne 
    procedure gentaget, om nødvendigt mange gange.
  </li>

  <li>
    Beslutningen træffes ved hjælp af den metode, som er beskrevet i § A.5 i de 
    generelle resolutionsprocedurer.  Det beslutningsdygtige antal er det samme, 
    som ved en generel resolution (§ 4.2), og standardvalget er <q>Ingen af 
    ovenstående</q> (<q>None Of The Above</q>).
  </li>

  <li>
    Projektlederen vælges for et år ad gangen.
  </li>
</ol>


<h3>§ 5.3. Fremgangsmåde</h3>

<p>
  Projektlederen bør prøve at træffe beslutninger som er i tråd med konsensus 
  blandt udviklerne.
</p>

<p>
  Hvor det er praktisk bør projektlederen på en uformel måde bede om udviklernes 
  synspunkter.
</p>

<p>
  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.
</p>


<toc-add-entry name="item-6">§ 6. Teknisk komité</toc-add-entry>

<h3>§ 6.1. Fuldmagt</h3>

<p>
  Den <a href="tech-ctte">tekniske komité</a> kan:
</p>

<ol>
  <li>
    <p>
      Træffe beslutninger om tekniske retningslinier.
    </p>

    <p>
      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).)
    </p>
  </li>

  <li>
    <p>
      Afgøre tekniske spørgsmål hvor udviklernes ansvarsområder overlapper.
    </p>

    <p>
      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.
    </p>
  </li>

  <li>
    <p>
      Træffe en beslutning når den bliver bedt om at gøre dette.
    </p>

    <p>
      Enhver person og ethvert organ kan uddelegere en af sine egne beslutninger 
      til den tekniske komité eller bede om råd fra den.
    </p>
  </li>

  <li>
    <p>
      Tilsidesætte en udviklers beslutning (kræver et 3:1-flertal).
    </p>

    <p>
      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.
    </p>
  </li>

  <li>
    <p>
      Give råd.
    </p>

    <p>
      Den tekniske komité kan give formelle erklæringer om sit syn på enhvert 
      emne.
      <cite>
        Individuelle medlemmer kan selvfølgelig give uformelle erklæringer
        om deres synspunkter og om komitéens sandsynlige 
        synspunkter.
      </cite>
    </p>
  </li>

  <li>
    <p>
      Sammen med projektlederen udnævne nye medlemmer til sig selv eller fjerne 
      nuværende medlemmer.  (Se § 6.2.)
    </p>
  </li>

  <li>
    <p>
      Udnævne forperson for den tekniske komité.
    </p>

    <p>
      Komitéen vælger forperson 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.5 i de generelle resolutionsprocedurer.  Der er ingen afgørende 
      stemme.  Hvis der er flere valgmuligheder som ikke er overgået i 
      Schwartz-sættet i slutningen af § A.5.8, vil vinderen blive udtrukket 
      tilfældigt fra disse valgmuligheder, ved hjælp af en mekanisme som vælges 
      af projektsekretæren.
    </p>
  </li>

  <li>
    <p>
      Forpersonen kan vikariere for lederen, sammen med sekretæren.
    </p>

    <p>
      Som beskrevet i § 7.1(2), kan forpersonen for den tekniske komité 
      og projektsekretæren i fællesskab vikariere for lederen, hvis der ikke er 
      en leder.
    </p>
  </li>
</ol>


<h3>§ 6.2. Sammensætning</h3>

<ol>
  <li>
    <p>
      Den tekniske komité består af op til otte udviklere og bør normalt have 
      mindst fire medlemmer.
    </p>
  </li>

  <li>
    <p>
      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.
    </p>
  </li>

  <li>
    <p>
      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.
    </p>
  </li>

  <li>
    <p>
      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.
    </p>
  </li>

  <li>
    <p>
      En udvikler kan ikke blive (gen)udnævnt til den tekniske komite, hvis 
      vedkommende har været medlem inden for de seneste tolv måneder.
    </p>
  </li>

  <li>
    <p>
      Hvis den tekniske komité og projektlederen er enige kan de fjerne eller 
      erstatte et nuværende medlem af den tekniske komité.
    </p>
  </li>

  <li>
    <p>
      Begrænset valgperiode:
    </p>

    <ol>
      <li>
	<p>Årligt den 1. januar, opsættes valgperioden til at udløbe den 31. 
	december samme år for alle komitemedlemmer, der har siddet i mere end 
	42 måneder (3,5 år) og som er en af de to længst siddende medlemmer.</p>
      </li>

      <li>
	<p>Et medlem af den tekniske komite defineres som at have siddet 
	længere end et andet, hvis den pågældende blev udnævnt tidligere eller 
	blev udnævnt på samme tid, samt har været medlem af Debian-projektet 
	i længere tid.  Hvis et medlem har været udnævnt flere gange, er kun den 
	seneste udnævnelse relevant.</p>
      </li>
    </ol>
  </li>
</ol>


<h3>§ 6.3. Fremgangsmåde</h3>

<ol>
  <li>
    <p>
      Den tekniske komité anvender den generelle resolutionsprocedure.
    </p>

    <p>
      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.
    </p>
  </li>

  <li>
    <p>
      Detaljerede afstemningoplysninger
    </p>

    <p>
      Forpersonen 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 forpersonen, som i dette tilfælde kun kan 
      benytte sin afgørende stemmeret).
    </p>
  </li>

  <li>
    <p>
      Offentlig diskussion og afgørelser
    </p>

    <p>
      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.
    </p>
  </li>

  <li>
    <p>
      Fortrolighed ved udnævnelser
    </p>

    <p>
      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.
    </p>
  </li>

  <li>
    <p>
      Ikke et detaljeret udviklingsarbejde
    </p>

    <p>
      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.
    </p>

    <p>
      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.
    </p>

    <p>
      <cite>
        Medlemmer af den tekniske komité kan selvfølgelig deltage på egne vegne 
	i alle aspekter af udviklings- og retningsliniearbejde.
      </cite>
    </p>
  </li>

  <li>
    <p>
      Den teknisk komité træffer kun afgørelser som en sidste udvej
    </p>

    <p>
      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.
    </p>
  </li>
</ol>


<toc-add-entry name="item-7">§ 7. Projektsekretæren</toc-add-entry>

<h3>§ 7.1. Fuldmagt</h3>

<p><a href="secretary">Sekretæren</a>:</p>

<ol>
  <li>
    <p>
      Indsamler stemmer fra udviklerne, finder ud af hvor mange udviklere der er 
      og hvem de er, når dette kræves af vedtægterne.
    </p>
  </li>

  <li>
    <p>
      Kan vikariere for lederen, i fællesskab med forpersonen for den 
      tekniske komité.
    </p>

    <p>
      Hvis der ikke er en projektleder, kan forpersonen for den 
      tekniske komité og projektsekretæren træffe afgørelser ved enighed, hvis 
      de mener at det er vigtigt at gøre dette.
    </p>
  </li>

  <li>
    <p>
      Dømmer i stridigheder om tolkning af vedtægterne.
    </p>
  </li>

  <li>
    <p>
      Kan uddelegere dele af eller hele sin fuldmagt til andre, eller til enhver 
      tid trække en sådan uddelegering tilbage.
    </p>
  </li>
</ol>


<h3>§ 7.2. Udnævnelse</h3>

<p>
  Projektsekretæren udnævnes af projektlederen og den forrige 
  projektsekretær.
</p>

<p>
  Hvis projektlederen og den forrige projektsekretær ikke kan blive enige om en 
  ny udnævnelse, skal de bede udviklerne om at udnævne en ny sekretær gennem en
  generel beslutning.
</p>

<p>
  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 forpersonen for den 
  tekniske komité, som fungerende sekretær.
</p>

<p>
  Projektsekretæren er valgt for et år ad gangen, hvorefter en ny 
  (gen)udnævnelse er nødvendig.
</p>


<h3>§ 7.3. Fremgangsmåde</h3>

<p>
  Projektsekretæren bør træffe afgørelser som er retfærdige og rimelige, og 
  helst i overensstemmelse med konsensus blandt udviklerne.</p>

<p>
  Når projektsekretæren og forpersonen 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.</p>


<toc-add-entry name="item-8">§ 8. Projektlederens delegater</toc-add-entry>

<h3>§ 8.1. Fuldmagt</h3>

<p>
  Projektlederens delegater:
</p>

<ol>
  <li>
    har fået uddelegeret en fuldmagt fra projektlederen;
  </li>

  <li>
    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.
    <cite>
      Dette er for at undgå en magtkoncentration hos projektlederen, særligt med 
      hensyn til udviklermedlemskab.
    </cite>
  </li>
</ol>


<h3>§ 8.2. Udnævnelse</h3>

<p>
  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.
</p>


<h3>§ 8.3. Fremgangsmåde</h3>

<p>
  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.
</p>


<toc-add-entry name="item-9">§ 9. Ejendele der forvaltes på vegne af Debian</toc-add-entry>

<p>
  I de fleste af verdens jurisdiktioner er Debian-projektet ikke i en 
  situation hvor det direkte må være i besiddelse af midler eller andre 
  ejendele.  Derfor er det nødvendigt at ejendele ejes af enhver af en række 
  organisationer, som beskrevet i § 9.2.
</p>

<p>
  Traditionelt var SPI den eneste organisation, der var autoriseret til at 
  forvalte ejendele og beløb for Debian-projektet.  SPI blev etableret i USA, 
  for der at forvalte beløb.
</p>

<p>
  <a href="https://www.spi-inc.org/">SPI</a> og Debian er adskilte 
  organisationer, der har nogle fælles mål.  Debian er taknemlig for det 
  juridiske støtteapparat, som SPI tilbyder.
</p>


<h3>§ 9.1. Relationer til tilknyttede organisationer</h3>

<ol>
  <li>
    <p>
      Debian-udviklere bliver ikke agenter for eller ansatte af organisationer
      der forvalter ejendele for Debian, eller af hinanden, eller af persioner 
      med myndighed i Debian-projektet, blot ved at være Debian-udviklere.
      En person der fungerer som udvikler gør dette som en individuel person, 
      på egne vegne.  Sådanne organisationer kan, af egen kraft, etablere 
      relationer mellem individer der også er Debian-udviklere.
    </p>
  </li>
</ol>


<h3>§ 9.2. Autoritet</h3>

<ol>
  <li>
    <p>
      En organisation der forvalter ejendele for Debian har ingen autoritet
      over Debians tekniske eller ikke-tekniske beslutninger, bortset fra at 
      ingen beslutninger taget af Debian hvad angår ejendele der forvaltes af
      organisationen må kræve at denne handler uden for sin juridiske 
      autoritet.
    </p>
  </li>

  <li>
    <p>
      Debian har ingen autoritet over en organisation der forvalter ejendele
      for Debian, bortset fra over de ejendele der forvaltes for Debian.
    </p>
  </li>
</ol>


<h3>9.3. Betroede organisationer</h3>

<p>
  Alle donationer til Debian-projektet skal ske til en af de organisationer,
  som projektlederen (eller en delegat) har autoriseret til at forvalte ejendele
  til anvendelse af Debian-projektet.
</p>

<p>
  Organisationer der forvalter ejendele for Debian bør påtage sig passende
  forpligtelser ved forvaltning af sådanne ejendele.
</p>

<p>
  Debian vedligeholder en offentlig liste over betroede organisationer, der
  accepterer donationer og forvalter ejendele for Debian (deriblandt 
  håndgribelige og intellektuelle ejendele), indeholdende disse organisationers
  tilsagn til hvordan disse ejendele vil blive forvaltet.
</p>


<toc-add-entry name="item-A">A. Generel resolutionsprocedure</toc-add-entry>

<p>
  Disse regler gælder fælles beslutninger truffet af komitéer og ved 
  afstemninger, som beskrevet ovenfor.
</p>



<h3>A.0. Forslag</h3>

<ol>
    <li>
	Den formelle procedure begynder når et udkast til en resolution er 
	foreslået og støttet, som angivet i § 4.2.1.
    </li>

    <li>
	Dette forslag til et resolutionsudkast bliver en valgmulighed på den 
	indledende stemmeseddel med to valgmuligheder, den anden valgmulighed er 
	standardmuligheden, og foreslagsstilleren af resolutionsudkastet bliver 
	foreslagstiller af den valgmulighed på stemmesedlen.
    </li>
</ol>


<h3>A.1. Diskussion og ændringsforslag</h3>

<ol>
    <li>
	Diskusionsperioden begynder når et forslag er fremsat og har fået 
	støtte.  Den minimale diskusionsperiode er to uger.  Den maksimale 
	diskusionsperiode er tre uger.
    </li>

    <li>
	En ny valgmulighed til stemmesedlen kan foreslås og støttes jævnfør 
	kravene til en ny resolution.
    </li>

    <li>
	Foreslagsstilleren af valgmuligheden til stemmesedlen kan komme med 
	ændringsforslag til denne valgmulighed, forudsat at ingen af støtterne 
	af den valgmulighed til stemmesedlen, på det tidspunkt hvor 
	ændringsforeslaget foreslås, indenfor 24 timer udtrykker uenighed om 
	ændringen.  Hvis nogen af dem er uenige, ændres valgmuligheden til 
	stemmesedlen ikke.
    </li>

    <li>
	Tilføjelsen af en valgmulighed til stemmesedlen eller en ændring gennem 
	et ændringsforslag af en valgmulighed til stemmesedlen, ændrer ophøret 
	af diskusionsperioden til at være en uge fra den handling blev udført, 
	med mindre det medfører at den totale diskusionsperiode bliver kortere 
	end den minimale diskusionsperiode eller længere end den maksimale 
	diskusionsperiode.  I sidstnævnte tilfælde, sættes længden af 
	diskusionsperioden i stedet til den maksimale diskuionsperiode.
    </li>

    <li>
	Foreslagsstilleren af en valgmulighed til stemmesedlen kan foretage 
	mindre ændringer til den valgmulighed (eksempelvis rettelser af slåfejl, 
	rettelser uoverensstemmelser eller andre ændringer, som ikke ændrer 
	meningen), forudsat at ingen udvikler protesterer indenfor 24 timer.  I 
	denne situation ændres diskusionsperioden ikke.  Hvis en udvikler 
	protesterer, skal ændringen i stedet foretages gennem et ændringsforslag 
	jævnfør § A.1.3.
    </li>

    <li>
	Projektlederen kan til enhver tid i processen, forøge eller formindske 
	den minimale eller maksimale diskusionsperiode med til en uge fra deres 
	oprindelige værdier i § A.1.1, bortset fra at det ikke må gøres på en 
	sådan måde, at diskusionsperioden opfører i løbet af 48 timer efter 
	denne ændring blev foreslået.  Længden af diskusionsperiode genberegnes 
	da som havde de nye minimale og maksimale længder været til stende under 
	alle tidligere ændringer til stemmesedlen under § A.1.1 og § A.1.4.
    </li>

    <li>
	Standardvalgmuligheden har ingen foreslagsstiller eller støtter, og kan 
	ikke blive tilføjet ændringsforslag eller blive trukket tilbage.
    </li>
</ol>


<h3>A.2. Tilbagetrækning af valgmuligheder på stemmesedlen</h3>

<ol>
    <li>
	Foreslagsstilleren af en valgmulighed på stemmesedlen, kan trække sig 
	tilbage.  Hvis det sker, kan nye foreslagsstillere melde sig, for at 
	bevare valgmuligheden på stemmesedlen, hvorved den første person som 
	gør dette, bliver den nye foreslagsstiller og eventuelle andre bliver 
	støtter, hvis de ikke allerede er det.  Enhver ny foreslagsstiller 
	eller nye støtter, skal leve op til kravene for foreslag eller støtter 
	af nye resolutioner.
    </li>

    <li>
	En støtte til en valgmulighed på stemmesedlen kan trække sig tilbage.
    </li>

    <li>
	Hvis en foreslagsstillers og/eller støtters tilbagetrækning betyder at 
	valgmuligheden ikke har nogen foreslagsstiller eller ikke nok støtter 
	til at leve op til kravene for en ny resolution, og der går 24 timer 
	uden det afhjælpes af en anden foreslagsstiller og/eller støtter dukker 
	op, fjernes den fra udkastet til stemmesedlen.  Det ændrer ikke på 
	længden af diskusionsperioden.
    </li>

    <li>
	Hvis alle valgmuligheder til stemmesedelen, bortset fra 
	standardvalgmuligheden, trækkes tilbage, annulleres resolutionen og der 
	stemmes ikke om den.
    </li>
</ol>


<h3>A.3. Opfordring til at stemme</h3>

<ol>
    <li>
	Efter en diskusionsperiode er ophørt, vil projektsekretæren 
	offentliggøre stemmesedlen og opfordre til at stemme.  Dette kan 
	projektsekretræren umiddelbart efter ophøret af diskusionsperioden, og 
	det skal ske indenfor syv dage efter ophøret af diskusionsperioden.
    </li>

    <li>
	Projektsekretæren bestemme rækkefølgen af valgmuligheder på stemmesedlen 
	og de opsummeringer, der benyttes til afstemningen.  Projektsekretæren 
	kan bede foreslagsstillerne til valgmulighederne om at komme med udkast 
	til disse opsummeringer, og kan efter egen vurdering tilpasse dem for at 
	de bliver mere tydelige.
    </li>

    <li>
	Mindre ændringer at valgmuligheder til stemmesedlen under § A.1.5, må 
	kun ske hvis der er mindst 24 timer tilbage af diskusionsperioden, eller 
	hvis projektsekretæren er enig i at det ikke ændrer betydningen af 
	valgmuligheden samt (hvis det er tilfældet) kræver at afstemningen 
	udskydes.  Projektsekretæren afsætter 24 timer til indsigelser efter 
	enhver sådan ændring, før der opfordres til at stemme.
    </li>

    <li>
	Ingen nye valgmuligheder til stemmesedlen må foreslås, der kan ikke 
	komme ændringsforslag til valgmuligheder og ingen foreslagsstillere 
	eller støtter må trække sig tilbage, hvis der er mindre end 24 timer 
	tilbage i diskusionsperioden, med mindre handlingen medfører en 
	udvidelse af diskusionsperiode jævnfør § A.1.4, med minimum yderligere 
	24 timer.
    </li>

    <li>
	Handlinger der bevarer den eksisterende stemmeseddel, kan tage indenfor 
	de sidste 24 timer af en diskusionsperiode, nemlig en støtte som har 
	indsigelser til et ændringsforslag under § A.1.3, en udvikler som har 
	indsigelser under § A.1.5, overgang til at være foreslagsstiller for en 
	eksisterende valgmulighed på stemmesedlen hvor den oprindelige 
	foreslagsstiller har trukket sig tilbage under § A.2.1, eller støtte til 
	en eksisterende valgmulighed på stemmesedlen har færre end det krævede 
	antal støtter, på grund af at en støtte har trukket sig tilbage under § 
	A.2.2.
    </li>

    <li>
	Projektsekretæren kan gøre en undtagelse til § A.3.4 og acceptere 
	ændringer til stemmesedlen efter det ikke længere er tilladt, forudsat 
	at det sker mindst 24 timer før der opfordres til at stemme.  Alle andre 
	krav til at foretage en ændring af stemmesedlen, skal stadig opfyldes. 
	Det forventes at ske sjældent, og bør kan ske hvis projektsekretæren 
	mener at det ville være skadeligt for projektets bedste interesser ikke 
	at foretage ændringen.
    </li>
</ol>


<h3>A.4. Afstemningsprocedure</h3>

<ol>
    <li>
	Valgmuligheder, der ikke har et eksplicit absolut flertal, har et 
	flertalskrav på 1:1.  Standardvalgmuligheden har ikke nogen krav om 
	absolut flertal.
    </li>

    <li>
	Stemmer optælles jævnfør reglerne i § A.5.
    </li>

    <li>
	I tvivlstilfælde træffer projektsekretæren beslutning om proceduren.
    </li>
</ol>


<h3>A.5. Stemmeoptælling</h3>

<ol>
   <li>
	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.
   </li>

   <li>
	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.
   </li>

   <li>
	Alle (ikke-standard-) valgmuligheder, der ikke overgår
	standardvalgmuligheden med dens krævede flertalsgrad, tages ikke i
	betragtning.
        <ol>
             <li> 
                  Med de to valgmuligheder A og B, er V(A,B) antallet af 
		  vælgere der foretrækker mulighed A fremfor mulighed B.
             </li> 
             <li> 
                  Valgmulighed A overgår standardvalgmulighed D med 
		  flertalsgraden N, hvis V(A,D) er større end eller lig med 
		  N * V(D,A) og V(A,D) er større end V(D,A).
             </li> 
             <li> 
                  Hvis et absolut flertal på S:1 er krævet af A, er dennes
		  flertalsgrad S; ellers er flertalsgraden 1.
             </li> 
        </ol>
   </li>

   <li>
	Ud fra listen over valgmuligheder der tages i betragtning, genereres 
	en liste over parvise nederlag.
        <ol>
             <li>
                  Valgmulighed A overgår mulighed B, hvis V(A,B) er større
		  end V(B,A).
             </li>
        </ol>
   </li>

   <li>
	Ud fra en liste over parvise nederlag (som tages i betragtning), 
	genereres en liste over transitive nederlag.
        <ol>
             <li>
                  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.
             </li>
        </ol>
   </li>

   <li>
	Ud fra sættet af transitive nederlag konstruere et Schwartz-sæt.
        <ol>
             <li>
                  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.
             </li>
        </ol>
   </li>

   <li>
	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.
        <ol>
             <li>
                  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).
             </li>
             <li>
                  Et svageste nederlag, er et nederlag hvortil der ikke er et
		  svagere nederlag.  Der kan være mere end et af sådanne
		  nederlag.
             </li>
        </ol>
   </li>

   <li>
	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.
   </li>
</ol>

<p><strong>Bemærk</strong>: Valgmuligheder, som vælgerne prioriterer over 
standardvalgmuligheden, er muligheder de betragter som acceptable.  
Valgmuligheder, der prioriteres under standardvalgmuligheder, er  muligheder, 
der betragtes som uacceptable.</p>

<p><cite>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.</cite></p>


<toc-add-entry name="item-B">B. Brug af sprog og typografi</toc-add-entry>

<p>
  Nutid (<q>er</q>, for eksempel) betyder at udtrykket er en regel i disse 
  vedtægter.  <q>Kan</q> og <q>skal</q> indikerer at personen eller organet kan 
  anvende skøn.  <q>Bør</q> betyder at det vil anses som en god ting om hvis 
  sætningen følges, men den er ikke bindende.
  <cite>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.
  </cite>
</p>

<p>
  <strong>Bemærk</strong>: Dette er en oversættelse af det 
  <a href="constitution.en.html">originale</a> 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.
</p>