Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Provide more guidance on what makes an issue "easy"

Open
#38 3 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
35/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Stale
Tech stack
python
Domain
documentation

Research direction

Start with the Keywords section of triaging.rst and review the existing guidance for the "easy" keyword. Read the linked discussion and article for the contributor and triager perspectives, then confirm the intended scope before editing. Done means adding the agreed paragraphs and clarifying how the "easy (Python)" and "easy (C)" keywords should be used.

Written by the indexing model from the issue text.

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)

Dominant language
Python
Stars
2.1k
Forks
1k
Avg merge
2d 12h
Merged PRs (30d)
12

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from python/devguide

All issues in python/devguide

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.