Define a pull request template
@benoit74 ci sta già lavorando.
Dal 22/12/2023.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
Some projects have a pull_request_template.yml, but it does not look like there is a convention on this yet.
The template I've found so far is:
## Rationale
[//]: # (Briefly explain the reason behind this change.)
<!--
Issue: [Title](link) or #123 for Github issues.
-->
## Changes
[//]: # (Summarize what has changed.)
Some inconvenient I find in this template:
- I do not find the term "Rationale" very obvious
- There is no mention about the fact that we must add "Fix: ###" to automatically close issues.
- The "Issue" template is misleading, it looks like it will do something automatically while it doesn't + all issues should be Github issues (or most at least), so no need to propose something for the case where it is not
ChatGPT suggested me the following sections:
## Description
<!-- Describe the purpose of this pull request -->
## Changes Made
<!-- List the changes made in this pull request -->
## Screenshots (if applicable)
<!-- Include screenshots or images demonstrating the changes -->
## Testing
<!-- Explain how the changes were tested -->
## Related Issues
<!-- Mention any related issues or link to them -->
## Checklist
- [ ] Code follows project standards
- [ ] Tests have been added/updated
- [ ] Documentation has been updated
- [ ] Changelog entry added
And it should be named pull_request_template.md (it's not a yaml file 😅)
My remarks on ChatGPT suggestion:
- I think the related issues should be clearer about the fact that we expect one or more "Fix: ###" and I would like to put this at the beginning of the PR, just after the description (or even before that) so that it is more obvious why we are proposing this PR
- in the checklist:
- we should add a link to our project standards so that it is obvious
- most scrappers do not have tests (yet, at least) ; and usually there structure makes testing a daunting task ; I think we should not add this check in most scrapers yet
- documentation should refer to usage + wiki
I welcome all suggestions on this, I can handle the creation of a PR once arguments have settled a little bit.
- Lingua principale
- Python
- Stelle
- 1
- Fork
- 2
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di openzim/_python-bootstrap
-
bug
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 76/100
openzim/_python-bootstrap#57 ·
-
enhancement
openzim/_python-bootstrap#54 · 1 commento · 2 assegnatari ·
-
Workflow convention Apertaquestion
openzim/_python-bootstrap#53 · 1 assegnatario ·
-
enhancement
Difficoltà 3/5 1-2 giorni Idoneità per principianti 25/100
openzim/_python-bootstrap#51 · 3 commenti ·
-
What about nested logs Apertaenhancement
openzim/_python-bootstrap#48 · 2 assegnatari ·
Tutte le issue di openzim/_python-bootstrap
Issue simili
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
canonical/paas-charm#368 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
tech debt
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
addition to tracking list Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
StevenBlack/hosts#3256 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
qualcomm/qai-appbuilder#275 ·