Add GitHub issue templates (Bug Report, Feature Request, Description)

[abhi-14gyan]

What

Adds structured GitHub issue templates using YAML issue forms, so the "New Issue" page presents contributors with 3 clear options instead of a blank editor.

Why

The repository currently has no issue templates, which leads to:

• Inconsistent issue formatting
• Missing context (no reproduction steps, no environment info, etc.)
• Extra back-and-forth between maintainers and reporters

Changes

Templates added

Template	File	Auto-label	Key Fields
Bug Report	bug_report.yml	bug	Description, repro steps, expected/actual behavior, component, environment
Feature Request	feature_request.yml	enhancement	Problem statement, proposed solution, alternatives, component
Description	description.yml	question	Summary, details, related component

Configuration

• config.yml — Disables blank issues so all issues follow a template

Component dropdown options

All templates include a dropdown to identify the affected component:

• Library (library/)
• Prototype / Streamlit app (prototype/)
• Data pipeline (data/)
• Analysis / Notebooks (analysis/)
• Documentation (docs/)

How to test

1. Merge this PR into main
2. Go to Issues → New Issue
3. Verify the 3 template options appear as a chooser

[bassosimone]

Same comment as the other pull request. We never discussed this. We ought to discuss what we want to achieve here, why adding this is a net improvement, as opposed to just more stuff to maintain. I think this is the right direction, but I'd like to hear more about your motivation and why you structured the diff as such. What should we achieve by adding this? Why did you choose such templates specifically?

[bassosimone]

Also, can you maybe make sure that you review and re-read the titles of the PR(s) you submit?

[abhi-14gyan]

Thank you for the feedback - completely fair point, and I apologize for jumping ahead without discussion. I'm fairly new to open-source contribution and I'm still learning the proper workflow. Let me share my reasoning here so we can align before I make any further changes.

What problem do issue templates solve?

Right now, when someone opens an issue on this repo, they get a blank text box. This means:

• Bug reports may lack reproduction steps, environment details, or which component is affected.
• Feature requests may lack context on the problem being solved, or which parts of the codebase are involved.
• Maintainers end up spending time asking follow-up questions before they can even triage.

Structured templates shift that effort to the contributor upfront, so issues arrive in a consistent, actionable format.

Why these three templates specifically?

I chose Bug Report, Feature Request, and Description (general/question) because they cover the three most common types of issues in most projects, and I didn't want to add anything beyond what's useful:

1. Bug Report - Asks for description, reproduction steps, expected vs. actual behavior, affected component, and environment. This gives maintainers everything needed to triage and reproduce without back-and-forth.

2. Feature Request - Asks for problem statement, proposed solution, alternatives considered, and affected component. This ensures feature requests are grounded in a real problem rather than just "add X".

3. Description - A lightweight catch-all for questions, discussions, or topics that don't fit the other two. Without this, people would either misuse the bug/feature templates or be blocked by blank_issues_enabled: false.

Why I structured the diff this way:

• I used GitHub Issue Forms (YAML) instead of the older markdown-based templates because they provide structured fields (dropdowns, required validation) that ensure contributors fill in all the relevant information rather than deleting placeholder sections.
• Each template includes a Component dropdown (library/, prototype/, data/, analysis/, docs/) matching the project's architecture, which makes triaging easier.
• I set blank_issues_enabled: false in config.yml to guide contributors toward the templates, but I'm happy to change this if you'd prefer to allow free-form issues as well.

Why this is a net improvement over maintenance cost:

The templates themselves are low-maintenance - they're static YAML files that only need updating when the project structure changes (e.g., if a new top-level component is added). The time saved on triaging well-structured issues should far outweigh the occasional template update.

That said, I'm very open to feedback on:

• Whether all three templates are needed, or if we should start with fewer.
• Whether the fields I chose are the right ones, or if some should be added/removed.
• Whether blank_issues_enabled should be true or false.

Happy to iterate based on your guidance!

[bassosimone]

After listing our project for GSoC, we received a large amount of pull requests across several repositories. We are dealing with the backlog, but this would take time. We will get back to this pull request eventually. In the meanwhile, if you are a GSoC applicant, please read our updated GSoC policy: https://github.com/m-lab/gsoc/.