Zanim skontaktujesz się z zespołem, zgłosisz błąd, utworzysz post na forum itd. powinieneś przeczytać tą stronę. Stosowanie się do wytycznych i instrukcji na tej stronie spowoduje, że społeczność oraz projekt będą działały lepiej i wydajniej. Pomimo, że ten artykuł może brzmieć trochę szorstko nie bój się publikować. Zespół gry jest zazwyczaj cierpliwy chyba, że recydywistą. ;)
Spis treści
Pamiętaj, że…
Deweloperzy nie dostają pieniędzy
Deweloperzy robią to, ponieważ lubią to robić, nie dlatego, że im zapłaciłeś. Nie zarabiają z tego aby ciebie zadowolić, chociaż mimo to spróbują wziąć twoją sugestię pod uwagę jeżeli to możliwe.
Deweloperzy pracują nad grą tylko w swoim wolnym czasie
Mogą nie mieć szansy aby odpowiedzieć od razu. Bądź cierpliwy—w końcu odpowiedzą. Jednak jeżeli nie, uprzejmie wybij swój post. Znaczy to też, że nie powinieneś robić trywialnych próśb, które nie mają znaczenia lub niezwykle wymagających próśb.
Otwarto-źródłowe nie zawsze oznacza, że każdy twój wkład będzie zaakceptowany
Zespół musi dbać o jakość kodu oraz grafik. To oznacza, że czasem twoja praca nie może być zaakceptowana. Nie zniechęcaj się—zespół chętnie pomoże lub udzieli rady.
Wytyczne
Podczas zgłaszania błędu lub awarii gry
- Jeżeli błąd jest już zgłoszony w serwisie GitHub:
- Jeżeli zgłoszenie błędu jest już otwarte sprawdź czy możesz dostarczyć więcej informacji o nim.
- Jeżeli zgłoszenie błędu jest zamknięte, najprawdopodobniej musisz poczekać do następnego wydania aby poprawka była zawarta w grze, chyba, że chcesz skompilować grę ze źródeł.
- Jeżeli błąd nie jest zgłoszony:
- Tytuł powinien być jasny i opisowy.
- Opis problemu powinien być szczegółowy. Instrukcje krok po kroku jak odtworzyć problem są wyjątkowo pomocne.
- Zawrzyj informacje o systemie takie jak twój system operacyjny, wersja systemu operacyjnego, model oraz producent procesora graficznego (GPU), wersja sterownika graficznego oraz model CPU.
- Zawrzyj plik stdout.log. (Zobacz “Gdzie STK zapisuje pliki konfiguracyjne użytkownika” na stronie FAQ aby dowiedzieć się gdzie znajduje się ten plik.)
- W razie potrzeby dołącz zrzuty ekranu.
- Jeżeli jesteś w stanie skompilować STK samodzielnie i uruchomić go w debugerze (takim jak GDB, Valgrind lub Visual Studio Debugger) skompiluj STK w trybie debugowania, uruchom grę i wyślij dane wyjściowe z debugera.
- Dołącz jakiekolwiek inne informacje, które uważasz za potrzebne.
- Odpowiedz na pytania tak dokładnie jak potrafisz.
Podczas prezentacji zasobu lub innej pracy artystycznej
- Dostarcz pliki źródłowe (.kra, .xcf, .blend, itd.).
- Wyraźnie podaj licencję (Zobacz Licencjonowanie aby dowiedzieć się o dostępnych licencjach.)
- Zaakceptuj krytykę i sprawdź co może być zrobione aby ulepszyć twoją pracę.
- Porozmawiaj z zespołem na temat swojej pracy kiedy jest ona w trakcie prac aby uzyskać opinie.
- Wyjaśnij czy twój praca jest ukończona czy w trakcie prac.
Podczas zgłaszania sugestii
To jest drażliwy temat. Oczywiście, musimy akceptować krytykę i sugestie—jeżeli byśmy tego nie robili wtedy byłoby to sprzeczne z ideałem open-source: oprogramowanie jest z korzyścią dla wszystkich. Ale kiedy prośba staje się zbyt duża? W tym celu musimy również uważać na konflikty z ideałem open source: każdy powinien wnosić swój wkład tam, gdzie to możliwe. Więc w trakcie zgłaszania sugestii dla STK zadaj sobie następujące pytania:
- Czy wcześniej przyczyniłem się do rozwoju gry SuperTuxKart?
- To może być darowizna, tworzenie obiektów, tras, tekstur, itd. Nawet tworzenie dodatków pomaga grze.
- Gdybym był w stanie zrobić to co sugeruję, czy byłbym skłonny to zrobić?
- Czy rozumiem ile wysiłku trzeba włożyć aby wykonać to zadanie?
- Czy przynajmniej wyrażam wsparcie dla zespołu i wykonywanej pracy?
- Czy w ostatnim czasie robiłem dużo sugestii?
- To może brzmieć prozaicznie ale tak naprawdę jest to znak tego czy szanujesz pracę zespołu. Jeżeli szanujesz pracę zespołu znacznie rzadziej będziesz narzekać.