[feedhenry-dev] Dogfooding for Developer Experience

Summers Pittman supittma at redhat.com
Wed Nov 16 12:57:35 UTC 2016


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20161116/e91b9659/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/e91b9659/attachment.png>


More information about the feedhenry-dev mailing list