|
|
(One intermediate revision by one other user not shown) |
Line 1: |
Line 1: |
− | ==Task repository:==
| |
| | | |
− | =Open tasks:=
| |
− | *Management structure
| |
− | General Information
| |
− | What is nydus one?
| |
− | formal constitution
| |
− | What do we do?
| |
− | What are our aims?
| |
− | Where to put which information?
| |
− | What information to expose to whom? (think of target groups like potencial members, etc)
| |
− | Do we need tutorials?
| |
− | What are our active projects?
| |
− | finished projects
| |
− | For new members
| |
− | principles of membership
| |
− | What are the general workflows we have? (Protocols, Pull-principle, ...)
| |
− | How does collaboration look like?
| |
− | How can I contribute to a project?
| |
− | how can I come up with my own projects
| |
− | what kind of projects do we support
| |
− | how can we help you
| |
− | What are our tools?
| |
− | how to get in touch
| |
− | rules of conduct
| |
− | For new partners
| |
− | current parnters
| |
− | what are we looking for
| |
− | how to get in touch? -> Cooperate@nydus.com?
| |
− | internal section
| |
− | protocols /final reports
| |
− | publications
| |
− | corporate finance
| |
− | fundings / how to get a funding
| |
− | bill board / search and find
| |
− |
| |
− |
| |
− | *contacts of people: Kai Gehring, Hexamer, Open network structure?
| |
− | *Marcs projects: FinTech, Historical Data management,
| |
− | * Disclaimer for website:The website needs to be conform with the european and german law.
| |
− |
| |
− | My current information is, that we need
| |
− |
| |
− | Imprint (§ 5 TMG and § 55 RStV)
| |
− | Data&Privacy (§?? DSGVO?)
| |
− | Disclaimer (312 O 85/98)
| |
− | *Google Drive Einbindung https://drive.google.com/drive/folders/0B6mmUpRdtDgcajlROHJyT3BaT00
| |
− | *BCI-Cluster shizzle (to be done later)
| |
− | *Digitalisierung vom Bioprinter (Teile, Konzepte, Anleitung, Steuerung via Octopi? uvm. Mosig hat Image Processing von geprinteten Strukturen angeboten)
| |
− | *Extruder Version V2. Besonders wichtig: Kraftsensoren, Endstops, Digitalisierung?, Getrirebe (Auflösung)
| |
− | *Discord Invite Link: https://discordapp.com/invite/UJb7FFc
| |
− | G-Drive Link https://drive.google.com/drive/folders/0B6mmUpRdtDgcajlROHJyT3BaT00
| |
− |
| |
− |
| |
− | **Grundlegende Fragen vorab:**
| |
− |
| |
− | - Wie definieren wir Projekte
| |
− | - Wie definieren wir Milestones
| |
− | - Wie definieren wir Teilprojekte
| |
− | - Wie definieren wir einen Projektmanager (PM)
| |
− | - Welche weiteren Rollen sind relevant (Assistent PM(APM)?, Mentibzw. Padawan?)
| |
− |
| |
− |
| |
− | **Taskmanagement:**
| |
− |
| |
− | - Wie werden Task definiert
| |
− | - Wie definieren wir Subtask (Wie kleinteilig und wie groß dürfen Aufgaben sein)
| |
− | - Wer darf Tasks in den jeweiligen Projekten beschreiben bzw. festlegen? Vorschlag, nur PM? (Eventuell auch Assistant?)Wie bzw. wonach sollen Task priorisiert werden? Prio durch PM oder APM?
| |
− | - Definition für Regeln, vor allem, wann sind Tasks Blocker
| |
− | - **Welche Task-Stati benötigen wir?**
| |
− | -- Benötigen wir ein Reasigned/Review Status?
| |
− | - **Gibt es ein Task-Tracking?**
| |
− | -- Tracking vorerst nach Bearbeitungszeit
| |
− | -- Kein Tracking im Sinne von Bearbeitungsetappen (Sprints)
| |
− | -- Vorerst kein Scoring
| |
− | -- Wollen wir Regeln für Task/Aufwand (z.b. leicht, mittel, aufwendig)-> vorerst unnötig
| |
− | - **Pull oder Push Prinzip bei Task**
| |
− | -- möglichst kein oder minimalst Push, wenn Push, dann feste Regeln
| |
− | -- Nachteile Push, Keine festdefinierten Zeiträume und keine definierte maximale Auslastung, daher stark von persönlicher Einschätzung abhängig Aus diesem Grunde arbeiten nach Pull
| |
− | -- Alternative zu Pull -> Request
| |
− | -- Request läuft Adressatenbezogen durch PM (APM?) also direkt an jeweilige Person (Empfehlung).
| |
− |
| |
− | **Kanban:**
| |
− | - **Wie soll der Aufbau gestaltet werden**
| |
− | -- Wir geben Empfehlungen, vor allem zu Beginn, einzelne Projekte können sich langfristig selbst organisieren
| |
− | -- Empfehlung: Workboards nach Arbeitsbereichen: Backlog, Mechanik, Elektronik, Software. Oder: Backlog, MVP, FutureApp
| |
− | -- Workflow Abbildung durch Prozesse, nicht durch Boardstruktur
| |
− | -- Wichtig! Klare Definition von "Bereichen" in Abgrenzung zu Teilprojekten!
| |
− | -- Festlegung der Workboards soll über Mitgliederbefragungen im Nydus festgelegt werden (Was wollt ihr haben, was würde Sinn machen, was würde helfen
| |
− |
| |
− | **Dokumentation:**
| |
− | - Auch hier, Empfehlungen und keine Richtlinien für Dokumentation innerhalb der Einzelprojekte
| |
− | - Keine Dateianhänge!
| |
− | - Wie soll das Wiki gegliedert werden?
| |
− | - Wann und wofür wird ein Blog verwendet
| |
− | - Welche Dokustruktur (Z.B. nach Fragen: Was, wie, warum? - Kurz vs ausführlich
| |