Wyatt, I don't see any reviews really necessary for this one. If you are happy with it just go ahead and merge it to master.

I mildly object to this being merged: I expect the folder where the doxygen stuff is generated to be added to .gitignore.

Not a second objection, but I would very much like to see a short how-to added to the project. I suggest starting a new file CONTRIBUTING or, possibly better yet, CONTRIBUTING.md that has a couple of lines on this or three. Lest every developer who's never used doxygen needs to go to the web side, one developer at a time.

(Yes, I did notice the breach of process and understand my objection comes to late to be addressed before the merge. I don't know what to think about it. If you people do not discuss my proposal and also ignore it, why the heck did I bother writing it up?)

Yes, I did fail to add it to the .gitignore, I actually had a d'oh moment earlier today to that effect. I blame @Chris-AC9KH for the fast merge since he effectively signed off on it. 🙄 I'll do better next time, I promise!

(Yes, I did notice the breach of process and understand my objection comes to late to be addressed before the merge. I don't know what to think about it. If you people do not discuss my proposal and also ignore it, why the heck did I bother writing it up?)

This was a simple configuration file that doesn't change the functionality of the code, and that I didn't see any reason to leave it as a open PR. Modifications to it can be easily made with subsequent PR.

So we should augment the rule? "If a reviewer is certain a change is low risk, the merge may be done by that reviewer." or something?

As far as that goes, there's other things yet that should probably be added to .gitignore. Xcode can put a new artifact I discovered into the source tree (depending on how Xcode is set up) for app entitlements.

I suggest starting a new file CONTRIBUTING or, possibly better yet, CONTRIBUTING.md that has a couple of lines on this or three. Lest every developer who's never used doxygen needs to go to the web side, one developer at a time.

@aknrdureegaesr there is a contributor's guide in the docs (at least in JS8Call-improved):

https://github.com/Chris-AC9KH/JS8Call-improved/blob/master/docs/CONTRIBUTOR_GUIDE.md

If it needs changing for here (it likely does), then feel free to make any changes to it. It was included in the documentation update I did on JS8Call official, but never merged (yet).

I see zero reason to leave simple PR's that don't change the functionality of the codebase, but they add necessary development features. These can just be merged without going thru any formal review process. They are easy to reverse, or change, with subsequent PR's without affecting the build-ability or functionality of the code. It helps to keep the PR list cleaned up, and if something was missed just fix it with another PR and move on. I've got one coming up with a new tools directory with linux build scripts that is the same thing. I wouldn't expect wasting everybody's time going thru a formal review process for such a thing. If two developers agree on it, merge it.