There are lots of commands with incomplete documentation. They should get an intern (or group of 2 or 3) tasked with documenting all commands in the same format and checking if every option is documented.
Still waiting on the NAT-PMP docs …
I also have noticed the tool/sms/status that is now always off instead of running.
Also, more problematic, if you send a /tool/sms set receive-enabled=yes when receive-enabled was already yes, the allowed-number is erased!!!
I did a reset and reconfigured the device. For a while it started to look like that report was false as it was able to get over 48 hours of uptime without problems but now route list statis made a record as previously routing locked up far earlier than this count of crashes. Every uptick in this graph counts for a crash in routing - list of about 400 routes grew up to 6000. Only way out was to disconnect the power (reboot command left device unresponsive) - and this of course is on 7.13.5, which did not brought any changes (in this behaviour compared to 7.13.4)
Would really like to hope that internal development documentation is better than these incomplete “placeholders” in user documentations that sometimes lack even most basic things like default values for parameters etc. If development documentation would be as bad then there would not be much hope in getting out of current state of mess…
All hints make me think that dev docs aren’t much better or even not exist. Software developers like to automate monkey tasks. So it is very common to generate docs from source-code comments (there exist many approaches for ages like doxygen). So there may be no automation to get that into their user docs (don’t want to expose confidential information etc). But there should at least be something like a very technical internal doc generated by their well commented source-code. Would make it easy for support staff to port the relevant stuff to user docs. But since there is so much information missing in their user docs, I must assume: no proper internal docs as well.
User documentation (a manual) is quite different from programmer’s documentation. You cannot generate a user manual from source code, unless you put the manual text as comments in the source code. Maybe you could generate it from design documentation.
At least there has been an attempt at creating a format for the manual sections. So it should be “easy” to walk along all entries and see if the format has been completed for all options, if there is meaningful text for each option, and if there is a general explanation section for every command (what it does, how that generally fits in the total configuration).
This is something that should not be done by the programmer, but by persons who do not know the system from inside.
https://help.mikrotik.com/docs/display/ROS/NAT-PMP
+
https://help.mikrotik.com/docs/display/ROS/Services
5350/udp NAT-PMP client
5351/udp NAT-PMP server
There’s one thing even worse than patchy documentation and changelogs - releases do not seem to have “known issues” section in “release documentation” - if forum threads can qualify as “documentation”…
As there is obviously not much testing, it is hard for them to know about known issues.
The current history of 7.13.1 to 7.15.5 has 26 (!!) bugs introduced with 7.13.x releases.
MT knows about issues for sure, like here with vlan mtu: http://forum.mikrotik.com/t/v7-14rc-testing-is-released/173569/146
It is also the acknowledging reply from support when they can reproduce an issue: “We are aware of this issue, and we look forward to fixing it on an upcoming RouterOS versions.”
So MT does have an internal list of known issues. But they are kept top secret.
Maybe this list is getting longer with each release and they struggle to keep up?
Just for a reference how proper “known issues” list should look like
https://docs.fortinet.com/document/fortigate/7.2.7/fortios-release-notes/236526/known-issues
Such a list should be doable for Mikrotik as well.
But: Don’t adopt Fortinet’s security 
That last one was real black eye fo them for sure. It was real fun to waste hours in attempts of downoading the firmware. 88 megabyte file and 6 hours…
It is also the acknowledging reply from support when they can reproduce an issue: “We are aware of this issue, and we look forward to fixing it on an upcoming RouterOS versions.”
Breaking MTU handling on bridges should not be a known issues but a showstopper as it has the potential to put WAN interfaces offline. There is also not much concept nor priorities: Everything is changed all the time, instead of concentrating on a few topics and fix/complete them in a meaningful order: WiFi, Bridging, L3HW, IPv6, MLAG etc. is still buggy and incomplete, but they add Rose/SMB, containers and similar stuff being a nice add-on, but not worth bothering as long as the basics are not ready. Documentation is in a poor state and and obviously written without the required English skills.
But we have to keep it fair: For the price point of MT HW, we cannot expect enterprise grade SW development an testing. After all, MT is just a few hundred peoples in a small country. For many of of our Cisco, Juniper etc. boxes the annual support contract alone is more expensive than a complete CCR2216.
And without MT many small ISPs and also larger ones in developing countries would not exists, and many peoples would not have access to internet. MT did a lot for many peoples around the world. I saw this myself in the Philippines and in Thailand.
OT but stating that and than write “peopleS” more than once … quite a shot to the knee i might add 
PS:
MT started as a wireless and routing software company and are fairly young in switching-business.
one of the hardest certifications is the switching cert. from them
I agree with the state of documentation. It can be improved quite a bit.
About English … do you speak Latvian ? I guess not. I definitely don’t.
Personally I think the quality of English is still pretty acceptable. Really !
I’ve seen a lot worse coming from other persons and I’ve worked with A LOT of nationalities during my career.
Unless you are able to communicate with the other person in his/her native language, I might suggest you do not comment on any effort done by the same person to use a common ground, flawed as it may be. They are doing an effort to make it available for an as wide audience as possible.
haha exactly. ever dealt with Cisco TAC? most of the time you get connected to someone in india or bosnia … good luck with that. had my fair share with them and now really like to consider reading docs and boards rather than talking to cisco tac ever again
I prefer reading (good) docs over talking at any time.