Is the idea of involving the community in writing documentation less than great?

9

Hello, @TylerJPresley

We did exchange a few thoughts in the past before and I remember liking what you had to say. I also do not want to leave any post in this discussion without my comments. So, I will address your opinion:

I don’t think that the blog posts are the issue as much as the support on here and gitter. I’m probably going to move on if I post a few questions and they never get answered. Especially if I’m new to frontend frameworks.

I believe there should be a core team member in here answering questions MOST of the time. Not all, most. This is how you “Market” a framework.

Eons ago I was working at Visix Software, Inc as a VP engineering selling one of the first ever cross platform toolkit named Galaxy. All development shops of relevance at that time were our customers - and we were selling it at $10000 (yes, for trailing zeros). In a few short years we were one of the most successful young companies in USA and I could never foresee that it is possible to run out of sufficiently smart customers that could use our product without the enormous amount of hand-guidance.

You would clearly belong to the class of a sufficiently smart customer for aurelia - but again, there is not a sufficient amount of such aurelia users, to take us to the needed prominence. So, I am not “buying” your opinion that the solution is there should be a core team member in here answering questions MOST of the time, because while this would make you (and your types) happy it would not enough for folks like me. I care about sufficient amount of examples that illustrate more then the use of a single API, I care about articles about architectural solutions that might apply in my own case - in summary, please try to make the comparison between the documenation for Microsoft’s development tools and Aurelia’s and you should know what I mean.

I will also repeat the basic premise of AUCS: let’s completely unload the task of writing the technical documents and samples from the core team for two reasons:

  1. we (application developers) know how to do that better than core team (framework geeks) members.

  2. our group can scale up nearly indefinitely - their cannot.