963639df6a
* Write down the rule for UI changes to Studio, and put it on every pull request Studio has taken a run of performance changes recently, and the question that decided each of them was not whether it was faster but whether the interface still behaved the same way. That rule has been applied consistently and written down nowhere, so it is stated here. Two exemptions, both of which have come up for real: a dramatic performance win can justify a deliberate UI difference if it is called out with its cost, and a difference that exists only off screen is fine, because rendering only what is visible is a technique rather than a violation. The off-screen exemption is the one that needs the guard rails, so those are spelled out. A partly visible element is visible. Selection, clipboard, find-in-page and printing are whole-document operations, so a copied thread that stops at the edge of the viewport is data loss rather than an off-screen difference. Scroll geometry is visible even when the thing that shrank is not. Each of those is a mistake that was made and measured rather than imagined. Adds a pull request template so the question is asked once per PR instead of being remembered. * Require the parity verdict, and its null, on the pull request Asking whether the UI changed is not the same as checking. Every Studio change in the recent run that turned out to alter the interface was caught by the parity suite rather than by reading the diff, and the two that were nearly missed were missed because the verdict was quoted without its control. So the template now asks for the verdict, the number of action pairs compared, and the null control's score on the same run. A verdict with no null has no floor, which means a suite that compared nothing reports the same clean line as a suite that compared everything and agreed. That happened: a run once scored the treatment better than two copies of the same build. It also asks which claim the verdict supports. The structural digest covers thread structure and is blind to the sidebar and to computed layout, so a change confined to either passes while being invisible to it. Visible-region parity is the check that backs the off-screen exemption, since a whole-document digest reports differences by design on a windowed or deferred change and proves nothing. * Link the contribution guidelines by a URL that survives a pull request body * Run the template link guard in the lane with no paths filter * Catch a relative reference-style link in the template too * Accept root-relative targets in the PR template link guard A leading slash discards the current path and resolves against the host, so /owner/repo/blob/main/CONTRIBUTING.md reaches the same page the absolute URL does from any PR at any number. The guard classified it alongside ../CONTRIBUTING.md and would have failed CI on a valid link. The guard's own message gave the reason it does not apply: the template is rendered at /owner/repo/pull/N, so a DOCUMENT-relative target resolves off the repository tree. A root-relative target throws that base away, which is the point of the form. * Unwrap angle-bracketed inline link destinations in the PR template guard * Tighten the comments in the PR template link guard --------- Co-authored-by: danielhanchen <unslothshared@gmail.com> Co-authored-by: danielhanchen <unslothai@gmail.com>
4.6 KiB
🦥 Contributing to Unsloth
Thank you for not only using Unsloth but also for being interested in helping out! We value all contributions, whether they come in the form of code, ideas, support for others or just by simply spreading the word of Unsloth! 💕
- Support the Community: Answer questions, review pull requests, or assist others in discussions.
- Fix Bugs: Identify and resolve issues with the existing codebase.
- Submit Ideas: Request new features or share enhancements you'd like to see.
- Develop Features: Implement new functionality or improve existing tools which can be done via PRs.
- Improve Documentation: Help by creating guides, FAQs, or enhancing clarity.
One of the best ways to support us is by spreading the word about Unsloth! Share how it’s powering your amazing projects in blog posts or social media, and inspire others to explore its potential. Even a simple star on our repo goes a long way in showing your support and helping the community grow. 🌟
Submitting Issues
If you find a bug or have a feature idea, we’d love to hear from you! Here’s how to make your submission stand out:
Reporting Bugs
- Search First: Check if the issue has already been reported using GitHub’s search bar under Issues.
- Details Matter: Is this on Google Colab, Kaggle, or on another platform service? Are you using Unsloth's official notebook? Include your OS, Python version, and other relevant details. For bugs, a concise code snippet that reproduces the issue is incredibly helpful.
- Be Thorough: Attach screenshots, traceback logs, or any additional information that might speed up resolution.
Spread the Word
Your support extends beyond code:
- Spread the word by writing about Unsloth in blogs or social media.
- Share how Unsloth powers your projects.
- Star our repository to show your appreciation.
Finally, please be mindful of our Code of Conduct to ensure a welcoming and inclusive environment for everyone.
Thank you so much for reading and we hope you have lots of fun using Unsloth! 🦥
Pull Request Guidelines
- Keep PRs focused on a single change
- Include a concise description and motivation
- Link related issues when applicable
Changes to Studio's UI
A pull request that touches the Studio frontend must leave the interface behaving the same way it did before. Reviewers should be able to assume that a change described as a performance fix is a performance fix and nothing else.
There are two exemptions.
- A dramatic performance improvement can justify a deliberate UI difference. State the difference plainly in the PR body, say what it costs the user, and attach the measurement that justifies it. A difference that is not called out is a regression, however fast the PR is.
- A difference that exists only off screen is fine. Rendering only what is visible is an accepted technique, not a parity violation. Windowing, deferring off-screen work and unmounting rows the user cannot see are all allowed, provided everything inside the viewport is identical to what it was before.
The second exemption is narrower than it sounds, and the boundary is where these changes go wrong in practice:
- An element that is partly on screen is visible, and so is one that scrolls into view during an interaction.
- Selection, clipboard, native find-in-page and printing are whole-document operations. A user pressing Ctrl+A, Ctrl+C or Ctrl+F is asking about the conversation, not about the viewport, so off-screen content still has to participate. Truncating a copied thread is a data-loss bug, not an off-screen rendering difference.
- Scroll geometry is visible. A scrollbar that no longer describes the length of the thread is a UI change even though the thing that shrank was off screen.
If you are changing what the thread renders, measure at the 100K rung or larger against a concurrent control, and say which of the two exemptions you are relying on, or that you are relying on neither.
Run the parity suite either way and put its verdict in the PR, with the number of action pairs compared and the concurrent null control's score on the same run. Without the null there is no floor, so a clean-looking verdict cannot be distinguished from a suite that compared nothing. Say which claim the verdict supports: the structural digest covers thread structure and is blind to the sidebar and to computed layout, while visible-region parity is the check that supports the off-screen exemption.