DataWiki

User Tools

Site Tools

Trace: • ws20130206 • system_architecture • namespace_allocation_proposal • overview
software:ws20130206

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
software:ws20130206 [2013/02/05 12:06]
pampel [Wieso hat sich dieses Thema noch nicht erledigt?] 		software:ws20130206 [2013/02/08 15:49] (current)
jklump [Materialien] Link to Strategies in Software Travel added
Line 136: Line 136:
  
 > Software bzw -entwicklung wird nicht allzu sehr anerkannt, sondern ist ein notwendiges übel, was nebenbei abfallen muss. Aber das ist meine persönliche Erfahrung und kann ich anderen Disziplinen ganz anders gelagert sein. > Software bzw -entwicklung wird nicht allzu sehr anerkannt, sondern ist ein notwendiges übel, was nebenbei abfallen muss. Aber das ist meine persönliche Erfahrung und kann ich anderen Disziplinen ganz anders gelagert sein.
 +
 +Heinz Pampel:
 +
 +> Die Bedeutung von Software steigt in allen Disziplinen (siehe z.B. die Diskussionen um die Digital Humanities). Damit gewinnt die Professionalisierung der Entwickler an Bedeutung. (In den Biowissenschaften gibt es z.B. Konferenzen und Berufsverbände, die die Interessen dieser Akteure vertreten.) Eine solche Professionalisierung scheint auch in anderen Disziplinen nötig. Diese Professionalisierung könnte helfen die Anerkennung der Arbeit und auch die Praxis der Entwickler (z.B. mit Blick auf Publikationsstrategien) zu verbessern. 
  
  
Line 152: Line 156:
 > Lebendiger Austausch mit anderen Entwicklern. > Lebendiger Austausch mit anderen Entwicklern.
  
 +Heinz Pampel
 +
 +> Ideensammlung. Multidisziplinärer Diskurs. Blick in die Zukunft. 
 ==== Was sind eure Wünsche oder Ziele im Umgang mit wissenschaftlichem Code? ==== ==== Was sind eure Wünsche oder Ziele im Umgang mit wissenschaftlichem Code? ====
  
Line 177: Line 184:
 > Der hohe Bekanntheitsgrad ermöglicht schnelleres Auffinden von thematisch ähnlich gelagerten Projekten. Doch gerade bei Verwendung von verteilter Versionskontrolle (z.B. git) spricht nichts dagegen den Code auf Github sowie auf anderen/eigenen Repositories zu hosten. > Der hohe Bekanntheitsgrad ermöglicht schnelleres Auffinden von thematisch ähnlich gelagerten Projekten. Doch gerade bei Verwendung von verteilter Versionskontrolle (z.B. git) spricht nichts dagegen den Code auf Github sowie auf anderen/eigenen Repositories zu hosten.
  
 +Heinz Pampel:
  
 +> Funktionalität steht im Vordergrund (usability). Eine dauerhafte Speicherung wird nicht garantiert. Grundsätzlich stellt sich die Frage ob privat-wirtschaftliche Akteure die optimalen Player für persistente Lösungen sind. 
 ==== Wie könnte ein Qualitäts-Check jenseits des klassischen Peer-Review aussehen? ==== ==== Wie könnte ein Qualitäts-Check jenseits des klassischen Peer-Review aussehen? ====
  
Line 188: Line 197:
 > Unit tests. Natürlich muss Anfwand abgewogen werden. > Unit tests. Natürlich muss Anfwand abgewogen werden.
  
 +Heinz Pampel:
 +
 +> Das Verfahren der Qualitätssicherung schient abhängig von der Publikationsstrategie zu sein. Wir ein Paper veröffentlicht, dass die Software dokumentiert, sind klare inhaltliche Anforderungen an den Review-Prozess notwendig. Sollte darüber hinaus auch die Software geprüft werden, so müssen auch hier klare Anforderungen (technische und inhaltliche) formuliert werden. Wichtig wäre es den Gutachter beim Review zu unterstützen. Je komplexer die Software-Produkte desto aufwändiger wird der Review-Prozess sei. Ggf. müsste das Journal auch eine Server für Testinstallationen bereitstellen. 
 ==== Welche Erfahrungen habt ihr mit der Wahl von Lizenzen und mit Lizenzkonflikten? ==== ==== Welche Erfahrungen habt ihr mit der Wahl von Lizenzen und mit Lizenzkonflikten? ====
  
Line 255: Line 267:
 > Man darf nicht aus den Augen verlieren, dass die wissenschaftliche Arbeit Priorität hat: Software verteilfähig zu machen ist mit nicht geringem Aufwand verbunden. Andererseits kann die Korrektheit der Software durch Öffentlichkeit profitieren. Um ständige Abwägung kommt man, fürchte ich, nicht herum. > Man darf nicht aus den Augen verlieren, dass die wissenschaftliche Arbeit Priorität hat: Software verteilfähig zu machen ist mit nicht geringem Aufwand verbunden. Andererseits kann die Korrektheit der Software durch Öffentlichkeit profitieren. Um ständige Abwägung kommt man, fürchte ich, nicht herum.
  
 +Heinz Pampel:
  
 +> Ein Paper, dass Software beschreibt, scheint nur dann sinnig, wenn der Code zum Zeitpunkt der Veröffentlichung zugänglich ist. Anderfalls müsste auch überlegt werden, wie die Software begutachtet werden kann. 
 ==== Wie soll die langfristige Strategie eines Code Repository sein (t > 5 Jahre) ==== ==== Wie soll die langfristige Strategie eines Code Repository sein (t > 5 Jahre) ====
  
Line 288: Line 302:
 > Ja. Ob digitale Hardware oder Arbeitsteams "programmiert" werden scheint aus struktureller Sicht nur ein Detail zu sein ... > Ja. Ob digitale Hardware oder Arbeitsteams "programmiert" werden scheint aus struktureller Sicht nur ein Detail zu sein ...
  
 +
 +Heinz Pampel:
 +
 +> Mit Blick auf die Nachnutzung ist jegliche Dokumention wertvoll und sinvoll. Längerfristig müssen die einzelnen Disziplinen Stratgien entwickeln. 
  
  
Line 294: Line 312:
  
 [[software:start#resources|Materialien]] [[software:start#resources|Materialien]]
 +
 +[[software:ws20130206:softwaretravel|Strategies in software travel]]
  
  
software/ws20130206.1360065972.txt.gz · Last modified: 2013/02/05 12:06 by pampel

Page Tools

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki