This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
software:ws20130206 [2013/02/05 12:21] pampel [Was sind eure Erwartungen an die Veranstaltung?] |
software:ws20130206 [2013/02/08 15:49] (current) jklump [Materialien] Link to Strategies in Software Travel added |
||
|---|---|---|---|
| Line 184: | 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/ | > 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/ | ||
| + | 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 195: | 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, | ||
| ==== 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 262: | 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 295: | Line 302: | ||
| > Ja. Ob digitale Hardware oder Arbeitsteams " | > Ja. Ob digitale Hardware oder Arbeitsteams " | ||
| + | |||
| + | Heinz Pampel: | ||
| + | |||
| + | > Mit Blick auf die Nachnutzung ist jegliche Dokumention wertvoll und sinvoll. Längerfristig müssen die einzelnen Disziplinen Stratgien entwickeln. | ||
| Line 301: | Line 312: | ||
| [[software: | [[software: | ||
| + | |||
| + | [[software: | ||