Guidelines for syntax of titles in GitHub issues and pull requests?
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Documentazione
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- github
- Ambito
- documentation
Direzione di ricerca
Inizia esaminando gli esempi proposti di titoli di issue e pull request, la motivazione per i prefissi e la discussione esistente in questa issue. Non sono identificati file del repository né test. Il lavoro sarebbe completo quando il progetto avrà concordato le raccomandazioni sui titoli e la guida Do e Don’t della bozza sarà stata finalizzata.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
There are usage recommendations for GitHub labels. Should there be recommendations for issue and pull request titles? (editors on my CG was recently asking themselves this question)
Examples I've seen in the wild:
[module-name] Discussion specific to a single module[module-name,other-module-name] Discussion related to multiple modulesGeneral discussion or question
Ideally, we'd document the reasoning behind these recommendations (see draft below).
Curious to hear what other folks think.
DRAFT Proposal:
Benefit of prefixes
Why use prefixes, when labels can do the same job? Both are useful, here are a few reasons to use prefixes in issue titles:
[prefix]is a useful visual hint when scanning a long list of issues- Facilitates plain text search
- Prevents duplicate titles across modules
- May be used by automations/bots
- When someone mentions an issue in a GitHub comment, issue, or PR, GitHub automatically expands the title, but labels aren't shown
Screen capture showing an issue without a prefix in its title. The user has to hover it to reveal the label, and understand that it has to do with the format module. Had it been prefixed with [format], the user would have immediately known about what module this issue touches on.
Do
todo
Don’t
todo
- Lingua principale
- HTML
- Stelle
- 148
- Fork
- 41
- Merge medio
- 1m
- PR unite (30g)
- 2
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
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 w3c/w3c.github.io
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 35/100
w3c/w3c.github.io#93 · 1 commento ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 45/100
w3c/w3c.github.io#92 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 20/100
w3c/w3c.github.io#91 ·
-
Allow shortName in w3c.json?Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 35/100
w3c/w3c.github.io#78 · 5 commenti ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 15/100
w3c/w3c.github.io#70 ·
Tutte le issue di w3c/w3c.github.io
Issue simili
-
bug documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
awslabs/visual-asset-management-system#514 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
rancher/fleet-product-docs#417 ·
I maintainer di solito rispondono entro 1 giorno
-
good first issue help wanted
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
dafonton77-tech/Cadreenf#10 ·
-
docs(storage-resize-images): kit README's Multiple instances section fails in an installed projectApertakits type: bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
firebase/extensions#3271 ·
I maintainer di solito rispondono entro 1 giorno
-
https://docs.Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100