jan.bertram/portfolio
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Anforderungen und Hinweise zur Umsetzung

Browse Source
This commit is contained in:
Jan Bertram
2024-02-01 17:10:07 +01:00
parent 1b4f0253e0
commit 4759a44d55
3 changed files with 95 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
How_to_set_up_an_Open_Source_Project.md Normal file
View File

@@ -0,0 +1,28 @@
# 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