- Symulator MaSzyna -
Symulator EU07 (i nie tylko) => Bieżące Symulatorowe => Wątek zaczęty przez: Milek7 w 09 Sierpnia 2023, 04:48:04
-
Ten post jest odpowiedzią na powracające wciąż żądania, żeby przyznać innej osobie stanowisko administratora. Jest to prezentowane przez część osób aktywnych w projekcie jako panaceum na wszelkie problemy z którymi od dłuższego czasu boryka się projekt MaSzyny w sferze zarządzania.
Faktem jest, że w ostatnim okresie część członków administracji zrezygnowała ze stanowiska, a moja aktywność jest niewielka. Nie jestem jednak skłonny nominować nowych administratorów, zarówno ze względu na ostatnie doświadczenia z przyznawaniem dostępów osobom które nadwyrężyły nasze zaufanie, jak i moje przekonanie że żonglowanie rangami nie wprowadzi realnej zmiany jakościowej.
Podnosi się argument że nowa administracja miałaby ożywić projekt, jednak w jaki sposób miałoby się to wydarzyć? Przecież nie jest wymagane aprobata od administratora, żeby poprawiać błędy, tworzyć nową zawartość czy wprowadzać zmiany w exe.
W celu uregulowania tej sytuacji, chciałbym zaproponować pewne zmiany w funkcjonowaniu projektu. Niezmiennie od początku mojej aktywności jestem przeciwnikiem specjalnych stanowisk, ukrytych działów, limitu postów w działach, czy innych rozwiązań ograniczających transparentność (i co za tym idzie, ilość afer związanych z dostępem do ukrytej treści i wycieków stamtąd) jak i uniemożliwiających pełne zaangażowania nowych osób bez zbędnych przeszkód.
Proponuję więc:
- Zlikwidowanie działów niepublicznych (deweloperów, betatesterów, repozytorium, promocji, webmasterów, promotorów). Nie pełnią one istotnej funkcji, poza możliwością bycia punktem niezdrowych konfliktów. Należałoby tu zrobić przegląd zawartych w nich treści i wyciągniecie tego co możemy wykorzystać (są odpowiednie zgody itd.) do działów publicznych. Reszty, skoro i tak nie można wykorzystać niech zostanie jedynie w czeluściach archiwum serwera, bez ogólnego dostępu.
- Utworzenie zespołu składającego się z kilkunastu osób z doświadczeniem w projekcie, którego głównym zadaniem byłaby akceptacja zmian wprowadzanych na repozytorium symulatora. Nie wiązałoby się to z żadnymi dodatkowymi benefitami czy dostępem.
- Wprowadzenie przejrzystej procedury wprowadzania zmian na repozytorium, w formie zbliżonej do obecnego testu dodatków. Zmiany wymagałaby akceptacji przez powyższy zespół, np. przez aprobatę N jego członków.
- Zespół mógłby w jakiś sposób dodawać nowych członków, np. przez nominację przez N jego członków i następnie głosowanie większością.
- Dodawanie treści na mediach społecznościowych również przechodziłoby proces aprobaty tak samo jak dla zmian repo, zaakceptowany post wstawiany byłby na platformę przez administrację/moderację, ale to byłaby czynność jedynie techniczna.
- Aktualizacji repozytorium po zaakceptowaniu zmian dokonywałaby również administracja, moderacja i wyznaczone przez nią osoby, ale to byłaby czynność jedynie techniczna. Docelowo powinno zostać opracowane narzędzia które to zautomatyzują.
- Wprowadzony zostałby stały cykl wydawniczy paczki, w którym terminy byłyby ściśle określone, np. miesięczne czy kwartalne. Zawierałyby stan repozytorium na dany dzień, bez osobnej fazy wydawniczej, testów, przesuwania terminów bo coś się nie załapało, itd. Publikacją paczki zajmowała by się administracja i moderacja (w obecnej sytuacji pewnie ja), do momentu przygotowania narzędzi które będą to robić automatycznie.
- Administracja i wyznaczeni przez nich moderatorzy czuwaliby nad zachowaniem kultury wypowiedzi. Zasadniczym wyzwaniem jest niedopuszczenie do eskalacji wszelkich dymów i zatrzymanie ich na samym początku. Jeżeli regulamin jest w tych kwestiach niewystarczająco jasny, może warto wprowadzić dodatkowy CoC.
Oczywiście to tylko wstępny zarys propozycji. Jeżeli opinia społeczności byłaby pozytywna, to trzeba przygotować uszczegółowione zasady, w szczególności w zakresie sposobu akceptacji, głosowania/aprobaty N osób, sposobu nominacji nowych członków, sposobu wyboru początkowych członków zespołu itd. Zachęcam do propozycji w tym zakresie.
-
Biorąc pod uwagę to co dzieje się od kilku miesięcy, taki plan jest chyba wystarczający, powinien zlikwidować spory. Chociaż osobiście uważam że odsłonięcie działów specjalnych sprawi że znowu stanie się pobieralnią dodatków, to warto podjąc jakieś kroki w kierunku ponownego rozpędzenia projektu. W razie co zawsze będzie można wrócić do tego co było przed.
-
"Zlikwidowanie działów niepublicznych (deweloperów, betatesterów, repozytorium, promocji, webmasterów, promotorów). Nie pełnią one istotnej funkcji" - no moim zdaniem jednak pełnią, za swojej kadencji nie miałem styczności z żadną sytuacją, w której o te działy były kłótnie, za to można wstawić rzeczy do dokończenia, można wstępnie testować przez osoby bardziej kompetentne niż szary użytkownik, ja np. odkopuję w starych wątkach materiały na tekstury pojazdów, które wyszły już X lat temu.
"Należałoby tu zrobić przegląd zawartych w nich treści i wyciągniecie tego co możemy wykorzystać (są odpowiednie zgody itd.) do działów publicznych. Reszty, skoro i tak nie można wykorzystać niech zostanie jedynie w czeluściach archiwum serwera, bez ogólnego dostępu." - wykorzystać to my możemy tam większość rzeczy. Taka mała sugestia - te rzeczy nie bez powodu siedzą w zamkniętych działach, modele niedokończone, materiały, które w założeniu miały być udostępnione małej ilości osób - to wszystko w mojej subiektywnej opinii nie powinno być dostępne dla każdego, jest to po prostu głupie.
"Utworzenie zespołu składającego się z kilkunastu osób z doświadczeniem w projekcie, którego głównym zadaniem byłaby akceptacja zmian wprowadzanych na repozytorium symulatora. Nie wiązałoby się to z żadnymi dodatkowymi benefitami czy dostępem." - a rozwój symulatora? Komu to potrzebne, zatwierdzanie rzeczy z testu dodatków (który został otworzony właśnie po to, żeby nie było do tego tak wąskiej liczby osób) do repo, to jest to. Przecież to brzmi jak zaprzeczenie testu dodatków dla wszystkich, żeby testowali, skoro i tak ktoś z wyznaczonej grupy musi to przejrzeć i zatwierdzić. To by zrównało rolę testu dodatków do pobieralni, bo i tak nie ważne co stestujesz, ostateczne zdanie należy do kogoś innego xd
Ponadto - jak chcesz zachęcać nowe osoby do tworzenia? Brakiem benefitów czy nawet głupiego napisu przy nicku?
"Wprowadzenie przejrzystej procedury wprowadzania zmian na repozytorium, w formie zbliżonej do obecnego testu dodatków. Zmiany wymagałaby akceptacji przez powyższy zespół, np. przez aprobatę N jego członków" - To my chcemy zaorać test dodatków? Chyba właśnie po to został otworzony, żeby miał kto to testować, a nie teraz zamykać i robić kopię, ale dla jakieś rady XD
"Zespół mógłby w jakiś sposób dodawać nowych członków, np. przez nominację przez N jego członków i następnie głosowanie większością." - a potem ktoś coś odwali i będzie jak TK, który nie może orzekać, bo nie ma odpowiedniej liczby osób do głosowania XD
"Dodawanie treści na mediach społecznościowych również przechodziłoby proces aprobaty tak samo jak dla zmian repo, zaakceptowany post wstawiany byłby na platformę przez administrację/moderację, ale to byłaby czynność jedynie techniczna" - No, to jeszcze uwalić moją robotę, żeby dbać o stronę na FB, bo tak xD Ty jakiś niepoważny jesteś? Jaka jest argument za tym, co zepsułem, że chcesz mi zabrać opcję wstawiania postów? Może są za często, i nagle się wydaje, że symulator się rozwija, a Simrail nie? Bo nie jestem w stanie tego pojąć.
"Aktualizacji repozytorium po zaakceptowaniu zmian dokonywałaby również administracja, moderacja i wyznaczone przez nią osoby, ale to byłaby czynność jedynie techniczna. Docelowo powinno zostać opracowane narzędzia które to zautomatyzują" - o, to jeszcze nie dość, że mamy radę, to ta rada nawet jak wyda jakąś decyzję, to nie może jej sama wykonać, tylko łaskawie czekać XD
"Wprowadzony zostałby stały cykl wydawniczy paczki, w którym terminy byłyby ściśle określone, np. miesięczne czy kwartalne. Zawierałyby stan repozytorium na dany dzień, bez osobnej fazy wydawniczej, testów, przesuwania terminów bo coś się nie załapało, itd. Publikacją paczki zajmowała by się administracja i moderacja (w obecnej sytuacji pewnie ja), do momentu przygotowania narzędzi które będą to robić automatycznie" - pod warunkiem, że będzie to jasno ustalone, kiedy będą te paczki, a nie będą zrzucane jak bomby w postaci "tu jest paczka, zajmijcie się resztą", kiedy ustalenia były inne, a co za tym idzie, będzie można nie zapowiadać rzeczy, które się nie załapią itd, to w tej kwestii się powiedzmy że zgadzam z tą propozycją.
Poza propozycji z paczką, uważam, że zmiany są na minus, robione na siłę i realnie nie rozwiązują istniejących problemów.
-
Z upublicznieniem Wydziału Promocji bym się wstrzymał, ponieważ wiele lat temu w kilku wątkach podawaliśmy tam różne dane, które niekoniecznie powinny być publiczne: imiona, nazwiska, numery telefonów, maile, adresy, numery rachunków bankowych itd.
-
Cała organizacja tego projektu leży już od dobrych paru lat. Świeży i chętny programista nie wie nawet gdzie może znaleźć aktualny kod źródłowy, ponieważ powstał jakiś idiotyczny podział pomiędzy repozytorium tmj, a milka. Główne repozytorium praktycznie było aktualizowane raz na jakiś czas od święta.
Zobaczcie na ten przykładowy projekt: https://github.com/multitheftauto/mtasa-blue To multiplayer do gta san andreas. Gra ma prawie 20 lat bo została wydana w 2004 roku, a ten projekt gdzieś w 2006. Działa do dziś, rozwijany jest do dziś, ciągle przybywa nowych funkcji i developerów - Wiecie dlaczego? Bo to jest w jakiś sposób zorganizowane. Jest repozytorium, do którego nie ma uprawnień każdy, ale każdy może stworzyć pull request i po testach i sprawdzeniu przez doświadczonych programistów dana zmiana zostaje zaakceptwoana i dodana do gry lub odrzucna z podanym powodem czy sugestią poprawek.
Mało tego, oprócz normalnie dostepnego repozytorium mamy też tam instrukcje jak skompilować projekt, co jest potrzebne, jakie są ich wytyczne nt. kodowania, co robić, czego nie robić, dobre praktyki https://wiki.multitheftauto.com/wiki/PL/Kompilowanie_MTASA, https://github.com/multitheftauto/mtasa-blue/blob/master/CONTRIBUTING.md#contributors-guide i obszerna dokumentacja na wiki.
Tymczasem w MaSzynie mamy 3 różne repozytoria, przestarzałą i wybrakowaną wiki, brak jakichkolwiek instrukcji dla nowych programistów i atmosferę jak w obozie, każdy do każdego ma pretensje. Szary użytkownik nie może wyrazić swojej subiektywnej opinii na temat jakichś decyzji czy modeli, ponieważ zaraz wszyscy na niego lecą "nie podoba się?! To nie graj albo zrób lepsze".
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 moim zdaniem jednak pełnią, za swojej kadencji nie miałem styczności z żadną sytuacją, w której o te działy były kłótnie, za to można wstawić rzeczy do dokończenia, można wstępnie testować przez osoby bardziej kompetentne niż szary użytkownik
Zdarzały się kłótnie o te działy, pamiętam że coś było z wyciekiem elfa; za to test dodatków jest z założenia do testowania często niedokończonych dodatków, nie ma też przeszkód aby bardziej kompetentne osoby testowały właśnie tam.
ja np. odkopuję w starych wątkach materiały na tekstury pojazdów, które wyszły już X lat temu.
Milek zasugerował przegląd treści w tych działach. W takiej sytuacji te zdjęcia najprawdopodobniej by po prostu trafiły do wątku ze zdjęciami na tekstury.
Taka mała sugestia - te rzeczy nie bez powodu siedzą w zamkniętych działach, modele niedokończone, materiały, które w założeniu miały być udostępnione małej ilości osób - to wszystko w mojej subiektywnej opinii nie powinno być dostępne dla każdego, jest to po prostu głupie.
Równie dobrze autor tych materiałów i modeli mógłby rozesłać te rzeczy osobom, do których chce aby się dostały. Wtedy też jest mniejsze ryzyko wycieku, bo daje się osobom zaufanym, a nie każdej osobie z uprawnieniami.
"a rozwój symulatora? Komu to potrzebne, zatwierdzanie rzeczy z testu dodatków (który został otworzony właśnie po to, żeby nie było do tego tak wąskiej liczby osób) do repo, to jest to. Przecież to brzmi jak zaprzeczenie testu dodatków dla wszystkich, żeby testowali, skoro i tak ktoś z wyznaczonej grupy musi to przejrzeć i zatwierdzić. To by zrównało rolę testu dodatków do pobieralni, bo i tak nie ważne co stestujesz, ostateczne zdanie należy do kogoś innego xd
Nie widzę tutaj nic co by zastopowało rozwój. W pomyśle Milka też jest wiele rzeczy do doprecyzowania. Moim zdaniem test dodatków mógłby być nadal funkcjonalny, jeżeli to grono nie zajmowałoby się testowaniem od zera, a sprawdzaniem czy dodatek ogólnie działa i czy zostały poprawione zgłoszone błędy, a jeżeli nie to dlaczego.
Ponadto - jak chcesz zachęcać nowe osoby do tworzenia? Brakiem benefitów czy nawet głupiego napisu przy nicku?
Działalność w symulatorze nie powinna być motywowana benefitami. Moim zdaniem też system rang powinien być przebudowany, np na system reputacji.
To my chcemy zaorać test dodatków? Chyba właśnie po to został otworzony, żeby miał kto to testować, a nie teraz zamykać i robić kopię, ale dla jakieś rady XD
Jak się odniosłem wyżej. Gdyby dobrze to zorganizować, ma prawo to działać.
a potem ktoś coś odwali i będzie jak TK, który nie może orzekać, bo nie ma odpowiedniej liczby osób do głosowania XD
Tutaj bym się zgodził. Taki system niesie spore ryzyko, choć to też mógłby kontrolować Milek.
No, to jeszcze uwalić moją robotę, żeby dbać o stronę na FB, bo tak xD Ty jakiś niepoważny jesteś? Jaka jest argument za tym, co zepsułem, że chcesz mi zabrać opcję wstawiania postów? Może są za często, i nagle się wydaje, że symulator się rozwija, a Simrail nie? Bo nie jestem w stanie tego pojąć.
Jeżeli zrozumiałem Milka to pisałbyś nadal posty, ale dodawałaby je moderacjo-administracja. Niemniej nie jestem fanem tego pomysłu, bo wydaje mi się to dodawaniem zbędnej biurokracji. System zatwierdzania postów jednak popieram, bo dzisiaj przepraszałeś za brak impulsów, a ja Ci musiałem napisać jakiś czas temu, żebyś nie pokazywał moich tektur węglarek, bo pokazanie n-tej tekstury węglarki jest śmiechu warte i nie pokazuje rozwoju symulatora.
o, to jeszcze nie dość, że mamy radę, to ta rada nawet jak wyda jakąś decyzję, to nie może jej sama wykonać, tylko łaskawie czekać XD
Milek napisał, że administracja mogłaby mianować osoby do tego i najpewniej osobami uprawnionymi przez administrację byliby członkowie tych rad, co też zasugerował Milek kilka punktów wyżej. Sam pomysł dodawania przez uprawnione osoby jest powrotem do przeszłości, bo kiedyś zmianami na repozytorium, włącznie z dodawaniem rzeczy z testu, zajmował się głównie (jeżeli nie wyłącznie) wydział repozytorium.
pod warunkiem, że będzie to jasno ustalone, kiedy będą te paczki, a nie będą zrzucane jak bomby w postaci "tu jest paczka, zajmijcie się resztą", kiedy ustalenia były inne, a co za tym idzie, będzie można nie zapowiadać rzeczy, które się nie załapią
Milek napisał że terminy paczek byłby ściśle określone.
Poza propozycji z paczką, uważam, że zmiany są na minus, robione na siłę i realnie nie rozwiązują istniejących problemów.
Więc jakie są realnie istniejące problemy? W tym poście Milek się odnósł do tego, co pisał w innym poście Jakub, a ciągłe gadanie o braku administracji jest męczące.
-
Glowna idea dzialow zamknietych, dawno temu bylo:
Beta-dopracowac jakas oczewkiwana nowosc, aby dla userwo bylo przyslowiowe wow. Unikano wtedy narzekania, ze to, ze tamto i ze ciulowe, bo nie dziala. Takie tam niespodzianki dla uzytkownikow.
Dev-protopy, rozmowy rozwoju itp, rozdzieleanie zadan-poziom wyzej niz beta.
Mysle, ze czasy sie zmienily na tyle, ze juz ta struktura nie jest optymalna i mysle takze, ze jak byscie nie kombinowali, to aktywnych jest wciaz za malo, aby z przytupem ruszyc z miejca. Tak to odbieram, jako juz maszynowy emeryt. Dobrze by bylo, iz jesli ktos zapodaje co jest zle i propozycje zmian, aby wzial cos na siebie np wiki, poradniki spiac czy cos. Samo sie nie zrobi.
Pozdrawiam zaloge.
-
Kilka osób narzeka tutaj na wiki, że jest zła. Przecież rok-dwa temu została gruntownie przebudowana i zaktualizowana przez Balaclavę! Co tam jest nie tak? Uważam ją za najlepsze źródło informacji o symulatorze.
-
za to można wstawić rzeczy do dokończenia
Równie dobrze rzeczy do dokończenia mogą wisieć publicznie. Przecież wiele jest niedokończonych rzeczy w działach takich jak Na warsztacie, i nie ma z tego powodu problemu.
Taka mała sugestia - te rzeczy nie bez powodu siedzą w zamkniętych działach, modele niedokończone, materiały, które w założeniu miały być udostępnione małej ilości osób - to wszystko w mojej subiektywnej opinii nie powinno być dostępne dla każdego, jest to po prostu głupie.
Co znaczy "udostępnione małej ilości osób"? Możliwości są dwie:
a) mamy zgodę na wykorzystanie danych materiałów, więc równie dobrze może wisieć w publicznym dziale, kiszenie w zamkniętym nic tu nie pomaga
b) z jakiegoś powodu nie możemy materiału wykorzystać, więc... po co mieć działy z materiałami, których nie da się wykorzystać? I tak są bezużyteczne.
Przecież to brzmi jak zaprzeczenie testu dodatków dla wszystkich, żeby testowali, skoro i tak ktoś z wyznaczonej grupy musi to przejrzeć i zatwierdzić.
Czym niby różni obecny się test dodatków od tego? Ostateczna decyzja przecież należy do tego kto wgrywa dodatek na repozytorium. Jasne, jest zasada że zgłoszone błędy muszą być poprawione, ale jak ktoś zgłosi, że piksel powinien mieć kolor 342534 zamiast 342635 to nikt nie będzie wstrzymywał dodatku z tego powodu, tylko zostanie wrzucony na repo mimo że teoretycznie był zgłoszony błąd. Moja propozycja ma na celu uregulowanie tego przejrzystymi zasadami: jest aprobata N osób - zmiana jest akceptowana. Żeby było jasne: ten system zastępowałby obecny test dodatków, po prostu trafiałyby tam wszystkie zmiany, zarówno nowe dodatki jak i zmiany które obecnie są robione na repozytorium bezpośrednio przez osoby z dostępem; w zasadzie byłoby to rozszerzeniem zakresu testu dodatków.
Brakiem benefitów czy nawet głupiego napisu przy nicku?
Jak ktoś robi coś tylko dlatego żeby mieć głupi napis przy nicku, to smutne to jest.
a potem ktoś coś odwali i będzie jak TK, który nie może orzekać, bo nie ma odpowiedniej liczby osób do głosowania XD
Dlatego liczę na dyskusję w jaki sposób miałoby to dokładnie działać - "będzie jak TK" niewiele tu wnosi. Administracja cały czas pozostanie, ale podejmowanie działań przez nią to jedynie ostateczność gdy system zawiedzie. Trzeba tak stworzyć procedury żeby zminimalizować to ryzyko.
No, to jeszcze uwalić moją robotę, żeby dbać o stronę na FB, bo tak xD
Chodzi o to żeby nie było specjalnych stanowisk, tylko wszystko przechodziło tą samą ścieżkę: dowolny użytkownik (również ty...) może napisać post, gdy uzyska aprobatę zespołu to jest dodawany.
Z upublicznieniem Wydziału Promocji bym się wstrzymał, ponieważ wiele lat temu w kilku wątkach podawaliśmy tam różne dane, które niekoniecznie powinny być publiczne: imiona, nazwiska, numery telefonów, maile, adresy, numery rachunków bankowych itd.
Nie chodzi mi o upublicznienie działów, tylko bardziej likwidację. Wyciągniecie przydatnych treści po to żeby nic nie zginęło w sytuacji: mamy zgodę na wykorzystanie materiałów, nie ma przeszkód żeby je wykorzystywać, ale zostały wrzucone do ukrytego działu. Wypisałem wszystkie działy, w praktyce pewnie z promocji, webmasterów, promotorów nie będzie nic do wyciągnięcia.
Jest repozytorium, do którego nie ma uprawnień każdy, ale każdy może stworzyć pull request i po testach i sprawdzeniu przez doświadczonych programistów dana zmiana zostaje zaakceptwoana
Właśnie coś w rodzaju pull requestów mam na myśli, z uregulowanymi zasadami zatwierdzania.
Niemniej nie jestem fanem tego pomysłu, bo wydaje mi się to dodawaniem zbędnej biurokracji. System zatwierdzania postów jednak popieram
Osób upoważnionych do dodawania postów może być więcej (wyznaczonych przez administrację/moderację), ale chodzi o to że byłaby to funkcja jedynie techniczna, po prostu wstawiane byłyby posty które zostałyby zatwierdzone przez zespół.
o, to jeszcze nie dość, że mamy radę, to ta rada nawet jak wyda jakąś decyzję, to nie może jej sama wykonać, tylko łaskawie czekać XD
Rada decyduje merytorycznie, i sama zarządza swoim składem. Końcowe wrzucenie na repozytorium to tak jak wyżej jedynie czynność techniczna, administracja/moderacja może wyznaczyć więcej osób w celu usprawnienia procesu.
-
Od strony technicznej, docelowo najprawdopodobniej postawiony zostałby interfejs do gita, i zostałyby utworzone repozytoria:
- strony głównej eu07.pl (zostałaby przeniesiona na generator hugo, zmiana plików aktualizowałaby treść strony)
- posty na mediach społecznościowych (dodawanie pliku oznaczałoby nowy post, który zostałby dodany przez wyznaczone osoby (lub automatycznie, ale nie sprawdzałem jeszcze czy to jest możliwe))
- repozytorium symulatora (w tym celu repozytorium zostałoby zmigrowane do gita, oraz zostałby postawiony serwer git-as-svn żeby dalej dało się korzystać z narzędzi svn)
- repozytorium exe (zostałoby przeniesione z mojego githuba, na którym jest obecnie aktualna gałąź)
Zmiany mogłyby być proponowane przez każdego użytkownika utworzeniem pull request, po aprobacie N członków zespołu byłby automatycznie mergowane.
-
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.
-
b) z jakiegoś powodu nie możemy materiału wykorzystać, więc... po co mieć działy z materiałami, których nie da się wykorzystać? I tak są bezużyteczne.
Zawsze można próbować jeszcze załatwić zgodę, zamiast niszczyć czyjąś pracę nad np. konwersją modelu.
Jak ktoś robi coś tylko dlatego żeby mieć głupi napis przy nicku, to smutne to jest.
A ja uważam, że ten napis to jednak trochę szpanu daje i satysfakcję z jego posiadania. No i na pierwszy rzut oka wiadomo, kto zrobił coś więcej dla projektu.
Od strony technicznej, docelowo najprawdopodobniej postawiony zostałby interfejs do gita, i zostałyby utworzone repozytoria:
[...]
Zmiany mogłyby być proponowane przez każdego użytkownika utworzeniem pull request, po aprobacie N członków zespołu byłby automatycznie mergowane.
Czy drobne zmiany takie jak poprawienie literówki w skrypcie czy wrzucenie nowych/aktualizacja czcionek do wyświetlaczy także automatycznie tworzyłaby ticket w teście dodatków, i musiałbym czekać na aprobatę X osób? Z jednej strony skompletowanie wszystkiego jako jeden pull request ułatwiałoby instalację dodatków (patrz dźwięki Fordana), z drugiej wymuszałoby kompletność implementacji (plus dyskusje czy dać jako losowane czy zastąpić), z trzeciej nie trzeba by było tworzyć struktur katalogowych i mieć pewność, że wszystko leci w konkretne miejsce.
Mam nadzieję, że interfejs nie będzie tak toporny w użytkowaniu jak bugtracker, gdyż strasznie ciężko się z niego korzysta (i dlatego tam nie wchodzę).
-
Czy drobne zmiany takie jak poprawienie literówki w skrypcie czy wrzucenie nowych/aktualizacja czcionek do wyświetlacz
Tak, wszystkie zmiany przechodziłyby tą samą procedurę.
Mam nadzieję, że interfejs nie będzie tak toporny w użytkowaniu jak bugtracker, gdyż strasznie ciężko się z niego korzysta (i dlatego tam nie wchodzę).
Prawdopodobnie Gitea/Forgejo. Ewentualnie GitLab, ale ze względu na jego ociężałość i złożoność raczej bym nie chciał, byłby bardziej zajmujący dla administracji.
Bugtracker zostałby też przeniesiony w to samo miejsce.
-
W pełni zgadzam z postulatami, jednak uważam, że aż takie rozebranie hierarchii mogłoby doprowadzić do samowolki. Ponadto apeluję o dokładne przejrzenie archiwalnych tekstur i scenerii (które często są nieprzejezdne), lub wydanie okrojonej, alternatywnej paczki lite.
-
za to można wstawić rzeczy do dokończenia
Równie dobrze rzeczy do dokończenia mogą wisieć publicznie. Przecież wiele jest niedokończonych rzeczy w działach takich jak Na warsztacie, i nie ma z tego powodu problemu.
No tylko że jakby autor chciał, żeby dane prace były upublicznione już w trakcie prac, to by je dawał do działu publicznego, a nie zamkniętego? Nie wiem po co upubliczniać prace nad chociażby nowymi lokami, moim zdaniem skutkiem tego będzie jedynie nakręcanie niepotrzebnych pytań "KIEDY MODEL X WIDZIAŁEM ŻE JEST ROBIONY".
Taka mała sugestia - te rzeczy nie bez powodu siedzą w zamkniętych działach, modele niedokończone, materiały, które w założeniu miały być udostępnione małej ilości osób - to wszystko w mojej subiektywnej opinii nie powinno być dostępne dla każdego, jest to po prostu głupie.
Co znaczy "udostępnione małej ilości osób"? Możliwości są dwie:
a) mamy zgodę na wykorzystanie danych materiałów, więc równie dobrze może wisieć w publicznym dziale, kiszenie w zamkniętym nic tu nie pomaga
b) z jakiegoś powodu nie możemy materiału wykorzystać, więc... po co mieć działy z materiałami, których nie da się wykorzystać? I tak są bezużyteczne.
c) możemy korzystać z materiałów, ale autor takowych nie chciałby, aby były publicznie dostępne. Tak, wiem, można wysłać to do konkretnej osoby, ale materiały o których mówię (celowo nie wymieniam które, bo o to właśnie chodzi), nie będą użyte teraz, a za np. X miesięcy - i mogą być w tych zamkniętych działach, bo wtedy można robiąc projekt je po prostu wziąć, a nie pisać po wszystkich czy przypadkiem czegoś nie mają.
Przecież to brzmi jak zaprzeczenie testu dodatków dla wszystkich, żeby testowali, skoro i tak ktoś z wyznaczonej grupy musi to przejrzeć i zatwierdzić.
Czym niby różni obecny się test dodatków od tego? Ostateczna decyzja przecież należy do tego kto wgrywa dodatek na repozytorium. Jasne, jest zasada że zgłoszone błędy muszą być poprawione, ale jak ktoś zgłosi, że piksel powinien mieć kolor 342534 zamiast 342635 to nikt nie będzie wstrzymywał dodatku z tego powodu, tylko zostanie wrzucony na repo mimo że teoretycznie był zgłoszony błąd. Moja propozycja ma na celu uregulowanie tego przejrzystymi zasadami: jest aprobata N osób - zmiana jest akceptowana. Żeby było jasne: ten system zastępowałby obecny test dodatków, po prostu trafiałyby tam wszystkie zmiany, zarówno nowe dodatki jak i zmiany które obecnie są robione na repozytorium bezpośrednio przez osoby z dostępem; w zasadzie byłoby to rozszerzeniem zakresu testu dodatków.
No to jak mamy to wprost - ja osobiście, po niedawnym otworzeniu testu dodatków, nie jestem zwolennikiem tworzenia czegoś zamiast testu dodatków, nie podoba mi się ten pomysł, tak po prostu.
Brakiem benefitów czy nawet głupiego napisu przy nicku?
Jak ktoś robi coś tylko dlatego żeby mieć głupi napis przy nicku, to smutne to jest.
Idk, ale ja tam pamiętam, że jak po ponad roku robienia niezbyt dobrej jakości skórek w końcu mi się udało dać kilka na repo i dostać ten głupi napis, to tak, było to dla mnie "coś", co dało mi motywację do dalszego działania. Uważam też, że dodaje to jakby nie patrzeć trochę satysfakcji, że się wyróżniasz, że coś realnie robisz dla symulatora, i tak, brak absolutnie niczego w tym stylu może być po prostu demotywujące dla nowych twórców.
a potem ktoś coś odwali i będzie jak TK, który nie może orzekać, bo nie ma odpowiedniej liczby osób do głosowania XD
Dlatego liczę na dyskusję w jaki sposób miałoby to dokładnie działać - "będzie jak TK" niewiele tu wnosi. Administracja cały czas pozostanie, ale podejmowanie działań przez nią to jedynie ostateczność gdy system zawiedzie. Trzeba tak stworzyć procedury żeby zminimalizować to ryzyko.
Dobrze, to jako, że nie jestem zwolennikiem tego pomysłu, pozostawiam go pod dyskusję innym osobom.
Czy drobne zmiany takie jak poprawienie literówki w skrypcie czy wrzucenie nowych/aktualizacja czcionek do wyświetlacz
Tak, wszystkie zmiany przechodziłyby tą samą procedurę.
To ja tutaj byłbym na nie, że musisz mieć aprobatę X osób, żeby poprawić 5 pikseli na teksturze, bo dałeś je nie tego koloru co trzeba.
No, to jeszcze uwalić moją robotę, żeby dbać o stronę na FB, bo tak xD
Chodzi o to żeby nie było specjalnych stanowisk, tylko wszystko przechodziło tą samą ścieżkę: dowolny użytkownik (również ty...) może napisać post, gdy uzyska aprobatę zespołu to jest dodawany.
Teraz już nie ma specjalnych stanowisk, bo robię to ja, nie mają żadnego stanowiska, większość postów przechodzi wewnętrzny akcept i nie trzeba się bawić w wysyłanie tego do moderatorów czy administratorów. Nie widzę realnej potrzeby wprowadzania tutaj zbędnej biurokracji, mogę, jak bardzo jest to potrzebne, podsyłać posty grupę beta/dev na mm, żeby tam przechodziły akcept.
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.
Oczywiście, że discord jest czytelny, da się stworzyć posegregowanego discorda dla takiej usługi, nie ma on służyć pokazywaniu nowości tylko tam, ale też na forum (test dodatków na ten moment) i na fb. I gwarantuję ci, że discordem i facebookiem dotrzesz do osób młodych, mogących rozwijać ten projekt przez lata, a nie przez forum, które wśród tych osób jest mało popularnym środkiem kontaktu.
Słowem podsumowania, co do zaorania działów niepublicznych jestem na nie, co do tej rady, to będę obserwować istniejącą dyskusję. Co do FB, zdanie jak wyżej, nie jestem fanem tego pomysłu. Co do paczek, poddałbym to jednak pod dyskusję - bo co z tego, że mamy paczkę raz na kwartał, jak w tej paczce jedynymi nowościami są węglarki, skórki na pojazdy i trochę obiektów. No sorry, ale jak sobie wejdziesz na FB czy discorda, to opinie są dość jasno nakierowane na impulsy i na to, że nie warto pobierać, bo nie ma żadnych nowych modeli ani nic w tym stylu.
W mojej opinii paczka powinna być raz na 3-6 miesięcy, ale przystosowana jednak o to, żeby zawierała coś więcej, aby odbiór był jednak nieco lepszy. Budować wrażenie, że coś się dzieje, można poprzez regularne posty na FB, bo to zaczęło przynosić efekty. Takie jest moje zdanie w tym temacie.
Dalej uważam, że mimo że temat przeorany, to potrzebujemy drugiego człowieka w administracji, żeby była opcja B w sytuacjach awaryjnych.
Z tego miejsca chciałem cię również Milku przeprosić za niecenzuralne wypowiedzi z dnia wczorajszego, byłem nieco zbyt zirytowany, że przyszedłeś i bez zapowiedzi nikomu wrzuciłeś paczkę, mimo innych, wcześniejszych ustaleń.
-
Uważam też, że dodaje to jakby nie patrzeć trochę satysfakcji, że się wyróżniasz, że coś realnie robisz dla symulatora, i tak, brak absolutnie niczego w tym stylu może być po prostu demotywujące dla nowych twórców.
Jak to ma komuś pomóc, to można zrobić jakiś licznik punktów, gwiazdek, eurogąbek czy czego tam, ale to byłoby za zaakceptowane zmiany na repozytorium, a nie za zasiadanie w radzie.
To ja tutaj byłbym na nie, że musisz mieć aprobatę X osób, żeby poprawić 5 pikseli na teksturze
Nowy zainteresowany użytkownik miałby takie same możliwości wprowadzania zmian jak każdy inny - a nie że jest jakaś uprzywilejowana grupa, której procedura nie dotyczy.
Słowem podsumowania, co do zaorania działów niepublicznych jestem na nie
Istnienie działów niepublicznych wymaga istnienia uprzywilejowanej grupy która ma do nich dostęp. Moim zdaniem to negatywny czynnik ograniczający możliwości udziału w projekcie nowym użytkownikom.
Dalej uważam, że mimo że temat przeorany, to potrzebujemy drugiego człowieka w administracji, żeby była opcja B w sytuacjach awaryjnych.
Jest 5 administratorów którzy logowali się w ciągu ostatniego roku. Czyli: zmian nie chcesz, ale chcesz kolejnego administratora, który ma wszystko uzdrowić. Aha.
-
przestarzałą i wybrakowaną wiki, brak jakichkolwiek instrukcji dla nowych programistów i atmosferę jak w obozie, każdy do każdego ma pretensje.
Tak jak Jakub wspomniał, Wiki jest aktualnie najbardziej uporządkowanym i dla niektórych aspektów (choćby chory system obslugi przezroczystości) nawet jedynym źródłem informacji o działaniu symulatora. Od dłuższego czasu czułem, że nie będę mógł ciągnąć w nieskończoność rozwoju maszyny w pewnych aspektach a chciałem zapewnić w miarę ponadczasowe źródło podstawowej wiedzy o strukturze symulatora. O ile można powiedzieć, że dział teoretyczny, przynajmniej w zakresie moich zainteresowań tj. modeli, scenerii i struktury plików jest w zasadzie kompletny, to zabrakło chęci i czasu na stworzenie strony praktycznej tj. poradników dla początkujących.
Myślę że było by to kluczową rzeczą do przyciągnięcia nowych deweloperów. Czasem trzeba na prawdę niewiele - jakiś czas temu napisała do mnie na FB pewna osoba, zadała łącznie kilkanaście pytań a teraz widzę że co parę dni wrzuca nowe modele do testu i są to konkretne, potrzebne i dobre jakościowo assety. To wystarczyło. Trzeba tylko pamiętać, że to wymaga poświęcenia własnego czasu, bez gwarancji że przyniesie to owoce. No cóż, nie każdy się w tym odnajdzie, ale jak nie będziemy probować, to nikt nowy już tu nie przyjdzie tworzyć i nie pomogą żadne reformy administracyjne.
Na temat organizacji części biurokracyjnej i administracyjnej zdania nie mam.
-
To ja tutaj byłbym na nie, że musisz mieć aprobatę X osób, żeby poprawić 5 pikseli na teksturze
Nowy zainteresowany użytkownik miałby takie same możliwości wprowadzania zmian jak każdy inny - a nie że jest jakaś uprzywilejowana grupa, której procedura nie dotyczy.
Nigdzie nie powiedziałem że tak nie będzie, powiedziałem, że istnienie takich ról jak "deweloper" na forum symulatora jest czymś prestiżowym i tak, nowi twórcy (a przynajmniej tak było w moim przypadku) dążyli do tego. Tak, młodego człowieka nie zmotywujesz już tym, że patrz, może i nic nie dostaniesz w zamian, ale przynajmniej poświęcisz na to dużo swojego wolnego czasu.
Słowem podsumowania, co do zaorania działów niepublicznych jestem na nie
Istnienie działów niepublicznych wymaga istnienia uprzywilejowanej grupy która ma do nich dostęp. Moim zdaniem to negatywny czynnik ograniczający możliwości udziału w projekcie nowym użytkownikom.
Moim zdaniem nowy użytkownik, który dotychczas dostaje rangę po max 10 dodatkach dodanych na repo, wcześniej niekoniecznie będzie potrafił wnieść dużo jakościowo do projektów typu nowy model pojazdu, który jest w zamkniętym dziale, a może być pewnego rodzaju motywacją dla nowego użytkownika. Moja subiektywna opinia na podstawie moich doświadczeń.
Dalej uważam, że mimo że temat przeorany, to potrzebujemy drugiego człowieka w administracji, żeby była opcja B w sytuacjach awaryjnych.
Jest 5 administratorów którzy logowali się w ciągu ostatniego roku. Czyli: zmian nie chcesz, ale chcesz kolejnego administratora, który ma wszystko uzdrowić. Aha.
Z czego w 2023: Ty, Iwan, Winger, z czego jakiekolwiek działania w kierunku rozwoju podjąłeś ty, i kto jeszcze? Nie wliczam tych, którzy w tej randzie już nie są. Z czego ty jesteś aktywny (a przynajmniej byłeś dotychczas) dosyć rzadko. I tak, uważam, że część z propozycji, które dałeś, mi się nie podoba, a nie że nie chcę jakichkolwiek zmian. Tak, posiadanie aktywnego codziennie administratora jest konieczne. Jak będziesz to ty, bo w końcu zaczniesz wchodzić tu częściej niż raz w miesiącu, to powiedzmy, że przeżyjemy.
-
Tak, młodego człowieka nie zmotywujesz już tym, że patrz, może i nic nie dostaniesz w zamian, ale przynajmniej poświęcisz na to dużo swojego wolnego czasu.
Nie przypominam sobie żebym jako 12-latek miał jakiekolwiek motywacje rangowe w tym 2017 roku, tylko chciałem fajną siódemkę zrobić. Za to w momencie dostania rangi się dowiedziałem o działach zamkniętych, zachłysnąłem się dostępem do nich i zacząłem się po facebookach elfem chwalić, wówczas siedzącym w WBT czy tam WD.
-
Nigdzie nie powiedziałem że tak nie będzie
Napisałeś że nie chcesz aprobaty X osób, żeby poprawić 5 pikseli na teksturze. Więc chcesz mieć dostęp i możliwość wprowadzania zmian na repozytorium samemu, bo jak inaczej? Osoby bez stanowiska tego przecież mieć nie będą, więc dla równości wszyscy powinni wprowadzać zmiany zgodnie z procedurą.
Jak będziesz to ty, bo w końcu zaczniesz wchodzić tu częściej niż raz w miesiącu, to powiedzmy, że przeżyjemy.
Nie zanosi się na to. Ale istnieje takie pojęcie jak samorząd, o czym jest ten wątek.
Nie udajmy że ranga i dostęp do repozytorium to jakiś zaszczyt, który ma motywować ludzi. Trzeba zminimalizować próg wejścia do projektu, usunąć ukryte działy służące do kiszenia zasobów, i przy okazji usunąć specjalne stanowiska z większym dostępem, żeby zmniejszyć ilość awantur. To projekt potrzebuje ludzi, a nie ludzie projektu.
-
To inaczej, w mojej opinii tymi sposobami, które proponujesz, może niekoniecznie udać się przedstawiony cel. Nie chce mi się tutaj już przerzucać kolejnymi rzeczami, bo ani ja nie zmienię twojego zdania, ani ty nie zmienisz mojego. Tak, uważam że zrównanie wszystkich użytkowników i zrobienie rady, która musi wszystko zatwierdzić (czyli wprowadzenie rangowania, ale inaczej) oraz wywalenie zamkniętych działów nie ma sensu. Tyle.
-
tymi sposobami, które proponujesz, może niekoniecznie udać się przedstawiony cel
A pamiętasz w ogóle jaki jest cel? Nie chodzi o zabetonowanie maszyny, tylko o pozyskiwanie nowych użytkowników. Cały czas piszesz "nie bo nie". Milek przedstawił bardzo dobre, genialne w swojej prostocie pomysły. Powinny zostać wprowadzone chociażby z jednego powodu. Od lat trzymamy się jednego schematu z drobnymi modyfikacjami i cały czas idzie ku złemu. A jak czytam argumenty:
niepotrzebnych pytań "KIEDY MODEL X WIDZIAŁEM ŻE JEST ROBIONY".
To nie wiem czy śmiać się czy płakać. Zaraz nie będzie komu takich komentarzy pisać, bo fanbase maszyny robi się coraz węższy. Podobnie jak dyskusja o rangach. Jakiś czas temu prowadzono polubienia.
-
Słowem podsumowania, co do zaorania działów niepublicznych jestem na nie
Istnienie działów niepublicznych wymaga istnienia uprzywilejowanej grupy która ma do nich dostęp. Moim zdaniem to negatywny czynnik ograniczający możliwości udziału w projekcie nowym użytkownikom.
W momencie otwarcia/częściowego otwarcia testu dodatków został utworzony poddział w którym były wątki z działu zamkniętego. Mam propozycję kompromisową. Można zablokować możliwość zakładania nowych wątków w działach zamkniętych. Obecne rangi ukryć. Nowych rang nie nadawać. Zamknięte działy byłyby swojego rodzaju archiwum.
-
Jeżeli mamy pozbyć się rang, to wypadało by chociaż wprowadzić system reputacji, żeby mimo wszystko, dało się wyróżnić użytkowników z większym stażem i doświadczeniem do których można zwracać się o pomoc. Bo tak to wszystko zginie w gąszczu szarych nicków i nie będzie wiadomo kogo lepiej się słuchać.
-
Po pierwsze proponuję zostawić obecne polubienia jako subiektywną reputację. Dodatkowo proponowałbym (obiektywny) drugi rodzaj reputacji oparty o ilość zaakceptowanych PR na repozytoria - zastąpiłoby to aktualne rangi. Oczywiście do tego trzeba by było ustalić mnożniki, żeby było sprawiedliwie. Wagi trzeba by było odpowiednio zbilansować, żeby były adekwatne do nakładu włożonej pracy w daną treść.
-
Bla bla bla, bla bla bla i tak dalej. Już nie raz o tym pisałem poza forum. Aż zaczynam żałować decyzji gdy wykorzystując zmiany w exe zacząłem rozbijać duże wagowo modele na klocki, cele były dwa: łatwiejsze wprowadzanie poprawek i zmniejszenie chociaż trochę wagi repo. Poszło to w stronę której nie planowałem, więc sorry, mój czas jest zbyt cenny żebym do testowania czegokolwiek spędzał więcej czasu na ściąganie plików z repo. Dawać do testu dodatki już w binarce to może nagle cudownie to wszystko ruszy. Zniesiono limit w TD, pach, pierwszy z brzegu wątek - zwykły Kowalski nie potrafi uruchomić dodatku.
-
W t3d łatwiej wyśledzić problemy (źle dobrane min i max distance itp.) których w binarce gołym okiem namierzyć nie da się. W związku z tym gdzieś na forum padła propozycja, żeby autorzy dodatku robili paczki wsporcze z częściami składowymi, które są już na repo. Oczywiście to ma sens przy świeżych wrzutkach do testu.
-
Niech będzie e3d dołączone do każdej paczki w teście. Pobieranie z łapy to nieporozumienie, a jak zaraz ileś tam osób będzie pobierać repo żeby łatwo testować to z serwera zostanie kupka popiołu.
-
Miło słyszeć, ze istnieje kilka pomysłów na poprawę obecnej sytuacji. Czytam dyskusję, i tak naprawdę każda „strona” ma sporo racji. Ja jednakże dla dopełnienia prosiłbym o zwrócenie szczególnej uwagi na dodatkowy aspekt - userów, naszych użytkowników docelowych.
Wiemy jak wyglądają testy dodatków, wiemy jaki jest ogólny poziom wiedzy userów o działaniu symulatora. Większość musi mieć wszystko na „gotowe”, inaczej rozpoczynają się zgłoszenia o problemach etc., które tylko niepotrzebnie rozpraszają twórców.
Nie mam żadnego stanowiska w tej sprawie, nie czuję się na tyle doświadczony. Proszę was jednakże, żebyście pamiętali o użytkowniku końcowym.
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ć.
-
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
-
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.
-
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.
-
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).
-
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.
-
- 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.
-
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.
-
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.
-
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
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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ą?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Przyklejam wątek
-
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.
Natomiast proponuję, żeby dostęp do nich był zachowany na dotychczasowych zasadach.
Ale bezterminowo? To się trochę mija z celem, bo dalej będą rangi dające dostęp do dodatkowych działów, a to chciałbym zlikwidować.
-
A ja bym był za zachowaniem bezterminowym. Bo mimo wszystko jest tam dużo cennego materiału. Nie kupuję udostępniania tego publicznie, wcześniej argumentowałem dlaczego.
-
Nigdy nie proponowałem żeby to udostępnić publicznie. Jak bezterminowo, to kto będzie miał do tego dostęp? Posiadacze byłych rang, których już nie będzie dało się zdobyć?
-
Należałoby tu zrobić przegląd zawartych w nich treści i wyciągniecie tego co możemy wykorzystać (są odpowiednie zgody itd.) do działów publicznych. Reszty, skoro i tak nie można wykorzystać niech zostanie jedynie w czeluściach archiwum serwera, bez ogólnego dostępu.
Udostępnić co się da, a reszta niech zdycha. No jak na moje to jest publiczne udostępnienie tej zawartości. Na razie proponuję wstrzymanie tych "zmian", w celu zobaczenia, jak nowa kadra zarządzająca będzie się spisywać chociażby w kwestii wydawania paczek.
-
Nigdy nie proponowałem żeby to udostępnić publicznie. Jak bezterminowo, to kto będzie miał do tego dostęp? Posiadacze byłych rang, których już nie będzie dało się zdobyć?
Jakaś ukryta ranga. Z tym że się nie będzie dało jej nigdy już zdobyć to przesada. Może jakieś nowe aktywnie tworzące osoby będą mogły też dostać dostęp do tego. Kluczowe jest zamknięcie działu dla nowych postów. Jak nie będzie nowego kontentu w takich działach, z czasem straci na wartości. Z "sejfu" dalej dodatki będzie można wyciągać. Zresztą to nie jest tak, że większość dodatków które znajdują się w tym dziale i tak podlega pod licencję MaSzyny, więc jeśli raz zostanie uzyskana zgoda nie trzeba się nikogo pytać do ich wyciągnięcia?
-
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.
Natomiast proponuję, żeby dostęp do nich był zachowany na dotychczasowych zasadach.
Ale bezterminowo? To się trochę mija z celem, bo dalej będą rangi dające dostęp do dodatkowych działów, a to chciałbym zlikwidować.
W istniejących działach zamkniętych (poza krytycznymi) widziałbym zablokowanie możliwości pisania nowych postów (takie archiwum powiedzmy). Jeżeli ktoś coś tam pisał, to raczej z myślą, że ta wiadomość nie trafi do ogółu.
Jeżeli koś z autorów treści wrzuconej do zamkniętego działu ma chęć przenieść coś do działów ogólnodostępnych, to nie widzę przeciwwskazań.
Zresztą to nie jest tak, że większość dodatków które znajdują się w tym dziale i tak podlega pod licencję MaSzyny, więc jeśli raz zostanie uzyskana zgoda nie trzeba się nikogo pytać do ich wyciągnięcia?
Ja się spotkałem z taką tezą, że jeżeli coś jest nie wydane, to nie powinno się publikować bez zgody autora dodatku.
-
No dobra, ale autorzy znikają. Kabina do SA134 też jest spisana na straty, bo Stele zniknął?
W takich przypadkach najlepiej po prostu wydać i przy ewentualnym wecie autora wycofać. W końcu autorzy tych dodatków raczej robili je w celu wydania do MaSzyny.
-
Poza nieukończonymi dodatkami są jeszcze inne rzeczy, które były pisane lub udostępniane w grupach niepublicznych z jakiegoś powodu i byłoby przynajmniej nieeleganckie, gdyby takie treści pojawiły się publicznie. Już raz akcja wyciągania wypowiedzi miała miejsce, niesmak do tej pory pozostał, a sam autor zamieszania dziwnie ucichł i uciekł.
No dobra, ale autorzy znikają. Kabina do SA134 też jest spisana na straty, bo Stele zniknął?
W tym konkretnym przypadku autor żyje i przed zniknięciem dał wolną rękę (nawet wypuścić do starego pudła, żeby nie kisić). Myślę, że z kontekstu działalności osoby i sposobu zaprzestania prac można wywnioskować, czy coś jest do dokończenia/opublikowania, czy nie.
-
Minął prawie rok. Jestem ciekaw, czy coś drgnęło jeżeli chodzi o implementację, czy póki co ten system jest wciąż tylko w sferze dyskusji?