Autor Wątek:  Potencjalne zmiany w zarządzaniu projektem  (Przeczytany 3431 razy)

0 użytkowników i 1 Gość przegląda ten wątek.

Offline tor424

  • Wiadomości: 128
  • Spokojny człowiek
    • Zobacz profil
    • Wielkopolska galeria kolejowa.
  • Otrzymane polubienia: 57
Odp: Potencjalne zmiany w zarządzaniu projektem
« Odpowiedź #30 dnia: 10 Sierpnia 2023, 12:47:14 »
Należy iść z duchem czasu i stworzyć oficjalnego discorda, gdzie byłaby administracja, wytypowani moderatorzy do zarządzania treścią na discordzie, a developerzy tak samo jak i w tamtym projekcie będą mieli wyróżnienie w postaci rangi na forum czy discordzie. Tam też każdy robi za darmo bo to projekt open source darmowy. Jedyną nagrodą jest wyróżnienie rangą na discordzie bo na foorum trzeba się mocno postarać i wpis do autorów. Przecież discord dzisiaj to najpopularniejszy środek komunikacji, niż jakiś mattermost czy irc.

No ale co to ma dać, co to zmienia? Discord nie jest czytelny do takich rzeczy i szczerze nie wiem po co by był. Ot kolejna platforma, gdzie trzeba by było śledzić, by przypadkiem czegoś nie przegapić.

Taka ciekawostka z takiej innej gierki - Simrail. Oni mają forum, Discorda i FB. Jak zaczęli pokazywać nowości tylko na Discordzie i FB to widziałem głosy niezadowolenia na forum czemu te wiadomości się tam nie pojawiały. Od tego jest właśnie forum - jedno miejsce do dyskusji i publikacji, a reszta jak np. FB to tylko dodatki informacyjne pokazujące to co jest dostępne na forum, nie na odwrót.

Absolutnie nie chodzi mi, aby zastąpić forum discordem. Bardziej mam na myśli, że był taki luźny chat na mattermost, który został zamknięty przez spiny. W dodatku projekt, który wskazałem jeśli chodzi o dyskusje to używa głównie discorda - Forum służy do poradników, pytań, ogłoszeń, nowości itp. Discord również ma kanały z pomocą techniczną itd.

Można pogodzić forum z discordem. Chyba MaSzyna powinna celować w młodych bo SimRaila ma kto rozwijać, a tutaj nie ma nieemalże nikogo. Przyszłość tego projektu skupia się na zachęcaniu nowych i młodych osób do rozwijania go. Wiem, że to tworzono jako grupka pasjonatów, ale czasy się zmieniają niestety i należy iść z duchem czasu i postępami. Jeśli ktoś nie lubi nowinek to zawsze może pozostać przy forum
Pasjonat elektroniki, informatyki i programowania - C++,C#,Lua i reverse engineering

Offline matek123

  • Moderator
  • Wiadomości: 5861
    • Zobacz profil
  • Otrzymane polubienia: 1895
Odp: Potencjalne zmiany w zarządzaniu projektem
« Odpowiedź #31 dnia: 10 Sierpnia 2023, 18:19:29 »
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.

Poszukuję zdjęć na tekstury pociągów sieciowych. Szczególnie platform z pomostami.

Offline Kalikowsky

  • Zasłużony dla Symulatora
  • Wiadomości: 115
  • Citizen.
    • Zobacz profil
  • Otrzymane polubienia: 56
Odp: Potencjalne zmiany w zarządzaniu projektem
« Odpowiedź #32 dnia: 11 Sierpnia 2023, 05:45:09 »
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.

Offline jakubg1

  • Wydział Repozytorium
  • Wiadomości: 1430
  • MaSzyna ma szynę, szyna ma MaSzynę - na kołach.
    • Zobacz profil
  • Otrzymane polubienia: 1004
Odp: Potencjalne zmiany w zarządzaniu projektem
« Odpowiedź #33 dnia: 13 Sierpnia 2023, 21:08:12 »
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).
« Ostatnia zmiana: 13 Sierpnia 2023, 21:15:49 wysłana przez jakubg1 »
10 lat na forum MaSzyny!

Offline marcinn

  • Wiadomości: 61
    • Zobacz profil
  • Otrzymane polubienia: 62
Odp: Potencjalne zmiany w zarządzaniu projektem
« Odpowiedź #34 dnia: 04 Września 2023, 20:45:38 »
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.
« Ostatnia zmiana: 04 Września 2023, 23:08:54 wysłana przez marcinn »

Offline jakubg1

  • Wydział Repozytorium
  • Wiadomości: 1430
  • MaSzyna ma szynę, szyna ma MaSzynę - na kołach.
    • Zobacz profil
  • Otrzymane polubienia: 1004
Odp: Potencjalne zmiany w zarządzaniu projektem
« Odpowiedź #35 dnia: 05 Września 2023, 02:38:02 »
- 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.
10 lat na forum MaSzyny!

Offline mk1991

  • Deweloper
  • Wiadomości: 647
  • Niech żyje EU43!
    • Zobacz profil
  • Otrzymane polubienia: 250
Odp: Potencjalne zmiany w zarządzaniu projektem
« Odpowiedź #36 dnia: 12 Września 2023, 14:07:28 »
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.
Prawda jest okruchem lodu.

Offline marcinn

  • Wiadomości: 61
    • Zobacz profil
  • Otrzymane polubienia: 62
Odp: Potencjalne zmiany w zarządzaniu projektem
« Odpowiedź #37 dnia: 12 Września 2023, 14:24:53 »
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.

Offline matek123

  • Moderator
  • Wiadomości: 5861
    • Zobacz profil
  • Otrzymane polubienia: 1895
Odp: Potencjalne zmiany w zarządzaniu projektem
« Odpowiedź #38 dnia: 12 Września 2023, 21:09:06 »
Próbowałeś korzystać z wbudowanego startera? Po usunięciu z eu07.ini  linijki 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
Poszukuję zdjęć na tekstury pociągów sieciowych. Szczególnie platform z pomostami.

Offline Milek7

  • Administrator ds. Technicznych
  • Wiadomości: 1038
    • Zobacz profil
  • Otrzymane polubienia: 870
Odp: Potencjalne zmiany w zarządzaniu projektem
« Odpowiedź #39 dnia: 14 Września 2023, 16:31:10 »
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.

Offline Milek7

  • Administrator ds. Technicznych
  • Wiadomości: 1038
    • Zobacz profil
  • Otrzymane polubienia: 870
Odp: Potencjalne zmiany w zarządzaniu projektem
« Odpowiedź #40 dnia: 26 Września 2023, 22:09:11 »
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
« Ostatnia zmiana: 26 Września 2023, 22:13:43 wysłana przez Milek7 »

Offline jakubg1

  • Wydział Repozytorium
  • Wiadomości: 1430
  • MaSzyna ma szynę, szyna ma MaSzynę - na kołach.
    • Zobacz profil
  • Otrzymane polubienia: 1004
Odp: Potencjalne zmiany w zarządzaniu projektem
« Odpowiedź #41 dnia: 26 Września 2023, 23:27:06 »
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.
10 lat na forum MaSzyny!