[Misc] PR templates

[youkaichao]

Add a PR template with guidelines for contributors.

Preview at https://github.com/youkaichao/vllm/blob/main/.github/PULL_REQUEST_TEMPLATE.md .

[simon-mo]

please add a section on tagging relevant issues.

I also prefer to keep most of these as HTML comments to keep PR clean.

[simon-mo]

Let's add the following section about RFC:

If the changes are big, create or tag the RFC issue.
For major architectural changes (>500 LOC excluding kernel/data/config/test), we would expect a GitHub issue discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not take a look at the PR.

[youkaichao]

@simon-mo how about this mixture of HTML and markdown?

PR Checklist

Before submitting your pull request, please ensure you have met the following criteria. This helps us maintain quality and efficiency in our review process. Check each box to indicate your understanding and compliance:

PR Title And Classification

- I understand that only specific types of PRs will be reviewed. My PR title is prefixed appropriately to indicate the type of change, using one of the following:

• [Doc] for documentation fixes.
• [Bugfix] for bug fixes.
• [CI/Build] for build or continuous integration improvements.
• [Model] for adding a new model or improving an existing model. Model name should appear in the title.
• [Kernel] for changes affecting computation kernels.
• [Hardware][Vendor] for hardware-specific changes. Vendor name should appear in the prefix, e.g., [Hardware][AMD].
• [Misc] for PRs that do not fit the above categories. Please use this sparingly.

- Note: If my PR spans more than one category, I will include all relevant prefixes.

Coding Standards

- I understand that I must run ./format.sh before submitting the PR and after any new commits to ensure compliance with linter checks. PRs failing to meet linter standards will not be reviewed or merged.

Code Quality

- I understand that my code must be well-commented and include sufficient tests, ensuring future contributors can easily understand and modify the codebase.

Documentation for User-Facing Changes

- I understand that if my PR introduces user-facing changes, it must be accompanied by relevant documentation to help users understand and utilize the new features or changes.

Thank you for your contribution!

PR Justification

Please provide a brief explanation of the motivation behind the PR and the changes it introduces. This helps reviewers understand the context and rationale for the contribution.

[youkaichao]

The good thing is that we can collapse the "must-to-read" section (n.b. inside this section only html is allowed, markdown rendering does not work). This way, PR looks clean, and we convey the message to contributors (hopefully they will expand and read the section).

[simon-mo]

<details> is a good idea!

[zhuohan123]

I am reviewing this PR as well! Please do not merge it yet :)

[zhuohan123]

Left initial round of comments. Will also push more changes after these comments being fixed.

[zhuohan123]

Just did a pass over the PR template. @youkaichao can you take a final pass and possibly we can merge this?