A couple of things I've been thinking about these past few months, and which could (potentially) help:
Having someone take over support & development for the two MIPS routers (RT-N66U and RT-AC66U). These models (especially the N66U) are far too popular to completely drop support for, however having someone take care of maintaining the MIPS side of things would free up some of my time. No more hunts for MIPS-specific GPLs (for the MIPS binary blobs), two less routers to test.
Extending development cycles. I've already started on this, extending from the former one month cycle (where I was generally alternating between feature releases and bugfix releases) into a longer 2-3 months cycle, with occasional beta (and even alpha) builds. This did help in getting some issues spotted earlier during development, thanks to a few users willing to run even alpha level code, and providing really good feedback. I will most likely continue in this direction.
Re-enabling the issue tracker on Github. I disabled it a few years ago because the vast majority of new issues were really support requests rather than genuine bug reports, and it was becoming a good amount of work sorting through my mailbox notifications. I might be considering re-opening it once again.
Getting a more reliable access to new GPLs. That one isn't under my control unfortunately, but issues like the 2695/2697 corrupted and/or missing GPL drops do cost me a lot of time and efforts.
Enforcing a strict "if you don't mention your router model then your bug report will be ignored" policy. This isn't about being a jerk to people, just that I often waste a lot of time trying to reproduce an issue, only to learn later on that it only happens on a very specific model. Take the RT-AC87U for instance, which accounts for a lot of "My 5 GHz no longer works" reports. Maybe setup (at least informally) some type of template of info that MUST be included whenever reporting any issue. Router model and whether or not it can be reproduce on the stock firmware would be good starting points.
More eyeballs on the code on the debugging front. So far, I've noticed that most people actively contributing are more interested in feature addition/improvements than actual debugging of existing issues. Once again, not something I have any control over. The learning curve isn't necessarily easy for anyone's first attempt at diving into this jungle. There are large parts of the code where I simply don't step foot myself, like the Dual WAN code, or any of the non-router operation modes...
Once again, just thinking out loud here.
