[feedhenry-dev] Dogfooding for Developer Experience

Wed Nov 16 12:58:37 UTC 2016

+1 for having Drag and Drop app.

On Wed, Nov 16, 2016 at 12:57 PM, Summers Pittman <supittma at redhat.com>
wrote:

>
>
> On Wed, Nov 16, 2016 at 5:24 AM, David Martin <davmarti at redhat.com> wrote:
>
>> Here's a practical use case for dogfooding that could really benefit the
>> team.
>> I'm currently trying to get info about how our templates are used.
>> However, this is a tricky thing that can currently only yield limited
>> factual info from querying the platform db.
>>
>> How about the 'RHMAP Developer Experience Feedback App'
>> - a forms app
>> - each form is a VERY short 'survey' (because I'd imagine most people
>> hate filling in surveys)
>> - inital form would have 2 things
>> -- loads of checkboxes for selecting which templates you have/do use (so
>> 1 checkbox per template)
>> -- how do you use the templates? (checkboxes for 'Solutions', 'Training',
>> 'Demos')
>>
>> Future forms/surveys could be:
>> - Which of these templates/samples would you potential use? (radio for
>> various templates/samples ideas we have)
>> - Which of these databrowser features would you most like to see? (radio
>> for things like 'shell access', or 'complex queries via UI' or 'export
>> based on a complex query'
>>
>> I was planning on putting together a POC to see if could work.
>>
>>
> +1.  Forms for me has always been a "that's this thing over there I've
> never touched" so getting more first hand reports on it would be nice.
> Also IIRC it is a big selling feature.
>
>
>> On 10 November 2016 at 18:59, John Frizelle <jfrizell at redhat.com> wrote:
>>
>>> I'm not really sure it makes that much of a difference.
>>>
>>> Typically, almost all development work is done locally - i.e. outside of
>>> the studio.
>>>
>>> The real interactions (and problems) with the product come after an app
>>> has been released as people are then fairly well locked into using the
>>> studio for management, monitoring, upgrades, debugging problems etc...
>>>
>>> So, if we really want to dogfood our product, we need to get something
>>> deployed and then go through the pain of trying to manage it through the
>>> platform...
>>>
>>>
>>> --
>>> John Frizelle
>>> Platform Architect, Red Hat Mobile
>>> Consulting Engineering
>>>
>>> mobile: *+353 87 290 1644 <//+353872901644>*
>>> twitter:* @johnfriz*
>>> skype: *john_frizelle*
>>> mail: *jfrizell at redhat.com <jfrizell at redhat.com>*
>>>
>>>
>>>
>>>
>>> On 10 November 2016 at 09:15, Matthias Wessendorf <mwessend at redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Nov 9, 2016 at 7:06 PM, Summers Pittman <supittma at redhat.com>
>>>> wrote:
>>>>
>>>>> Y'all,
>>>>>
>>>>> Wojciech and I had a quick call to flesh out the discussion we were
>>>>> having on IRC about having a dogfooding exercise to better understand and
>>>>> discover what pain points developers have.
>>>>>
>>>>> As far as Jiraisms go, we have a few things to figure out before we
>>>>> can make a proper Epic out of it.  Once we do, however, I hope that we can
>>>>> get things ready to start coding relatively quickly.
>>>>>
>>>>> 1) Do we want to greenfield an application or port an existing open
>>>>> source application to the platform?  Greenfielding works great for learning
>>>>> specific parts of the platform (ex Auth) or answering certain questions
>>>>> (how do I get sync to do X, Y ,Z), but porting an existing application
>>>>> gives us the opportunity to see how our platform's assumptions mesh with
>>>>> the practices developers are currently using.
>>>>>
>>>>
>>>> I think we should to greenfield, as that might be a bit more fun. So if
>>>> we figure out certain parts of the platform that are not fun to use, it's
>>>> good feedback for improving. I think greenfield works a bit better here,
>>>> because you are a bit more flexible on ideas and concepts
>>>>
>>>>
>>>> @porting:
>>>> A bit off-topic; But: Currently I am mentoring a student from
>>>> Waterford. He works on a Node.js / Microservices version of AeroDoc
>>>> (+adding Keycloak). At a later stage this might be even ported to an RHMAP
>>>> template. So this might be related. bringing in existing code to the
>>>> platform
>>>>
>>>>
>>>>
>>>>>
>>>>> 2) Do we want to focus on native (Windows + iOS + Android) or Cordova
>>>>> clients?  Cordova apps will give us a better experience of challenges our
>>>>> current users have, but because there are so few native users in comparison
>>>>> a native focus may yield things which have been overlooked.
>>>>>
>>>>
>>>> Hrm, not sure: both have benefits: native and cordova
>>>>
>>>>
>>>>
>>>>>
>>>>> 3) I'm sure that more will come from this so feel free to ask and
>>>>> answer your own questions here.
>>>>>
>>>>> Let's discuss in this thread today and Thursday and we can review it
>>>>> in our meeting Friday.
>>>>>
>>>>> Summers
>>>>>
>>>>> _______________________________________________
>>>>> feedhenry-dev mailing list
>>>>> feedhenry-dev at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Project lead AeroGear.org
>>>>
>>>> _______________________________________________
>>>> feedhenry-dev mailing list
>>>> feedhenry-dev at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> feedhenry-dev mailing list
>>> feedhenry-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>>
>>>
>>
>>
>> --
>> David Martin
>> Red Hat Mobile
>> Twitter: @irldavem
>> IRC: @irldavem (feedhenry, mobile-internal)
>>
>> _______________________________________________
>> feedhenry-dev mailing list
>> feedhenry-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>
>>
>
> _______________________________________________
> feedhenry-dev mailing list
> feedhenry-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>
>

-- 
Wojciech Trocki
Software Engineer, Red Hat Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20161116/7ca9d7e5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.png
Type: image/png
Size: 11472 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20161116/7ca9d7e5/attachment.png>