Uwaga! To tłumaczenie jest przestarzałe, prosimy przejść do oryginału.

Historyczny Statut Debiana v 1.0

Historyczna wersja Statutu Projektu Debian (v1.0)

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

1. Wstęp

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

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.

2. Organa i osoby podejmujące decyzje

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

  1. Deweloperzy, w drodze Ogólnej Uchwały bądź wyborów;
  2. Lider Projektu;
  3. Komisja techniczna i/lub jej Przewodniczący;
  4. Indywidualny Deweloper pracujący nad konkretnym zadaniem;
  5. Delegaci mianowani przez Lidera Projektu do określonego zadania;
  6. Sekretarz Projektu.

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

2.1. Zasady ogólne

  1. Ż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.

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

  3. Osoba może opuścić Projekt, albo zrezygnować z obejmowanego stanowiska w dowolnym czasie, oznajmiając to publicznie.

3. Indywidualni Deweloperzy

3.1. Uprawnienia

Indywidualny Deweloper może

  1. podejmować jakiekolwiek techniczne bądź nietechniczne decyzje dotyczące jego własnej pracy;
  2. przedkładać lub popierać projekty Ogólnych Uchwał;
  3. przedkładać swoją kandydaturę na Lidera Projektu w wyborach;
  4. głosować nad Ogólnymi Uchwałami i w wyborach Kierownictwa.

3.2. Skład i mianowanie

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

  2. Delegaci Lidera Projektu mogą zdecydować nie przyjąć nowych Deweloperów lub wydalić już istniejących. Jeśli Deweloperzy czują, że Delegaci nadużywają swojej władzy, oczywiście mogą uchylić ich decyzję poprzez Ogólną Uchwałę - zobacz §4.1(3), §4.2.

3.3. Procedura

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

4. Deweloperzy drogą Ogólnej Uchwały lub wyboru

4.1. Uprawnienia

Wspólnie Deweloperzy mogą:

  1. Mianować bądź odwoływać Lidera Projektu.

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

  3. Uchylić każdą decyzję Lidera Projektu bądź Delegata.

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

  5. Wydawać nietechniczne dokumenty dotyczące polityki oraz oświadczenia.

    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.

    Można także w nie włączać oświadczenia dotyczące bieżących spraw.

  6. 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 §9.1.)

4.2. Procedura

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

  2. Opóźnienie decyzji Lidera Projektu lub jego Delegatów:

    1. 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 §4.1(3).
    2. 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).
    3. 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.
    4. 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.
    5. Jeśli Lider Projektu (lub Delegat) wycofuje oryginalną decyzję, głosowanie nie jest przeprowadzane.

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

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

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

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

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

5. Lider Projektu

5.1. Uprawnienia

Lider Projektu może:

  1. Mianować delegatów lub udzielać Komitetowi Technicznemu pełnomocnictwa w sprawie decyzji.

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

    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.

  2. Udzielać władzy innym Deweloperom.

    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.

  3. Podejmować wszelkie decyzje, które wymagają pilnego działania.

    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.

  4. Podejmować decyzje, za które nikt inny nie jest odpowiedzialny.

  5. Przedkładać projekty Ogólnych Uchwał i poprawek.

  6. Wspólnie z Komitetem Technicznym mianować nowych członków do Komitetu. (Zobacz §6.2.)

  7. Korzystać z głosu decydującego, gdy głosują Deweloperzy.

    Lider Projektu ma również zwykły głos w takich głosowaniach

  8. Zmieniać okres dyskusji dla głosowań Deweloperów (patrz wyżej).

  9. Prowadzić dyskusje wśród Deweloperów.

    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.

  10. 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 §9.1.)

5.2. Mianowanie

  1. Lider Projektu jest wybierany przez Deweloperów.
  2. Wybory zaczynają się na dziewięc tygodni przed zwolnieniem stanowiska kierowniczego lub (jeśli już jest za późno) niezwłocznie.
  3. Przez następne trzy tygodnie każdy Deweloper może nominować siebie jako kandydata na Lidera Projektu.
  4. 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).
  5. 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.
  6. 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).
  7. Decyzja będzie podjęta wykorzystując metodę Condorcet Vote Counting. Kworum jest takie samo jak dla Ogólnej Uchwały (§4.2), a domyślną opcją jest Żaden z Powyższych.
  8. Lider Projektu pełni swoją funkcję przez jeden rok od wyborów.

5.3. Procedura

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

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

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

6. Komitet Techniczny

6.1. Uprawnienia

Komitet Techniczny może:

  1. Decydować w każdej sprawie dotyczącej polityki technicznej.

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

  2. Decydować w sprawach technicznych, gdzie jurysdykcje Deweloperów się nakładają.

    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.

  3. Podejmować decyzję, gdy jest o to proszony.

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

  4. Unieważnić decyzję Dewelopera (wymagana większość 3/4).

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

  5. Oferować radę.

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

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

  7. Mianować Prezesa Komitetu Technicznego.

    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.

  8. Prezes, wspólnie z Sekretarzem, może zastępować Lidera.

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

6.2. Skład

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

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

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

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

  5. Jeśli Komitet Techniczny i Lider Projektu zgadzają się, mogą oni usunąć lub zamienić istniejącego członka Komitetu Technicznego.

6.3. Procedura

  1. Komitet Techniczny korzysta z Podstawowej Procedury Uchwałodawczej.

    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.

  2. Szczegóły dotyczące głosowania

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

  3. Dyskusja publiczna i podejmowanie decyzji.

    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.

  4. Poufność mianowania.

    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.

  5. Żadnej szczegółowej pracy projektowej.

    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.

    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.

    Indywidualni członkowie komitetu technicznego mogą oczywiście uczestniczyć na własną rękę w każdym aspekcie projektowania i pracy dotyczącej polityki.

  6. Komitet Techniczny podejmuje decyzje tylko w ostateczności.

    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.

7. Sekretarz Projektu

7.1. Uprawnienia

Sekretarz:

  1. Zbiera głosy wśród Deweloperów i ustala liczbę i tożsamość Deweloperów, kiedykolwiek wymaga tego status.

  2. Może zastępować Lidera wspólnie z Prezesem Komitetu Technicznego.

    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.

  3. Rozstrzyga wszelkie spory na temat interpretacji statutu.

  4. Może przekazywać część swojej władzy komuś innemu lub wycofywać takie pełnomocnictwa w dowolnym czasie.

7.2. Mianowanie

Sekretarz Projektu jest mianowany przez Lidera Projektu oraz aktualnego Sekretarza Projektu.

Jeśli Lider Projektu i aktualny Sekretarz Projektu nie mogą zdecydować o nowym mianowaniu, muszą poprosić zarząd OIP (zobacz §9.1.) o mianowanie Sekretarza.

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.

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

7.3. Procedura

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

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.

8. Delegaci Lidera Projektu

8.1. Uprawnienia

Delegaci Lidera Projektu:

  1. mają uprawnienia przekazane im przez Lidera Projektu;
  2. 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. Ma to na celu uniknięcie koncentracji uprawnień, w szczególności nad członkostwem jako Deweloper, w rękach Lidera Projektu.

8.2. Mianowanie

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.

8.3. Procedura

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.

9. Oprogramowanie w Interesie Publicznych

OPI i Debian są oddzielnymi organizacjami, które mają kilka wspólnych celów. Debian jest wdzięczny za wsparcie prawne oferowane przez OIP. Deweloperzy Debiana są aktualnie członkami OIP z racji ich statusu jako Deweloperów.

9.1. Władza

  1. 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.
  2. 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.
  3. 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ę.

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

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.

OIP podjęło następujące przedsięwzięcia:

  1. 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.
  2. Ta własność będzie rozliczana oddzielnie i posiadana pod zarządem do celów wybranych przez Debiana i OIP zgodnie z tą sekcją.
  3. 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.
  4. OIP rozważy wykorzystanie lub dysponowanie własnością posiadaną pod zarządem dla Debiana, gdy zostanie o to poproszone przez Lidera Projektu.
  5. 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.
  6. 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.

A. Podstawowa Procedura Uchwałodawcza

Te zasady dotyczą wspólnego podejmowania decyzji i plebiscytów, jak podano powyżej.

A.1. Wniosek

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

A.1. Dyskusja i poprawki

  1. 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.
  2. 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ł.
  3. 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.
  4. 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).)
  5. 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.
  6. 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.

A.2. Wezwanie do głosowania

  1. 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).
  2. 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.
  3. 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).
  4. 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.

A.3. Procedura głosowania

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. Głosy są liczone zgodnie z zasadą Condorcet Vote Counting. Jeśli jest wymagane kworum, wtedy domyślną opcją jest opcja Dalsza Dyskusja.
  6. 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).

A.4. Wycofywanie uchwał lub nieprzyjętych poprawek.

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

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

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.

A.5. Wygaśnięcie

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

A.6. Liczenie głosów - Condorcet Vote Counting

  1. 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.)
  2. 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.
  3. 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.
  4. Jeśli jest opcja, która Dominuje nad wszystkimi innymi, wtedy ta opcja wygrywa.
  5. 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:
    • 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.
    • W innym przypadku opcja z najniższą liczbą pierwszych preferencji jest eliminowana, a głosy na nią oddane są rozdzielane pomiędzy drugimi preferencjami.
    • 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ę pierwszych preferencji.
  6. 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.
  7. 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. 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.
  8. 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.

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.

B. Wykorzystanie języka i typografii

Tryb oznajmujący czasu teraźniejszego (na przykład jest) oznacza, że stwierdzenie jest zasadą statutu. Może wskazuje, że osoba lub organ ma dowolność. Powinien oznacza, że dobrze byłoby to widziane, gdy zdanie byłoby przestrzegane, ale nie jest ono wiążące. 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.