Wurde schon desöfteren versucht und ist immer gescheitert. (kannst mal in Board Diskussionen suchen)

würde ich nicht gut finden, dann machen irgnetwelche anfänger mit, die eigentlich nicht programmieren können und da ist mit ausbessern des codes schon viel zu lange beschäftigt

@Higlav: Programmiere nur mit solchen Leuten zusammen, die zusammenzucken, wenn Du brüllst.
Soll heißen sie sollten im selben Zimmer / Büro sitzen und alle sollten denselben Server benutzen.

RodFromGermany schrieb:

@Higlav Programmiere nur mit solchen Leuten zusammen, die zusammenzucken, wenn Du brüllst.
Soll heißen sie sollten im selben Zimmer / Büro sitzen und alle sollten denselben Server benutzen.

Und mit dieser Meldung disqualifizierst du über 90% der Opensource Projekte.

Was den Schaden angeht müsste es natürlich einen Teamserver geben bei dem halt nur wenige User checkin Rechte haben. Neben dem Teamserver müsste es auch eine Art Platform geben bei der auch andere Code beitragen können(den aktuellen Code bekommen sie vom Teamserver). Ist dieser Code immer mit einer gewissen Qualität verbunden kann man sie ins Kernteam aufnehmen. Jedoch ist der Organisationsaufwand wahrscheinlich einfach zu groß und sowas bekommste auch nicht zum laufen.

Sowas hatten wir nun schon unzählige Male. Früher gab es auch ein eigenes Unterforum für die verschiedenen Community-Projekte (Direct-RC, XP-Sidebar und Jump High). Alle sind gescheitert. So schnell wird's sowas auch nicht mehr geben.

thefiloe schrieb:

sowas bekommste auch nicht zum laufen.

git init - Git ist ziemlich genau das, was du da beschrieben hast.

Natürlich weiß ich, dass man den Teamserver zum laufen bekommt
Ich meinte damit das Projekt an sich. Du bekommst das mit fast jedem Teamserver zum laufen. Ob dies nun git, tfs,... ist macht da nicht viel unterschied. Aber, dass das Projekt wirklich ankommt, läuft und daran gearbeitet wird -> ist schwer hinzubekommen.

Hi
will ja keinem hier zu nahe treten, aber von der Einschätzung her sind viele der Leute schon mit Klassen, Vererbung, etc. überfordert. Das sind aber erforderliche Kenntnisse, da man sich sonst gegenseitig den Code zerlegt (man stelle sich eine 20000-Zeilen Form vor :P). Viele Köche verderben bekanntlich den Code und da es sich eben um Communityprojekte handeln würde, wäre es auch nicht möglich, Leute davon auszuschließen - va. wer nimmt sich's heraus, jemand anderen als schlecht einzustufen? Dagegen steht halt auch der Gedanke, dass die Leute, die's noch nicht können, die Chance bekommen, schnell zu lernen, da es halt sehr anspruchsvoll sein kann, sich in den Code anderer einzulesen und zu verstehen oder sich neue Konzepte anzueignen. Das Problem, das ich allerdings ebenfalls da sehe ist, dass man auch gemeinsam gegen eine Wand fahren kann, wenn man sich gemeinsam falsche Programmierweisen angewöhnt. Das Problem bei den bisherigen Community-Projekten ist afaik, dass am Anfang jeder euphorisch dabei ist und dann immer mehr Leute keine Lust oder Zeit mehr haben. Da es keinen "Zwang" gibt, der die Leute an die Projekte bindet, gibt's auch keine Garantie, dass die durchlaufen.
Aus meiner Sicht wären Community-Projekte zwar sinnvoll, aber praktisch nicht ohne durchdachtes Konzept und dauerhaft aktiver Beteiligung möglich. Wenn man's wirklich durchziehen möchte, wäre es vllt. gut, das Projekt in Einzelkomponenten zu zerteilen, die sukzessive nach oben programmiert und getestet werden, bis das Programm letztendlich fertig ist. Die Leute, die Interesse am Projekt haben, können sich dann eben zu einer Gruppe melden oder werden zugeteilt und pro Gruppe gibt's dann einen "Experten", der die Richtlinien und Zuständigkeiten vorgibt. Regelmäßige, automatisierte Backups sind ebenfalls Pflicht. Wenn es immer kleine, einzelne Komponenten sind, die unabhängig voneinander entwickelt werden können, ist's auch nicht soo tragisch, wenn wirklich jemand aussteigt und die Arbeit ist dann auch nicht umsonst gewesen.
Das setzt aber dann wirklich voraus, dass die Leute lernwillig sind und auch mal ihren Horizont erweitern und ihren Kopf anstrengen - dafür ist er ja eigentlich auch da!
Für das Konzept wäre es wichtig, dass jeder weiß, was der andere im Team übernimmt und dass sich die Gruppen untereinander absprechen. Das wird dann eben anfangs auf Basis der Softwareanforderungen ausdiskutiert und den Gruppen zugeteilt, die dann das noch mal in sich diskutieren und Konzeptfehler ausdiskutieren, diese dann an die anderen Gruppen weitergeben, etc. Sobald alles soweit fertig designt ist und die Leute sich das nötige Wissen angeeignet haben, kann man erst anfangen, das zu implementieren. Da wäre es evtl. auch gut, ungefähre Termine festzulegen und "Ersatzarbeiten". Man sollte außerdem die Möglichkeit offen lassen, später Details und Ergänzungen einzubauen (==> Abstraktion!).
Ich hab' zwar eh nicht das letzte Wort und ich will mich jetzt auch nicht wichtig machen, aber ich denke mal, dass es ohne die interne Organisation und Vorarbeit fast nicht möglich ist, ein anständiges Programm in einer großen Gruppe zu programmieren. Spaß würde es so auf jeden Fall machen, wahrscheinlich sogar dauerhaft für die meisten und man würde auch nicht nur Programmieren lernen, sondern auch Kompetenzen in der Organisation, usw. bekommen. Das heißt aber auch, dass man mal längere Zeit in ein Projekt investiert, weil das nicht mit 30 Minuten am Tag gemacht ist, sonst zieht sich's hin und verliert sich wieder im nirgendwo.

Gruß
~blaze~

thefiloe schrieb:

Und mit dieser Meldung disqualifizierst du über 90% der Opensource Projekte.

Das war nicht meine Absicht, denn ich habe Higlav explizit persönlich angesprochen und so keinen Raum für eine Verallgemeinerung auf andere Leute und andere Projekte gelassen.