Opening with comments such as that (or others riddled throughout ) certainly does not compel a person to expound, paraphrase or help further.
Speaking in general.
[ Off topic regarding documentation ]
There are obviously still attributes of the documentation that need filled out and finished, along with videos that were discussed back around last summer regarding whether to use a computer voice vs human voice. Having incomplete documentation of course does not help, as it fragments the understanding with users having to dicier across differentiating versions and UI’s, or with nothing at all.
No doubt more updates to the documentation resources (written and video) are still to come and the staff continues to work on these resources.
v4 was supposed to be the culmination of everything, the documentation, etc., but obviously this is still a work in progress. There has been indicators of a new main site appearance a few times, so I assume things are still underway for some major transition to the new version since the rewrite. We are now back to the dot release versions again (even though a few more milestones where seemingly reached), so not sure when that actual transition will culminate, v5 ?
Obviously the Pinegrow team is small yet nimble, and has a lot to accomplish between the main application development, new features, performance, bug fixes, documentation, marketing, participating and helping across communication channels, etc., etc. So a lot of times documentation can fall behind and suffer because of this. I have seen it be the case with other small development teams as well.
The other thing is developers obviously have a clear understanding of the how and why of features and workflows of their application. But sometimes that does not translate into documentation that is clear or simple for those that are just users, especially new users, or for new versions. Or fully encompass documenting all features, sub features, points of entry for usage and workflow, general intricacies and insight, best practices, tips and tricks, etc., which is a massive undertaking to document.
Many times things are taken for granted and only come out if specific questions are asked by users. It is easy for developers to take things for granted and not understand how to translate all of what they know as the developers down to the user about their application. But it generally comes down to time and resources, as documentation can be very time consuming, especially for small teams.
When writing documentation its hard to set aside the concise understanding for a developer and in contrast clearly and simply explain to the mindset of someone whom is a user and does not know perhaps anything. So many times, documentation is written from the developers point of view and understanding, not from a users point of view of not knowing.
Generally though users don’t take the time to understand software or familiarize themselves within a software through practice or trial and error, reading the documentation, gaining general understanding through general research of the underlying tech and terminology etc., before complaining or asking questions they could educate themselves on. So like most things, both sides play a role.
This is historical regarding documentation for many applications. But just like features, documentation can likewise be improved through user feedback, most developers gladly welcome understanding such deficiencies and ways for improvement. But any feedback should be as clear and concise as possible, without nonsense and precisely focused.