28 lines
1.9 KiB
Markdown
28 lines
1.9 KiB
Markdown
|
# How to set up an Open Source Project
|
|||
|
|
|
|||
|
|
inspiriert von Karl Fogel »[Producing Open Source Software](https://producingoss.com/)«, das auch [in deutscher Übersetzung](https://producingoss.com/de/index.html) vorliegt.
|
|||
|
|
|
|||
|
|
## Bevor es losgeht
|
|||
|
|
|
|||
|
|
Sieh’ dich um: wurde das Problem bereits von jemand anderem gelöst?
|
|||
|
|
|
|||
|
|
## Die private Vision in eine öffentliche verwandeln
|
|||
|
|
|
|||
|
|
1. Einen guten Namen auswählen
|
|||
|
|
2. Eine kurze und aussagekräftige Projektbeschreibung schreiben (Mission Statement)
|
|||
|
|
3. Klarmachen, dass das Projekt unter einer Open Source-Lizenz entwickelt wird. (z.B. GPL oder MIT)
|
|||
|
|
4. Liste auf, welche Features (auch geplante) die Software enthält, und welche Voraussetzungen benötigt werden (Features and Requirements List)
|
|||
|
|
5. Den Status der Entwicklung kommunizieren (z.B. in einer Projekt-Timeline oder mit einem Aktivitätstracker)
|
|||
|
|
6. Downloadmöglichkeit mit wenig Overhead und eindeutiger Versionsnummer schaffen
|
|||
|
|
7. Ein zugängliches Versionsverwaltungssystem und ein Bug-Tracker
|
|||
|
|
8. Kommunikationskanäle eröffnen
|
|||
|
|
9. Richtlinien für Entwickler_innen (Hinweis auf Kommunikationskanäle, Bug-Reporting, Einreichen von Patches, Art der Entwicklung)
|
|||
|
|
10. Dokumentation (Basics: einrichten, Arbeitsweise, erste Schritte, Tasks erledigen; ggf. noch zu dokumentierende Teile kennzeichnen; FAQ einrichten)
|
|||
|
|
11. Die Dokumentation verfügbar machen: online (User Documentation), sowie im Programmcode (Developer Documentation)
|
|||
|
|
12. Ggf.: Demos, Screenshots, Videos, Beispiele
|
|||
|
|
13. GitHub (o.ä.) hosted den Code, ggf. eine Website für User, die keine Entwickler_innen sind
|
|||
|
|
14. Eine Lizenz wählen (z.B. GPL oder MIT)
|
|||
|
|
15. Pflege eine gute Projektkultur
|
|||
|
|
16. Vermeide private, projektentscheidende Diskussionen (»If there's no reason for it to be private, it should be public.«)
|
|||
|
|
17. Unhöflichkeit von Beginn an abwürgen (Eigene Richtlinien ernstnehmen)
|
|||
|
|
18. Nutze Code-Reviews, um Qualität zu sichern und Entwickler_innen zu beteiligen und Feedback zu ermöglichen
|