|
|
|
## Warum?
|
|
|
|
|
|
|
|
Marketing / Vernetzungs / Wissensaustausch
|
|
|
|
Zentraler Einstiegspunkt für das Thema Open Science Entwicklung an der SUB (oder Uni oder Campus) - wir sollten aber mit SUB starten. Kann mir aber auch vorstellen, dass die eRA da schnell dran interessiert ist bzw. wir ein wenig das machen, was sie auch machen wollen würde!? Wenn das der Fall wäre, dann sollten wir den Fokus doch eher auf Entwicklung von Tools und Services legen. Das ist auf alle Fälle unser "Cup of Tea"
|
|
|
|
|
|
|
|
## Wer?
|
|
|
|
|
|
|
|
Möglichst alle Entwickler und beteiligte Personen (PO, SM)
|
|
|
|
Auch Projektmanager mit der Sicht auf den Betrieb und das Management von Entwicklerteams.
|
|
|
|
Vielleicht sollten wir auch hier erstmal mit dem Fokus auf Entwickler starten, aber ich sehe da durchaus mehr Potenzial
|
|
|
|
|
|
|
|
|
|
|
|
## Wie?
|
|
|
|
|
|
|
|
### Inhalt
|
|
|
|
|
|
|
|
Alles aus den Entwicklungsbereichen.
|
|
|
|
Auch Datensets dort verlinken (siehe http://lab.kb.nl/)
|
|
|
|
Die Tools (GROSSE wie kleine), die wir anbieten, sollten dort präsentiert werden (Servicekatalog) -> Dann als Inhaltsseite und nicht als Blog? Ggf. Überschneidungen mit der SUB Seite
|
|
|
|
Die Sprache sollte keine Hürde darstellen, daher Deutsch. Aber auch gern Englisch, wenn damit mehr Erreichbarkeit möglich ist bzw. das Projekt ohnehin englisch kommuniziert.
|
|
|
|
Die Artikel dürfen auch kurz und knackig sein.
|
|
|
|
Kommentarfunktion? --> würde ich als notwendig sehen. Sonst ist ein WissensAUSTAUSCH schwer!?
|
|
|
|
Fokus auf Open Science Entwicklungen - wir machen eh alles OPEN. Damit haben wir auch einen Rahmen, in dem andere aus dem Haus sich beteiligen können. Um so mehr wir ansprechen, um so mehr können potentielle sich auch beteiligen.
|
|
|
|
|
|
|
|
Beispiele:
|
|
|
|
* Code Schnipsel die ein lange ungelöstes Problem lösen
|
|
|
|
* PM Strategien (geile Retros, Ideen, Grundsätze)
|
|
|
|
* Workflows
|
|
|
|
* Toolz
|
|
|
|
* Deployments
|
|
|
|
* Betrieb & Infrastruktur
|
|
|
|
* Sonstige erarbeitete Lösungen
|
|
|
|
* Technische Hintergründe zu gelaunchten Projekten (ggf. mit Verlinkungen von der SUB Seite)
|
|
|
|
|
|
|
|
Sollte ein Bild verpflichten beigefügt werden müssen? Immer besser, auch wenn stock photo. Wenn es sinnvoll ist, ja. Ich würde es nicht verpflichtend machen. Stock Photos sehen meist auch nach Stock Photos aus, also sehr beliebig.
|
|
|
|
Wenn man das Layout von lab.kb.nl als Vorbild nimmt (optisch), dann sind Bilder verpflichtend. Manchmal vielleicht einfach ein guter Screenshot
|
|
|
|
|
|
|
|
### Technologie
|
|
|
|
|
|
|
|
Wenig Hürden, ggf Jekyll mit Markdown. Jekyll auf Github ist perfekt für solche Sachen.
|
|
|
|
Kommentare mit Disqus oder etwas Ähnlichem
|
|
|
|
Themen können über ein Trello oder ähnliches Board geplant und vorbereitet werden. -> https://trello.com/b/pMuXDBiH
|
|
|
|
|
|
|
|
### Lizenz
|
|
|
|
CC-BY
|
|
|
|
|
|
|
|
DOIs für längere Artikel? --> gute Idee!
|
|
|
|
|
|
|
|
## Beispiele
|
|
|
|
https://uclab.fh-potsdam.de/
|
|
|
|
Ich finde immer noch das hier geil: http://lab.kb.nl/ (Drupal 7) -> ich finde nicht Drupal geil, sondern wie es aussieht und was es kann ;-)
|
|
|
|
|
|
|
|
## Wann?
|
|
|
|
|
|
|
|
Regelmäßige, jeder 2 Artikel im Jahr.
|
|
|
|
|
|
|
|
## Wo?
|
|
|
|
|
|
|
|
devblog.sub.uni-goettingen.de
|
|
|
|
dev.sub.uni-goettingen.de
|
|
|
|
subugoe.github.io
|
|
|
|
bits.sub.uni-goettingen.de
|
|
|
|
lab.sub.uni-goettingen.de
|
|
|
|
opensciencelab.sub.uni-goettingen.de
|
|
|
|
openscience.sub.uni-goettingen.de
|
|
|
|
open.sub.uni-goettingen.de (https://open.nytimes.com/)
|
|
|
|
open.uni-goettingen.de
|
|
|
|
|
|
|
|
ich würde etwas neutrales wie »lab« bevorzugen, »open science« gibt schon wieder eine thematische Richtung vor.
|
|
|
|
Ich finde 'lab' und 'open' gut. Die github domain würde halt das entwickler thema stark implizieren.
|
|
|
|
|
|
|
|
Es gibt auch die Domain ugoe.de - vielleicht kann man dann xxx.sub.ugoe.de nutzen. |
|
|
\ No newline at end of file |
