[PetiteCloud] grate book on how to specify systems

Aryeh Friedman aryeh.friedman at gmail.com
Fri Feb 14 18:12:40 PST 2014

Forgot to mention one advantage of using aegis is it makes forking rather
easy (for reasons you can read about on the aegis mailing list this much
easier in the distributed baseline model then the single monolithic one)

On Fri, Feb 14, 2014 at 8:43 PM, Michael Thoreson <m.thoreson at c4labs.ca>wrote:

> A built in anonymous "bug" collector may be an option. I know some don't
> trust them to be anonymous but this could be implemented perhaps as a
> module instead of a core feature. Basically something that monitors usage,
> then sends reports which then can either confirm that PC is being used as
> intended or the vast majority have other plans for the project and may need
> redesign or be forked into a sub project. This would also give insight into
> how PC is being used and perhaps avoid gaps in features and possible show
> stopping bugs.
> Michael Thoreson,
> On 14/02/2014 7:26 PM, Aryeh Friedman wrote:
>> 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:
>> For the above reasons we have the following tech support policies:
>> * The community (when possible) is the first source of answers. This
>> should eliminate the vast majority of non-bug report style tech support
>> requests.
>> * 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
>> * Aryeh and Dee and a team will decide how to route all tech support
>> requests with the following status classifications:
>> "Resolved" - the question has been resolved and all
>> needed/code/UI/documentation needed to resolve it "for good" are complete.
>> "Planned for" - The requested functionality is already planned for in the
>> development plan
>> "Unresolvable" - All possible solutions are in some way fundamentally
>> incompatible with PetiteCloud
>> "Impossible" - The requested behavior is either physically/theortically
>> impossible or breaks the petitecloud architecture in a
>> non-trivial-to-repair way.
>> "False alarm" - A question that somehow slipped through the community
>> filter
>> "Open question" - The problem involves an "open question" in computer
>> science, software engineering and/or cloud archicture.
>> "Open" - The question is still being dealt with internally
>> * 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
>> * 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).
>> * 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.
>> * 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.
>> 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).
>> On Fri, Feb 14, 2014 at 8:20 PM, Michael Thoreson <m.thoreson at c4labs.ca<mailto:
>> m.thoreson at c4labs.ca>> wrote:
>>     There are a few solutions to the typical tech support failures.
>>     1) All tech calls get reviewed by a dev or dev team periodically.
>>     2) Devs rotate from developing to taking tech support calls on a
>>     set rotation
>>     3) A Dev or Dev(s) is available and dedicated to assisting tech
>>     support intake with any unusual problems
>>     4) Don't train monkeys how to answer phones and read flow charts
>>     of text book answers and expect to solve problems.
>>     Michael Thoreson,
>>     On 14/02/2014 7:01 PM, Aryeh Friedman wrote:
>>         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).
>>         A comment on "we don't support that feature"... here is a
>>         quote from our business plan on that:
>>         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.
>>     _______________________________________________
>>     petitecloud-general mailing list
>>     petitecloud-general at lists.petitecloud.nyclocal.net
>>     <mailto:petitecloud-general at lists.petitecloud.nyclocal.net>
>>     http://lists.petitecloud.nyclocal.net/listinfo.cgi/
>> petitecloud-general-petitecloud.nyclocal.net
>> --
>> Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
>> _______________________________________________
>> petitecloud-general mailing list
>> petitecloud-general at lists.petitecloud.nyclocal.net
>> http://lists.petitecloud.nyclocal.net/listinfo.cgi/petitecloud-general-
>> petitecloud.nyclocal.net
> _______________________________________________
> petitecloud-general mailing list
> petitecloud-general at lists.petitecloud.nyclocal.net
> http://lists.petitecloud.nyclocal.net/listinfo.cgi/petitecloud-general-
> petitecloud.nyclocal.net

Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.petitecloud.nyclocal.net/pipermail/petitecloud-general-petitecloud.nyclocal.net/attachments/20140214/c08174c1/attachment-0003.htm>

More information about the petitecloud-general mailing list