I agree that the plugin documentation should be updated at this point. The goal of the “depreciation” time period where the plugins still work but the site puts up a warning that they will break soon is to give the plugin authors enough time to fix them. Yet in that time period, a team of full-time paid developers couldn’t update the core plugin development documentation. It’s an odd expectation to place on individual developers when a team can’t fully manage it in the same time period.
What that signals to me is that the speed of development is too fast and/or plugin authors are not a significant priority to Discourse. Personally, I feel it’s moreso the latter. I understand that something has to fall to the side, so this is an observation from me rather than a criticism. Discourse remains fully customizable via plugins and I appreciate the continued improvements.
All that said, I think we are at a moment where a step-by-step documentation guide for building a boilerplate plugin is an obsolete idea. A single context document for an agent to read and build a plugin skeleton is all that’s needed now for an amateur plugin author. In fact, for an opensource codebase like Discourse, documentation is not needed at all since the agents get context directly from the codebase itself. When I was working on my plugins, I saw Claude reading the existing plugins as a way to learn the design patterns. And I was even able to root out a bug in the core code Chat Pitchfork timeouts: replies silently create threads and auto-tracking bloats over time
Basically, for anyone reading this who aspires to be an amateur plugin author, the documentation may be out of date but it’s 1000x easier to build a plugin than it ever has been before.