<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">From: Drew Einhorn <<a href="mailto:drew.einhorn@gmail.com" class="">drew.einhorn@gmail.com</a>><br class=""><blockquote type="cite" class="">The point is to make it easier for licensed folks to avoid mistakes that<br class="">violate the law, not to make it impossible for folks who intend to violate<br class="">the law.<br class=""><br class="">It's easy to accidentally press the TX button. I would prefer to easily<br class="">configure the radio to limit the damages. Duplex off is nice. But, I'd<br class="">prefer to set my country to US and license to Amateur Technician and<br class="">automatically have Duplex set correctly for all frequencies outside the<br class="">amateur bands.</blockquote></div><div class=""><br class=""></div><div class="">From: John Wilkerson <<a href="mailto:jl_wilkerson@att.net" class="">jl_wilkerson@att.net</a>></div><div class=""><blockquote type="cite" class="">The suggestions should be posted at the Chirp website, if you'd ever<br class="">want them considered.</blockquote></div><div class=""><br class=""></div>If sounds like you’re requesting more of an additive template system with importable sets of preference templates based on license/region/organization that only overwrite specified fields, or open a new document with those fields set. This would allow you to save different presets in groups for different use cases/clients as well as combine sets (with the latest template added taking precedence). For instance that would allow a person to start with a “Technician,” “Extra,” template overlay a “CARLA region set” of channels, and then import their groups sets. Numerical collisions could either automatically add to the end or give the user a remap to # option per channel or per group. That system could be group sourced, and maintain the flexibility for an infinite number of use cases. <div class=""><div class=""><br class=""></div><div class="">From: David <<a href="mailto:weather@lightingunlimited.com" class="">weather@lightingunlimited.com</a>></div><div class=""><blockquote type="cite" class="">What is MediaWiki?</blockquote></div><div class=""><br class=""></div><div class="">From: Drew Einhorn <<a href="mailto:drew.einhorn@gmail.com" class="">drew.einhorn@gmail.com</a>></div><div class=""><blockquote type="cite" class="">MediaWiki is the very powerful wiki software that runs the Wikipedia and<br class="">many other well-known wikis. It is not the easiest to work with, but it can<br class="">do just about anything wiki related, and do it well. Casual users are<br class="">frequently overwhelmed by its complexity. So, it is often not the best<br class="">choice.<br class=""></blockquote></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I’ve been running a MediaWiki installation for over 10 years now. While MediaWiki is great for crowdsource, for file exchange, security & safety can be problematic. Instead I would probably crowdsource templates, suggested above, on github.</div><div class=""><br class=""></div><div class=""> For crowdsourced information, MediaWiki is great. Setup complexity is dependent on your server environment. For some it’s as simple as downloading a package and running the setup wizard, while for others it’s compiling from source, etc. If you need advice, I’d be happy to help. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Thanks for Chirp.</div><div class=""><br class=""></div><div class="">Mike</div><div class="">KF6FGE</div></div></body></html>