-
-
Notifications
You must be signed in to change notification settings - Fork 9.2k
Remove unnecessary explicit title anchors and use relative links instead #20620
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Signed-off-by: Harry Mellor <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Summary of Changes
Hello @hmellor, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request significantly improves the project's documentation by standardizing how internal links are managed. By moving away from explicit title anchors to relative file paths, the documentation becomes more robust, easier to navigate in its raw form, and more compatible with modern development tooling for link validation.
Highlights
- Documentation Link Standardization: Replaced explicit title anchors (e.g.,
[](){ #anchor }
) with direct relative file paths (e.g.,../path/to/file.md
) for internal documentation links across numerous markdown files. - Improved Link Robustness: The transition to relative links ensures that documentation links remain functional and accurate even when browsing raw markdown files directly, enhancing usability outside of a rendered documentation site.
- Enhanced Developer Experience: Using relative file paths allows Integrated Development Environments (IDEs) to more effectively identify and flag dead links, significantly aiding in documentation maintenance and preventing broken references.
- Cleanup of Redundant Anchors: Removed unnecessary explicit title anchors from the front matter or body of many markdown files, streamlining the document structure and reducing clutter.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command>
or @gemini-code-assist <command>
. Below is a summary of the supported commands.
Feature | Command | Description |
---|---|---|
Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/
folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
👋 Hi! Thank you for contributing to the vLLM project. 💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels. Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging. To run CI, PR reviewers can either: Add 🚀 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request is a great improvement to the documentation's maintainability. By removing unnecessary anchors and switching to relative links, browsing the raw markdown files and identifying dead links with IDEs becomes much easier. The changes are consistent and well-executed across all the modified files. The updates to the generate_examples.py
script to use logging instead of print statements are also a welcome improvement for better debugging of the documentation build process. Overall, this is a solid contribution to the project's documentation quality.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes the logging during example generation less noisy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM once the doc build passes
Thanks, both RTD and BK seem to be passing the docs build |
…ead (vllm-project#20620) Signed-off-by: Harry Mellor <[email protected]>
…ead (vllm-project#20620) Signed-off-by: Harry Mellor <[email protected]>
…ead (vllm-project#20620) Signed-off-by: Harry Mellor <[email protected]> Signed-off-by: Patrick von Platen <[email protected]>
…ead (vllm-project#20620) Signed-off-by: Harry Mellor <[email protected]>
…ead (vllm-project#20620) Signed-off-by: Harry Mellor <[email protected]> Signed-off-by: avigny <[email protected]>
…ead (vllm-project#20620) Signed-off-by: Harry Mellor <[email protected]>
…ead (vllm-project#20620) Signed-off-by: Harry Mellor <[email protected]>
.md
files themselves.md
files is better because:.md
docs