I’m planning to change how I handle new feature requests for Klipper. The current process involves submitters opening a PR on github and then a reviewer (typically me) provides feedback. Going forward I’d like to change to a process where feature enhancements are first discussed here on Klipper Discourse, and we can collectively get a sense of those features that are considered highest priority. I’d then like to focus my time on the coding and reviewing of those topics of high priority. Ideally, with new features and new priorities selected every 8-10 weeks or so.
The reason I want to change how I review feature enhancements is that I feel there are some “big ticket” items in Klipper that have been continually delayed. I have limited time that I can work on Klipper and I fear that some high priority items aren’t getting enough attention.
Some of these “big ticket” items include:
The docs need to be upgraded so they recommend Mainsail/Fluidd/etc. instead of OctoPi/OctoPrint. This may also require changes to the install scripts in the main Klipper repo.
I’d like to make it possible for most users to be able to compile and flash the MCU code without using ssh. I suspect this would involve additions to printer.cfg that define the pertinent MCU settings, and changes to Klipper, Moonraker and the Klipper GUIs to support automated compilation and flashing.
Some of the existing PRs really need to get merged (for example, laser support)
I think we need to figure out a way to empower developers to add powerful new commands without using goofy jinja/gcode hacks and without having to add a Klipper “extra” module. That is, some kind of Klipper “plugin system”.
The current “trapq flushing” code is fragile and needs some refactoring (so that we can support multiple toolheads, synchronize toolheads, synchronize manual_steppers to toolheads, etc.). Similarly, the G28/homing system in Klipper is not flexible - improvements are needed to better support advanced kinematics, filament change systems, and similar.
The next Klipper release needs to be tagged and released.
This change in process will, in practice, mean that I’m unlikely to review any new Klipper feature enhancements for the next 6-8 months. If a feature enhancement PR was submitted after July 1st, I’m unlikely to review it. As part of this change in process I’ll look to provide feedback on the PRs opened prior to that (the review feedback, however, may be that the PR wont be merged in 2023).
This process change wont impact PRs that are reviewed by other listed reviewers ( Contributing to Klipper - Klipper documentation ). Nor will it impact simple bug fixes, nor regular code updates from the “established owner” of existing Klipper modules.
As part of this process change I’ll look to update the Klipper documentation to point new developers at Klipper Discourse (instead of github PRs).
Let me know if you have any comments.