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

#use wml::debian::template title="Historyczny Statut Debiana v 1.0" BARETITLE="true"
#use wml::debian::translation-check translation="1374b16f63a09f02275d87bf6aa6fa8ee4c84833"

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

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

<h2>1. Wstęp</h2>

<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, 
jak te cele osiąga, ani nie zawiera żadnych przepisów oprócz tych, które 
bezpośrednio odnoszą się do procesu podejmowania decyzji.</p>

<h2>2. Organa i osoby podejmujące decyzje</h2>

<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>Komisja techniczna i/lub jej Przewodniczący;</li>

  <li>Indywidualny Deweloper 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 przedstawi w zarysie uprawnienia 
tych organów, ich skład i mianowanie oraz procedury podejmowania przez 
nie decyzji. Uprawnienia osoby lub organu mogą podlegać ocenie i/lub 
ograniczeniu przez innych; w takim przypadku zostanie to oznajmione 
przez organ oceniający lub poprzez notatkę. <cite>Na powyższej liście 
osoba lub organ jest zwykle umieszczana przed jakimikolwiek 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>

<h2>3. Indywidualni Deweloperzy</h2>

<h3>3.1. Uprawnienia</h3>

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

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

  <li>przedkładać lub popierać projekty 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) 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 
    czują, że Delegaci nadużywają swojej władzy, oczywiście 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>

<h2>4. Deweloperzy drogą Ogólnej Uchwały lub wyboru</h2>

<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>Uchylić każdą decyzję Lidera Projektu bądź Delegata.</p>
  </li>

  <li>
    <p>Uchylić każdą decyzję Komitetu Technicznego pod warunkiem, że 
    zgadzają się z większością 2/3 głosów.</p>
  </li>

  <li>
    <p>Wydawać 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łączać oświadczenia dotyczące bieżących spraw.</p>
  </li>

  <li>
    <p>Wspólnie z Liderem Projektu i OIP podejmować decyzje o własności będącej 
    pod jej zarządzem w celach związanych z Debianem. (Zobacz &sect;9.1.)</p>
  </li>
</ol>

<h3>4.2. Procedura</h3>

<ol>
  <li>
    <p>Deweloperzy stosują się do Podstawowej Procedury Uchwałodawczej 
    (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óźnienie 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 
      napisane).</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łe, 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, i może być skrócony przez Sekretarza Projektu, kiedy 
    nie ma wątpliwości co do wyników głosowania.</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 dyskusyjnej 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ą 
    zmienić 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>

<h2>5. Lider Projektu</h2>

<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 określonych
    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 stosownych 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 &sect;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łosowań 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>Wspólnie z OIP podejmować decyzje dotyczące własności będącej pod 
    jej zarządem w celach związanych z Debianem (Zobacz &sect;9.1.)</p>
  </li>
</ol>

<h3>5.2. Mianowanie</h3>

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

  <li>Wybory zaczynają się na dziewięc 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ą osobą 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ę Condorcet Vote Counting. 
  Kworum jest takie samo jak dla Ogólnej Uchwały (&sect;4.2), a 
  domyślną opcją jest Żaden z Powyższych.</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>

<h2>6. Komitet Techniczny</h2>

<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 techniczne lub stanowiska (na przykład, gdy nie 
    zgadzają 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ę w tej sprawie.</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ć decyzję Dewelopera (wymagana większość 3/4).</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/4. 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 
    sowich 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 &sect;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 komitetu, włączając w to siebie 
    samych; nie ma opcji Żaden z powyższych. Głosowanie kończy się, 
    gdy wszyscy członkowie zagłosowali lub gdy wynik nie pozostawia 
    wątpliwości. Wynik jest ustalany przy wykorzystaniu metody 
    Condorcet Vote Counting.</p>
  </li>

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

    <p>Jak wyszczególniono w &sect;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 
    manowaniu.</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 zgadzają 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 Podstawowej Procedury 
    Uchwałodawczej.</p>

    <p>Projekt uchwały lub poprawki może zostać przedłożony przez 
    każdego 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ą zmienić 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, projekty 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>Żadnej szczegółowej pracy projektowej.</p>

    <p>Komitet Techniczny nie angażuje się w opracowywanie nowych 
    propozycji i polityk. Taka praca projektowa powinna być 
    przeprowadzana przez osoby prywatne 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ękę 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>

<h2>7. Sekretarz Projektu</h2>

<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 status.</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ć decyzje, 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łnomocnictwa 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ą 
zdecydować o nowym mianowaniu, muszą poprosić zarząd OIP 
(zobacz &sect;9.1.) o mianowanie 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>

<h2>8. Delegaci Lidera Projektu</h2>

<h3>8.1. Uprawnienia</h3>

<p>Delegaci Lidera Projektu:</p>

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

  <li>mogą podejmować pewne 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 nieutrzymujących pakietów. 
  <cite>Ma to na celu uniknięcie koncentracji uprawnień, w szczególności 
  nad członkostwem 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ć wprowadzać dobre technicznie decyzje i/lub 
postępować zgodnie z ustalonym wspólnie stanowiskiem.</p>

<h2>9. Oprogramowanie w Interesie Publicznych</h2>

<p><a href="https://www.spi-inc.org/">OPI</a> i Debian są oddzielnymi 
organizacjami, które mają kilka wspólnych celów. Debian jest wdzięczny 
za wsparcie prawne oferowane przez OIP. <cite>Deweloperzy Debiana są 
aktualnie członkami OIP z racji ich statusu jako Deweloperów.</cite></p>

<h3>9.1. Władza</h3>

<ol>
  <li>OIP nie ma żadnej władzy odnośnie technicznych i nietechnicznych 
  decyzji Debiana, oprócz tego, że żadna decyzja Debiana, w związku z 
  jakąkolwiek własnością posiadaną przez OIP nie powinna wymagać, aby 
  OIP występowało poza jej władzę prawną oraz oprócz tego, że statut 
  Debiana może czasami używać OIP jako ostateczny organ decyzyjny.</li>

  <li>Debian nie rości sobie żadnej władzy nad OIP innej niż ta nad 
  wykorzystaniem pewnej części własności OIP, jak opisano poniżej, 
  jednak Deweloperom mogą zostać przyznane uprawnienia w ramach 
  OIP poprzez przepisy OIP.</li>

  <li>Deweloperzy Debiana nie są agentami ani pracownikami OIP, 
  ani swoimi nawzajem, ani władz Projektu Debian. Osoba występująca 
  jako Deweloper robi to indywidualnie i na własną rękę.</li>
</ol>

<h3>9.2. Zarządzanie własnością do celów związanych z Debianem</h3>

<p>Ponieważ Debian nie ma uprawnień, aby posiadać pieniądze lub własność, 
jakiekolwiek dotacje dla Projektu Debian muszą być przekazane OIP, 
które zarządza takimi sprawami.</p>

<p>OIP podjęło następujące przedsięwzięcia:</p>

<ol>
  <li>OIP będzie posiadało pieniądze, znaki handlowe i inną rzeczową 
  i nierzeczową własność oraz będzie zarządzać innymi sprawami do 
  celów związanych z Debianem.</li>

  <li>Ta własność będzie rozliczana oddzielnie i posiadana pod  
  zarządem do celów wybranych przez Debiana i OIP zgodnie z tą 
  sekcją.</li>

  <li>OIP nie będzie dysponować lub wykorzystywać własności 
  posiadanej pod zarządem dla Debiana bez jego zgody, która może 
  być wydana przez Lidera Projektu lub Ogólną Uchwałę Deweloperów.</li>

  <li>OIP rozważy wykorzystanie lub dysponowanie własnością posiadaną 
  pod zarządem dla Debiana, gdy zostanie o to poproszone przez 
  Lidera Projektu.</li>

  <li>OIP wykorzysta lub będzie dysponować własnością posiadaną pod 
  zarządem dla Debiana, gdy zostanie poproszona poprzez Ogólną 
  Uchwałę Deweloperów, jeśli jest to zgodne z władzą prawną OIP.</li>

  <li>OIP poinformuje Deweloperów poprzez wysłanie poczty elektronicznej 
  na listę dyskusyjną Projektu Debian, gdy będzie wykorzystywać 
  lub dysponować własnością posiadaną pod zarządem dla Debiana.</li>
</ol>

<h2>A. Podstawowa Procedura Uchwałodawcza</h2>

<p>Te zasady dotyczą wspólnego podejmowania decyzji i plebiscytów, 
jak podano powyżej.</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 wprowadzić zmiany korygujące pomniejsze 
  błedy (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 popierający wniosek może wzywać do głosowania 
  nad jedną lub wszystkimi poprawkami indywidualnie lub razem; 
  wnioskodawca lub popierający poprawkę może wzywać do głosowania 
  tylko nad tą poprawką i poprawkami powiązanymi.</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(6).</li>

  <li>Minimalny okres dyskusji jest liczony od momentu, gdy ostatnia 
  formalna poprawka została zaakceptowana, lub od momentu, gdy ostatnia
  powiązana formalna poprawka została zaakceptowana, jeśli zostało 
  przeprowadzone głosowanie na nią, lub, jeśli żądane 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żdy niezależny zestaw powiązanych poprawek jest 
  przegłosowywany na pojedyńczej karcie do głosowania. Każda karta 
  posiada jako opcję wszystkie sensowne kombinacje poprawek i opcji 
  oraz opcję Dalszej Dyskusji. Jeśli wygra opcja Dalszej Dyskusji 
  wtedy cała procedura uchwałodawcza jest cofana do początku okresu 
  dyskusji. Dla poprawek brak jest wymaganego kworum.</li>

  <li>Kiedy zostanie określony ostateczny kształt uchwały, jest on 
  przegłosowywany na ostatecznej karcie do głosowania, na której 
  są umieszczone opcje Tak, Nie oraz Dalsza Dyskusja. Jeśli wygra 
  opcja Dalszej Dyskusji wtedy cała procedura jest cofana do 
  początku okresu dyskusji.</li>

  <li>Osoba zbierająca głosy (jeśli jest jedna) lub wyborcy (jeśli 
  głosowanie odbywa się poprzez publiczne ogłoszenie) mogą tak zorganizować 
  te głosowania, aby odbyły się one jednocześnie, nawet (na przykład) 
  używając jednego pytania na karcie. Jeśli karta dotycząca poprawki/poprawek 
  oraz karta dotycząca ostatecznej formy uchwały zostanie połączona, 
  musi istnieć możliwość dla głosujących oddania różnych głosów na ostatecznej 
  karcie dla każdej możliwej ostatecznej formy projektu.</li>

  <li>Głosy są oddawane w okresie głosowania określonym w innym miejscu.
  Jeśli okres głosowania może być skrócony, kiedy nie ma już wątpliwości 
  co do wyniku głosowania, wtedy nie bierze się pod uwagę możliwości 
  zmiany już oddanych głosów.</li>

  <li>Głosy są liczone zgodnie z zasadą Condorcet Vote Counting. Jeśli jest 
  wymagane kworum, wtedy domyślną opcją jest opcja Dalsza Dyskusja.</li>

  <li>W przypadku wątpliwości Sekretarz Projektu powinien zadecydować 
  w sprawach procedury (na przykład, czy określona poprawka powinna być 
  rozpatrzona oddzielnie, czy też nie).</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 wnioskodawcy i/lub popierających oznacza, że 
uchwała nie ma wnioskodawcy lub ma 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, 
wtedy jest uznawana za odrzuconą.</p>

<h3>A.6. Liczenie głosów - Condorcet Vote Counting</h3>

<ol>
  <li>Metoda ta jest używana do określenia zwycięzcy spośród 
  podanej listy opcji. Każda karta do głosowania zawiera 
  ranking preferowanych opcji wyborcy. (Ranking nie musi być 
  kompletny.)</li>

  <li>Mówi się, że opcja A Dominuje nad opcją B, jeśli liczba  
  kart preferujących opcję A nad opcją B jest większa, niż liczba 
  kart preferujących opcję B nad opcję A.</li>

  <li>Wszystkie opcje, które zostały Zdominowane przez co najmniej 
  jedną opcję zostają odrzucone, a odwołania do nich na kartach do 
  głosowania będą ignorowane.</li>

  <li>Jeśli jest opcja, która Dominuje nad wszystkimi innymi, wtedy 
  ta opcja wygrywa.</li>

  <li>Jeśli pozostała więcej niż jedna opcja, będzie zastosowana 
    metoda Single Transferrable Vote, aby wybrać wśród tych pozostałych 
    opcji:

    <ul>
      <li>Liczona jest liczba pierwszych preferencji dla każdej opcji, 
      i jeśli któraś z opcji ma więcej niż połowę z nich, ta opcja 
      wygrywa.</li>

      <li>W innym przypadku opcja z najniższą liczbą pierwszych 
      preferencji jest eliminowana, a głosy na nią oddane są 
      rozdzielane pomiędzy drugimi preferencjami.</li>

      <li>Powyższa procedura eliminacji jest powtarzana, schodząc w 
      dół do drugich, trzecich, czwartych itd. preferencji jeżeli 
      jest taka konieczność, dopóki jedna opcja nie będzie posiadała 
      więcej niż połowę <q>pierwszych</q> preferencji.</li>
    </ul>
  </li>

  <li>W przypadku remisu, decyduje wyborca z głosem decydującym.
  Głos decydujący nie jest liczony jak głos normalny;  
  jednakże taki wyborca posiada zazwyczaj także możliwość oddania głosu 
  normalnego.</li>

  <li>Jeśli jest wymagana kwalifikowana większość głosów, liczba 
  głosów na TAK na końcowych 
  kartach do głosowania jest zmniejszania przy użyciu odpowiedniego 
  współczynnika. Mówiąc dokładnie, dla uzyskania większości F:A liczba 
  kart z wybraną opcją TAK dla X (rozważając, czy Tak Domuniuje X czy też 
  X Dominuje Tak) lub liczba kart, na których pierwsza (pozostała) opcja 
  to Tak (kiedy wykorzystuje się porównanie STV do wyłonienia zwycięzcy 
  lub w celu eliminacji) jest mnożona przez współczynnik A/F przed 
  wykonaniem porównania. <cite>Oznacza to, że na przykład stosunek 
  głosów 2:1 znaczy, że dwa razy więcej wyborców głosowało za niż 
  przeciw; frekwencja nie jest liczona.</cite></li>

  <li>Jeśli jest wymagane kworum, wtedy musi być przynajmniej tyle 
  głosów oddanych na wygraną opcję w stosunku do domyślnej opcji. 
  Jeśli nie ma tylu głosów, wtedy wygrywa opcja domyślna. W głosowaniach, 
  w których wymagana jest większość kwalifikowana, do określenia, czy zostało 
  osiągnięte kworum brana jest rzeczywista liczba głosów na Tak.</li>
</ol>

<p><cite>Gdy Podstawowa Procedura Uchwałodawcza ma być użyta, tekst, 
który się do niej odnosi musi określać, 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ą większość i/lub kworum (oraz domyślną opcję), które mają być 
użyte.</cite></p>

<h2>B. Wykorzystanie języka i typografii</h2>

<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>