Provide more guidance on what makes an issue "easy"

Aperta
#38 3 commenti 2 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
35/100
Tipo di issue
Documentazione
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
python
Ambito
documentation

Direzione di ricerca

Inizia dalla sezione Keywords di triaging.rst e rivedi le indicazioni esistenti per la keyword "easy". Leggi la discussione e l’articolo collegati dal punto di vista del contributor e del triager, quindi conferma l’ambito previsto prima di modificare il contenuto. Il lavoro è completato quando sono stati aggiunti i paragrafi concordati ed è stato chiarito come utilizzare le keyword "easy (Python)" e "easy (C)".

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

topic-triage type-feature

https://github.com/python/devguide/blob/master/triaging.rst#keywords currently states that "easy" issues shouldn't take more than a day for someone new to CPython development, but @gvanrossum pointed out in http://psf.upfronthosting.co.za/roundup/meta/issue605 that that at least needs to be qualified for C level changes based on whether or not the contributor already knows how to program in C.

Guido's specific concern is going to be addressed by splitting the "easy" keyword into "easy (Python)" and "easy (C)", but I think it may be worth providing more concrete guidance to developers and triagers on when it makes sense to mark an issue as "easy". Specifically, I think the main things that make for good first contribution opportunity for folks that aren't sure yet if they want to commit a lot of time are:

  • clearly defined scope (specific reproducer for a bug, clear API design for a minor feature)
  • already approved-in-principle by a core developer (as this means the issue is likely to have someone willing to review and merge a patch, and is unlikely to get bogged down in debates over whether the bug is actually a bug, or whether the feature addition is a good idea)

Guido also pointed to https://medium.com/@shubheksha/finding-your-first-open-source-project-or-bug-to-work-on-1712f651e5ba#.36q7njkjd as a good overview of the perspective of folks that we're aiming to reach with these "easy" tags.

(To be clear, I'm offering to write a couple of paragraphs for the Triaging page that explains how we seek to use the "easy" keywords, but wanted to discuss our aims for those keywords explicitly before submitting a PR)

Lingua principale
Python
Stelle
2.1k
Fork
1k
Merge medio
2g 12h
PR unite (30g)
12

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di python/devguide

Tutte le issue di python/devguide

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.