README & Projektstruktur optimieren: Sicherheit, Klarheit und Nutzerfreundlichkeit

Beschreibung:

Kontext

Dieses Issue sammelt konkrete Vorschläge zur Verbesserung des README und der Projektstruktur von DOITPi. Ziel ist es, das Projekt noch zugänglicher, sicherer und nutzerfreundlicher zu gestalten – besonders für die Zielgruppen Bildungseinrichtungen, Entwickler:innen und Lernende.

Die Vorschläge basieren auf einer detaillierten Analyse der aktuellen README und sind nach Priorität sortiert.

---

1. 🔒 Kritische Sicherheitshinweise (Priorität: Hoch)

a) Standard-Passwörter

• Problem:
  • Access Point: 123456789 (fest codiert, unsicher).
  • SSH: Unklar, ob Standard-Passwort oder Schlüssel verwendet wird.
• Lösung:
  • Access-Point-Passwort zufällig generieren (z. B. bei erstem Start).
  • SSH nur mit Public-Key erlauben (oder Standard-Passwort deutlich warnend kennzeichnen).
• README-Ergänzung:

  ⚠️ **Sicherheitshinweis:**
  - Das Access-Point-Passwort ist standardmäßig `123456789` – **ändere es nach der ersten Einrichtung!** (Siehe [Wiki: Sicherheit](../../wiki/Sicherheit)).
  - SSH verwendet ein **Standard-Passwort (`doitpi`)** – **deaktiviere es oder nutze Schlüssel!**
  

b) Hostname & Netzwerk

• Problem: Unklar, ob der Hostname automatisch gesetzt wird (z. B. doitpi-[ZUFALLSID]).
• Lösung: Im README präzisieren:

  🔧 **Automatische Einrichtung:**
  - Hostname: `doitpi-[ZUFALLSID]` (wird beim ersten Start generiert).
  - Access Point: Aktiviert sich **nur ohne WLAN** (SSID: `AP-<HOSTNAME>`).
  

---

2. 📖 Dokumentation & Klarheit (Priorität: Hoch)

a) „Vollautomatisch“ definieren

• Problem: Der Begriff ist mehrdeutig.
• Lösung: Kurze Erklärung hinzufügen (siehe oben).

b) Unterstützte Hardware

• Problem: Keine klare Liste der unterstützten Raspberry-Pi-Modelle.
• Lösung: Tabelle oder Liste einfügen:

  **Unterstützte Hardware:**
  | Modell               | Status          | Einschränkungen                     |
  |----------------------|-----------------|-------------------------------------|
  | Raspberry Pi 4       | ✅ Empfohlen    | Volle ROS2-Unterstützung            |
  | Raspberry Pi 5       | ⚠️ Experimentell | ROS2 möglicherweise instabil       |
  | Raspberry Pi Zero 2 W | ⚠️ Eingeschränkt | Kein ROS2, nur IoT/DevOps-Tools    |
  

c) Redundanzen in Tabellen bereinigen

• Problem: Doppelte Einträge (z. B. „Python, Bash, YAML“).
• Lösung: Tabellen thematisch trennen (z. B. „Programmiersprachen“ vs. „Anwendungsbereiche“).

---

3. 🛠️ GitHub-Optimierung (Priorität: Mittel)

a) Badges hinzufügen

• Vorschlag:

  [![GitHub Release](https://img.shields.io/github/v/release/kraeml/DOITPi)](https://github.com/kraeml/DOITPi/releases)
  [![GitHub License](https://img.shields.io/github/license/kraeml/DOITPi)](LICENSE)
  [![Build Status](https://img.shields.io/github/actions/workflow/status/kraeml/DOITPi/build.yml)](https://github.com/kraeml/DOITPi/actions)
  

b) Issue-Templates erstellen

• Vorschlag: Vorlagen für:
  • [Bug Report](https://github.com/kraeml/DOITPi/issues/new?template=bug_report.md)
  • [Feature Request](https://github.com/kraeml/DOITPi/issues/new?template=feature_request.md)

c) CONTRIBUTING.md auslagern

• Inhalt:
  • Schritt-für-Schritt-Anleitung für Pull Requests.
  • Code-Standards (z. B. shellcheck für Shell-Skripte).
  • Verweis auf „Good First Issues“.

---

4. 🎨 Visuelle Elemente (Priorität: Niedrig)

a) Screenshots/GIFs

• Vorschlag: Bilder hinzufügen für:
  • Node-RED-Flow (Beispiel: IoT-Sensor → MQTT → Grafana).
  • CodeServer-Oberfläche im Browser.
  • Access-Point-Anmeldung (Passwort unkenntlich machen).

b) Architekturdiagramm

• Vorschlag: Einfaches Mermaid-Diagramm:

  graph TD
    A[Raspberry Pi] --> B[ROS2]
    A --> C[Node-RED]
    A --> D[Mosquitto MQTT]
    C --> D
    B --> D
    D --> E[InfluxDB/Grafana]
  

---

5. 📚 Wiki & Externe Links (Priorität: Niedrig)

• Problem: Einige Wiki-Links könnten veraltet sein.
• Lösung:
  • Wiki-Seiten priorisieren (z. B. „Schnellstart“, „Sicherheit“).
  • Externe Links mit GitHub Actions automatisch prüfen.

---

Fragen an die Community

1. Sicherheit: Soll das Access-Point-Passwort zufällig generiert werden (erfordert Code-Änderungen)?
2. Dokumentation: Welche Hardware soll offiziell unterstützt werden?
3. GitHub: Soll ich Pull Requests für die README-Änderungen erstellen?