English is currently available.
KiCad DISCUSSION
Release-candidate testing is most useful when problems are reproducible. How can a designer reduce a private KiCad project to a shareable example of a routing or plotting defect?
What information should accompany the example, and how do we avoid removing the very geometry or rule that triggers the problem?
Reference: KiCad release announcements (https://www.kicad.org/blog/).
Work on a separate copy and first record the exact steps that trigger the problem. Note the full KiCad build information, operating system and any relevant graphics or plugin configuration. Then remove unrelated sheets, components and geometry in small stages, rerunning the same steps after each reduction. Keep the last version that still demonstrates the failure.
Include the affected custom footprint or rule if the failure depends on it, while checking that you are allowed to share it. Rename confidential labels and remove unrelated metadata without changing the relevant geometry. For an export defect, provide the small source project and the incorrect output. A screenshot helps identify the visible symptom but usually cannot reproduce its cause.
State expected and observed behavior separately and identify the last version known to work if you actually tested it. Avoid guessing a regression range from release dates. A short deterministic example helps maintainers distinguish a defect from configuration or unsupported input, and it gives you a practical test to rerun when a fix becomes available.
