Hello Chirp developers,

Google spreadsheet with open items: https://docs.google.com/spreadsheets/d/1WhU74C7PhlLGM3HUFzZ5YhPzf0R7OSA5ZGpT1-mqsZQ/edit?usp=sharing

Our ticket database is now more than nine years old and growing rapidly. It had been in some need of review for a while. I took on the task to go through open tickets to see what can be closed. I've completed three passes of combing through all open and closed tickets; the result is the spreadsheet above and a significant reduction in open tickets:
* Bugs: from >60% down to 14%,
* Feature requests: from >60% to 28%,
* New model requests: from >60% to 41%.
Lots of duplicates were identified. Several tickets had to be retargeted (e.g. not a bug, but a new model request).
Ah yes, and a couple of spam tickets or spam posts were removed as well.

Bugs:
* There was a lot of traffic which actually wasn't about any bugs, often it was the typical problem of a radio not connecting with Chirp due to a bad cable, driver, or connector. I closed all of these, if the last feedback from our side was older than 30 days.
* Many of the bug reports could be easily closed, they often require just a fix for a single parameter (like a missing tone or step, or NFM not working, etc.).
* There are a few serious issues with serial communications. A lot of the Icom radios dislike FTDI cables (Alinco DR-x35 radios do that, too). That's a problem especially when using MacOS, where FTDI seems to be the almost only option for serial cables. (I've added a special section for Icom serial issues in the spreadsheet.). Also, there's a recurring issue with Linux and serial communications.
* A hot and often observed problem is when the user encounters an empty Settings tab. We know that the issue occurs when the radio contains a value in the settings which is out of range by Chirp's measures.
* There's a lot of trouble with RepeaterBook imports, which appear to work with select US ZIP codes only, and not at all outside the US (e.g. Canada).

Feature requests:
* I think the most requested feature was an extension of the CSV format to carry the power setting (or in general more available parameters).
* Several requests can be weeded out with the transition to Python 3 (such as requests for localisation, or certain UI changes)
* And then there was that ticket listing a recipe for grilled shrimp with bacon and lemon pepper BBQ sauce (seriously! #1101).

New Model requests:
The requests for new models are listing a stunning amount of radios. For each request, I researched the radio and added its properties to the spreadsheet (e.g. handheld, VHF+UHF, 128 channels). That way, I found a few radios which don't exist at all, but there also were requests for a "Kenwood TH-F8" and an "Icon UV-90" (both brazen counterfeits - I've rejected those).
* I suspect that many of the requested models are already supported or are variations of already supported models. It might be helpful to go through the tickets and see where we can work with the owners to get more information.
* Some of the requests are for already supported radios with new firmware in it (new ID string). Same thing, maybe we can find out whether it's easy enough to add those.
* There are many requests for DMR radios. We don't support DMR (nor Yaesu's C4FM Fusion) yet.

The spreadsheet will be updated continually. To protect it from vandalism, commenting only is allowed. I'm happy to share edit rights with confirmed developers - just let me know if you want access. I hope you will find this information useful.


Regards!
Bernhard AE6YN