Provide more guidance on what makes an issue "easy"

Ouverte
#38 3 commentaires 2 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
35/100
Type d'issue
Documentation
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
python
Domaine
documentation

Piste de recherche

Commencez par la section Keywords de triaging.rst et examinez les indications existantes concernant le keyword "easy". Lisez la discussion et l’article liés du point de vue du contributor et du triager, puis confirmez la portée prévue avant de modifier le contenu. Le travail est considéré comme terminé lorsque les paragraphes convenus ont été ajoutés et que l’utilisation des keywords "easy (Python)" et "easy (C)" a été clarifiée.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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)

Langage dominant
Python
Étoiles
2.1k
Forks
1k
Merge moyen
2 j 12 h
PR mergées (30 j)
12

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de python/devguide

Toutes les issues de python/devguide

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.