eu07/maszyna
17
0
Fork 0
mirror of https://github.com/MaSzyna-EU07/maszyna.git synced 2026-10-17 00:29:19 +02:00
Code Issues 150 Wiki Activity

Unowocześnienie issue trackera dla new comerów + analiza aktywności #526

New Issue
Open
opened 2026-09-09 11:09:17 +02:00 by Hirek · 0 comments
Hirek commented 2026-09-09 11:09:17 +02:00
Owner
Copy Link

W związku ze spadkiem liczby aktywnych twórców zawartości proponuję rozszerzenie obecnego systemu issue oraz lepsze wyeksponowanie możliwości współpracy.

Nowe oznaczenia issue

  • Trudność
    • łatwe
    • umiarkowane
    • trudne
  • Dodatkowe
    • materiały dostępne
    • dostępny mentor
    • dobre na początek

Oznaczenia pozwolą osobom zainteresowanym pomocą łatwo znaleźć zadania odpowiadające ich umiejętnościom.

Informacja o możliwości współpracy

Na forum, Discordzie oraz GitHubie powinno zostać utworzone widoczne miejsce opisujące możliwości wsparcia projektu.

Dla nowych twórców zawartości głównym punktem wejścia powinien być odnośnik do przefiltrowanej listy issue oznaczonych dobre na początek.

Należy również krótko opisać:

  • sposób przesyłania nowej zawartości przez upload.eu07.pl,
  • działanie procedury testów,
  • podstawowe wymagania dotyczące przygotowywanej zawartości.

Dokumentacja dla początkujących powinna zawierać skrócone wytyczne i odsyłać do pełnej dokumentacji dopiero w razie potrzeby.

Procedura testowania

Dla nowej zawartości pozostaje obecna procedura:

  • minimum 1 tydzień testów,
  • 2 tygodnie w przypadku braku odpowiedzi testerów.

Drobne poprawki istniejącej zawartości przesłane przez osoby zewnętrzne mogłyby korzystać z uproszczonej procedury, np. poprzez załączenie paczki ZIP bezpośrednio do odpowiedniego issue. Po sprawdzeniu poprawki maintainer mógłby wprowadzić ją do SVN bez konieczności upływu okresu tygodnia/dwóch. Procedura uproszczona dotyczyłaby wyłącznie niewielkich poprawek istniejącej zawartości, a nie nowych modeli, pojazdów, scenerii czy innych większych zmian.

Przyczyna propzycji

Od 2020 roku widoczna jest długoterminowa tendencja spadkowa aktywności w repozytorium SVN. Nie wydaje się, aby jej główną przyczyną był obecny sposób przesyłania i testowania zawartości. Znacznie większym problemem jest stopniowe zmniejszanie się liczby regularnie aktywnych twórców oraz brak wystarczającego napływu nowych osób.

Obecny system przyjmowania dodatków funkcjonuje i nie wymaga zasadniczej przebudowy. Brakuje natomiast nowoczesnej i łatwo dostępnej informacji o tym, w jaki sposób można rozpocząć współpracę, czego obecnie projekt potrzebuje oraz gdzie znaleźć zadania odpowiednie dla nowych osób.

GitHub i Discord są obecnie naturalnymi miejscami, do których trafiają potencjalni nowi contributorzy. Informacja o możliwości współpracy powinna być jednak dostępna również na forum, stronie głównej projektu oraz, w miarę możliwości, na stronach MaSzyny na platformach dystrybucyjnych, takich jak Steam, Epic Games Store czy GOG.

Dane z historii SVN pokazują wyraźną zmianę skali aktywności:

Rok Commity Aktywni committerzy ≥20 commitów Dni z commitem Przerwy >2 dni
2018 1216 26 14 312 14
2019 1622 34 15 343 4
2020 1687 32 15 337 4
2021 1004 24 9 304 21
2022 865 29 10 253 35
2023 291 18 5 153 60
2024 247 13 5 115 56
2025 315 18 6 144 60
2026* 201 18 3 104 39

Rok 2020 był szczytem aktywności w analizowanym okresie, z 1687 commitami i 337 dniami, w których pojawiła się przynajmniej jedna zmiana. Spadek rozpoczyna się wyraźnie w 2021 roku, natomiast szczególnie silne ograniczenie aktywności następuje w drugiej połowie 2022 roku i jest w pełni widoczne od 2023 roku.

Dla zobrazowania:
image.png

Przebieg drugiej połowy 2022 roku dobrze pokazuje moment załamania:

2022-01   116
2022-02   152
2022-03    85
2022-04    91
...
2022-08    79
2022-09    45
2022-10    28
2022-11    33
2022-12    19

Jednocześnie porównanie aktywności do 24 sierpnia każdego roku pokazuje, że 2026 nie jest najsłabszym rokiem całego okresu:
image.png

Nie chodzi więc o próbę powrotu do dawnej liczby commitów poprzez zwiększanie obciążenia obecnych twórców. Celem powinno być odbudowanie dopływu nowych contributorów poprzez ułatwienie im znalezienia zadań, poznania podstawowych zasad projektu oraz wykonania pierwszej niewielkiej zmiany.

Proponowane oznaczenia issue, skrócona dokumentacja dla początkujących i lepsze wyeksponowanie możliwości współpracy mają przede wszystkim stworzyć czytelną ścieżkę:
zainteresowanie projektem > znalezienie odpowiedniego zadania > wykonanie pierwszej zmiany > przesłanie jej do projektu > test/review > dalsza współpraca.

Drugi wątek

Od poprzedniej dyskusji dotyczącej sposobu prowadzenia projektu minęło już kilka miesięcy. Emocje zdążyły opaść, część spraw można dziś ocenić z większym dystansem, a przede wszystkim mamy możliwość sprawdzenia, co faktycznie udało się od tamtej pory zmienić.
Dodatkowym argumentem za uporządkowaniem tych kwestii jest potrzeba zapewnienia ciągłości działania projektu niezależnie od aktualnego składu osób pełniących poszczególne role.
Nie chciałbym w tym miejscu rozstrzygać powodów, dla których ktoś ogranicza swoją aktywność, rezygnuje z pełnionej funkcji albo przestaje uczestniczyć w projekcie. Istotne jest natomiast to, aby taka sytuacja nie powodowała jednocześnie utraty wiedzy o
sposobie podejmowania decyzji ani powrotu do niejasnego podziału kompetencji.
Nie chciałbym również wracać do poprzedniej dyskusji po to, aby ponownie ustalać, kto miał rację, kto czego nie zrobił albo kto powinien był zachować się inaczej. Moim zdaniem znacznie bardziej użyteczne będzie zastanowienie się, czy problemy, które wtedy ujawniły się w projekcie, zostały rzeczywiście rozwiązane i co możemy zrobić, żeby podobna sytuacja nie powtórzyła się za kilka miesięcy.
Spisanie podstawowych zasad pozwoliłoby zachować ciągłość działania projektu również w przypadku zmian personalnych, niezależnie od ich przyczyn.

Od tamtego czasu wprowadziliśmy kilka konkretnych zmian:

  • pull request wymaga obecnie co najmniej jednego review przed merge,
  • powstał git.eu07.pl, który służy między innymi jako bugtracker całej paczki.
  • Jakub oraz Zielu zostali nowymi administratorami
  • Miłosz pozostał głównym administratorem

Zmiany te uważam za potrzebne, jednak nie rozwiązały one w pełni problemu niejasnego podziału kompetencji i sposobu podejmowania decyzji.

Jednocześnie poza nimi sposób podejmowania decyzji i organizacji pracy w projekcie pozostał w dużej mierze taki sam jak wcześniej. W dalszym ciągu nie mamy jasno określonego:

  • kto podejmuje decyzje dotyczące poszczególnych części projektu,
  • które decyzje techniczne mogą być podejmowane przez osoby rozwijające dany komponent,
  • które zmiany wymagają szerszej konsultacji,
  • kto powinien reviewować zmiany dotyczące konkretnych obszarów,
  • co robimy w sytuacji, gdy osoby mające wiedzę o danym komponencie nie są aktywne,
  • jak rozstrzygamy spory techniczne,
  • jak podejmujemy decyzje dotyczące infrastruktury,
  • jak postępujemy w sytuacjach awaryjnych,
  • gdzie zapisujemy większe ustalenia, aby po kilku miesiącach nie trzeba było odtwarzać ich z Discorda lub starych wątków.

Uważam, że brak takiego podziału był jednym z głównych źródeł poprzedniego konfliktu, a stwierdzenie "moderatorzy, administracja" nie rozwiązuje tego problemu.

W poprzedniej dyskusji Kapuce zwrócił uwagę na jeszcze jeden aspekt, który moim zdaniem warto tutaj przypomnieć. Przez dłuższy czas projekt znajdował się w stanie, który można określić jako względnie stabilny, ale jednocześnie stagnacyjny. Późniejszy okres dużej liczby zmian był próbą przełamania tej stagnacji i ponownego przyspieszenia rozwoju projektu, ale odbywało się to kosztem większej niestabilności i ujawnienia problemów organizacyjnych, których wcześniej w takim stopniu nie było widać.
Nie oznacza to, że każda wprowadzona w tym okresie zmiana była dobra, że każda została przeprowadzona prawidłowo ani że pojawiające się regresje należy akceptować jako nieunikniony koszt rozwoju. Takie problemy należy normalnie zgłaszać i poprawiać.
Nie chciałbym jednak, abyśmy w efekcie poprzednich doświadczeń doszli do sytuacji, w której sposobem na zachowanie stabilności będzie ponowne unikanie większych zmian. Moim zdaniem celem powinno być znalezienie trzeciej drogi: projektu, który potrafi rozwijać się aktywnie, ale robi to w sposób przewidywalny, z jasno określonym procesem podejmowania decyzji, review i odpowiedzialnością za poszczególne obszary.
Właśnie temu miałyby służyć proponowane niżej zasady governance. Nie chodzi o ograniczenie rozwoju, ale o stworzenie warunków, w których rozwój nie musi oznaczać organizacyjnego chaosu.

W kilku sytuacjach pojawiał się zarzut, że jakaś decyzja została podjęta bez konsultacji. Problem polega na tym, że często nie było jednocześnie jasne, z kim taka konsultacja powinna się odbyć i kto ostatecznie miał prawo daną decyzję zatwierdzić albo odrzucić (patrz punkt wyżej). Forum powinno pozostać miejscem konsultacji i szerszej dyskusji, jednak przy braku jasno określonego sposobu zakończenia takiej dyskusji różnice zdań mogą prowadzić do długotrwałego braku decyzji i w praktyce blokować dalsze prace.
Jeżeli chcemy wymagać konsultowania decyzji, powinniśmy również jasno określić, kto posiada w danym obszarze kompetencje do ich podejmowania. Nie chodzi przy tym o tworzenie hierarchii, w której jedna osoba "rządzi" określonym elementem projektu. Nie chodzi również o przypisywanie komukolwiek obowiązku wykonywania jakiejś pracy.
W jednej z wcześniejszych dyskusji proponowałem wskazanie osób zajmujących się poszczególnymi obszarami projektu. Zosała wówczas interpretowana jako próba narzucenia komuś obowiązku pracy. Nie taki jest cel tej propozycji. Argumentem było to, że "naczelnicy" działów już kiedyś byli i pomysł nie wypalił.
MaSzyna jest projektem tworzonym w dużej mierze w wolnym czasie i oczywiste jest, że nikt nie może być zobowiązany do wykonania konkretnej pracy, naprawienia błędu czy poświęcenia określonej liczby godzin. Można jednak wskazać osoby, które:

  • mają największą wiedzę o konkretnym komponencie,
  • mogą reviewować dotyczące go zmiany,
  • uczestniczą w podejmowaniu decyzji architektonicznych,
  • mogą ocenić, czy proponowana zmiana jest zgodna z dalszym kierunkiem rozwoju.

Pełnienie takiej roli nie oznacza obowiązku wykonywania pracy ani wyłączności na rozwój danego komponentu. Każdy nadal powinien mieć możliwość przygotowania zmiany w dowolnej części projektu.
Dlatego zamiast mówić o "osobach odpowiedzialnych za wykonanie pracy", proponuję mówić o maintainerach lub opiekunach technicznych poszczególnych obszarów.

Przykładowe obszary mogłyby wyglądać następująco:

  • exe i architektura silnika,
  • renderer,
  • fizyka pojazdów,
  • systemy pojazdów,
  • narzędzia i skrypty,
  • formaty danych i kompatybilność contentu,
  • paczka i proces wydawania wersji,
  • infrastruktura serwerowa,
  • forum i sprawy społecznościowe.

Nie twierdzę, że dokładnie taki podział musi zostać przyjęty. Chodzi przede wszystkim o ustalenie zasady, według której wiadomo, kto posiada wiedzę i kompetencje decyzyjne w danym obszarze.

Jednocześnie powinno być jasno zapisane, że:

  • maintainer nie ma obowiązku wykonywania pracy,
  • maintainer nie musi być dostępny przez cały czas,
  • maintainer może w każdej chwili zrezygnować z tej roli,
  • obszar może tymczasowo nie posiadać maintainera, przy czym governance powinno określać sposób podejmowania decyzji w takiej sytuacji,
  • brak aktywności jednej osoby nie może na stałe blokować rozwoju danego komponentu.

Drugim elementem powinno być rozróżnienie decyzji technicznych od decyzji organizacyjnych. Nie każda zmiana powinna wymagać tego samego procesu.

Przykładowo:

  • poprawka błędu w rendererze,
  • refaktoryzacja fragmentu kodu,
  • zmiana wewnętrznej implementacji,
  • aktualizacja używanej biblioteki

nie powinny wymagać takiego samego poziomu konsultacji jak:

  • breaking change w formacie danych,
  • usunięcie publicznie używanej funkcjonalności,
  • zmiana procesu wydawniczego,
  • migracja dużej części infrastruktury,
  • zmiana zasad działania projektu lub forum.

Podobnie sytuacje awaryjne powinny mieć osobne zasady.
Jeżeli istnieje:

  • ryzyko utraty danych,
  • problem bezpieczeństwa,
  • poważna awaria,
  • niedostępność kluczowej usługi,

osoba administrująca danym systemem powinna mieć możliwość podjęcia potrzebnej decyzji bez oczekiwania kilku dni na pełną dyskusję.
Takie działania powinny być jednak później opisane, aby pozostałe osoby wiedziały, co zostało zmienione i dlaczego.
Chciałbym również, abyśmy zaczęli rozdzielać realne problemy techniczne od sporów organizacyjnych.
Przykładem może być obecny stan PBR. Po stronie exe sam system działa zgodnie z przyjętymi założeniami, natomiast część istniejących materiałów była przygotowana pod wcześniejsze zachowanie renderera i po zmianach pojawiły się regresje wizualne. Jest to realny problem, który należy poprawić. Powinien jednak funkcjonować jako konkretny problem techniczny opisany w bugtrackerze, z przykładami i możliwością jego naprawienia, a nie jako argument w dyskusji o tym, kto miał lub nie miał prawa rozwijać daną część projektu.
Tak samo powinniśmy traktować inne regresje.
Jeżeli zmiana coś psuje, zgłaszamy to, opisujemy i poprawiamy. Jeżeli rozwiązanie techniczne po czasie okazuje się nietrafione, możemy się z niego wycofać. Nie oznacza to automatycznie, że samo podjęcie decyzji o jego przetestowaniu było błędem organizacyjnym. Jako konkretny rezultat tej dyskusji proponuję utworzenie w repozytorium na githubie pliku: "GOVERNANCE.md". Dokument nie musiałby być szczególnie długi ani próbować przewidywać każdej możliwej sytuacji. Powinien opisywać przede wszystkim:

  1. główne obszary projektu,
  2. sposób wskazywania maintainerów lub opiekunów technicznych,
  3. zakres ich kompetencji,
  4. zasady review i merge pull requestów,
  5. rodzaje zmian wymagających szerszej konsultacji,
  6. sposób rozwiązywania sporów technicznych,
  7. zasady postępowania w sytuacjach awaryjnych,
  8. sposób dokumentowania większych decyzji,
  9. sposób zmiany samych zasad governance.

Obok niego można utworzyć prosty plik: "MAINTAINERS.md" z aktualną listą osób zajmujących się poszczególnymi obszarami. Dzięki temu zmiana osoby zajmującej się konkretnym komponentem nie wymagałaby edytowania całego dokumentu zasad. Na forum proponuję natomiast stworzyć przypięty wątek zawierający skróconą wersję zasad oraz odnośnik do aktualnego GOVERNANCE.md. Repozytorium byłoby w takim układzie źródłem aktualnych zasad, natomiast forum pozostawałoby miejscem ich omawiania. Zmiany samego "GOVERNANCE.md" również powinny przechodzić normalnie przez pull request i review. Dzięki temu wszystkie zmiany sposobu zarządzania projektem byłyby jawne, możliwe do przedyskutowania i miałyby zachowaną historię.

Nie proponuję tego po to, aby zwiększać formalizm projektu, a wręcz przeciwnie. Obecnie część zasad istnieje wyłącznie jako zwyczaj, część jako ustalenia z Discorda, część jako wcześniejsze decyzje konkretnych osób, a część nie istnieje w ogóle. Kilka prostych i jasno zapisanych zasad może ograniczyć ilość formalności, ponieważ nie będzie trzeba za każdym razem od początku ustalać, kto powinien podjąć konkretną decyzję. Nie chciałbym również, aby efektem tego wątku było ponowne analizowanie przez kilkadziesiąt postów wydarzeń sprzed kilku miesięcy. Jeżeli mamy z niego coś wynieść, dobrze byłoby zakończyć go konkretnym rezultatem.

Moja propozycja jest więc następująca:

  1. ustalamy podstawowy podział obszarów projektu,
  2. definiujemy rolę maintainera bez nakładania obowiązku pracy,
  3. ustalamy, które decyzje mogą być podejmowane lokalnie, a które wymagają szerszej konsultacji,
  4. zapisujemy proces review,
  5. ustalamy sposób działania w sytuacjach awaryjnych,
  6. spisujemy to w "GOVERNANCE.md" na githubie,
  7. publikujemy skrót zasad w przypiętym wątku na forum.

Nie traktuję przedstawionych wyżej punktów jako gotowego regulaminu. To jest propozycja punktu wyjścia do dyskusji.
Chciałbym jednak, aby tym razem jej efektem były konkretne, zapisane zasady, do których za pół roku każdy będzie mógł się odwołać, zamiast kolejnej sytuacji, w której dopiero po wykonaniu jakiejś zmiany zaczynamy zastanawiać się, kto właściwie miał prawo podjąć decyzję.

W związku ze spadkiem liczby aktywnych twórców zawartości proponuję rozszerzenie obecnego systemu issue oraz lepsze wyeksponowanie możliwości współpracy. ## Nowe oznaczenia issue - Trudność - łatwe - umiarkowane - trudne - Dodatkowe - materiały dostępne - dostępny mentor - dobre na początek Oznaczenia pozwolą osobom zainteresowanym pomocą łatwo znaleźć zadania odpowiadające ich umiejętnościom. ## Informacja o możliwości współpracy Na forum, Discordzie oraz GitHubie powinno zostać utworzone widoczne miejsce opisujące możliwości wsparcia projektu. Dla nowych twórców zawartości głównym punktem wejścia powinien być odnośnik do przefiltrowanej listy issue oznaczonych dobre na początek. Należy również krótko opisać: - sposób przesyłania nowej zawartości przez upload.eu07.pl, - działanie procedury testów, - podstawowe wymagania dotyczące przygotowywanej zawartości. Dokumentacja dla początkujących powinna zawierać skrócone wytyczne i odsyłać do pełnej dokumentacji dopiero w razie potrzeby. ## Procedura testowania Dla nowej zawartości pozostaje obecna procedura: - minimum 1 tydzień testów, - 2 tygodnie w przypadku braku odpowiedzi testerów. Drobne poprawki istniejącej zawartości przesłane przez osoby zewnętrzne mogłyby korzystać z uproszczonej procedury, np. poprzez załączenie paczki ZIP bezpośrednio do odpowiedniego issue. Po sprawdzeniu poprawki maintainer mógłby wprowadzić ją do SVN bez konieczności upływu okresu tygodnia/dwóch. Procedura uproszczona dotyczyłaby wyłącznie niewielkich poprawek istniejącej zawartości, a nie nowych modeli, pojazdów, scenerii czy innych większych zmian. # Przyczyna propzycji Od 2020 roku widoczna jest długoterminowa tendencja spadkowa aktywności w repozytorium SVN. Nie wydaje się, aby jej główną przyczyną był obecny sposób przesyłania i testowania zawartości. Znacznie większym problemem jest stopniowe zmniejszanie się liczby regularnie aktywnych twórców oraz brak wystarczającego napływu nowych osób. Obecny system przyjmowania dodatków funkcjonuje i nie wymaga zasadniczej przebudowy. Brakuje natomiast nowoczesnej i łatwo dostępnej informacji o tym, w jaki sposób można rozpocząć współpracę, czego obecnie projekt potrzebuje oraz gdzie znaleźć zadania odpowiednie dla nowych osób. GitHub i Discord są obecnie naturalnymi miejscami, do których trafiają potencjalni nowi contributorzy. Informacja o możliwości współpracy powinna być jednak dostępna również na forum, stronie głównej projektu oraz, w miarę możliwości, na stronach MaSzyny na platformach dystrybucyjnych, takich jak Steam, Epic Games Store czy GOG. Dane z historii SVN pokazują wyraźną zmianę skali aktywności: Rok | Commity | Aktywni committerzy | ≥20 commitów | Dni z commitem | Przerwy >2 dni -- | -- | -- | -- | -- | -- 2018 | 1216 | 26 | 14 | 312 | 14 **2019** | 1622 | 34 | 15 | **343** | 4 **2020** | **1687** | 32 | 15 | 337 | 4 2021 | 1004 | 24 | 9 | 304 | 21 2022 | 865 | 29 | 10 | 253 | 35 2023 | 291 | 18 | 5 | 153 | 60 2024 | 247 | 13 | 5 | 115 | 56 2025 | 315 | 18 | 6 | 144 | 60 2026* | 201 | 18 | 3 | 104 | 39 Rok 2020 był szczytem aktywności w analizowanym okresie, z 1687 commitami i 337 dniami, w których pojawiła się przynajmniej jedna zmiana. Spadek rozpoczyna się wyraźnie w 2021 roku, natomiast szczególnie silne ograniczenie aktywności następuje w drugiej połowie 2022 roku i jest w pełni widoczne od 2023 roku. Dla zobrazowania: ![image.png](/attachments/fc56969d-4f80-4dd0-ab78-43e788260bb6) Przebieg drugiej połowy 2022 roku dobrze pokazuje moment załamania: ``` 2022-01 116 2022-02 152 2022-03 85 2022-04 91 ... 2022-08 79 2022-09 45 2022-10 28 2022-11 33 2022-12 19 ``` Jednocześnie porównanie aktywności do 24 sierpnia każdego roku pokazuje, że 2026 nie jest najsłabszym rokiem całego okresu: ![image.png](/attachments/5135c174-6c54-4625-a747-5aaeaa719304) Nie chodzi więc o próbę powrotu do dawnej liczby commitów poprzez zwiększanie obciążenia obecnych twórców. Celem powinno być odbudowanie dopływu nowych contributorów poprzez ułatwienie im znalezienia zadań, poznania podstawowych zasad projektu oraz wykonania pierwszej niewielkiej zmiany. Proponowane oznaczenia issue, skrócona dokumentacja dla początkujących i lepsze wyeksponowanie możliwości współpracy mają przede wszystkim stworzyć czytelną ścieżkę: zainteresowanie projektem > znalezienie odpowiedniego zadania > wykonanie pierwszej zmiany > przesłanie jej do projektu > test/review > dalsza współpraca. # Drugi wątek Od poprzedniej dyskusji dotyczącej sposobu prowadzenia projektu minęło już kilka miesięcy. Emocje zdążyły opaść, część spraw można dziś ocenić z większym dystansem, a przede wszystkim mamy możliwość sprawdzenia, co faktycznie udało się od tamtej pory zmienić. Dodatkowym argumentem za uporządkowaniem tych kwestii jest potrzeba zapewnienia ciągłości działania projektu niezależnie od aktualnego składu osób pełniących poszczególne role. Nie chciałbym w tym miejscu rozstrzygać powodów, dla których ktoś ogranicza swoją aktywność, rezygnuje z pełnionej funkcji albo przestaje uczestniczyć w projekcie. Istotne jest natomiast to, aby taka sytuacja nie powodowała jednocześnie utraty wiedzy o sposobie podejmowania decyzji ani powrotu do niejasnego podziału kompetencji. Nie chciałbym również wracać do poprzedniej dyskusji po to, aby ponownie ustalać, kto miał rację, kto czego nie zrobił albo kto powinien był zachować się inaczej. Moim zdaniem znacznie bardziej użyteczne będzie zastanowienie się, czy problemy, które wtedy ujawniły się w projekcie, zostały rzeczywiście rozwiązane i co możemy zrobić, żeby podobna sytuacja nie powtórzyła się za kilka miesięcy. Spisanie podstawowych zasad pozwoliłoby zachować ciągłość działania projektu również w przypadku zmian personalnych, niezależnie od ich przyczyn. Od tamtego czasu wprowadziliśmy kilka konkretnych zmian: - pull request wymaga obecnie co najmniej jednego review przed merge, - powstał git.eu07.pl, który służy między innymi jako bugtracker całej paczki. - Jakub oraz Zielu zostali nowymi administratorami - Miłosz pozostał głównym administratorem Zmiany te uważam za potrzebne, jednak nie rozwiązały one w pełni problemu niejasnego podziału kompetencji i sposobu podejmowania decyzji. Jednocześnie poza nimi sposób podejmowania decyzji i organizacji pracy w projekcie pozostał w dużej mierze taki sam jak wcześniej. W dalszym ciągu nie mamy jasno określonego: - kto podejmuje decyzje dotyczące poszczególnych części projektu, - które decyzje techniczne mogą być podejmowane przez osoby rozwijające dany komponent, - które zmiany wymagają szerszej konsultacji, - kto powinien reviewować zmiany dotyczące konkretnych obszarów, - co robimy w sytuacji, gdy osoby mające wiedzę o danym komponencie nie są aktywne, - jak rozstrzygamy spory techniczne, - jak podejmujemy decyzje dotyczące infrastruktury, - jak postępujemy w sytuacjach awaryjnych, - gdzie zapisujemy większe ustalenia, aby po kilku miesiącach nie trzeba było odtwarzać ich z Discorda lub starych wątków. Uważam, że brak takiego podziału był jednym z głównych źródeł poprzedniego konfliktu, a stwierdzenie "moderatorzy, administracja" nie rozwiązuje tego problemu. W poprzedniej dyskusji Kapuce zwrócił uwagę na jeszcze jeden aspekt, który moim zdaniem warto tutaj przypomnieć. Przez dłuższy czas projekt znajdował się w stanie, który można określić jako względnie stabilny, ale jednocześnie stagnacyjny. Późniejszy okres dużej liczby zmian był próbą przełamania tej stagnacji i ponownego przyspieszenia rozwoju projektu, ale odbywało się to kosztem większej niestabilności i ujawnienia problemów organizacyjnych, których wcześniej w takim stopniu nie było widać. Nie oznacza to, że każda wprowadzona w tym okresie zmiana była dobra, że każda została przeprowadzona prawidłowo ani że pojawiające się regresje należy akceptować jako nieunikniony koszt rozwoju. Takie problemy należy normalnie zgłaszać i poprawiać. Nie chciałbym jednak, abyśmy w efekcie poprzednich doświadczeń doszli do sytuacji, w której sposobem na zachowanie stabilności będzie ponowne unikanie większych zmian. Moim zdaniem celem powinno być znalezienie trzeciej drogi: projektu, który potrafi rozwijać się aktywnie, ale robi to w sposób przewidywalny, z jasno określonym procesem podejmowania decyzji, review i odpowiedzialnością za poszczególne obszary. Właśnie temu miałyby służyć proponowane niżej zasady governance. Nie chodzi o ograniczenie rozwoju, ale o stworzenie warunków, w których rozwój nie musi oznaczać organizacyjnego chaosu. W kilku sytuacjach pojawiał się zarzut, że jakaś decyzja została podjęta bez konsultacji. Problem polega na tym, że często nie było jednocześnie jasne, z kim taka konsultacja powinna się odbyć i kto ostatecznie miał prawo daną decyzję zatwierdzić albo odrzucić (patrz punkt wyżej). Forum powinno pozostać miejscem konsultacji i szerszej dyskusji, jednak przy braku jasno określonego sposobu zakończenia takiej dyskusji różnice zdań mogą prowadzić do długotrwałego braku decyzji i w praktyce blokować dalsze prace. Jeżeli chcemy wymagać konsultowania decyzji, powinniśmy również jasno określić, kto posiada w danym obszarze kompetencje do ich podejmowania. Nie chodzi przy tym o tworzenie hierarchii, w której jedna osoba "rządzi" określonym elementem projektu. Nie chodzi również o przypisywanie komukolwiek obowiązku wykonywania jakiejś pracy. W jednej z wcześniejszych dyskusji proponowałem wskazanie osób zajmujących się poszczególnymi obszarami projektu. Zosała wówczas interpretowana jako próba narzucenia komuś obowiązku pracy. Nie taki jest cel tej propozycji. Argumentem było to, że "naczelnicy" działów już kiedyś byli i pomysł nie wypalił. MaSzyna jest projektem tworzonym w dużej mierze w wolnym czasie i oczywiste jest, że nikt nie może być zobowiązany do wykonania konkretnej pracy, naprawienia błędu czy poświęcenia określonej liczby godzin. Można jednak wskazać osoby, które: - mają największą wiedzę o konkretnym komponencie, - mogą reviewować dotyczące go zmiany, - uczestniczą w podejmowaniu decyzji architektonicznych, - mogą ocenić, czy proponowana zmiana jest zgodna z dalszym kierunkiem rozwoju. Pełnienie takiej roli nie oznacza obowiązku wykonywania pracy ani wyłączności na rozwój danego komponentu. Każdy nadal powinien mieć możliwość przygotowania zmiany w dowolnej części projektu. Dlatego zamiast mówić o "osobach odpowiedzialnych za wykonanie pracy", proponuję mówić o maintainerach lub opiekunach technicznych poszczególnych obszarów. Przykładowe obszary mogłyby wyglądać następująco: - exe i architektura silnika, - renderer, - fizyka pojazdów, - systemy pojazdów, - narzędzia i skrypty, - formaty danych i kompatybilność contentu, - paczka i proces wydawania wersji, - infrastruktura serwerowa, - forum i sprawy społecznościowe. Nie twierdzę, że dokładnie taki podział musi zostać przyjęty. Chodzi przede wszystkim o ustalenie zasady, według której wiadomo, kto posiada wiedzę i kompetencje decyzyjne w danym obszarze. Jednocześnie powinno być jasno zapisane, że: - maintainer nie ma obowiązku wykonywania pracy, - maintainer nie musi być dostępny przez cały czas, - maintainer może w każdej chwili zrezygnować z tej roli, - obszar może tymczasowo nie posiadać maintainera, przy czym governance powinno określać sposób podejmowania decyzji w takiej sytuacji, - brak aktywności jednej osoby nie może na stałe blokować rozwoju danego komponentu. Drugim elementem powinno być rozróżnienie decyzji technicznych od decyzji organizacyjnych. Nie każda zmiana powinna wymagać tego samego procesu. Przykładowo: - poprawka błędu w rendererze, - refaktoryzacja fragmentu kodu, - zmiana wewnętrznej implementacji, - aktualizacja używanej biblioteki nie powinny wymagać takiego samego poziomu konsultacji jak: - breaking change w formacie danych, - usunięcie publicznie używanej funkcjonalności, - zmiana procesu wydawniczego, - migracja dużej części infrastruktury, - zmiana zasad działania projektu lub forum. Podobnie sytuacje awaryjne powinny mieć osobne zasady. Jeżeli istnieje: - ryzyko utraty danych, - problem bezpieczeństwa, - poważna awaria, - niedostępność kluczowej usługi, osoba administrująca danym systemem powinna mieć możliwość podjęcia potrzebnej decyzji bez oczekiwania kilku dni na pełną dyskusję. Takie działania powinny być jednak później opisane, aby pozostałe osoby wiedziały, co zostało zmienione i dlaczego. Chciałbym również, abyśmy zaczęli rozdzielać realne problemy techniczne od sporów organizacyjnych. Przykładem może być obecny stan PBR. Po stronie exe sam system działa zgodnie z przyjętymi założeniami, natomiast część istniejących materiałów była przygotowana pod wcześniejsze zachowanie renderera i po zmianach pojawiły się regresje wizualne. Jest to realny problem, który należy poprawić. Powinien jednak funkcjonować jako konkretny problem techniczny opisany w bugtrackerze, z przykładami i możliwością jego naprawienia, a nie jako argument w dyskusji o tym, kto miał lub nie miał prawa rozwijać daną część projektu. Tak samo powinniśmy traktować inne regresje. Jeżeli zmiana coś psuje, zgłaszamy to, opisujemy i poprawiamy. Jeżeli rozwiązanie techniczne po czasie okazuje się nietrafione, możemy się z niego wycofać. Nie oznacza to automatycznie, że samo podjęcie decyzji o jego przetestowaniu było błędem organizacyjnym. Jako konkretny rezultat tej dyskusji proponuję utworzenie w repozytorium na githubie pliku: "GOVERNANCE.md". Dokument nie musiałby być szczególnie długi ani próbować przewidywać każdej możliwej sytuacji. Powinien opisywać przede wszystkim: 1. główne obszary projektu, 2. sposób wskazywania maintainerów lub opiekunów technicznych, 3. zakres ich kompetencji, 4. zasady review i merge pull requestów, 5. rodzaje zmian wymagających szerszej konsultacji, 6. sposób rozwiązywania sporów technicznych, 7. zasady postępowania w sytuacjach awaryjnych, 8. sposób dokumentowania większych decyzji, 9. sposób zmiany samych zasad governance. Obok niego można utworzyć prosty plik: "MAINTAINERS.md" z aktualną listą osób zajmujących się poszczególnymi obszarami. Dzięki temu zmiana osoby zajmującej się konkretnym komponentem nie wymagałaby edytowania całego dokumentu zasad. Na forum proponuję natomiast stworzyć przypięty wątek zawierający skróconą wersję zasad oraz odnośnik do aktualnego `GOVERNANCE.md`. Repozytorium byłoby w takim układzie źródłem aktualnych zasad, natomiast forum pozostawałoby miejscem ich omawiania. Zmiany samego "GOVERNANCE.md" również powinny przechodzić normalnie przez pull request i review. Dzięki temu wszystkie zmiany sposobu zarządzania projektem byłyby jawne, możliwe do przedyskutowania i miałyby zachowaną historię. Nie proponuję tego po to, aby zwiększać formalizm projektu, a wręcz przeciwnie. Obecnie część zasad istnieje wyłącznie jako zwyczaj, część jako ustalenia z Discorda, część jako wcześniejsze decyzje konkretnych osób, a część nie istnieje w ogóle. Kilka prostych i jasno zapisanych zasad może ograniczyć ilość formalności, ponieważ nie będzie trzeba za każdym razem od początku ustalać, kto powinien podjąć konkretną decyzję. Nie chciałbym również, aby efektem tego wątku było ponowne analizowanie przez kilkadziesiąt postów wydarzeń sprzed kilku miesięcy. Jeżeli mamy z niego coś wynieść, dobrze byłoby zakończyć go konkretnym rezultatem. Moja propozycja jest więc następująca: 1. ustalamy podstawowy podział obszarów projektu, 2. definiujemy rolę maintainera bez nakładania obowiązku pracy, 3. ustalamy, które decyzje mogą być podejmowane lokalnie, a które wymagają szerszej konsultacji, 4. zapisujemy proces review, 5. ustalamy sposób działania w sytuacjach awaryjnych, 6. spisujemy to w "GOVERNANCE.md" na githubie, 7. publikujemy skrót zasad w przypiętym wątku na forum. Nie traktuję przedstawionych wyżej punktów jako gotowego regulaminu. To jest propozycja punktu wyjścia do dyskusji. Chciałbym jednak, aby tym razem jej efektem były konkretne, zapisane zasady, do których za pół roku każdy będzie mógł się odwołać, zamiast kolejnej sytuacji, w której dopiero po wykonaniu jakiejś zmiany zaczynamy zastanawiać się, kto właściwie miał prawo podjąć decyzję.
image.png
64 KiB
image.png
47 KiB
Hirek changed title from Unowocześnienie issue trackera dla new comerów. to Unowocześnienie issue trackera dla new comerów + analiza aktywności 2026-09-09 11:09:27 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
!important
Do oznaczania ważnych kwestii
 błąd
Błąd w symulatorze
 cleanup
Usuwanie zawartości lub funkcjonalności, porządki
 duplikat
Ten błąd był już zgłoszony
 exe/edytor
Exe - sprawy dotyczące edytora
 exe/fizyka
Exe - fizyka jazdy lub obsługa pojazdu
 exe/renderer
Exe - sprawy dotyczące renderera
 exe/rozgrywka
Exe - dotyczące stanów symulatora, ogólnotechniczne
 feature
propozycja usprawnienia/nowości
 odrzucone
Ten wątek nie będzie prowadzony dalej
 repo/dzwieki
Dotyczy dźwięków w symulatorze
 repo/model
Dotyczy modelu pojazdu/otoczenia
 repo/ogólne
Repo - sprawy ogólne
 repo/pojazdy
Dotyczy plików pojazdów - mmd/fiz/textures.txt - innych rzeczy pojazdowych nie kwalifikujących się do modlei/dzwiekow/tekstur
 repo/python
Dotyczy skryptów pythonowych
 repo/scenariusze
Dotyczy scenariuszy
 repo/scenerie
Dotyczy scenerii
 repo/tekstury
Dotyczy tekstur
 www/forum
Dotyczy forum
 www/git
Dotyczy portalu zgłoszeń
 www/strona-glowna
Dotyczy strony głównej eu07.pl
 www/upload
Dotyczy uploadu
 www/wiki
Dotyczy wiki.eu07.pl
No Label !important feature repo/ogólne www/forum www/git www/strona-glowna www/wiki
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
daniu danniel DieselPower DzordZ fuji8 Hirek Iwan-XXI jakubg1 Kermit Kogut macius5991 MichauSto MiloszDorsz spot57 Turbokibel x_Zielu
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: eu07/maszyna#526
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?