Provide more guidance on what makes an issue "easy"

Aberta
#38 3 comentários 2 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
2/5
Tempo estimado
1-3 horas
Facilidade para iniciantes
35/100
Tipo de issue
Documentação
Clareza
Razoavelmente clara
Status de atividade
Estagnada
Stack de tecnologia
python
Domínio
documentation

Direção de pesquisa

Comece pela seção Keywords de triaging.rst e revise as orientações existentes para a keyword "easy". Leia a discussão e o artigo vinculados sob as perspectivas do contributor e do triager e, em seguida, confirme o escopo pretendido antes de editar. O trabalho estará concluído quando os parágrafos acordados forem adicionados e for esclarecido como as keywords "easy (Python)" e "easy (C)" devem ser usadas.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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)

Linguagem predominante
Python
Estrelas
2.1k
Forks
1k
Merge médio
2d 12h
PRs com merge (30d)
12

Guia de contribuição

Abrir o guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de python/devguide

Todas as issues de python/devguide

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.