Diskussion Autorenschaft und Interaktivität: Unterschied zwischen den Versionen
Anna (Diskussion | Beiträge) (→Subversion: add) |
(→Kollaboration und Kontrolle) |
||
Zeile 43: | Zeile 43: | ||
--[[Benutzer:Anna|anna]] 08:44, 6. Jun. 2008 (CEST) | --[[Benutzer:Anna|anna]] 08:44, 6. Jun. 2008 (CEST) | ||
+ | |||
+ | |||
+ | == Kollaboration, Einsamkeit und Freiheit == | ||
+ | |||
+ | Echtzeit-Kollaborationstools ermöglichen nicht nur Versonsverwaltung und gegenseitiges Ergänzen/Korrigieren/Kommentieren eines Textes (Codes), sondern interaktives gleichzeitiges Bearbeiten (zB in Sitzungsreviews, wobei die Partner räumlich getrennt sein können und dann meist zusätzlich in Audio- bzw. Videoverbindung stehen). | ||
+ | |||
+ | Mitglieder autonomer Teams arbeiten nicht "in Einsamkeit"; sie sind hochgradig vernetzt, über Ziele und Gesamtkonzept bestens informiert. Sie arbeiten zwar intern im Rahmen der Möglichkeiten "in Freiheit", sind aber nach außen relativ streng gekoppelt. Zu strikte Arbeitsteilung im Team einerseits und zu lose Kopplung zwischen den Teams andererseits führen zu den oben von Andyk dargestellten Problemen. | ||
+ | |||
+ | Was die "Symphilosophie" betrifft, ist meines Wissens nicht viel herausgekommen, auch fand diese offenbar in den digitalen Medien bisher kaum Fortsetzung. Ein nur aneinanderreihender Austausch von Ideen ist nach meinem Verständnis keine Kollaboration, sondern Kooperation. So sehe ich auch dieses WIKI eher als Kooperationsplattform (das gilt wohl auch für das Tool "Subversion"). Wird daraus ein gemeinsames Ergebnis, das von allen Beteiligten getragen wird, von dem die einzelnen Baitragenden letztendlich evtl. nicht einmal mehr sagen können, welche Gedanken bzw. Elemente von ihnen beigesteuert wurden (zB ein Lernobjekt bzw. WIKIBOOK), so wäre das meines Erachtens Kollaboration. Dabei ist zwar Echtzeit-Kommunikatoin keine Voraussetzung, aber äußerst nützlich. Meine Erfahrung ist, dass zumindest in der Initiierungsphase (Zielsetzung, Spezifikation, Strukturierung) ein physisches Beisammensein erforderlich ist, dann läuft die nachfolgende Telekommunikation viel besser. Bewährt haben sich in einem derartigen Startworkshop zusätzliche gemeinsamen Aktivitäten außerhalb des Projektes, also sportliche, kulturelle und kulinarische Aktivitäten (oder in Abwandlung des OPen Culture Gedankens: "Free Speech '''and''' Free Beer") | ||
+ | |||
+ | --[[Benutzer:Hofbauerr|Hofbauerr]] 09:18, 6. Jun. 2008 (CEST) | ||
Aktuelle Version vom 6. Juni 2008, 08:18 Uhr
Kollaboration und Kontrolle
In der letzten Vorlesung (das ist jene vom 30.5.2008) wurde die Frage gestellt, ob Jemand, der in einem Stegreiftheater Einwürfe macht, ein Co-Autor ist. Die Grenze ist schwer zu ziehen. Sie liegt wohl irgendwo zwischen Applaus, Zugabe-Rufen, "No Amol" (Pradler Ritterspiele) und verbalen Einwürfen aus dem Publikum, aus denen sich manchmal Dialoge entwickeln (Tschauner).
Doch nicht nur im Theater gibt es "Feedback", auch bei elektronischen Medien, beginnend bei interaktiven TV Sendungen und Telefozzuschaltunfg von Hörern/Sehern, derzeit endend bei "Second Life". Dazwischen liegt das Feld interaktiver oder kooperativer Gestaltung, zB mittels WIKIs, Blogs, Foren. Nicht nur wenn Beiträge anonym erfolgen stellt sich die Frage, wer letztlich der Autor ist. In der Softwareproduktion ist Collaborative Working seit langem üblich. Auch wenn die Autoren rückverfolgbar wären, zählt die Gesamtleistung (Funktion, Kosten, Termin) der autonomen Entwicklergruppe ("empowered team"). Nicht-naturwissenschaftlich-technische Universitäten/Fakultären tun sich mit Kollaboration (im Unterschied zu Kooperation) noch schwer.
Kontrolle erfolgt bei Kollaboration nur auf Team-Ebene. Die Leistungen der einzelnen Team-Mitglieder mögen zwar erfasst sein, spielen aber bei der Bewertung keine Rolle. Kein Team trägt mittelfristig einen Faulpelz mit, sehr wohl aber (temporär) unverschuldete Minderleister, und das ist ein gesellschaftlicher Wert.
Bei Wissensarbeit (wozu auch Softwareentwicklung zählt, sei es angestellt oder selbstständig) findet Kontrolle nicht beim input (Zeitaufwand, Präsenz; enstprechend SSt oder ECTS) statt, was in einer vernetzten und telearbeitenden Welt auch gar nicht möglich wäre (Logonzeiten, Lines of Code, ja nicht einmal Functional Points sagen auf Individualebene etwas aus), sondern beim output, auch wenn dieser nicht genau messbar ist: Qualität der gelieferten Dienstleistung, Vertrauen statt Kontrolle (wobei auch ein Studium mittelfristig ist), Feedback statt unerklärter Code in Form von Geld (Incentives, Gehaltserhöhung) oder Note (wenige Prüfer geben bei schriftlichen Prüfungs- oder Seminararbeiten zusätzlich zur Note ein Feedback).
--Hofbauerr 22:01, 5. Jun. 2008 (CEST)
- Mir ist beim Lesen unwillkürlich die Symphilosophie eingefallen. Also man hat so wie es aussieht durchaus auch in der Philosophie Derivate von Kollaborationen ausprobiert, wobei die Symphilosophie ja noch ein paar Schritte weitergeht und sozusagen "kreative Wohngemeinschaften" zu bilden versucht, die nicht zwangsläufig outputorientiert sind.
- Bezüglich Softwarekollaboration kann ich nur zustimmen. Es ist großteils gar nicht mehr möglich, dass ein Einzelner sich hinsetzt, und ein umfangreiches Projekt von 0 auf und ganz alleine entwickelt. Aber sehr oft ist die Tätigkeit des Programmierens trotzdem eine einsame. Man zerlegt das große Projekt in Unmengen von Teilprojekten, wo der einzelne Programmierer das Gesamtkonzept nicht mehr notwendigerweise kennen muss (bzw. auch nicht immer soll).* Da stellen sich dann auch Fragen in Richtung: Verantwortung.
- *Beim ersten Teil der Cube-Trilogie kommen IMHO die möglichen fatalen Folgen einer radikalen isolierten Arbeitsteilung, wo die eine Hand nicht mehr weiß, was die andere tut, zur Sprache. Den Film (incl. Sequel und Prequel) kann ich empfehlen.
- Eine Referenz zu den oft verwendeten Kollaborationstools in der SW-Entwicklung: SVN bzw. der Vorgänger CVS
--Andyk 23:38, 5. Jun. 2008 (CEST)
Subversion
Dass die Diskussion hier auf "Subversion" kommt, ist ein schönes Beispiel von Interaktion, zusammen mit einer überraschenden Antizipation. Gestern habe ich im Seminar über diese Software gesprochen und ihren Gebrauch für das Sokrates-Projekt (Interaktive_Fiktion_(PJS)) erläutert. Wir verwenden dieses Repository und arbeiten speziell an diesen Dokumenten als Quellkode zur Erstellung eines interaktiven Spiels zum Thema Sokrates.
Hier ein paar Stichworte zur theoretischen Bedeutung dieser Software:
- Sie dient einem kreativen Arbeitsprozess in einer Gruppe, speziell in Fällen, in denen das Ergebnis streng reglementierten Erfordernissen genügen muss.
- Sie regelt den Arbeitsablauf nach dokumentierter Teilnahme in der Zeit. Sie produziert ein lückenloses Protokoll, das gleichzeitig die Möglichkeit eröffnet, hochflexibel zu disponieren.
- Sie schränkt die Freiheit am eigenen Desktop ein: Man muss die Dokumente "unter Versionsverwaltung stellen", d.h. einem Regime einpassen, das mit den Kooperationspartnerinnen prästabilisiert ist. Dafür partizipiert man quasi unmittelbar an der Aktivität aller Beteiligten.
Zum Versionsverwaltungsproblem:
- "Jemand anders hat diese Seite geändert, nachdem du angefangen hast diese zu bearbeiten. Das obere Textfeld enthält den aktuellen Stand. Das untere Textfeld enthält deine Änderungen. Bitte füge deine Änderungen in das obere Textfeld ein. Nur der Inhalt des oberen Textfeldes wird gespeichert, wenn du auf „Speichern“ klickst!"
--anna 08:44, 6. Jun. 2008 (CEST)
Kollaboration, Einsamkeit und Freiheit
Echtzeit-Kollaborationstools ermöglichen nicht nur Versonsverwaltung und gegenseitiges Ergänzen/Korrigieren/Kommentieren eines Textes (Codes), sondern interaktives gleichzeitiges Bearbeiten (zB in Sitzungsreviews, wobei die Partner räumlich getrennt sein können und dann meist zusätzlich in Audio- bzw. Videoverbindung stehen).
Mitglieder autonomer Teams arbeiten nicht "in Einsamkeit"; sie sind hochgradig vernetzt, über Ziele und Gesamtkonzept bestens informiert. Sie arbeiten zwar intern im Rahmen der Möglichkeiten "in Freiheit", sind aber nach außen relativ streng gekoppelt. Zu strikte Arbeitsteilung im Team einerseits und zu lose Kopplung zwischen den Teams andererseits führen zu den oben von Andyk dargestellten Problemen.
Was die "Symphilosophie" betrifft, ist meines Wissens nicht viel herausgekommen, auch fand diese offenbar in den digitalen Medien bisher kaum Fortsetzung. Ein nur aneinanderreihender Austausch von Ideen ist nach meinem Verständnis keine Kollaboration, sondern Kooperation. So sehe ich auch dieses WIKI eher als Kooperationsplattform (das gilt wohl auch für das Tool "Subversion"). Wird daraus ein gemeinsames Ergebnis, das von allen Beteiligten getragen wird, von dem die einzelnen Baitragenden letztendlich evtl. nicht einmal mehr sagen können, welche Gedanken bzw. Elemente von ihnen beigesteuert wurden (zB ein Lernobjekt bzw. WIKIBOOK), so wäre das meines Erachtens Kollaboration. Dabei ist zwar Echtzeit-Kommunikatoin keine Voraussetzung, aber äußerst nützlich. Meine Erfahrung ist, dass zumindest in der Initiierungsphase (Zielsetzung, Spezifikation, Strukturierung) ein physisches Beisammensein erforderlich ist, dann läuft die nachfolgende Telekommunikation viel besser. Bewährt haben sich in einem derartigen Startworkshop zusätzliche gemeinsamen Aktivitäten außerhalb des Projektes, also sportliche, kulturelle und kulinarische Aktivitäten (oder in Abwandlung des OPen Culture Gedankens: "Free Speech and Free Beer")
--Hofbauerr 09:18, 6. Jun. 2008 (CEST)
zurück zu Code: Kommunikation und Kontrolle (Vorlesung Hrachovec, 2007/08)