gitea: add checklist to the pull request template #279

jkimmel · 2023-02-20T17:47:58+01:00

jkimmel commented

2023-02-20 17:47:58 +01:00

Add a small pull request template that communicates the basic
requirements for submissions to be included in the code base.

Add a small pull request template that communicates the basic requirements for submissions to be included in the code base.

jkimmel added 1 commit 2023-02-20 17:47:58 +01:00

ci/woodpecker/pr/woodpecker Pipeline is pending Details

42d3f63002 gitea: add checklist to the pull request template

Add a small pull request template that communicates the basic
requirements for submissions to be included in the code base.

jkimmel commented

2023-02-20 17:52:38 +01:00

Ich bin kein Anwalt, also gerne Verbesserungsvorschläge für den Wortlaut melden. Vielleicht können wir uns darauf verständigen, dass es uns die Hinweise genügen und damit auf Klarnamenspflich, sowie das Signed-Off-By in Zukunft verzichten können.

Ich glaube auch, dass ein Kommentar reicht und wir nicht unbedingt verpflichtende Checkboxen oder so mit ins Template nehmen müssen: https://docs.gitea.io/en-us/issue-pull-request-templates/#syntax-for-yaml-template

Ich bin kein Anwalt, also gerne Verbesserungsvorschläge für den Wortlaut melden. Vielleicht können wir uns darauf verständigen, dass es uns die Hinweise genügen und damit auf Klarnamenspflich, sowie das `Signed-Off-By` in Zukunft verzichten können. Ich glaube auch, dass ein Kommentar reicht und wir nicht unbedingt verpflichtende Checkboxen oder so mit ins Template nehmen müssen: https://docs.gitea.io/en-us/issue-pull-request-templates/#syntax-for-yaml-template

fbl commented

2023-02-20 18:25:13 +01:00

dass es uns die Hinweise genügen und damit auf Klarnamenspflich, sowie das Signed-Off-By in Zukunft verzichten können

Da bisher keiner so richtig begründen konnte, warum wir das überhaupt bisher so gemacht haben, sehe ich erst einmal nichts, was hier dagegen spricht. Die Klarnamenpflicht haben wir ja eh schon aufgelöst. Bis für alle genug Zeit war sich zu diesem Thema zu äußern würde ich mir aber wünschen, dass wir uns an die bisherigen (teilweise ungeschriebenen) Richtlinien halten.

Ich glaube auch, dass ein Kommentar reicht und wir nicht unbedingt verpflichtende Checkboxen oder so mit ins Template nehmen müssen: https://docs.gitea.io/en-us/issue-pull-request-templates/#syntax-for-yaml-template

Ich bin in jedem Fall dafür das ganze lieber früher als später aufzunehmen. Verbesserungsvorschläge oder Änderungswünsche kommen am ehesten dann, wenn schon mal was als Basis da ist.

Das ganze sollten wir später vielleicht noch um etwas ausführlichere Contribution Guidelines (analog zu beispielsweise GitHub oder Rails) ergänzen, in denen dann beispielsweise auch eine Anleitung zum Pull Request machen drin sein könnte.

Weiterhin wäre das ganze auch für Issues eine gute Idee.

Verbesserungsvorschläge für den Wortlaut

Ich war mal so frei und habe mir ein bisschen was von verschiedenen Stellen zusammenkopiert.

## Beschreibung

Zusammenfassung der Änderungen, ggf. Anmerkung der gelösten Tickets aus dem Bug Tracker. Motivation für die Änderung.

Fixes # (issue)


### Abhängigkeiten

Hier alle Abhängigkeiten für diese Änderung (z.B. noch offene Pull Requests) eintragen, andernfalls entfernen.


### Tags

- [ ] Bugfix
- [ ] Feature
- [ ] Breaking change
- [ ] Erfordert Änderungen an der Dokumentation


## Checkliste (bitte entfernen)

- [ ] Alle Änderungen wurden von mir selbst erstellt oder ich habe vom Autor die Berechtigung diese in die Freifunk Franken Firmware unter der angegebenen freien Lizenz zu verwenden.
- [ ] Änderungen, die ein im [Bug Tracker](https://git.freifunk-franken.de/freifunk-franken/firmware/issues) eingetragenes Ticket oder einen früheren Commit beheben, sind in den entsprechenden Commits mit `Fixes: #123` oder `Fixes: <sha1sum>` angemerkt.
- [ ] Die Änderungen wurden grundlegend getestet. Dies ist mit `Tested-by: Name <email@domain.tld>` in den entsprechenden Commits angemerkt.
- [ ] Passende Änderungen an der Dokumentation sind vorbereitet

> dass es uns die Hinweise genügen und damit auf Klarnamenspflich, sowie das Signed-Off-By in Zukunft verzichten können Da bisher keiner so richtig begründen konnte, warum wir das überhaupt bisher so gemacht haben, sehe ich erst einmal nichts, was hier dagegen spricht. Die Klarnamenpflicht haben wir ja eh schon aufgelöst. Bis für alle genug Zeit war sich zu diesem Thema zu äußern würde ich mir aber wünschen, dass wir uns an die bisherigen (teilweise ungeschriebenen) Richtlinien halten. > Ich glaube auch, dass ein Kommentar reicht und wir nicht unbedingt verpflichtende Checkboxen oder so mit ins Template nehmen müssen: https://docs.gitea.io/en-us/issue-pull-request-templates/#syntax-for-yaml-template Ich bin in jedem Fall dafür das ganze lieber früher als später aufzunehmen. Verbesserungsvorschläge oder Änderungswünsche kommen am ehesten dann, wenn schon mal was als Basis da ist. Das ganze sollten wir später vielleicht noch um etwas ausführlichere Contribution Guidelines (analog zu beispielsweise [GitHub](https://github.com/github/docs/blob/main/CONTRIBUTING.md) oder [Rails](https://github.com/rails/rails/blob/main/CONTRIBUTING.md)) ergänzen, in denen dann beispielsweise auch eine Anleitung zum Pull Request machen drin sein könnte. Weiterhin wäre das ganze auch für Issues eine gute Idee. > Verbesserungsvorschläge für den Wortlaut Ich war mal so frei und habe mir ein bisschen was von verschiedenen Stellen zusammenkopiert. ``` ## Beschreibung Zusammenfassung der Änderungen, ggf. Anmerkung der gelösten Tickets aus dem Bug Tracker. Motivation für die Änderung. Fixes # (issue) ### Abhängigkeiten Hier alle Abhängigkeiten für diese Änderung (z.B. noch offene Pull Requests) eintragen, andernfalls entfernen. ### Tags - [ ] Bugfix - [ ] Feature - [ ] Breaking change - [ ] Erfordert Änderungen an der Dokumentation ## Checkliste (bitte entfernen) - [ ] Alle Änderungen wurden von mir selbst erstellt oder ich habe vom Autor die Berechtigung diese in die Freifunk Franken Firmware unter der angegebenen freien Lizenz zu verwenden. - [ ] Änderungen, die ein im [Bug Tracker](https://git.freifunk-franken.de/freifunk-franken/firmware/issues) eingetragenes Ticket oder einen früheren Commit beheben, sind in den entsprechenden Commits mit `Fixes: #123` oder `Fixes: <sha1sum>` angemerkt. - [ ] Die Änderungen wurden grundlegend getestet. Dies ist mit `Tested-by: Name <email@domain.tld>` in den entsprechenden Commits angemerkt. - [ ] Passende Änderungen an der Dokumentation sind vorbereitet ```

jkimmel commented

2023-02-20 23:48:59 +01:00

Also ich persönlich finde zu Umfangreiche Templates immer etwas lästig, vor allem, wenn sehr viele Eventualitäten abgedeckt sind und man erst mal eine Minute Zeug entfernen muss.

In https://github.com/go-gitea/gitea/pull/22888/files gibt es den Vorschlag die Hinweise mit Kommentare zu versehen, dass sie im Notfall automatisch gelöscht werden können. Eventuell ist das ein Kompromiss. Die Infrastruktur dafür hätten wir.

Wenn ich die Dokumentation richtig lese, kann man nur für Issues mehrere Templates anlegen (https://docs.gitea.io/en-us/issue-pull-request-templates/#directory-names). Man kann dann eine Auswahl treffen und dann gezieltere Hilfestellung geben und dann auch passend Labels verteilen (Bugs vs. Feature Request, ...). Für Pull Requests sehe ich da gerade leider keine Möglichkeit die Anweisungen zu spezialisieren. Das Thema um Issue Templates, würde ich aber gerne in einer separaten Diskussion führen.

Also ich persönlich finde zu Umfangreiche Templates immer etwas lästig, vor allem, wenn sehr viele Eventualitäten abgedeckt sind und man erst mal eine Minute Zeug entfernen muss. In https://github.com/go-gitea/gitea/pull/22888/files gibt es den Vorschlag die Hinweise mit Kommentare zu versehen, dass sie im Notfall automatisch gelöscht werden können. Eventuell ist das ein Kompromiss. Die Infrastruktur dafür hätten wir. Wenn ich die Dokumentation richtig lese, kann man nur für Issues mehrere Templates anlegen (<https://docs.gitea.io/en-us/issue-pull-request-templates/#directory-names>). Man kann dann eine Auswahl treffen und dann gezieltere Hilfestellung geben und dann auch passend Labels verteilen (Bugs vs. Feature Request, ...). Für Pull Requests sehe ich da gerade leider keine Möglichkeit die Anweisungen zu spezialisieren. Das Thema um Issue Templates, würde ich aber gerne in einer separaten Diskussion führen.

fbl commented

2023-02-26 19:26:02 +01:00

Solange wir Hinweise und Zeug was tatsächlich enthalten sein soll nicht mischen, sondern voneinander getrennt in der Vorlage haben ist das Löschen ja schnell erledigt, dafür vergisst man dann auch weniger.

jkimmel commented

2023-02-26 22:16:29 +01:00

Mit https://docs.gitea.io/en-us/issue-pull-request-templates/#syntax-for-yaml-template kann man Markdown Elemente für Beschreibungen nutzen, die dann nicht mit in den PR-Text wandern.
Danach also einfach ein Textfeld und wir haben das beste aus zwei Welten, sofern es denn funktioniert? Also sämtliche Hinweise, die wir hinschreiben möchten, aber trotzdem nichts, was man manuell entfernen muss und damit vergessen kann?

Vermutlich verliert man aber, dass der Text automatisch aus dem Commit gefüllt wird, falls der PR aus nur einem einzelnen Commit besteht.

Wäre gut, wenn das noch jemand ausprobieren kann, ansonsten übernehme ich auch gerne den anderen Textvorschlag.

Mit https://docs.gitea.io/en-us/issue-pull-request-templates/#syntax-for-yaml-template kann man [Markdown Elemente für Beschreibungen](https://docs.gitea.io/en-us/issue-pull-request-templates/#markdown) nutzen, die dann nicht mit in den PR-Text wandern. Danach also einfach ein [Textfeld](https://docs.gitea.io/en-us/issue-pull-request-templates/#textarea) und wir haben das beste aus zwei Welten, sofern es denn funktioniert? Also sämtliche Hinweise, die wir hinschreiben möchten, aber trotzdem nichts, was man manuell entfernen muss und damit vergessen kann? Vermutlich verliert man aber, dass der Text automatisch aus dem Commit gefüllt wird, falls der PR aus nur einem einzelnen Commit besteht. Wäre gut, wenn das noch jemand ausprobieren kann, ansonsten übernehme ich auch gerne den anderen Textvorschlag.

fbl commented

2023-12-26 21:49:02 +01:00

Wie geht es hier weiter? Ich hätte das nach wie vor sehr gerne. Ich bin nach wie vor der Meinung, dass das Löschen der gesamten Textbox kein allzu großer Aufwand ist, und der Vorteil - grade bei meiner eigenen Vergesslichkeit - bei weitem größer ist. Wenn diese yaml templates funktionieren ist das aber bestimmt ein sehr guter Kompromiss, grade für die Checkboxen aus meinem Vorschlag am Ende. Denn die mir eigentlich am allerwichtigsten.

ci/woodpecker/pr/woodpecker Pipeline is pending

Details

This pull request can be merged automatically.

This branch is out-of-date with the base branch

You are not authorized to merge this pull request.

Sign in to join this conversation.

No reviewers