=== Siehe auch === MeatBall:WikiAsSourceControlRepository

Motivation

Wikis sind dafür bekannt, daß sie einen hohen Grad an Kollaboration und Kommunikation fördern. Die Nutzung eines Wiki-ähnlichen Mechanismus für die Softwareentwicklung ist hier für mich eine interessante Fortsetzung dieser Idee.

Vorallem die direkte Anwendbarkeit von ExtremeProgramming-Methoden finde ich als Ziel sehr reizvoll.

-- DavidSchmitt

Zielvorstellung

Verwaltung eines kompletten OpenSourceHosts in einer Wiki-ähnlichen Struktur.

Bestandteile:

• SourceCode
• Dokumentation
• VersionsKontrolle
• ReleaseMechanismus?
• TestFramework
• BugTracking?

Umsetzung

notwendige Modifikationen:

• komplette VersionsKontrolle mit z.B. cvs
• Export-/Importmöglichkeiten für größere Änderungen am SourceCode
• Behandlung großer Mengen von <nowiki> Daten
• trotzdem SyntaxHighlighting plus WikiElemente? im Code
• tiefe Hierarchien müssen möglich sein
• Flexibles Auflösen von Referenzen auf andere Seiten
• erweiterte Interfaces für Inhaltsgenerierung. z.B. MailToWikiInterface?

Anwendung

Im speziellen habe ich dabei die Wartung von Debian Paketen im Hinterkopf. Das würde dann noch einige weiterführende Funktionen interessant machen und vorallem in der Struktur des Projektes interessante Möglichkeiten für QA-Arbeit ermöglichen. Ähnlich dem ports System von BSD.

-- DavidSchmitt

Siehe auch

MeatBall:WikiAsSourceControlRepository

FeedBack

• Sehr erwünscht.

Fragen

Ist die Zielvorstellung wirklich eine Infrastruktur für beliebig viele (frei anlegbare) OS Projekte?

Konkret habe ich an eine Infrastruktur zur Entwicklung von Debian Paketen gedacht. Das ist allerdings eine funktionelle Übermenge dessen, was ich hier beschreibe.

Das wäre auch möglich.

Die Zugangsschranke wird stark reduziert. Es ist wesentlich einfacher auf 'Edit this text' zu klicken und eine Kleinigkeit auszubessern oder nachzusehen, als ein cvs checkout zu machen.

Verbesserte Dokumentation durch die Möglichkeiten, die einem das Hypermedium bietet.

Das andere was mich an der Idee fasziniert, ist daß hier die entsprechenden technischen Vorraussetzungen für Methoden wie KurzeReleaseZyklen, KomponentenTests, GemeinsameVerantwortlichkeit und FortlaufendeIntegration anbieten lassen.

Als Erweiterung für die Paketentwicklung bei Debian, würden sich auch einige QA-Arbeiten - orthogonal zu den "Maintainern" der einzelnen Pakete - erledigen lassen, ohne großen Overhead.

zB BugReports?, die via Email eingeschickt werden, um dann auf BugReports/Paket/BlahBlah? aufzutauchen. Der Einsender wird dann bei Änderungen an der Seite benachrichtigt.

Auch hier wieder als Versuch die Zugangsbarrieren zu verringern.