We need a new issue template for reporting bug related issues

[Vizonex]

Important

This has taken me a while to write (over an hour) and definitely not how I wanted to spend my weekend so keep in mind with me that I am doing my best within my own mental capacity to explain this problem.

I'm having trouble coming up with a proper issue template from a .yaml file extension due to the vagueness and wording of the documentation but here is some examples of what I am expecting to see more of in the future:

• Bad Examples:
  Know that In the future issues like these should be discarded.

  • cannot change WindowsProactorEventLoopPolicy to WinLoopPolicy in fastapi #101
  • Winloop is not work in uvicorn multiprocessing #11

• Good Examples:
  These kinds of issues should be more encouraged as they are straight forward reports without being vague as to what the problem is.

  • Process.stdin.[write&drain] succeeds after the pipe is closed #84
  • building on MSYS2 #59
  • Seemingly spurious UV_EOF (errno 4095) upon closing TCP connection. #12

The Rules going forward should be simple practice and common sense for anybody to understand

We need a template that Acknowledges these important key rules

• Disallowing AI/LLM Generated issues or code and closing/terminating these issues if or when found along with labeling a tag titled AI Generated or AI
• Acknowledge that duplicate issues will be redirected and promptly discarded.
• Acknowledge that vague reproducers may result in not being able to do anything or even having the issue being closed or terminated.
• Acknowledge that reproducers should be text and not partial code snippets or screenshots and that no closed source code for reproducers should be allowed period
• Acknowledge that if a problem or bug is not related to winloop that it will be labeled as being an external-library's-fault and possibly may be reviewed on weather or not to close or redirect the issue to that external library's repo.
• Encourage Users to write a description of the bug being faced although have it be a completely optional thing.

Something like this .yaml configuration is what I'm aiming for but currently I don't understand it.

name: Report Bug with winloop
description: Report an issue with winloop
body:
  - type: markdown
    attributes:
      value: |
        > [!IMPORTANT]
        > Ensure you have agreed to these terms before throwing an issue

  - type: checkboxes
    id: checklist
    attributes:
      label: Checklist
      description: |
        Carefully read and checkmark all the terms and conditions before 
        continuing with reporting the issue
      options:
        - label: I am not a kindergartener and that creating AI generated code or grammar of any sort
            will result in my issue being terminated, promptly closed and labeled as **AI**
          required: true
        - label: If there was already an issue about this that hasn't been closed at all
            your issue will be treated and duplicate and closed
          required: true
        - label: If I do not have a code snippet or can't reproduce the bug to the issue I'm 
            experiencing to best of my own abilities then the issue will be ignored.
          required: true
        - label: If something is caused by a dependency that is unrelated to winloop 
            my issue will be labeled under **external library's fault** and that I will be redirected
            to throwing the issue with the external library's issue page
          required: true
        - lablel: If my code is incomplete it will be marked as **reproducer vauge** and that I will need
            to go back and redo my reproducable bug.
          required: true

[evnchn]

Feel absolutely free to copy https://github.com/zauberzeug/nicegui/tree/main/.github%2FISSUE_TEMPLATE

[evnchn]

0. We're ripping through Claude Code credits right now, and you see it everywhere in our commit history.
1. Perhaps well-regulated use of AI isn't that bad. Though I may be wrong because Winloop is much more low-level.
2. Besides our issue template Mandating AI co-authorship may be a good idea you can copy as well.

[Vizonex]

1. Perhaps well-regulated use of AI isn't that bad. Though I may be wrong because Winloop is much more low-level.

I agree with you that it may help our codebase, however I'm trying to have a simillar policy as yt-dlp And I quote:

If you submit a pull request, you need to understand what every line of code you've changed does. 
If you can't explain why your PR is doing something, then do not submit it. Using an AI tool to 
generate entire lines of code is unacceptable.

The rationale behind this policy is that automated contributions are a waste of the maintainers' time. 
Humans spend their time and brainpower reviewing every submission. Issues or pull requests generated 
by automation tools create an imbalance of effort between the submitter and the reviewer. 
Nobody learns anything when a maintainer reviews code written by an LLM.

My main reason for this policy that I have planned is because I would like for future contributors to at least understand and have the knowledge of what the code is doing as I would rather have someone learn something than having learned nothing at all incase something new were to arise. The experience and knowledge gained by learning something new (Example: A Code change with this library) and remembering something you fixed may come in handy to you later in life and may not just be useful here.