Potencjalne zmiany w zarządzaniu projektem

[matek123]

Wiemy co znajduje się w działach zamkniętych, są one po części ogromnym archiwum. Wydaje mi się, że zacząć powinnismy od scalenia działów niepublicznych do jednego. Potem można rozpocząć ich przysłowiowe czyszczenie, żeby dodatki, które już dawno nie działają / nie będą działać przy obecnych paczkach, zarchiwizować oraz odpowiednio oznaczyć. 

Dla porządku proponuję zostawić strukturę i poziomy dostępów jak są. Tylko zablokować zakładanie nowych wątków.

Bardziej mam na myśli, że był taki luźny chat na mattermost, który został zamknięty przez spiny.

Ale MM działa.

[Kalikowsky]

MM działa, jednakże Discord ma nieporównywalnie większy potencjał oraz zasięg. Można promować serwer na wielu stronach (wyszukiwarkach serwerów ), w tym również bezpłatnie.

Discord cieszy się ogromną popularnością i może nam pomóc w promocji projektu na wielu płaszczyznach. Moderacja jest również bardziej przystępna. Osobiście o istnieniu MM dowiedziałem się wyłącznie przez Maszynę.

Założenie serwera i jego prowadzenie jest w pełni bezpłatne. Zachęcam do przyjrzenia się sprawie.

Co do zachowania struktury działów jasne, to była wyłącznie propozycja aby je scalić i zamknąć jako wspólne archiwum.

[jakubg1]

Czy w międzyczasie, zanim zaproponowane zmiany zostaną wdrożone, są planowane jakiekolwiek zmiany wymagające mniejszego nakładu pracy, aby mieć pewność, że sytuacja, którą mamy w tym roku, została zażegnana i się nie powtórzyła?

Jeszcze co do składu komisji testu dodatków, trzy propozycje:
1. Początkowy skład komisji powinien składać się z wszystkich osób, które mają obecnie rangę Betatester, Deweloper i Wydział Repozytorium, ewentualnie również moderacja i administracja;
2. Komisja, oprócz demokratycznego wybierania nowych członków, powinna mieć także możliwość ich demokratycznego usuwania;
3. Użytkownicy, którzy przez miesiąc nie logowali się na forum, byliby automatycznie usuwani z komisji (w przypadku powrotu wciąż mogliby zostać dodani za pomocą głosowania, jak każdy inny użytkownik).

[marcinn]

1. Dodatki
- Oddzielny manager dodatków.
- Rozważyć, czy exe nie powinien dodatkowo obsługiwać nowych ścieżek do addonsów (w schemacie addons/<id>/<wszystkie pliki dodatku>)
- Website z dodatkami (właściwie indeks, content mógłby leżeć gdziekolwiek)
- Ocena dodatków przez community bez względu na autorstwo
- Moderowanie dodatków po zgłoszeniu naruszenia zasad

2. Exe
- Jedno docelowe repozytorium dla exe
- Wyznaczyć cele makro (żeby wiedzieć co warto, a czego nie warto robić z exe)
- Wyznaczyć więcej osób do review i mergowania PR
- Usprawnić cykl wydawniczy (dev buildy, stable buildy, release branche do testow i stabilizacji) - ten punkt ma zabezpieczyć przed wejściem na stable nieewidentnych baboli

Ad. 2
Co wracam do exe, to rozbijam się o nieustalony coding standards i nieprzeformatowany kod, co utrudnia merge / rozwiązywanie konfliktów. Mam też uwagę, że źródła są prawie płasko w jednym katalogu - przydałby się sensowniejszy podział na podkatalogi (zrobiłem próbę czegoś takiego - kompiluje się, a lata się po plikach wygodniej). Przed zaproszeniem większej liczby osób warto byłoby to ogarnąć.

Fantazje: ponieważ kręcę się wokół tematu edytora, chciałem użyć renderera/engine. Ten jest mocno powiązany z elementami symulatora, co też trzeba byłoby nieco ruszyć. Myślałem też o hot reloading, ale to wymagałoby zmiany sposobu wczytywania danych (parser) oraz wprowadzenia drzewa obiektów (hot reload wybranej gałęzi lub pojedynczych węzłów - ściśle związane z tym jak tworzone są pliki z danymi, szczególnie scn). Z tyłu głowy wisi refaktoryzacja buttonow/gauges, o której gadane było z rok temu i roboty miało być na dwa lata.

Niestety na chwilę obecną ciągle odbijam się od poczucia że jest ogrom roboty, którą nie wiadomo czy warto zaczynać. Stąd punkt o celach. Bo może nie ma sensu robić rewolucji?

EDIT: Dotarłem w końcu do paczki z Galicją. Jestem pod wrażeniem tego projektu, talentu i zawziętości Twórców. Po instalacji oczywiście nie działa, a oprócz customowego exe win-only czas wczytywania się jest kosmiczny. Tzn. jeszcze niczego nie udało mi się wczytać, więc oglądam sobie screeny i filmiki na YT. Dopisałbym do listy fantazji jakiś level streaming.

[jakubg1]

- Oddzielny manager dodatków.
- Rozważyć, czy exe nie powinien dodatkowo obsługiwać nowych ścieżek do addonsów (w schemacie addons/<id>/<wszystkie pliki dodatku>)

Nie wiem, czy nie odbiłoby się to negatywnie na prędkość szukania plików, kiedy mamy dużo addonów. Chociaż w sumie symulator na starcie mógłby skanować cały folder addons. A jak rozwiązywane by były kolizje w nazwach?
Ponadto mogłoby to spowodować problem Trainza - dużo brakujących dodatków i trwające dniami poszukiwania i ręczne dosztukowywanie z tysięcy lokalizacji.

- Website z dodatkami (właściwie indeks, content mógłby leżeć gdziekolwiek)

Z tym gdziekolwiek bym się nie zapędzał, bo pliki hostowane gdziekolwiek lubią po jakimś czasie znikać.

- Jedno docelowe repozytorium dla exe

W sumie poniekąd mamy, ale jest to zdecydowanie zbyt słabo rozpowszechniona wiedza - branch sim z githuba Milka7 (https://github.com/Milek7/maszyna/tree/sim).

- Wyznaczyć cele makro (żeby wiedzieć co warto, a czego nie warto robić z exe)

W tej chwili to najlepiej solidnie posprzątać i zoptymalizować program tak, by wycisnąć więcej wydajności (prace nad tym są prowadzone, patrz co napisał @MichauSto na mattermoście).

- Wyznaczyć więcej osób do review i mergowania PR

Obawiam się, że Milek będzie stanowczo przeciw. W końcu jego stanowisko to albo on, albo nikt.

- Usprawnić cykl wydawniczy (dev buildy, stable buildy, release branche do testow i stabilizacji) - ten punkt ma zabezpieczyć przed wejściem na stable nieewidentnych baboli

W sumie i tak mało kto podmienia exe, chociaż jeśli paczkowe miałyby być generowane automatycznie, to nie jest głupi pomysł.

Ad. 2
Co wracam do exe, to rozbijam się o nieustalony coding standards i nieprzeformatowany kod, co utrudnia merge / rozwiązywanie konfliktów. Mam też uwagę, że źródła są prawie płasko w jednym katalogu - przydałby się sensowniejszy podział na podkatalogi (zrobiłem próbę czegoś takiego - kompiluje się, a lata się po plikach wygodniej). Przed zaproszeniem większej liczby osób warto byłoby to ogarnąć.

Jestem otwarty na dyskusje.

[mk1991]

Co do pobierania dodatków przez starter, to przecież jest taka możliwość w programie od @ra, tylko kto w efekcie z tego korzysta? Z tego co pamiętam była tam możliwość wybierania dodatków do pobrania na zasadzie paczek, ale to nie wiem czy ktoś to aktualizował, nigdy z tego nie korzystałem.

[marcinn]

Co do pobierania dodatków przez starter, to przecież jest taka możliwość w programie od @ra, tylko kto w efekcie z tego korzysta?

Najpierw regular user musiałby korzystać z Rainsteda. Narzędzia które powstają do Maszyny nie są cross platform. Np. ja mam prymitywny starter zrobiony w pythonie i odpalam z terminala.
Mamy exe cross platform, ale soft do odpalania tego exe - nie.

Addon manager, dla ułatwienia sprawy, mógłby być oddzielnym programem, który byłby w paczce. Natomiast problem z dodatkami jest taki, że ich instalacja jest względnie prosta, ale ich pliki mieszają się z bazowymi. Łatwo też o konflikty. Wolałbym pokombinować żeby addonsy miały swoje subfoldery np. w addons/ czy mods/, choć to wymagałoby sporych zmian w exe i nie wiem jak bardzo byłoby możliwe.

Ale addon manager będzie potrzebował serwera. To może być centrala (jak PyPI,  NPM, Docker Hub itp - pytanie kto to będzie utrzymywal i za czyje pieniądze), albo jak proponowałem wcześniej - autorzy paczek mogliby wrzucać wydania gdziekolwiek i być w pełni odpowiedzialni za utrzymanie storage (za jego dostępność i opłaty). Centrala byłaby wygodniejsza dla autorów paczek, ale kiedy myślę o przechowywaniu różnych wersji takich dodatków, to szybko możemy pójść w terabajty. Dziś autorzy paczek hostują je "gdzieś tam", więc można to podtrzymać, a tylko zrobić cetralny indeks tychże.

[matek123]

Próbowałeś korzystać z wbudowanego startera? Po usunięciu z eu07.ini  linijki

Kod: [Zaznacz]

sceneryfile td.scn i uruchomieniu eu07.exe od Milka powinien uruchomić się starter. Pozwala na podstawowe operacje na składach (dodawanie pojazdów, zmiana tekstur itp.). Na początku może wydawać się toporny, ale jak się go rozgryzie to może być. https://eu07.pl/forum/index.php/topic,35293.msg566319.html#msg566319

[Milek7]

Addon manager, dla ułatwienia sprawy, mógłby być oddzielnym programem, który byłby w paczce. Natomiast problem z dodatkami jest taki, że ich instalacja jest względnie prosta, ale ich pliki mieszają się z bazowymi. Łatwo też o konflikty. Wolałbym pokombinować żeby addonsy miały swoje subfoldery np. w addons/ czy mods/, choć to wymagałoby sporych zmian w exe i nie wiem jak bardzo byłoby możliwe.

Mam do skończenia na kiedyś: https://github.com/Milek7/maszyna/tree/vfs
Centralizacja wszystkich dostępów do plików przez klasę ivfsstream, czytanie plików ze skompresowanego archiwum (eu07vfs jako niezależna biblioteka w C, bo archiwa musiałyby też otwierane przez zewnętrzne narzędzia i startery), do zrobienia została obsługa otwierania wielu archiwów dodatków jako overlay na poprzednie.

[Milek7]

Kilka wariantów propozycji. Moje preferencje zaznaczyłem pogrubieniem ale to nic wiążącego, zapraszam do dyskusji (również innych możliwości których tu nie przestawiłem).

Gdy w dalszej części mowa o moderacji, to chodzi o moderację i administrację.

1. Nazewnictwo: zespół/rada/komitet/komisja?

2. Sposób akceptacji zmian na repozytorium:
a) głosowanie całego zespołu
b) akceptacja 3 osób, zatwierdzenie natychmiastowo po osiągnięciu wymaganej ilości
c) akceptacja 3 osób, zatwierdzenie 24h po ostatniej akceptacji, do tego czasu możliwość zgłaszania wet, po trzech wetach zmiana poddawana pod głosowanie

Wariant a) dawałby duże opóźnienia, bo głosowania powinny być wystarczająco długie (rzędu np. 2 tygodni) żeby każdy mógł się wypowiedzieć. b) daje szybkie efekty ale łatwo o wojnę edycyjną między małymi ale aktywnymi obozami. c) jest w miarę szybkie ale w przypadku konfliktów zmiana idzie pod głosowanie.

2.1. W przypadku 2b i 2c:
a) brak wpływu moderacji na proces akceptacji
b) jeżeli w czasie kilku dni pomimo zabezpieczeń proceduralnych występuje wojna edycyjna (np. wprowadzenie zmiany, tydzień później revert tego samego) moderacja może zdecydować o poddaniu zmiany pod głosowanie.

2.2. W przypadku 2b i 2c:
a) wliczanie autora zmian jako jedną akceptację (jeżeli jest członkiem zespołu)
b) wymaganie 3 akceptacji nie wliczając autora zmian

a) wydaje się tu bardziej logiczne, bo nie daje sztucznej korzyści przy przepuszczaniu zmian przez inną osobę

3. Sposób głosowania:
3.1.
a) tajne
b) jawne

3.2. Wymagana większość:
a) >50%
b) >60%
c) >66%

3.3. Wymagane kworum:
a) 0%
b) 33%
c) 50%

3.4. Okres głosowania:
a) 1 tydzień
b) 2 tygodnie
c) miesiąc

Myślę że wymaganie kworum nie jest potrzebne żeby nie tworzyć impasu w przypadku małej aktywności, a 2 tygodnie to wystarczający okres żeby wszyscy aktywni członkowie się wypowiedzieli.

4. Skład zespołu:
4.1. Ilość miejsc:
a) stała
b) zmienna

4.2. Początkowy skład:
a) obecni użytkownicy z rangą główną (coś około 40)
b) inny wybór przez moderację

4.2.1. Co z obecnymi użytkownikami z ukrytą rangą
a) nic, zdejmujemy dostęp
b) w ciągu 30 dni od wprowadzenia zmian możliwość dołączenia do zespołu na wniosek zainteresowanego

4.3. Sposób nominacji nowych członków
a) na wniosek kandydata
b) na wniosek 3 obecnych członków

4.4. Sposób akceptacji nowych członków:
Jeżeli 4.1a, konieczny wybór między wieloma kandydatami, niestety tu wchodzimy w skomplikowaną dyskusję o systemach wyborczych: FPTP, IRV, Concordet, STAR, coś innego?
Jeżeli 4.2b, wystarcza zwykłe głosowanie o akceptację, warianty takie same jak w punkcie 3., moje preferencje takie same z wyjątkiem 3.1a

4.5. Sposób usuwania członków:
a) na wniosek 3 obecnych członków, później głosowanie tak samo jak przy dodawaniu
b) automatyczne po 3 miesiącach nieaktywności

Myślę że nie ma tu potrzeby procedury na usuwanie osób, niepotrzebne pole do konfliktów. Automatyczne usuwanie po nieaktywności powinno być wystarczające.

5. Sposób procedowania zmian w exe
a) import wybranego exe jako gotowego elementu
b) przeniesienie repozytorium exe i procedowanie zmian w kodzie tak samo jak zmiany w repozytorium

Liczę że przeniesienie rozwoju exe bliżej pozostałej części projektu zmniejszy rozbicie gałęzi do jakiego się obecnie zmierza.

6.1. Moderacja nie ma wpływu merytorycznego na podejmowane decyzje, może przystąpić jako członek na zasadach ogólnych.
6.2. Niezależnie od powyższego moderacja pilnuje przestrzegania regulaminu i może banować za nieodpowiednie zachowanie.
6.3. Jeżeli liczba członków spadnie poniżej 6, moderacja mianuje dodatkowych członków według własnej decyzji

[jakubg1]

1. Moja proponowana nazwa to Komisja Testu Dodatków, ale to nie brzmi jeszcze aż tak dobrze. Może ktoś ma lepszy pomysł, albo sam wpadnę na coś lepszego później.
2. c), przy czym uważam, że dwa weta powinny wystarczyć do poddania zmiany pod głosowanie. Sądzę, że ludzie będą wetować tylko jeśli jest coś mocno nie tak z dodatkiem.
2.1. b), moderacja powinna mieć możliwość ręcznego uruchomienia głosowania.
2.2. a), chociaż jak mogłoby to działać, jeśli dodatek ma wielu autorów? automatyczny głos wrzucającego dodatek, czy wszyscy współautorzy jako jeden głos, aby wyeliminować wpływ współautorów dodatku na głosowanie?
3.1. b)
3.2. b), chociaż (jak również w kilku innych przypadkach) wartość pewnie będzie trzeba dobrać eksperymentalnie.
3.3. a), nie uzależniajmy głosowania od całkowitej ilości osób w komisji.
3.4. b), głosowania pewnie będą rzadko więc nie wpłynie to na wydajność testów.
4.1. b)
4.2. b)
4.2.1. b), aczkolwiek ile obecnie mamy osób z ukrytą rangą? jedną? dwie? Myślę, że to można załatwić na poziomie rozmowy indywidualnej.
4.3. b), aczkolwiek nie jestem pewien, jak miałoby to działać. Na wniosek trzech członków, czyli ktoś musi założyć projekt wniosku, a następnie dwie osoby zagłosować, żeby był wniosek trzech członków, żeby zacząć głosowanie? Trochę nie ma to sensu.
4.4. zgadzam się, głosowanie tajne z opublikowaniem wyników po jego zakończeniu. Być może wyższy próg, na przykład 75%?
4.5. b), zgadzam się, że głosowania na usuwanie osób mogłyby być przyczynami spin. Moderacja powinna mieć jednak możliwość usuwania z komisji osób natychmiastowo.
5. b), choć uważam że na exe za wcześnie. Moja propozycja to utworzenie oddzielnego komitetu do exe, większość osób ocenia dodatki a z exe nie mają nic wspólnego, więc aprobowaliby zmiany, co dopuszczałoby babole w kodzie.
Zgadzam się z 6.1. i 6.2.
6.3. Skąd liczba 6?

Ponadto z zasad niewymienionych: wrzucenie nowej wersji dodatku do testu resetowałoby cały proces głosowania/akceptowania.

[mk1991]

Popieram pomysł takiej komisji. Jeśli dodatki przez komisję zostały by ocenione jako dobre przed udostępnieniem ludziom na teście można by zredukować liczbę skarg, no po za tymi wystawianymi przez laików, którzy po prostu nie umieją zainstalować czegokolwiek i są wiedzo odporni.

[Milek7]

Spodziewałem że odniosę się od razu do większej ilości komentarzy, ale w takim razie odnośnie tego co jest:

2.2. a), chociaż jak mogłoby to działać, jeśli dodatek ma wielu autorów? automatyczny głos wrzucającego dodatek, czy wszyscy współautorzy jako jeden głos, aby wyeliminować wpływ współautorów dodatku na głosowanie?

Myślę że automatyczny głos wrzucającego dodatek. Liczenie współautorów jako jeden może powodować jakieś dziwne ruchy, żeby "oficjalnie" dodatek nie miał współautorów tylko po to żeby doliczyć dodatkowe głosy. Myślę że przejrzyściej jak każdy członek komisji ma głos liczony tak samo niezależnie czy akurat brał udział w danej zmianie.

4.2.1. b), aczkolwiek ile obecnie mamy osób z ukrytą rangą? jedną? dwie? Myślę, że to można załatwić na poziomie rozmowy indywidualnej.

Niestety to nie jest takie proste, wcześniejsza praktyka była inna i był zwyczaj zostawiania ukrytych uprawnień. Obecnie jest kilkadziesiąt takich kont (najczęściej jest to połączenie rangi Zasłużony + ukryta deweloperska, chociaż nie we wszystkich przypadkach).

4.3. b), aczkolwiek nie jestem pewien, jak miałoby to działać. Na wniosek trzech członków, czyli ktoś musi założyć projekt wniosku, a następnie dwie osoby zagłosować, żeby był wniosek trzech członków, żeby zacząć głosowanie? Trochę nie ma to sensu.

Coś w tym rodzaju. Dlaczego bez sensu? Założenie było takie, żeby wymagać wniosku kilku osób żeby nie było możliwości nadmiernego tworzenia głosowań (a ponieważ proponowałem też brak wymagań kworum w głosowaniach, nie można ich po prostu ignorować). Konsekwencją byłoby też to, że autorzy wniosku byliby jawni, a samo głosowanie jest tajne.
Można zastosować wariant z głosowaniem na wniosek kandydata, ale dla takich głosowań trzeba dodać wymóg kworum.

5. b), choć uważam że na exe za wcześnie. Moja propozycja to utworzenie oddzielnego komitetu do exe, większość osób ocenia dodatki a z exe nie mają nic wspólnego, więc aprobowaliby zmiany, co dopuszczałoby babole w kodzie.

Cóż, trzeba się zastanowić czy mamy tyle ludzi żeby stworzyć oddzielny komitet do exe. Ja mam co do tego wątpliwości. Myślę że można oczekiwać że członkowie komisji nie będą bezrefleksyjnie akceptować zmian o których nie mają pojęcia. Dodatkowo przecież efekty zmian będą łatwo widoczne, więc zawsze można je wycofać w tej samej procedurze. A zostawienie obecnego stanu jako osobny komponent daje ryzyko rozłamów gałęziowych (wstawmy inne exe, bo tam jest nowa funkcja), jak i zależy od (nie)aktywności autorów tych gałęzi.

6.3. Skąd liczba 6?

To taka liczba na oko. Proponowałem wniosek o dodanie przez 3 członków, więc minimum poniżej 4, plus 2 zapasu.

[x_Zielu]

Jak mniemam cała komisja odnosi się do procedowania zmian na repozytorium, zatem w tej kwestii:
2c
2.1b
2.2 każda osoba w komisji ma głos, którego może użyć, niezależnie od brania udziału w zmianie
3.1b
3.2b
3.3a
3.4a - jak ktoś jest w miarę aktywny, to nie potrzebuje 14 dni, żeby zauważyć, że jest coś głosowane.
4b
4.2a
4.2.1b - w przypadku odmowy, zostają uprawnienia ukryte, do czegoś jeszcze się do czegoś przydadzą te uprawnienia?
4.3b
4.5b - z czego trzeba zdefiniować "nieaktywność" i mimo wszystko musi być awaryjna opcja do usuwania osób za np. łamanie zasad czy coś w ten deseń.
5b
6.1 ok
6.2 ok
6.3 ok

Nie do końca wynika to z kontekstu, także proszę o uzupełnienie informacji:
a) komisja czy jak to się będzie zwać, zastępuje wszystkie rangi na forum poza tymi moderacyjnymi?
b) wprowadzenie komisji likwiduje działy zamknięte?
c) komisja zastępuje obecny test dodatków?
c') jeżeli tak, to czy osoby spoza komisji w sposób oficjalny będą mogły testować dodatki?

Cóż, trzeba się zastanowić czy mamy tyle ludzi żeby stworzyć oddzielny komitet do exe.

Rzekłbym, że niekoniecznie.

Tyle ode mnie, wcześniej nie zauważyłem tej wiadomości, stąd brak aktywności.

[jakubg1]

4.2.1. b), aczkolwiek ile obecnie mamy osób z ukrytą rangą? jedną? dwie? Myślę, że to można załatwić na poziomie rozmowy indywidualnej.

Niestety to nie jest takie proste, wcześniejsza praktyka była inna i był zwyczaj zostawiania ukrytych uprawnień. Obecnie jest kilkadziesiąt takich kont (najczęściej jest to połączenie rangi Zasłużony + ukryta deweloperska, chociaż nie we wszystkich przypadkach).

Fakt, zasłużeni wtedy faktycznie powinni być zapytani. Wśród zasłużonych jest sporo nieaktywnych osób, to będzie można to odsiać.

4.3. b), aczkolwiek nie jestem pewien, jak miałoby to działać. Na wniosek trzech członków, czyli ktoś musi założyć projekt wniosku, a następnie dwie osoby zagłosować, żeby był wniosek trzech członków, żeby zacząć głosowanie? Trochę nie ma to sensu.

Coś w tym rodzaju. Dlaczego bez sensu? Założenie było takie, żeby wymagać wniosku kilku osób żeby nie było możliwości nadmiernego tworzenia głosowań (a ponieważ proponowałem też brak wymagań kworum w głosowaniach, nie można ich po prostu ignorować). Konsekwencją byłoby też to, że autorzy wniosku byliby jawni, a samo głosowanie jest tajne.
Można zastosować wariant z głosowaniem na wniosek kandydata, ale dla takich głosowań trzeba dodać wymóg kworum.

Bardziej zastanawiam się, jak od strony systemowej zostanie zrobione składanie wniosku przez 3 osoby jednocześnie.

5. b), choć uważam że na exe za wcześnie. Moja propozycja to utworzenie oddzielnego komitetu do exe, większość osób ocenia dodatki a z exe nie mają nic wspólnego, więc aprobowaliby zmiany, co dopuszczałoby babole w kodzie.

Cóż, trzeba się zastanowić czy mamy tyle ludzi żeby stworzyć oddzielny komitet do exe. Ja mam co do tego wątpliwości. Myślę że można oczekiwać że członkowie komisji nie będą bezrefleksyjnie akceptować zmian o których nie mają pojęcia. Dodatkowo przecież efekty zmian będą łatwo widoczne, więc zawsze można je wycofać w tej samej procedurze. A zostawienie obecnego stanu jako osobny komponent daje ryzyko rozłamów gałęziowych (wstawmy inne exe, bo tam jest nowa funkcja), jak i zależy od (nie)aktywności autorów tych gałęzi.

Racja, raczej nikogo kompetentnego do audytu takich zmian już nie ma. Reverty jako dopuszczalne zmiany mają sens. Co do rozłamów gałęziowych, to obecny stan (exe idzie tylko z twojej gałązki) już to wyklucza - tylko, że w formie ręcznej (pull requesty musisz zaakceptować).
Aczkolwiek warto dopuścić utworzenie takiego komitetu jeżeli jakimś cudem znajdzie się garstka zapaleńców, żeby im czasem ktoś nie przegłosował jakiegoś bubla.
Jak będzie wyglądać rozwiązywanie konfliktów (np. dwie zmiany w tym samym kawałku kodu utworzone przez różnych użytkowników)?

I jeszcze co do tego:

Spodziewałem że odniosę się od razu do większej ilości komentarzy

Warto takie rzeczy dawać na stronę główną forum jako ogłoszenie.

[x_Zielu]

Jeszcze uważam, że wymaga to doprecyzowania - co z kwestią małych poprawek na repo czy innymi nieznacznymi duperelami, typu poprawka parametru w .fiz czy coś w tym guście? Też musi czekać tydzień i być głosowane pod komisją?

[jakubg1]

Pytałem o to na PW na czacie. Tak.
Podejrzewam, że w szczególnych przypadkach (krytyczny błąd w paczce) moderacja miałaby możliwość pominięcia głosowania. Zresztą raczej nikt weta by nie zgłosił, a bez weta 24 godziny czekania tylko.

[Milek7]

2.2 każda osoba w komisji ma głos, którego może użyć, niezależnie od brania udziału w zmianie

Dlatego uwzględniłem, że jeżeli autor zmiany jest członkiem komisji to wlicza się automatycznie. Bo raczej nie powinno być sytuacji, w której ktoś zgłasza zmianę i jednocześnie jej nie akceptuje. Ale to szczegół techniczny.

4.2.1b - w przypadku odmowy, zostają uprawnienia ukryte, do czegoś jeszcze się do czegoś przydadzą te uprawnienia?

Pisałem już w tym wątku o tym, że działy zamknięte chcę zlikwidować. Przez jakiś okres przejściowy (np. rok) te uprawnienia będą jeszcze umożliwiać wgląd do tych działów.

z czego trzeba zdefiniować "nieaktywność" i mimo wszystko musi być awaryjna opcja do usuwania osób za np. łamanie zasad czy coś w ten deseń.

Nieaktywność w kontekście działań członka komisji, czyli prawdopodobnie udział w głosowaniach. Jeżeli ktoś złamie zasady to może wyłapać bana od moderacji (6.2)

Nie do końca wynika to z kontekstu, także proszę o uzupełnienie informacji:

Tym kontekstem jest pierwszy post tego wątku. Tak, zastępuje rangi, likwiduje działy zamknięte (z okresem przejściowym), zastępuje test dodatków, osoby spoza komisji będą mogły dodawać komentarze odnośnie proponowanych zmian (i oczywiście zgłaszać swoje zmiany).

Jeszcze uważam, że wymaga to doprecyzowania - co z kwestią małych poprawek na repo czy innymi nieznacznymi duperelami, typu poprawka parametru w .fiz czy coś w tym guście? Też musi czekać tydzień i być głosowane pod komisją?

Zgodnie z tą samą procedurą, ale niekoniecznie to musi trwać tydzień - według obecnych propozycji jeżeli masz 3 akceptacje (i brak wymaganej liczby wet do rozpoczęcia głosowania) to 24h.

Bardziej zastanawiam się, jak od strony systemowej zostanie zrobione składanie wniosku przez 3 osoby jednocześnie.

Może być tak jak pisałeś, utworzenie wniosku przez jedną osobę i dołączenie do niego jeszcze dwóch osób rozpoczynało by procedurę głosowania. Nie widzę tu problemu.

Jak będzie wyglądać rozwiązywanie konfliktów (np. dwie zmiany w tym samym kawałku kodu utworzone przez różnych użytkowników)?

Pewnie ta zatwierdzona jako druga musiałaby być odrzucona z prośbą poprawy do autora.

[mk1991]

Czy są na naszej stronie mechanizmy, które pomogły by w zażądzaniu większą ilością wniosków? Mam pomysły na parę narzędzi, które mogły by w tym pomóc.

[jakubg1]

Raczej w założeniu system ma być skonstruowany w taki sposób, by nie była wymagana żadna ingerencja techniczna do jego działania. A co za tym idzie, żadne ręczne narzędzia do zarządzania wnioskami nie będą potrzebne.

[matek123]

4.2.1b - w przypadku odmowy, zostają uprawnienia ukryte, do czegoś jeszcze się do czegoś przydadzą te uprawnienia?

Pisałem już w tym wątku o tym, że działy zamknięte chcę zlikwidować. Przez jakiś okres przejściowy (np. rok) te uprawnienia będą jeszcze umożliwiać wgląd do tych działów.

Z mojej strony propozycja jest taka, żeby w działach zamkniętych zablokować możliwość tworzenia nowych wątków i pisania nowych postów. Natomiast proponuję, żeby dostęp do nich był zachowany na dotychczasowych zasadach. Jak był uruchamiany otwarty test dodatków, to wątki utworzone przed otwarciem tego działu zostały przeniesione do działu podrzędnego z dostępem na dotychczasowych zasadach. Jeżeli uczestnicy jakiejś dyskusji nie mają nic przeciwko temu, to wtedy taki wątek można by było przenieść do otwartego działu.

[Piotr93]

Zgadzam się z Mateuszem, w dews są wątki i linki do pojazdów nie wydanych nigdy, choćby Lxd2 która czeka na lepsze czasy. Żaden autor nie chciał aby to wpadło w czyjeś ręce i użyte bez zgody autora.

[matek123]

Przyklejam wątek