<div dir="ltr">All tech support goes to the tech team (one of our duties as a member of that team is to *ANSWER* tech support questions) here is a rather dated outline of our specific model:<br><br>
<style type="text/css">P { margin-bottom: 0.08in; direction: ltr; color: rgb(0, 0, 0); line-height: 105%; text-align: left; widows: 2; orphans: 2; }P.western { font-family: "Calibri",sans-serif; font-size: 11pt; }P.cjk { font-family: "Calibri",sans-serif; font-size: 11pt; }P.ctl { font-family: "Times New Roman",serif; font-size: 11pt; }A:link { }</style>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<span style="background:none repeat scroll 0% 0% transparent">For the above reasons we have
the following tech support policies:</span></p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<br><br>
</p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<span style="background:none repeat scroll 0% 0% transparent"> * The community (when
possible) is the first source of answers. This should eliminate the
vast majority of non-bug report style tech support requests.</span></p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<span style="background:none repeat scroll 0% 0% transparent"> * The remaining questions will
be handled in-house solely by the person(s) responible for
maintaining the feature(s) that are problematic in the report</span></p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<span style="background:none repeat scroll 0% 0% transparent"> * Aryeh and Dee and a team
will decide how to route all tech support requests with the following
status classifications:</span></p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<br><br>
</p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<span style="background:none repeat scroll 0% 0% transparent"> “Resolved” – the
question has been resolved and all needed/code/UI/documentation
needed to resolve it “for good” are complete.</span></p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<br><br>
</p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<span style="background:none repeat scroll 0% 0% transparent"> “Planned for” – The
requested functionality is already planned for in the development
plan</span></p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<br><br>
</p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<span style="background:none repeat scroll 0% 0% transparent"> “Unresolvable” – All
possible solutions are in some way fundamentally incompatible with
PetiteCloud</span></p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<br><br>
</p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<span style="background:none repeat scroll 0% 0% transparent"> “Impossible” – The
requested behavior is either physically/theortically impossible or
breaks the petitecloud architecture in a non-trivial-to-repair way.</span></p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<br><br>
</p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<span style="background:none repeat scroll 0% 0% transparent"> “False alarm” – A
question that somehow slipped through the community filter</span></p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<br><br>
</p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<span style="background:none repeat scroll 0% 0% transparent"> “Open question” – The
problem involves an “open question” in computer science, software
engineering and/or cloud archicture.</span></p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<br><br>
</p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<span style="background:none repeat scroll 0% 0% transparent"> “Open” – The question
is still being dealt with internally </span>
</p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<span style="background:none repeat scroll 0% 0% transparent"> * If the number of false
alarms makes it impossible meet delivery deadlines then we should
review our documentaion and UI's for ways to eliminate the most
common false alarms</span></p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<span style="background:none repeat scroll 0% 0% transparent"> * If the remaining false
alarms still make it impossible to meet we appoint one of the
development team members to do full time tech support. The will
keep development duties (just less of them).</span></p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<span style="background:none repeat scroll 0% 0% transparent"> * No tertiary version (the z
in x.y.z) will be marked as complete until the list of open tech
support requests contains nothing but false alarms that cannot be
fixed by improving the documentation and/or the UI.</span></p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<span style="background:none repeat scroll 0% 0% transparent"> * Whenever possible (without
revealing corporate security and/or compromising a user's ID), all
tech support requests should be logged in the project files for the
product or other publicly accessible (even to non-petitecloud users)
place. This logging should include all steps taken to resolve the
issue.</span></p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<br><br>
</p>
<p class="" style="margin-bottom:0.11in;font-weight:normal">
<span style="background:none repeat scroll 0% 0% transparent"> The philosophy behind using
such an expensive approach to tech support is that for every bug/UI
hiccup/confusion/etc. problem we hear about there are at least 20
more people who did not report the very same issue. We further
assume that out those 20 at least 5 have stopped using PetiteCloud
and those 5 at least 1 has complained about it publicly. That
single complaint has the potential of sinking a perfectly good
product (some times before it even gets off the ground) costing us
untold amounts (certainly much more then it would have been to just
fix the bug in the first place).</span></p>
<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 14, 2014 at 8:20 PM, Michael Thoreson <span dir="ltr"><<a href="mailto:m.thoreson@c4labs.ca" target="_blank">m.thoreson@c4labs.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There are a few solutions to the typical tech support failures.<br>
<br>
1) All tech calls get reviewed by a dev or dev team periodically.<br>
2) Devs rotate from developing to taking tech support calls on a set rotation<br>
3) A Dev or Dev(s) is available and dedicated to assisting tech support intake with any unusual problems<br>
4) Don't train monkeys how to answer phones and read flow charts of text book answers and expect to solve problems.<br>
<br>
Michael Thoreson,<div class=""><br>
<br>
On 14/02/2014 7:01 PM, Aryeh Friedman wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
A little glue in the *RIGHT* places and a nice skin will win *EVERY* time. The inappropriate marketing of any kind of product will always fail. Namely no appropriate marketing is possible if the product sucks. Only once you have a soild product can you start the real marketing (this assumes your aware of marketing 101 and know that without a market to market to no amount of marketing will sell your product). But you need one more element here which is prove that your product does in fact solve the actual problem the potential customer has. Now that everything is in place we can start the real work of marketing which is making the people who have the problem your product solves know that you have the a solution (a good healthy multi-vendor market should offer several solutions that are all appropriately marketed). Thus the real job marketing of an appropriately product is to just let people know about what your product is and what it can do. If it does not do what they want or in the way they want then no amount marketing will sell it to them if they are aware of a number of competing solutions. If all these competing solutions depend on a common enabling technology (like a cloud computing platform... in this case it need not be petitecloud just the ability to manage instances and such) then it is *CRITICAL* that every competitor have a fair say in it's creation.... there is a problem here though if you allow everyone to have an equal say then you end up with crap every time.... there fore the only reasonable model I see for the above to work for something like petitecloud is a democratic benevolent dictatorship (the philospher king model)... namely we (the core team) will take input from everyone and have open processes and all that but what is actualy committed to code is our say and our say alone... same goes for contributions we welcome all and except for cases of introduction a requirement for radical refactoring we will take it (assuming it is safe, stable and robust).<br>
<br>
A comment on "we don't support that feature"... here is a quote from our business plan on that:<br>
<br></div>
All software companies to some extent have “technical support” questions that must be answered (or people will simply stop buying their products). This is usually delegated to a tech support department. Having to deal with a “tech support specialist” of large companies is one of the quickest ways to anger our target market. The reason is despite how long we wait on hold (with the world's worst music played in a tin can) or how many useless menus we go through and have very carefully explained for the n^th time that we have already read the manual and searched the online knowledge base it is still guaranteed that an actual developer who can fix my issue will never be told about the issue, thus guaranteeing it will never be fixed and will eventually get buried so deep in the code base that it will be impossible to fix. This entire process is alienating to freelance developers because they often know as much, if not more, about the product then the tech support people do.<br>
<br>
<br>
</blockquote><div class="HOEnZb"><div class="h5">
<br>
______________________________<u></u>_________________<br>
petitecloud-general mailing list<br>
<a href="mailto:petitecloud-general@lists.petitecloud.nyclocal.net" target="_blank">petitecloud-general@lists.<u></u>petitecloud.nyclocal.net</a><br>
<a href="http://lists.petitecloud.nyclocal.net/listinfo.cgi/petitecloud-general-petitecloud.nyclocal.net" target="_blank">http://lists.petitecloud.<u></u>nyclocal.net/listinfo.cgi/<u></u>petitecloud-general-<u></u>petitecloud.nyclocal.net</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Aryeh M. Friedman, Lead Developer, <a href="http://www.PetiteCloud.org" target="_blank">http://www.PetiteCloud.org</a><br></div>
</div>