I feel I should comment here because I am the OP, and I want to make a couple of things clear.
My take, from reading the mission statement and the comments from the devs here in this thread is that KiCAD development is largely demand-driven - i.e. reactive rather than proactive. The devs have assured us that it is not entirely so, and that some medium-term strategic thinking also takes place.
I am not criticising this. It seems to be much like most other OS software, and it’s a good way of identifying and implementing the functionality that the professional users want, which also benefits the amateur users.
However, KiCAD does not benefit from a Steve Jobs-style vision of what KiCAD should be, where it should be going, what it should look like, and how it should work. Once again, this is not a criticism, it’s just an observation of reality. I happen to believe it would benefit enormously from a really clear, carefully thought out vision, implemented with the necessary authority. It would benefit from more proactivity in the development process. In my experience this is a better model for software development than being reactive. In reality most software is a bit of both, but more proactivity would be better, in my opinion. That can’t happen, though, without the kind of vision I’ve described.
The mission statement is meaningless and cannot be used to set a specific direction, it does not define what KiCAD should be, nor can it be used to measure progress. And yes, this is a criticism.
Well… I only partially agree. There are already restrictions - KiCAD development is far from a free-for-all. The team looks at the change requests, bug reports, and the medium term plan, and decides what development work will take place over the coming year. The volunteers have to work within those constraints.
I’ve noticed that software engineers are often terrible at doing the supporting documentation: help files, feature descriptions, etc. I don’t know why, but I suspect it is just pretty rare to find both skill sets in the one person. Also, because the devs know the code intimately, they maybe don’t understand why it needs explaining.
I see there is only one individual in the team with the title of Technical Writer - Graham Keeth. I’m not really sure what, and how much, Graham does. But personally I do think there is an important role for good documentation.
Hey, that’s a bit unfair. It’s getting dangerously close to telling people they can’t post: a missive that has already caused a lot of upset in another thread. I’ll tell you what, @teletypeguy, you mind your own business, and let other users decide for themselves what to post, yes?