|
|
| 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)
| |
| − | *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
| |
| − |
| |
| − |
| |
| − | **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
| |
