I agree 100% with Kirk. Like many people who are on the autism spectrum, I say what I mean. There is no need for you to search my words to find hidden meanings. If I thought you were lazy, I’d use the word lazy, and then give specific examples to support it. Since FreePBX is now a corporate sponsored project, the issue here is about allocation of resources. It has nothing to do with personal characteristics.
And since I’ve been accused of calling the dev team lazy, let me meander just a bit. I know for a fact that Andrew Nagy is a hard-working and brilliant programmer, and I have never, ever intended to communicate the opposite. The fact that I disagree with some of Andrew’s decisions does not mean that I think any less of him as a person. We should all be able to agree to disagree. Also, please don’t infer anything negative from the fact that I only mentioned Andrew here. I mention Andrew because he is the only former dev who is particiating here who I have spoken with one on one.
Getting back to the point: It’s not hard to understand how FreePBX got here. When started as an open source project, the coders were writing FreePBX for their own benefit, i.e., as hobbyists. They knew how it worked, because they wrote it. If others found it useful, that was great, but nobody was expecting that FreePBX would become a commercial product. When nobody was funding the project, and nobody expected to sell it, there was zero reason to spend much time on documentation.
Now that FreePBX is a corporate sponsored project, I’m saying that there’s a good reason for Sangoma to allocate more resources to documentation. I agree with everything that Kirk said on this point.
But, in addition to what Kirk said, there is another benefit to having documentation precede GUI changes: It helps to ensure that the GUI stays friendly, easy to use, and avoid unnecessary radical changes.
Forcing someone to think about how to explain a change in writing ensures that the change stays simple and user friendly. The simple changes are simple to explain. If a radical change required radical changes to the documentation, a dev might work harder to find a way to accomplish the same thing without the radical change.