path: root/polish/devel/constitution.1.3.wml

#use wml::debian::template title="Historyczny Statut Debiana v 1.3" BARETITLE="true"
#use wml::debian::toc
#use wml::debian::translation-check translation="1.5"

<h1>Historyczna wersja Statutu Projektu Debian (v1.3)</h1>

<p>Wersja 1.3 zatwierdzona 24. września 2006r. Zastąpiła
<a href="constitution.1.2">wersję 1.2</a> zatwierdzoną 29. października
2003r., która zastąpiła
<a href="constitution.1.1">wersję 1.1</a> zatwierdzoną 21. sierpnia
2003r., która z kolei zastąpiła <a href="constitution.1.0">wersję 1.0</a>
zatwierdzoną 2. grudnia 1998r.
Wersja 1.3 została natomiast zastąpiona przez 
<a href="constitution">wersję 1.4</a>
zatwierdzoną 7. października 2007 roku.
Ta natomiast została zastąpiona przez <a href="constitution">obecną wersję 1.5</a> 
zatwierdzoną 9 stycznia 2015 roku.
</p>

<toc-display/>

<toc-add-entry name="item-1">1. Wstęp</toc-add-entry>

<p><cite>Projekt Debian jest stowarzyszeniem osób, które podjęły wspólny
wysiłek w celu stworzenia wolnego systemu operacyjnego.</cite></p>

<p>Ten dokument opisuje strukturę organizacyjną formalnego podejmowania
decyzji w ramach Projektu. Nie opisuje on natomiast celów 
Projektu, sposobów ich osiągania, ani nie zawiera żadnych przepisów
oprócz tych, które bezpośrednio odnoszą się do procesu podejmowania
decyzji.</p>

<toc-add-entry name="item-2">2. Organa i osoby podejmujące decyzje</toc-add-entry>

<p>Każda decyzja dotycząca Projektu jest podejmowana poprzez
jeden lub więcej z następujących podmiotów:</p>

<ol>
  <li>Deweloperzy, w drodze Ogólnej Uchwały bądź wyborów;</li>

  <li>Lider Projektu;</li>

  <li>Komitet Techniczny i/lub jego Przewodniczący;</li>

  <li>Każdy z Deweloperów pracujący nad konkretnym zadaniem;</li>

  <li>Delegaci mianowani przez Lidera Projektu do określonego
  zadania;</li>

  <li>Sekretarz projektu.</li>
</ol>

<p>Znaczna część tego dokumentu przedstawia w sposób ogólny
uprawnienia tych organów, ich skład i mianowanie oraz procedury 
podejmowania decyzji. Uprawnienia osoby lub organu mogą 
podlegać ocenie i/lub ograniczeniu przez inne organy lub osoby; w takim
przypadku zostanie to oznajmione przez organ oceniający lub poprzez
notatkę osoby oceniającej. <cite>Na powyższej liście osoba lub organ jest
umieszczona przed osobami lub organami, których decyzje mogą uchylić, albo
których mogą (pomóc) mianować - ale nie zawsze wymienieni wyżej mogą uchylać decyzje
znajdujących się niżej na liście.</cite></p>

<h3>2.1. Zasady ogólne</h3>

<ol>
  <li>
    <p>Żaden przepis w tym statucie  nie nakłada na kogokolwiek 
    obowiązku pracy dla Projektu. Osoba która nie chce wykonać zadania 
    jej powierzonego lub przydzielonego, nie musi tego robić. Jednakże
    nie wolno jej aktywnie działać przeciwko przepisom i decyzjom,
    którym podlega.</p>
  </li>

  <li>
    <p>Jedna osoba może obejmować kilka stanowisk, z tym wyjątkiem,
    że funkcje Lidera Projektu, Sekretarza projektu i Prezesa Komitetu 
    Technicznego muszą pełnić różne osoby oraz, że Lider nie może mianować 
    siebie samego jako własnego Delegata.</p>
  </li>

  <li>
    <p>Osoba może opuścić Projekt, albo zrezygnować z obejmowanego
    stanowiska w dowolnym czasie, oznajmiając to publicznie.</p>
  </li>
</ol>

<toc-add-entry name="item-3">3. Indywidualni Deweloperzy</toc-add-entry>

<h3>3.1. Uprawnienia</h3>

<p>Indywidualny Deweloper może</p>

<ol>
  <li>podejmować jakiekolwiek techniczne bądź nietechniczne decyzje
  dotyczące ich własnej pracy;</li>

  <li>przedkładać lub popierać projekt Ogólnych Uchwał;</li>

  <li>przedkładać swoją kandydaturę na Lidera Projektu w 
  wyborach;</li>

  <li>głosować nad Ogólnymi Uchwałami i w wyborach Kierownictwa.</li>
</ol>

<h3>3.2. Skład i mianowanie</h3>

<ol>
  <li>
    <p>Deweloperzy są wolontariuszami, którzy zgadzają się, co do dalszych
    celów Projektu tak długo, jak w nim uczestniczą i którzy utrzymują
    pakiet(y) dla Projektu lub wykonują inną pracę uznaną przez Delegata(ów)
    Lidera Projektu za wartą zachodu.</p>
  </li>

  <li>
    <p>Delegaci Lidera Projektu mogą zdecydować nie przyjąć nowych
    Deweloperów lub wydalić już istniejących. <cite>Jeśli Deweloperzy
    uważają, że Delegaci nadużywają swojej władzy, mogą uchylić
    ich decyzję poprzez Ogólną Uchwałę - zobacz &sect;4.1(3), &sect;4.2.</cite></p>
  </li>
</ol>

<h3>3.3. Procedura</h3>

<p>Deweloperzy mogą podejmować decyzje, które uważają za stosowne.</p>

<toc-add-entry name="item-4">4. Deweloperzy na drodze Uchwały Ogólnej lub wyborów</toc-add-entry>

<h3>4.1. Uprawnienia</h3>

<p>Wspólnie Deweloperzy mogą:</p>

<ol>
  <li>
    <p>Mianować bądź odwoływać Lidera Projektu.</p>
  </li>

  <li>
    <p>Wnosić poprawki do tego statutu pod warunkiem, że
    zgadzają się z większością 3/4 głosów.</p>
  </li>

  <li>
    <p>Podejmować lub uchylać każdą decyzję będącą w mocy Lidera
	Projektu bądź Delegata.</p>
  </li>

  <li>
    <p>Podejmować lub uchylać każdą decyzję będącą w mocy Komitetu
	Technicznego większością głosów w stosunku co najmniej 2:1.</p>
  </li>

  <li>
    <p>Wydawać, zastępować i wycofywać nietechniczne dokumenty dotyczące 
    polityki oraz oświadczenia.</p>

    <p>Włącza się w to dokumenty opisujące cele projektu, jego
    stosunki z innymi jednostkami wolnego oprogramowania i 
    nietechniczną politykę taką, jak warunki licencji 
    wolnego oprogramowania, które musi spełniać oprogramowanie Debiana.</p>

    <p>Można także w nie włączyć oświadczenia dotyczące bieżących spraw.</p>
    
    <ol style="list-style: decimal;">
      <li>Dokument Fundacji to dokument lub oświadczenie postrzegane jako
       krytyczne dla misji lub celu Projektu.</li>
      <li>Dokumenty Fundacji to prace tytułowane <q>Umową Społeczną
       Debiana</q> i <q>Wytycznymi Debiana dotyczącymi Wolnego
       Oprogramowania</q>.</li>
      <li>Dokumenty Fundacji wymagają większości 3:1 do ich wyparcia. Nowe
       Dokumenty Fundacji są wydawane, a istniejące wycofywane poprzez 
       głosowanie listy Dokumentów Fundacji w tym statucie.</li>
    </ol>
  </li>

  <li>
    <p>Podejmować decyzje o własności będącej pod ich zarządem w celach
	związanych z Debianem (Zobacz &sect;9.).</p>
  </li>
  
  <li>
    <p>W przypadku braku porozumienia pomiędzy liderem projektu i
	urzędującym sekretarzem, powołać nowego sekretarza.</p>
  </li>
  
</ol>

<h3>4.2. Procedura</h3>

<ol>
  <li>
    <p>Deweloperzy stosują się do Standardowej Procedury Podejmowania Uchwał 
    (patrz poniżej). Uchwała lub poprawka jest wprowadzana, jeśli została
    przedłożona przez Dewelopera i poparta przez co najmniej K innych 
    Deweloperów lub jeśli została przedłożona przez Lidera Projektu lub 
    Komitet Techniczny.</p>
  </li>

  <li>
    <p>Opóźnianie decyzji Lidera Projektu lub jego Delegatów:</p>

    <ol>
      <li>Jeśli Lider Projektu, jego Delegat lub Komitet Techniczny
      podjął decyzję, wówczas Deweloperzy mogą ją uchylić poprzez wydanie
      uchwały tak postanawiającej; zobacz &sect;4.1(3).</li>

      <li>Jeśli uchwała jest poparta przez co najmniej 2K Deweloperów 
      lub jeśli jest przedłożona przez Komitet Techniczny, decyzja jest 
      niezwłocznie zatrzymywana (pod warunkiem, że w uchwale zostało to 
      zapisane).</li>

      <li>Jeśli oryginalna decyzja miała zmienić okres dyskusji lub głosowania,
      lub uchwała ma uchylić decyzję Komitetu Technicznego, wówczas
      tylko K Deweloperów musi poprzeć tą uchwałę, aby decyzja została
      niezwłocznie zatrzymana.</li>

      <li>Jeśli decyzja jest zatrzymana, niezwłocznie zostaje 
      przeprowadzone głosowanie, aby ustalić czy decyzja pozostanie 
      ważna, dopóki nie zostanie przeprowadzone pełne głosowanie nad 
      decyzją lub czy uprawomocnienie oryginalnej decyzji zostanie 
      opóźnione aż do tego czasu. Nie ma kworum dla tego niezwłocznego 
      głosowania proceduralnego.</li>

      <li>Jeśli Lider Projektu (lub Delegat) wycofuje oryginalną
      decyzję, głosowanie nie jest przeprowadzane.</li>
    </ol>
  </li>

  <li>
    <p>Głosy są zbierane przez Sekretarza Projektu. Głosy, rejestry 
       i wyniki nie są ujawniane podczas okresu głosowania; po głosowaniu
       Sekretarz Projektu wymienia wszystkie oddane głosy. Okres głosowania
       wynosi 2 tygodnie, lecz może być zmieniony o nie więcej niż 
       1 tydzień przez Lidera Projektu.
    </p>
  </li>

  <li>
    <p>Minimalny okres dyskusji wynosi 2 tygodnie, lecz może być zmieniony
    o nie więcej niż 1 tydzień przez Lidera Projektu. Lider Projektu ma głos
    decydujący. Kworum wynosi 3Q.</p>
  </li>

  <li>
    <p>Propozycje, poparcia, poprawki, wezwania do głosowania i 
    inne formalne działania są dokonywane poprzez ogłoszenia na
    elektronicznej liście pocztowej możliwej do odczytania przez
    dowolną osobę i wyznaczonej przez Delegata Lidera Projektu; 
    każdy Deweloper może umieścić na niej swój list.</p>
  </li>

  <li>
    <p>Głosy są oddawane poprzez pocztę elektroniczną w sposób odpowiedni
    dla Sekretarza. Sekretarz określa dla każdego głosowania, czy
    głosujący mogą zmieniać swoje, oddane już głosy.</p>
  </li>

  <li>
    <p>Q jest połową pierwiastka kwadratowego z bieżącej liczby
    Deweloperów. K jest równe mniejszej z liczb Q lub 5. Q i K
    nie muszą być liczbami całkowitymi i nie są zaokrąglane.</p>
  </li>
</ol>

<toc-add-entry name="item-5">5. Lider Projektu</toc-add-entry>

<h3>5.1. Uprawnienia</h3>

<p><a href="leader">Lider Projektu</a> może:</p>

<ol>
  <li>
    <p>Mianować delegatów lub udzielać Komitetowi Technicznemu
    pełnomocnictwa w sprawie decyzji.</p>

    <p>Lider może zdefiniować zakres  
    odpowiedzialności lub określonej decyzji i przekazać go innemu 
    Deweloperowi lub Komitetowi Technicznemu.</p>

    <p>Gdy określona decyzja została przekazana i podjęta, Lider
    Projektu nie może wycofać tego pełnomocnictwa; jednakże może
    wycofać trwające pełnomocnictwo z określonego obszaru 
    odpowiedzialności.</p>
  </li>

  <li>
    <p>Udzielać władzy innym Deweloperom.</p>

    <p>Lider Projektu może wydawać oświadczenia o poparciu dla
    punktów widzenia lub innych członków projektu, jeśli został 
    o to poproszony; te oświadczenia mają moc wtedy i tylko 
    wtedy, gdy Lider byłby uprawniony do podejmowania spornej 
    decyzji.</p>
  </li>

  <li>
    <p>Podejmować wszelkie decyzje, które wymagają pilnego
    działania.</p>

    <p>Nie dotyczy to decyzji, które stały się stopniowo pilne 
    poprzez brak podjęcia stosowanych działań, chyba że został wyznaczony
    nieprzekraczalny termin oddania.</p>
  </li>

  <li>
    <p>Podejmować decyzje, za które nikt inny nie jest odpowiedzialny.</p>
  </li>

  <li>
    <p>Przedkładać projekty Ogólnych Uchwał i poprawek.</p>
  </li>

  <li>
    <p>Wspólnie z Komitetem Technicznym mianować nowych członków
    do Komitetu.  (Zobacz §6.2.)</p>
  </li>

  <li>
    <p>Korzystać z głosu decydującego, gdy głosują
    Deweloperzy.</p>

    <p>Lider Projektu ma również zwykły głos w takich głosowaniach.</p>
  </li>

  <li>
    <p>Zmieniać okres dyskusji dla głosów Deweloperów (patrz wyżej).</p>
  </li>

  <li>
    <p>Prowadzić dyskusje wśród Deweloperów.</p>

    <p>Lider Projektu powinien próbować w pomocny sposób uczestniczyć 
    w dyskusjach wśród Deweloperów tak, aby szybko sprowadzić dyskusję 
    na sprawy kluczowe. Lider Projektu nie powinien wykorzystywać 
    kierowniczej pozycji, aby promować swoje własne poglądy.</p>
  </li>

  <li>
    <p>Po konsultacji z deweloperami pojedmować decyzje związane
	z majątkiem użytkowanym w związku z pracami na rzecz Debiana (patrz
	&sect;9.). Decyzje te są przedstawiane członkom poprzez
	Lidera Projektu lub jego Delegata(ów). Większe wydatki
	powinny być proponowane i dyskutowane na listach dyskusyjnych przed
	wydatkowaniem środków.</p>
  </li>
  <li>
    <p>Dodawać i usuwać organizacje z listy zaufanych
	organizacji (patrz &sect;9.3), które są uprawnione do przyjmowania
	i przechowywania środków dla Debiana. Ocena i dyskusja prowadząca
	do podjęcia takich decyzji odbywa się na liście dyskusyjnej
	wskazanej przez Lidera Projektu lub jego Delegata(ów), gdzie
	może zabierać głos każdy deweloper. Wymagany jest co najmniej
	dwutygodniowy okres dyskusji, zanim organizacja zostanie dodana
	do listy zaufanych organizacji.</p>
  </li>	

</ol>

<h3>5.2. Mianowanie</h3>

<ol>
  <li>Lider Projektu jest wybierany przez Deweloperów.</li>

  <li>Wybory zaczynają się na dziewięć tygodni przed zwolnieniem
  stanowiska kierowniczego lub (jeśli już jest za późno)
  niezwłocznie.</li>

  <li>Przez następne trzy tygodnie każdy Deweloper może nominować
  siebie jako kandydata na Lidera Projektu.</li>

  <li>Przez następne trzy tygodnie nie można nominować więcej 
  kandydatów; kandydaci powinni wykorzystać ten czas na kampanię 
  (aby zapoznać innych ze swoją tożsamością i pozycją). Jeśli
  pod koniec okresu nominacji nie ma żadnych kandydatów, wówczas
  jest on rozszerzany o dalsze trzy tygodnie (wielokrotnie
  jeśli jest to konieczne).</li>

  <li>Trzy następne tygodnie są okresem wyborów, podczas którego
  Deweloperzy mogą oddawać swoje głosy. Głosy w wyborach kierownictwa
  są utrzymywane w tajemnicy, nawet po zakończeniu wyborów.</li>

  <li>Opcje na kartach do głosowania będą obejmować tych kandydatów,
  którzy się nominowali i jeszcze się nie wycofali oraz dodatkowo
  pozycję Żaden z Powyższych. Jeśli Żaden z Powyższych wygra wybory,
  cała procedura musi być powtórzona (wielokrotnie jeśli jest
  to konieczne).</li>

  <li>
       Decyzja będzie podjęta wykorzystując metodę opisaną w sekcji
       §A.6 Standardowej Procedury Podejmowania Uchwał. Kworum jest takie
       samo jak dla Ogólnej Uchwały (§4.2), a domyślną opcją jest
       <q>Żaden z Powyższych</q>.
  </li>

  <li>Lider Projektu pełni swoją funkcję przez jeden rok od wyborów.</li>
</ol>

<h3>5.3. Procedura</h3>

<p>Lider Projektu powinien starać się podejmować decyzje, które są
zgodne ze stanowiskiem Deweloperów.</p>

<p>Gdy jest to możliwe, Lider Projektu powinien nieformalnie zabiegać
o poglądy Deweloperów.</p>

<p>Lider Projektu powinien unikać zbytniego podkreślania swojego
własnego punktu widzenia, gdy podejmuje decyzje, w sprawie których
jest kompetentny jako Lider.</p>

<toc-add-entry name="item-6">6. Komitet Techniczny</toc-add-entry>

<h3>6.1. Uprawnienia</h3>

<p><a href="tech-ctte">Komitet Techniczny</a> może:</p>

<ol>
  <li>
    <p>Decydować w każdej sprawie dotyczącej 
    polityki technicznej.</p>

    <p>Włącza się w to zawartość podręczników polityki technicznej,
    materiały podręczne dla Deweloperów, przykładowe
    pakiety i sposób zachowania nieeksperymentalnych narzędzi do budowania 
    pakietów. (Jednakże w każdej sytuacji opiekun odpowiedniego oprogramowania
    lub dokumentacji początkowo podejmuje decyzje samodzielnie; 
    zobacz 6.3(5).)</p>
  </li>

  <li>
    <p>Decydować w sprawach technicznych, gdzie jurysdykcje Deweloperów
    się nakładają.</p>

    <p>W sytuacjach w których Deweloperzy muszą wprowadzić zgodne 
    polityki technicze lub stanowiska (na przykład, gdy nie zgdzają się
    w sprawie priorytetów pakietów będących w konflikcie, lub 
    nazwy polecenia, lub tego, który pakiet jest odpowiedzialny
    za występujący błąd, lub kto powinien być opiekunem pakietu) 
    komitet techniczny może podjąć decyzję.</p>
  </li>

  <li>
    <p>Podejmować decyzję, gdy jest o to proszony.</p>

    <p>Każda osoba lub organ może przekazać pełnomocnictwo do podjęcia
    swojej decyzji Komitetowi Technicznemu lub zasięgnąć u niego rady.</p>
  </li>

  <li>
    <p>Unieważnić decyzje Dewelopera (wymaga większości 3:1).</p>

    <p>Komitet Techniczny może nakazać Deweloperowi podjęcie konkretnego
    technicznego kierunku działania nawet, gdy Deweloper tego nie chce; 
    wymaga to większości 3:1. Na przykład Komitet może postanowić, że 
    skarga wysłana przez autora informacji o błędzie jest usprawiedliwiona
    i zaproponowane przez niego rozwiązanie należy wprowadzić.</p>
  </li>

  <li>
    <p>Oferować radę.</p>

    <p>Komitet Techniczny może ogłaszać formalne komunikaty na temat
    swoich poglądów na dowolną sprawę. <cite>Indywidualni członkowie mogą
    oczywiście składać nieformalne stwierdzenia na temat swoich poglądów
    i prawdopodobnych poglądów komitetu. </cite></p>
  </li>

  <li>
    <p>Wspólnie z Liderem Projektu mianować nowych członków do komitetu
    lub usuwać już istniejących. (Zobacz §6.2.)</p>
  </li>

  <li>
    <p>Mianować Prezesa Komitetu Technicznego.</p>

    <p>
       Prezes jest wybierany przez członków Komitetu. Wszyscy członkowie
       komitetu są automatycznie nominowani; głosowanie do komitetu
       zaczyna się jeden tydzień przed zwolnieniem stanowiska (lub 
       niezwłocznie, jeśli jest już za późno). Członkowie mogą głosować
       przez aklamację na każdego członka rzeczywistego komitetu, włączając
       w to siebie samego; nie ma opcji domyślnej. Głosowanie kończy
       się, gdy wszyscy członkowie zagłosowali lub gdy okres głosowania
       skończył się. Wyniki są ustalane wykorzystując metodę opisaną w
       sekcji A.6 Standardowej Procedury Podejmowania Uchwał.
   </p>
  </li>

  <li>
    <p>Prezes może zastępować Lidera wspólnie z Sekretarzem.</p>

    <p>Jak wyszczególniono w §7.1(2) Prezes Komitetu Technicznego i 
    Sekretarz Projektu mogą wspólnie zastępować Lidera, jeśli jest
    on nieobecny.</p>
  </li>
</ol>

<h3>6.2. Skład</h3>

<ol>
  <li>
    <p>Komitet Techniczny składa się z co najwyżej 8 Deweloperów i
    powinien zwykle mieć nie mniej niż 4 członków.</p>
  </li>

  <li>
    <p>Gdy w Komitecie jest mniej niż 8 członków, może on wskazać nowego
    członka(ów) Liderowi Projektu, który decyduje o ich mianowaniu.</p>
  </li>

  <li>
    <p>Gdy w Komitecie Technicznym jest 5 lub mniej członków, może
    on mianować nowego członka(ów), dopóki ich liczba nie osiągnie
    6.</p>
  </li>

  <li>
    <p>Gdy w Komitecie Technicznym jest 5 lub mniej członków co najmniej
    przez jeden tydzień, Lider Projektu może mianować nowego członka(ów),
    dopóki ich liczba nie osiągnie 6, w odstępach co najmniej
    jeden tydzień na mianowanie.</p>
  </li>

  <li>
    <p>Jeśli Komitet Techniczny i Lider Projektu zgdzają się, mogą oni
    usunąć lub zamienić istniejącego członka Komitetu Technicznego.</p>
  </li>
</ol>

<h3>6.3. Procedura</h3>

<ol>
  <li>
    <p>Komitet Techniczny korzysta z Standardowej Procedury Podejmowania Uchwał.</p>

    <p>Projekt uchwały lub poprawki może zostać przedłożony przez 
    członka Komitetu Technicznego. Nie ma minimalnego czasu dyskusji, okres
    głosowania trwa nie dłużej niż jeden tydzień lub do czasu, gdy wynik nie 
    będzie podlegał już wątpliwości. Członkowie mogą zmieniać swoje głosy.
    Kworum wynosi dwa.</p>
  </li>

  <li>
    <p>Szczegóły dotyczące głosowania</p>

    <p>Prezes ma głos decydujący. Kiedy Komitet Techniczny głosuje, czy
    uchylić decyzję Dewelopera, który także jest członkiem Komitetu, ten
    członek nie może głosować (chyba że jest Prezesem, w tym przypadku
    może użyć tylko swojego głosu decydującego).</p>
  </li>

  <li>
    <p>Dyskusja publiczna i podejmowanie decyzji.</p>

    <p>Dyskusja, projekt uchwał i poprawek oraz głosy członków 
    komitetu są ujawnione na publicznej liście dyskusyjnej Komitetu
    Technicznego. Nie ma osobnego sekretarza Komitetu.</p>
  </li>

  <li>
    <p>Poufność mianowania.</p>

    <p>Komitet Techniczny może utrzymywać poufne dyskusje poprzez
    prywatną pocztę elektroniczną, prywatną listę dyskusyjną lub
    inne środki, aby przedyskutować mianowania do Komitetu. Jednakże głosy
    na mianowania muszą być publiczne.</p>
  </li>

  <li>
    <p>Brak szczegółowej pracy projektowej.</p>

    <p>Komitet Techniczny nie angażuje się w opracowywanie nowych
    propozycji i polityk. Taka praca projektowa powinna być przeprowadzana
    indywidualnie lub wspólnie i dyskutowana według zwykłych
    procedur technicznych i na forach projektowych.</p>

    <p>Komitet Techniczny ogranicza się do wyboru z rozwiązań 
    i decyzji, które zostały zaproponowane i dość gruntownie przedyskutowane 
    gdzie indziej, lub przyjmuje kompromisy pomiędzy tymi rozwiązaniami.</p>

    <p><cite>Indywidualni członkowie komitetu technicznego mogą 
    oczywiście uczestniczyć na własną ręke w każdym aspekcie projektowania
    i pracy dotyczącej polityki.</cite></p>
  </li>

  <li>
    <p>Komitet Techniczny podejmuje decyzje tylko w ostateczności.</p>

    <p>Komitet Techniczny nie podejmuje żadnych decyzji technicznych,
    dopóki wszystkie próby ich rozwiązania poprzez porozumienie nie 
    zostały podjęte i zawiodły, chyba że został o to poproszony przez osobę, 
    która normalnie byłaby za daną decyzję odpowiedzialna.</p>
  </li>
</ol>

<toc-add-entry name="item-7">7. Sekretarz projektu</toc-add-entry>

<h3>7.1. Uprawnienia</h3>

<p><a href="secretary">Sekretarz</a>:</p>

<ol>
  <li>
    <p>Zbiera głosy wśród Deweloperów i ustala liczbę i tożsamość
    Deweloperów, kiedykolwiek wymaga tego statut.</p>
  </li>

  <li>
    <p>Może zastępować Lidera wspólnie z Prezesem Komitetu 
    Technicznego.</p>

    <p>Jeśli nie ma Lidera Projektu, wówczas Prezes Komitetu
    Technicznego i Sekretarz Projektu mogą za wspólną
    zgodą podejmować decyzję, jeśli uważają to za konieczne.</p>
  </li>

  <li>
    <p>Rozstrzyga wszelkie spory na temat interpretacji
    statutu.</p>
  </li>

  <li>
    <p>Może przekazywać część swojej władzy komuś innemu lub wycofywać
    takie pełnomocnictwo w dowolnym czasie.</p>
  </li>
</ol>

<h3>7.2. Mianowanie</h3>

<p>Sekretarz Projektu jest mianowany przez Lidera Projektu oraz
aktualnego Sekretarza Projektu.</p>

<p>Jeśli Lider Projektu i aktualny Sekretarz Projektu nie mogą uzgodnić
nowego mianowania, muszą poprosić Deweloperów, aby w drodze  
Uchwały Ogólnej mianowali Sekretarza.</p>

<p>Jeśli nie ma Sekretarza Projektu lub aktualny Sekretarz jest
niedostępny i nie udzielił pełnomocnictwa do podjęcia decyzji, wówczas
decyzja może zostać podjęta lub przekazana przez Prezesa Komitetu 
Technicznego jako tymczasowo pełniącego obowiązki Sekretarza.</p>

<p>Czas urzędowania Sekretarza wynosi jeden rok, po czym musi on być
ponownie mianowany lub musi zostać mianowany inny Sekretarz.</p>

<h3>7.3. Procedura</h3>

<p>Sekretarz Projektu powinien podejmować decyzje, które są uczciwe
i rozsądne, a także najlepiej zgodne z porozumieniem Deweloperów.</p>

<p>Gdy występują wspólnie zastępując nieobecnego Lidera Projektu,
Prezes Komitetu Technicznego oraz Sekretarz Projektu powinni podejmować
decyzje tylko, gdy są całkowicie konieczne i zgodne z porozumieniem
Deweloperów.</p>

<toc-add-entry name="item-8">8. Delegaci Lidera Projektu</toc-add-entry>

<h3>8.1. Uprawnienia</h3>

<p>Delegaci Lidera Projektu:</p>

<ol>
  <li>mają uprawnienia przekazane im przez Lidera Projektu;</li>

  <li>mogą podejmować określone decyzje, których Lider nie może podjąć
  bezpośrednio, włączając w to zatwierdzanie lub wydalanie Deweloperów 
  lub wyznaczanie osób jako Deweloperów, którzy nie zajmują się opieką
  nad pakietami.
  <cite>Ma to na celu uniknięcie koncentracji uprawnień, w szczególności
  nad decyzjami o członkostwie w projekcie jako Deweloper, w rękach Lidera
  Projektu.</cite></li>
</ol>

<h3>8.2. Mianowanie</h3>

<p>Delegaci są mianowani przez Lidera Projektu i mogą być przez niego
zastąpieni według jego uznania. Lider Projektu nie może tworzyć
stanowiska Delegata uzależniając je od określonych decyzji Delegata,
ani nie może uchylić decyzji przez niego już podjętych.</p>

<h3>8.3. Procedura</h3>

<p>Delegaci mogą podejmować decyzje, które wydają się im odpowiednie,
lecz powinni próbować podejmować właściwe decyzje techniczne
i/lub kierować się wspólnie ustalonym stanowiskiem.</p>

<toc-add-entry name="item-9">9. Aktywa użytkowane dla Debiana</toc-add-entry>

<p>W większości państw na świecie, Debian nie jest osobą prawną
uprawnioną do posiadania funduszów lub innych aktywów. Z tego względu
właścicielami środków musi być któraś z organizacji
wyszczególnionych w &sect;9.2.</p>

<p>Dotychczas Software in the Public Interest, Inc. (SPI) była jedyną
organizacją upoważnioną do posiadania
wyposażenia i środków finasowych dla projektu Debiana. SPI została
założona w USA do posiadania środków na tym terenie.</p>

<p><a href="http://www.spi-inc.org/">SPI</a> 
i Debian są oddzielnymi organizacjami, które mają kilka
wspólnych celów. Debian jest wdzięczny za wsparcie prawne oferowane
przez SPI.</p>

<h3>9.1. Relacje z Powiązanymi Organizacjami</h3>

<ol>
  <li>  
    <p>Deweloperzy Debiana nie są agentami ani pracownikami
    Organizacji posiadających aktywa Debiana, ani swoimi nawzajem,
    ani władz Projektu Debian, występują samodzielnie jako Deweloperzy
    Debiana. Osoba występująca jako Deweloper robi to indywidualnie i na
    własną ręke. Organizacje Powiązane mogą oddzielnie nawiązywać relacje
    z osobami, które są również	Deweloperami Debiana.</p>
  </li>
</ol>

<h3>9.2. Uprawnienia</h3>

<ol>
  <li>
    <p>Organizacja posiadająca aktywa dla Debiana nie ma uprawnień dotyczących
    technicznych bądź nietechnicznych decyzji dotyczących Debiana, za wyjątkiem
    przypadków, w których decyzje podejmowane przez Debiana powodują naruszenie
    obowiązującego prawa.</p>
  </li>
  <li>
    <p>Debian nie domaga się żadnych uprawnień wobec Organizacji posiadającej
    aktywa dla Debiana, oprócz tych, które są związane z zarządzaniem tymi aktywami.</p>
  </li>
</ol>

<h3>9.3. Zaufane organizacje</h3>

<p>Wszelkie dary dla Projektu Debian muszą być przekazywane
do jednej z organizacji wskazanych przez Lidera Projektu (albo
Delegata), która jest uprawniona do zarządzania aktywami używanymi
przez Projekt Debian.</p>

<p>Organizacje posiadające aktywa dla Debiana biorą na siebie
odpowiedzialność za zgodne z prawem zarządzanie tymi aktywami.</p>

<p>Debian utrzymuje publiczną Listę Zaufanych Organizacji,
które przyjmują dary i posiadają aktywa w imieniu Debiana
(włączając w to środki trwałe i wartości niematerialne i prawne),
która zawiera zobowiązanie Organizacji do wydania oświadczenia
dotyczącego sposobu zarządzania aktywami.</p>


<toc-add-entry name="item-A">A. Standardowa Procedura Podejmowania Uchwał</toc-add-entry>

<p>Te zasady dotyczą wspólnego podejmowania decyzji i plebiscytów tam,
gdzie powyżej podano.</p>

<h3>A.1. Wniosek</h3>

<p>Formalna procedura zaczyna się, kiedy projekt uchwały jest przedkładany
i popierany tak, jak jest to wymagane.</p>

<h3>A.1. Dyskusja i poprawki</h3> 

<ol>
  <li>Po zgłoszeniu wniosku uchwała może być dyskutowana. Poprawki 
  mogą być wnoszone formalnie, poprzez ich przedłożenie i poparcie zgodnie z 
  wymaganiami dla nowej ustawy, lub bezpośrednio, przez wnioskodawcę 
  oryginalnej uchwały.</li>

  <li>Poprawka formalna może być zaakceptowana przez wnioskodawcę
  danej uchwały, w tej sytuacji formalny projekt uchwały jest niezwłocznie
  zmieniany tak, aby jej odpowiadał.</li>

  <li>Jeśli formalna poprawka nie jest zaakceptowana lub jeden z popierających
  nie zgadza się na jej przyjęcie, pozostaje ona poprawką i będzie
  przegłosowywana.</li>

  <li>Jeśli poprawka zaakceptowana przez wnioskodawcę nie odpowiada
  pozostałym, mogą oni wnieść kolejną poprawkę odwracającą wcześniejszą
  zmianę (znów musi ona spełniać wymagania co do wnioskodawcy 
  i popierającego(cych).)</li>

  <li>Wnioskodawca uchwały może zasugerować zmiany w sposobie 
  sformułowania poprawek; wchodzą one w życie, jeśli wnioskodawca
  poprawki i żaden z popierających nie wniesie sprzeciwu.
  W tej sytuacji zmienione poprawki będą przegłosowywane zamiast 
  oryginalnych.</li>

  <li>Wnioskodawca uchwały może wprowadzać zmiany korygujące
  pomniejsze błędy (na przykład, typograficzne lub niezgodności) lub
  zmiany, które nie wpływają na znaczenie treści uchwały, pod warunkiem, 
  że nikt nie sprzeciwi się w ciągu 24 godzin. W tej sytuacji minimalny 
  okres dyskusji nie jest odliczany od nowa.</li>
</ol>

<h3>A.2. Wezwanie do głosowania</h3>

<ol>
  <li>Wnioskodawca lub popierający wniosek lub poprawkę może wzywać
  do głosowania, pod warunkiem, że minimalny czas dyskusji minął (jeśli
  taki był wyznaczony).</li>

  <li>Wnioskodawca lub każdy z popierających uchwałę może wzywać do głosowania
  nad tą uchwałą i wszystkimi związanymi z nią poprawkami.</li>

  <li>Osoba która wzywa do głosowania oświadcza, jakie według niej
  jest sformułowanie uchwały i wszystkich istotnych poprawek, a w
  konsekwencji jaką formę powinna mieć karta do głosowania. Jednakże
  ostateczna decyzja o formie kart(y) do głosowania należy do Sekretarza -
  zobacz 7.1(1), 7.1(3) i A.3(4).</li>

  <li>Minimalny okres dyskusji jest liczony od momentu, gdy ostatnia 
  formalna poprawka została zaakceptowana lub, jeśli żadne poprawki nie 
  zostały zaproponowane lub zaakceptowane, od momentu, gdy cała uchwała
  została przedłożona.</li>
</ol>

<h3>A.3. Procedura głosowania</h3>

<ol>
  <li>Każda uchwała i związane z nią poprawki są przegłosowywane 
  na pojedynczej karcie do głosowania, która obejmuje możliwość wyboru
  uchwały w jej oryginalnej postaci, każdej poprawki i opcję domyślną 
  (w stosownych przypadkach).</li>

  <li>Opcja domyślna nie może mieć wymagania ponadwiększości. Opcje, które 
  nie mają wyraźnie określonego wymagania ponadwiększości, mają wymaganie
  większości 1:1.</li>

  <li>Głosy są liczone zgodnie z zasadami określonymi w A.6. Opcją
  domyślną jest <q>Dalsza Dyskusja</q>, chyba że określono inaczej.</li>

  <li>W przypadkach wątpliwości Sekretarz Projektu powinien zadecydować
  w  sprawach procedury.</LI>
</ol>

<h3>A.4. Wycofywanie uchwał lub nieprzyjętych poprawek</h3>

<p>Wnioskodawca uchwały lub nieprzyjętej poprawki może ją wycofać.
W takim przypadku nowi wnioskodawcy mogą zgłosić się, aby ją podtrzymać.
Pierwsza osoba, która to zrobi staje się nowym wnioskodawcą, a
wszyscy pozostali zostają popierającymi, jeśli jeszcze nimi nie są.</p>

<p>Popierający uchwałę lub poprawkę (chyba że została ona zaakceptowana)
może się wycofać.</p>

<p>Jeśli wycofanie się wnioskodawcy i/lub popierających oznacza, że
uchwała nie ma więcej wnioskodawców lub niewystarczającą liczbę
popierających, nie będzie przegłosowywana, chyba że się to zmieni, 
zanim uchwała wygaśnie.</p>

<h3>A.5. Wygaśnięcie</h3>

<p>
   Jeśli przedłożona uchwała nie była dyskutowana, poprawiana, 
   przegłosowywana lub w inny sposób traktowana przez 4 tygodnie, 
   sekretarz może wydać oświadczenie, że jest ona
   wycofywana. Jeśli żaden z popierających propozycji nie sprzeciwi
   się w ciągu tygodnia, sprawa zostaje wycofana.
</p>

<p>
   Sekretarz może także włączyć sugestie, jak należy dalej 
   postępować, jeśli jest to stosowne.
</p>

<h3>A.6. Liczenie głosów</h3>

<ol>
   <li> Karta do głosowania każdego z głosujących ocenia przegłosowywane
	opcje. Nie wszystkie opcje muszą być ocenione. Wszystkie ocenione
	opcje są uważane za preferowane w stosunku do nieocenionych. 
	Głosujący mogą ocenić opcje po równo. Nieocenione opcje są uważane
	za ocenione równo z innymi nieocenionymi. Szczegóły o tym, jak
	należy wypełniać karty zostaną włączone do Wezwania do Głosowania.
   </li>
   <li> Jeśli głosowanie ma wymaganie kworum R, każda opcja inna
        niż domyślna, która nie otrzyma co najmniej R głosów 
	oceniających ją wyżej, niż opcję domyślną, nie jest brana pod uwagę.
   </li>
   <li> Każda (niedomyślna) opcja, która nie pokona domyślnej opcji o
   	jej wymagany stosunek większości nie jest brana pod uwagę.
        <ol>
             <li> 
                  Biorąc pod uwagę dwie opcje A i B, V(A,B) jest liczbą
		  głosujących, którzy bardziej preferują opcję A niż opcję B
             </li> 
             <li> 
                  Opcja A pokonuje domyślną opcję D o stosunek większości
		  N, jeśli V(A,D) jest ściśle większe niż N * V(D,A).
             </li> 
             <li> 
                  Jeśli ponadwiększość S:1 jest wymagana dla A, jej stosunek
		  większości wynosi S; w przeciwnym razie jej stosunek
		  większości wynosi 1
             </li> 
        </ol>
   </li>
   <li> Z listy nieopuszczonych opcji generowana jest lista par pokonań.
        <ol>
             <li>
                  Opcja A pokonuje opcję B, jeśli V(A,B) jest ściśle większe
		  niż V(B,A)
             </li> 
        </ol>
   </li>
   <li> Z listy [nieopuszczonych] par pokonań, generowany jest zbiór przechodnich
   	pokonań.
        <ol>
             <li> 
                  Opcja A pokonuje opcję C w sposób przechodni, jeśli A pokonuje
		  C lub jeśli istnieje inna opcja B, gdzie A pokonuje B i
		  B pokonuje C w sposób przechodni.
             </li> 
        </ol>
   </li>
   <li> Konstruowany jest zbiór Schwartza ze zbioru przechodnich pokonań.
        <ol>
             <li> 
                  Opcja A jest w zbiorze Schwartza jeśli dla wszystkich
		  opcji B, albo A pokonuje B w sposób przechodni, albo B
		  nie pokonuje A w sposób przechodni.
             </li> 
        </ol>
   </li>
   <li> Jeśli są pokonania pomiędzy opcjami w zbiorze Schwartza,
   	opuszczane są najsłabsze z listy par pokonań i powraca się do
	kroku 5.	
        <ol>
             <li> 
                  Pokonanie (A,X) jest słabsze niż pokonanie (B,Y), jeśli
		  V(A,X) jest mniejsze niż V(B,Y). Ponadto, (A,X) jest 
		  słabsze niż (B,Y) jeśli V(A,X) jest równe V(B,Y) i V(X,A)
		  jest większe niż V(Y,B).
             </li> 
             <li> 
                  Najsłabsze pokonanie jest pokonaniem, od którego żadne 
		  pokonanie nie jest słabsze. Takich pokonań może być więcej
		  niż jedno.
             </li> 
        </ol>
   </li>
   <li> Jeśli nie ma pokonań w zbiorze Schwartza, wówczas zwycięzca jest 
   	wybierany z pozostałych opcji w zbiorze Schwartza. Jeśli jest tylko
	jedna taka opcja, jest ona zwycięzcą. Jeśli jest kilka opcji, wyborca z 
	głosem decydującym orzeka, która z tych opcji wygrywa.
   </li>
</ol>

<p>
 <strong>Uwaga:</strong> Opcje które głosujący oceniają wyżej niż
 domyślną opcję, są opcjami, które uważają z akceptowalne. Opcje
 oceniane poniżej domyślnej opcji są opcjami, które uważają za 
 nieakceptowalne.
</p>

<P><cite>Gdy Standardowa Procedura Podejmowania Uchwał ma być użyta, tekst,
który się do niej odnosi, musi określić, co jest wystarczające, aby
projekt uchwały był przedłożony i/lub poparty, ile wynosi minimalny
okres dyskusji oraz ile wynosi okres głosowania. Musi także określać
każdą ponadwiększość i/lub kworum (oraz domyślną opcję), które mają
być użyte.</cite></p>

<toc-add-entry name="item-B">B. Język i typografia</toc-add-entry>

<p>Tryb oznajmujący czasu teraźniejszego (na przykład <q>jest</q>) 
oznacza, że stwierdzenie jest zasadą statutu. <q>Może</q> wskazuje,
że osoba lub organ ma dowolność. <q>Powinien</q> oznacza, że dobrze 
byłoby to widziane, gdy zdanie byłoby przestrzegane, ale
nie jest ono wiążące. <cite>Tekst oznaczony jako cytat, taki jak ten,
jest racjonalnym uzasadnieniem i nie jest częścią statutu. Może
zostać użyty tylko jako pomoc w interpretacji w przypadku 
wątpliwości.</cite></p>