'Rufus is broken, please fix' has never fixed anything. The reports that turned into 4.15 changelog lines shared a structure - and it takes about four minutes to write one properly.
Rufus is maintained essentially by one developer, which makes report quality the whole game: he can fix what he can reproduce, and he can only reproduce what you describe precisely. The silent install bug got fixed because users reported a pattern - same feature, same stall point - instead of a hundred unrelated complaints.
Before writing a word, capture two things. The exact version from the Rufus title bar - '4.14' and '4.15' are different programs for debugging purposes. And the log: Rufus keeps a log of the session (open it from the log control in the main window) - save it right after the failure, before closing and reopening the program wipes the evidence. For install-time failures like the silent stall, note also which Rufus build created the media; the stick, not the PC you later ran Rufus on, is the suspect.
Install bugs live in combinations: the ISO build, the number and type of disks, UEFI or legacy mode, Secure Boot on or off. Name your ISO precisely and include its SHA-256 checksum (so a corrupt download can be ruled out in one line), list what disks were connected - the first-disk behaviour made that detail decisive in the silent reports - and state the exact point of failure. 'Stuck at 75 percent for forty minutes, then error' is a clue a developer can search a codebase with; 'froze halfway' is not.
The silent install story shows why: dozens of separate 'it hangs' threads would have been noise, but reports converging on one existing issue built the pattern that proved the bug and later let everyone verify the fix. Search the existing issues for your symptom and version first. If yours matches, add your version, log and hardware to that thread instead of opening a twin. And keep each report to one problem - a report that bundles a silent-install stall with a cosmetic complaint gets half-fixed.
Realistic expectations keep the system healthy. A confirmed bug may be fixed in the next release - the silent fix landed in 4.15 alongside the always-checked-checkbox fix - or marked as a duplicate, or answered with a workaround. You may be asked to test a pre-release build; that is the beta bargain working as intended, and testing it belongs on your bench machine, not a customer's. Silence does not mean ignored - it usually means not yet reproduced.
The video was itself a public bug demonstration - the next step after a video like that is a written report with the details on this page.
▶️ Watch Full VideoYes, filing and commenting on issues requires a free GitHub account. If you cannot create one, a precise forum post with the same five checklist items still helps other users, but the project's issue tracker is where fixes are organised.
No - duplicates are how a maintainer learns a bug is widespread rather than a one-machine oddity. Your hardware details added to the main thread still count as evidence, and you will be notified from that thread when the fix ships.
Never the ISO - it is huge and usually copyrighted Microsoft material; its name, build and SHA-256 checksum identify it completely. Screenshots of the exact failure screen, plus the saved Rufus log, are the attachments that matter.