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 11:39]
pampel [Zur Person und zum Hintergrund] 		software:ws20130206 [2013/02/08 15:49] (current)
jklump [Materialien] Link to Strategies in Software Travel added
Line 88: Line 88:
 Heinz Pampel: Heinz Pampel:
  
-> Helmholtz Open Access Koordinationsbüro, re3data.org et al. +> Helmholtz Open Access Koordinationsbüro, re3data.org, et al. 
  
 ==== Wieso hat sich dieses Thema noch nicht erledigt? ==== ==== Wieso hat sich dieses Thema noch nicht erledigt? ====
Line 109: Line 109:
  
 > Da kann ich mich nur Martin Fenner anschließen: "Momentan kann man als Softwareentwickler in der Wissenschaft eigentlich keine Karriere machen. Auch wenn Software eigentlich ständig gebraucht wird." > Da kann ich mich nur Martin Fenner anschließen: "Momentan kann man als Softwareentwickler in der Wissenschaft eigentlich keine Karriere machen. Auch wenn Software eigentlich ständig gebraucht wird."
 +
 +Heinz Pampel:
 +
 +> Wissenschaftliche Leistung sollte nicht mehr länger alleine an der Anzahl der Paper gemessen werden. Wissenschaftlicher Output sollte umfassender betrachtet werden. Die National Science Foundation (NSF) [[http://datapub.cdlib.org/data-to-receive-recognition-from-nsf/|zeigt]] wohin die Reise geht: Seit Anfang des Jahres kann auch Software bei der Antragstellung - als wissenschaftlicher Output - gelistet werden.
 +> Darüber hinaus sollten alle Ergebnisse wissenschaftlicher Arbeit dauerhaft zugänglich gemacht werden. Also auch Software und ihre Dokumentation. Nachnutzung und Nachprüfbarkeit sollen auch nach Ende eines Projektes oder Weggang eines Programmierers möglich sein. 
 +> Ziel sollt es sein Strategien der Software-Publikation zu identifizieren, die Anerkennung, Nachnutzung und Nachprüfbarkeit ermöglichen. 
 + 
 +
 +
  
 ==== Was sind euer Erfahrungen mit wissenschaftlichem Code, Zugang zu Code, Veröffentlichung, Anerkennung als wissenschaftliche Leistung? ==== ==== Was sind euer Erfahrungen mit wissenschaftlichem Code, Zugang zu Code, Veröffentlichung, Anerkennung als wissenschaftliche Leistung? ====
Line 127: 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 143: 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 168: 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 179: 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 246: 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 279: 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 285: Line 312:
  
 [[software:start#resources|Materialien]] [[software:start#resources|Materialien]]
 +
 +[[software:ws20130206:softwaretravel|Strategies in software travel]]
  
  
software/ws20130206.1360064391.txt.gz · Last modified: 2013/02/05 11:39 by pampel

Page Tools

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki