Symulator EU07 (i nie tylko) > Bieżące Symulatorowe

 Potencjalne zmiany w zarządzaniu projektem

(1/13) > >>

Milek7:
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.

Sebeq:
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.

x_Zielu:
"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.

MaciejM:
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.

tor424:
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.

Nawigacja

[0] Indeks wiadomości

[#] Następna strona