#use wml::debian::template title="Historyczny Statut Debiana v 1.3" BARETITLE="true" #use wml::debian::toc #use wml::debian::translation-check translation="f193e8edf0278164eba7348669907ecc2d714e8d"
Wersja 1.3 zatwierdzona 24. września 2006r. Zastąpiła wersję 1.2 zatwierdzoną 29. października 2003r., która zastąpiła wersję 1.1 zatwierdzoną 21. sierpnia 2003r., która z kolei zastąpiła wersję 1.0 zatwierdzoną 2. grudnia 1998r. Wersja 1.3 została natomiast zastąpiona przez wersję 1.4 zatwierdzoną 7. października 2007 roku. Ta natomiast została zastąpiona przez obecną wersję 1.5 zatwierdzoną 9 stycznia 2015 roku.
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, sposobów ich osiągania, ani nie zawiera żadnych przepisów oprócz tych, które bezpośrednio odnoszą się do procesu podejmowania decyzji.
Każda decyzja dotycząca Projektu jest podejmowana poprzez jeden lub więcej z następujących podmiotów:
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. 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.
Ż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.
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.
Osoba może opuścić Projekt, albo zrezygnować z obejmowanego stanowiska w dowolnym czasie, oznajmiając to publicznie.
Indywidualny Deweloper może
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.
Delegaci Lidera Projektu mogą zdecydować nie przyjąć nowych Deweloperów lub wydalić już istniejących. Jeśli Deweloperzy uważają, że Delegaci nadużywają swojej władzy, mogą uchylić ich decyzję poprzez Ogólną Uchwałę - zobacz §4.1(3), §4.2.
Deweloperzy mogą podejmować decyzje, które uważają za stosowne.
Wspólnie Deweloperzy mogą:
Mianować bądź odwoływać Lidera Projektu.
Wnosić poprawki do tego statutu pod warunkiem, że zgadzają się z większością 3/4 głosów.
Podejmować lub uchylać każdą decyzję będącą w mocy Lidera Projektu bądź Delegata.
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.
Wydawać, zastępować i wycofywać 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łączyć oświadczenia dotyczące bieżących spraw.
Umową Społeczną Debianai
Wytycznymi Debiana dotyczącymi Wolnego Oprogramowania.
Podejmować decyzje o własności będącej pod ich zarządem w celach związanych z Debianem (Zobacz §9.).
W przypadku braku porozumienia pomiędzy liderem projektu i urzędującym sekretarzem, powołać nowego sekretarza.
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.
Opóźnianie decyzji Lidera Projektu lub jego Delegatów:
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.
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.
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.
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.
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.
Lider Projektu może:
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.
Udzielać władzy innym Deweloperom.
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.
Podejmować wszelkie decyzje, które wymagają pilnego działania.
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.
Podejmować decyzje, za które nikt inny nie jest odpowiedzialny.
Przedkładać projekty Ogólnych Uchwał i poprawek.
Wspólnie z Komitetem Technicznym mianować nowych członków do Komitetu. (Zobacz §6.2.)
Korzystać z głosu decydującego, gdy głosują Deweloperzy.
Lider Projektu ma również zwykły głos w takich głosowaniach.
Zmieniać okres dyskusji dla głosów Deweloperów (patrz wyżej).
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.
Po konsultacji z deweloperami pojedmować decyzje związane z majątkiem użytkowanym w związku z pracami na rzecz Debiana (patrz §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.
Dodawać i usuwać organizacje z listy zaufanych organizacji (patrz §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.
Żaden z Powyższych.
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.
Komitet Techniczny może:
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).)
Decydować w sprawach technicznych, gdzie jurysdykcje Deweloperów się nakładają.
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ę.
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.
Unieważnić decyzje Dewelopera (wymaga większości 3:1).
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ć.
Oferować radę.
Komitet Techniczny może ogłaszać formalne komunikaty na temat swoich 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.
Wspólnie z Liderem Projektu mianować nowych członków do komitetu lub usuwać już istniejących. (Zobacz §6.2.)
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 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ł.
Prezes może zastępować Lidera wspólnie z Sekretarzem.
Jak wyszczególniono w §7.1(2) Prezes Komitetu Technicznego i Sekretarz Projektu mogą wspólnie zastępować Lidera, jeśli jest on nieobecny.
Komitet Techniczny składa się z co najwyżej 8 Deweloperów i powinien zwykle mieć nie mniej niż 4 członków.
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.
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.
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.
Jeśli Komitet Techniczny i Lider Projektu zgdzają się, mogą oni usunąć lub zamienić istniejącego członka Komitetu Technicznego.
Komitet Techniczny korzysta z Standardowej Procedury Podejmowania Uchwał.
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.
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).
Dyskusja publiczna i podejmowanie decyzji.
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.
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.
Brak szczegółowej pracy projektowej.
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.
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ęke w każdym aspekcie projektowania i pracy dotyczącej polityki.
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.
Zbiera głosy wśród Deweloperów i ustala liczbę i tożsamość Deweloperów, kiedykolwiek wymaga tego statut.
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ć decyzję, jeśli uważają to za konieczne.
Rozstrzyga wszelkie spory na temat interpretacji statutu.
Może przekazywać część swojej władzy komuś innemu lub wycofywać takie pełnomocnictwo w dowolnym czasie.
Sekretarz Projektu jest mianowany przez Lidera Projektu oraz aktualnego Sekretarza Projektu.
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.
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.
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.
Delegaci Lidera Projektu:
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.
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.
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 §9.2.
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.
SPI i Debian są oddzielnymi organizacjami, które mają kilka wspólnych celów. Debian jest wdzięczny za wsparcie prawne oferowane przez SPI.
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.
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.
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.
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.
Organizacje posiadające aktywa dla Debiana biorą na siebie odpowiedzialność za zgodne z prawem zarządzanie tymi aktywami.
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.
Te zasady dotyczą wspólnego podejmowania decyzji i plebiscytów tam, gdzie powyżej podano.
Formalna procedura zaczyna się, kiedy projekt uchwały jest przedkładany i popierany tak, jak jest to wymagane.
Dalsza Dyskusja, chyba że określono inaczej.
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 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.
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.
Sekretarz może także włączyć sugestie, jak należy dalej postępować, jeśli jest to stosowne.
Uwaga: 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.
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.
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.