Teams organisieren

[psython]

Welche Teams brauchen wir und wer kommt in welches Team?
Wie wäre es mit:

• Grafiker
• Dokumentatoren
• Debugger

[cpdef]

Diese Teams fide ich gut. Mir fallen jezt auch keine weiteren ein, außer
die die die :) Pull requests übernehmen, wenn nicht das mit Debugger gemeint ist.

[sebastian2443]

In dem Fall würde man vllt Grafiker und Komponisten zusammenwerfen können.
Am Anfang reicht es ja, wenn der Komponist kleine Sounds erstellt.
Sowas wie ein Ploppen oder n 'Doing' fürs springen oder ähnliches eben.
Eine Levelmusik kann man ja auch irgendwann zum Schluss adden, falls jemand sowas kann.

Ist der Debugger jemand, der den Code noch einmal sichtet?

Wir dokumentieren doch gerade alle, oder? Und später dann jeder seinen Quellcode. Oder wie muss ich das verstehen?

[cpdef]

Da hast du natürlich recht. Eigentlich brauchen wir keinen extra Dokumentator, außer vielleicht einen, der für das Wiki verantwortlich ist, aber da ergeben sich die meißten Dokumente ja auch von selbst (zumindest bis jetzt war das so).

[Marrin]

Ich vermute mal mit “Debugger“ ist Qualitätssicherung („Quality Assurance“, QA) oder Tester gemeint‽ Das wäre die dafür üblichere Job-/Rollenbezeichnung. :-)

Was Grafiken und Sounds angeht, da gibt es auch freie Quellen im Netz.

[cpdef]

Die Frage ist jetzt:
brauchen wir Teams für:

• Grafiker
• Dokumentatoren
  ?
  "Debugger" / QAs haben wir ja schon.

[psython]

Die Grundidee vom aller ersten Thread sah so aus.

Der erfahrene Programmierer erstellt das grobe Gerüst der Software und kann sich fast völlig auf das schreiben konzentrieren. Der fortgeschrittene könnte den Code lesen, verstehen und eine kurze Beschreibung als Text verfassen. Der Anfänger würde mit der Beschreibung einzelne Klassen, Methoden, Funktionen etc. auf die korrekte Ausführung testen. Dieser könnte noch die Dokumentation vervollständigen und mit dem debuggen anfangen. Wenn die Anfänger auf ihre Grenzen stoßen, wird die Bugs eine Instanz weiter geleitet. Dort wird die Dokumentation noch einmal überprüft (ob die Anfänger es wirklich verstanden haben) und die offenen Bugs bearbeitet. Trifft man dort wieder auf Grenzen, werden diese nochmal weiter geleitet. Der Profi behebt die letzten Bugs und verschafft sich noch einen überblick über das Gesamtprojekt.

Natürlich werden wir alle Debuggen und Dokumentieren müssen. Es sollte aber schon so aufgeteilt werde, dass die Anfänger die ersten sind, die mit dem Debuggen beginnen. Also den Code testen, auftrettende Fehler Dokumentieren, wenn möglich, den Fehler beseitigen, die Dokumentation erweitern und ein pull request an die Fortgeschrittenen senden. Vielleicht wären Teams wie Debugger_Instanz_1, Debugger_Instanz_2 und Debugger_Instanz_3 nötig dafür.

[Marrin]

Ich stelle mal die ketzerische Frage: Brauchen wird Teams? Grundsätzlich den Code dokumentieren sollte derjenige der ihn schreibt. Als Rolle könnte ich mir da vielleicht noch jemanden vorstellen der für so etwas wie Sphinx-Dokumentation zuständig ist, wenn Dokumentation mit so einem Werkzeug erstellt werden soll.

[cpdef]

Mit Sphinx kenne ich mich etwas aus, also ich habe schon mal mit rst und Sphinx eine Seite erstellt.
Allerdings bin ich die nächsten 3 Wochen (ab dem 7.8.) nicht mehr hier.

---

Das dürfte aber denke ich zu keinem Problem führen, wenn meinetwegen eine Woche noch Diskutiert wird, dann vieleicht die ersten anfangen etwas zu programmieren und dann ihre doku als .txt o.ä. schreiben. Dann sind 3 Wochen auch schon vorbei.

[sebastian2443]

Die Doku zum Quellcode als txt?
Sowas habe ich immer in den Quellcode geschrieben.
Also wenn es darum ging, zu beschreiben was die Funktionen oder Klassen machen.

Teams brauchen wir eigentlich nicht.
Von den Programmieraufgaben nimmt sich jeder immer, wenn er kann ein Happen.
Oder läuft das so nicht?

[cpdef]

Ja so geht das natürlich auch, vielleicht war das von mir etwas dumm überlegt.
(also die Doku in den Quelltext schreiben, und diese dann wie z.B. hier die Klassen in Sphinx darstellen)

Zu der Frage mit den Programmieraufgaben: Die sollten ja eigentlich gerade hier festgelegt werden.
andere Ideen gibt es bisher dazu nicht.

[sebastian2443]

Meilensteine sind doch aber keine Programmieraufgaben sondern Ziele auf die alle hinarbeiten.
Meilensteine lassen sich bisher auch schlecht ermitteln, wenn wir die Grundidee noch nicht in Zement gegossen haben.

[cpdef]

ok dann erst mal #7

[cpdef]

Am besten stimmen wir kurz mit 👍 ab ob wir die Teams löschen. Ich kann das wahrscheinlich
aber nicht mehr machen, da ich Morgen nur kurz und danach gar nicht mehr online bin.

Also 👍 = Teams werden gelöscht, 👎 eben nicht.