Open Stack

Hi all. Just wondering if there were any additional 
questions/concerns/thoughts on this matter?

Thank you,
-- 
Jimmy McArthur / Tipit.net <http://Tipit.net>< jimmy at tipit.net 
<mailto:jimmy at tipit.net>>



Jimmy Mcarthur wrote:
>> April 1, 2015 at 1:03 AM
>>
>> Can you explain what normalisation you would like to do ?
>>
> Happy to :)  Currently the survey questions are hard coded into the 
> PHP. What we'd like to do first off is make all of the questions and 
> answers dynamic, served from relational tables. This would allow any 
> Survey Admin to CRUD the questions without touching the code. This 
> should save lots of time in the long term as it would eliminate 
> development hours year over year.
>
> For the data output, everything is being stored in two tables. 
> Questions that have options for multiple answers are stored in an 
> array, which is generally bad practice. While it's not impossible to 
> work around, it makes it much more difficult to analyze the data. We'd 
> like to set up relational tables with questions and answers so we can 
> reference everything by ID. In addition, we would tag all 
> questions/answers with a survey ID.
>
> Which brings me to us losing tons of historical data because we're 
> writing over the same records every year. I propose that we snapshot 
> the survey for all companies by using the SurveyID. Combined with the 
> relational data for past surveys, we would be able to look 
> historically at all data that companies are submitting for each 
> survey. This has obvious advantages for spotting trends, improving 
> responses to questions that are historically getting incorrect/no 
> answers, etc...
>
> If you'd like me to provide some specific examples or a blueprint for 
> our proposal, we're happy to do that. However, wanted to make sure we 
> had input from the community before we even started down that road.
>
> Thank you!
> Jimmy
>
>
>> Tim
>>
>> *From:*Jimmy Mcarthur [mailto:jimmy at tipit.net]
>> *Sent:* 31 March 2015 18:10
>> *To:* user-committee at lists.openstack.org
>> *Subject:* Re: [User-committee] OpenStack Surveys moving forward
>>
>>
>>
>>     March 31, 2015 at 8:12 AM
>>
>>     If we create new rows for new data entry for an existing
>>     deployment, can we keep the same deployment id ? It is useful to
>>     have a unique identified for each deployment, especially if we
>>     eventually get to an automated way of reporting the current
>>     deployment state.
>>
>> Right now we're maintaining the deployment ID and re-populating 
>> questions from the past survey, where appropriate. That way users 
>> have a head start on the survey and can update data where appropriate.
>>
>>     We're not adding a huge number of questions each year so if it is
>>     easy to change the technology, that's OK but it would seem like a
>>     lot of work only for the delegation rights on its own.
>>
>> This year was a bigger lift than previous years, but you're right 
>> it's not a big shift from survey to survey. The driving force IMO is 
>> to normalize the data.
>>
>> Thanks!
>> Jimmy
>>
>>     *From:*Jimmy Mcarthur [mailto:jimmy at tipit.net]
>>     *Sent:* 31 March 2015 00:49
>>     *To:* user-committee at lists.openstack.org
>>     <mailto:user-committee at lists.openstack.org>
>>     *Subject:* [User-committee] OpenStack Surveys moving forward
>>
>>     Hello all -
>>
>>     We've been working on the development side of the user survey for
>>     OpenStack Foundation for the last two years. During that time,
>>     I've noticed a few issues which we'd like to address with the
>>     help of the stakeholders.
>>
>>     * Because of some earlier limitations with Silverstripe, the data
>>     isn't normalized. I'd like to propose a true relational data
>>     model. This is a problem for many reasons: data analysis, ease of
>>     updates, year over year changes, etc...
>>     * Users are updating the same Deployment and Survey rows year
>>     over year. Literally we're writing over historical data, which
>>     eliminates our ability to track data trends for companies and
>>     deployments.
>>     * Due to the current data model, updating the survey must be done
>>     by someone familiar with Silverstripe. I would propose a survey
>>     builder, built around the needs of the most current survey. This
>>     should allow the User Committee to create/edit their own
>>     questions and answers, including the style of the question (e.g.
>>     radio buttons, checkbox list, ranking of answers, etc...)
>>
>>     We would be happy to put together a blueprint of what we're
>>     thinking, but I'd like to first get general feedback from you
>>     all. You're much more familiar with both the data and what you
>>     want to do with it than we could ever be, so we welcome any input
>>     you might have in improving the process of both creating the
>>     surveys and managing the data.
>>
>>     Thank you!
>>
>>     -- 
>>
>>     Jimmy McArthur / Tipit.net <http://Tipit.net> < jimmy at tipit.net
>>     <mailto:jimmy at tipit.net>>
>>     m: 512.965.4846
>>
>>     o: 512.481.1161
>>
>> Jimmy Mcarthur <mailto:jimmy at tipit.net>
>> March 31, 2015 at 11:09 AM
>>
>>> March 31, 2015 at 8:12 AM
>>>
>>> If we create new rows for new data entry for an existing deployment, 
>>> can we keep the same deployment id ? It is useful to have a unique 
>>> identified for each deployment, especially if we eventually get to 
>>> an automated way of reporting the current deployment state.
>>>
>> Right now we're maintaining the deployment ID and re-populating 
>> questions from the past survey, where appropriate. That way users 
>> have a head start on the survey and can update data where appropriate.
>>>
>>> We're not adding a huge number of questions each year so if it is 
>>> easy to change the technology, that's OK but it would seem like a 
>>> lot of work only for the delegation rights on its own.
>>>
>> This year was a bigger lift than previous years, but you're right 
>> it's not a big shift from survey to survey. The driving force IMO is 
>> to normalize the data.
>>
>> Thanks!
>> Jimmy
>>>
>>> *From:*Jimmy Mcarthur [mailto:jimmy at tipit.net]
>>> *Sent:* 31 March 2015 00:49
>>> *To:* user-committee at lists.openstack.org
>>> *Subject:* [User-committee] OpenStack Surveys moving forward
>>>
>>> Hello all -
>>>
>>> We've been working on the development side of the user survey for 
>>> OpenStack Foundation for the last two years. During that time, I've 
>>> noticed a few issues which we'd like to address with the help of the 
>>> stakeholders.
>>>
>>> * Because of some earlier limitations with Silverstripe, the data 
>>> isn't normalized. I'd like to propose a true relational data model. 
>>> This is a problem for many reasons: data analysis, ease of updates, 
>>> year over year changes, etc...
>>> * Users are updating the same Deployment and Survey rows year over 
>>> year. Literally we're writing over historical data, which eliminates 
>>> our ability to track data trends for companies and deployments.
>>> * Due to the current data model, updating the survey must be done by 
>>> someone familiar with Silverstripe. I would propose a survey 
>>> builder, built around the needs of the most current survey. This 
>>> should allow the User Committee to create/edit their own questions 
>>> and answers, including the style of the question (e.g. radio 
>>> buttons, checkbox list, ranking of answers, etc...)
>>>
>>> We would be happy to put together a blueprint of what we're 
>>> thinking, but I'd like to first get general feedback from you all. 
>>> You're much more familiar with both the data and what you want to do 
>>> with it than we could ever be, so we welcome any input you might 
>>> have in improving the process of both creating the surveys and 
>>> managing the data.
>>>
>>> Thank you!
>>>
>>> -- 
>>>
>>> Jimmy McArthur / Tipit.net <http://Tipit.net> < jimmy at tipit.net 
>>> <mailto:jimmy at tipit.net>>
>>> m: 512.965.4846
>>>
>>> o: 512.481.1161
>>>
>> Tim Bell <mailto:Tim.Bell at cern.ch>
>> March 31, 2015 at 8:12 AM
>>
>> If we create new rows for new data entry for an existing deployment, 
>> can we keep the same deployment id ? It is useful to have a unique 
>> identified for each deployment, especially if we eventually get to an 
>> automated way of reporting the current deployment state.
>>
>> We're not adding a huge number of questions each year so if it is 
>> easy to change the technology, that's OK but it would seem like a lot 
>> of work only for the delegation rights on its own.
>>
>> Tim
>>
>> *From:*Jimmy Mcarthur [mailto:jimmy at tipit.net]
>> *Sent:* 31 March 2015 00:49
>> *To:* user-committee at lists.openstack.org
>> *Subject:* [User-committee] OpenStack Surveys moving forward
>>
>> Hello all -
>>
>> We've been working on the development side of the user survey for 
>> OpenStack Foundation for the last two years. During that time, I've 
>> noticed a few issues which we'd like to address with the help of the 
>> stakeholders.
>>
>> * Because of some earlier limitations with Silverstripe, the data 
>> isn't normalized. I'd like to propose a true relational data model. 
>> This is a problem for many reasons: data analysis, ease of updates, 
>> year over year changes, etc...
>> * Users are updating the same Deployment and Survey rows year over 
>> year. Literally we're writing over historical data, which eliminates 
>> our ability to track data trends for companies and deployments.
>> * Due to the current data model, updating the survey must be done by 
>> someone familiar with Silverstripe. I would propose a survey builder, 
>> built around the needs of the most current survey. This should allow 
>> the User Committee to create/edit their own questions and answers, 
>> including the style of the question (e.g. radio buttons, checkbox 
>> list, ranking of answers, etc...)
>>
>> We would be happy to put together a blueprint of what we're thinking, 
>> but I'd like to first get general feedback from you all. You're much 
>> more familiar with both the data and what you want to do with it than 
>> we could ever be, so we welcome any input you might have in improving 
>> the process of both creating the surveys and managing the data.
>>
>> Thank you!
>>
>> -- 
>>
>> Jimmy McArthur / Tipit.net <http://Tipit.net> < jimmy at tipit.net 
>> <mailto:jimmy at tipit.net>>
>> m: 512.965.4846
>>
>> o: 512.481.1161
>>
>> Jimmy Mcarthur <mailto:jimmy at tipit.net>
>> March 30, 2015 at 5:49 PM
>> Hello all -
>>
>> We've been working on the development side of the user survey for 
>> OpenStack Foundation for the last two years. During that time, I've 
>> noticed a few issues which we'd like to address with the help of the 
>> stakeholders.
>>
>> * Because of some earlier limitations with Silverstripe, the data 
>> isn't normalized. I'd like to propose a true relational data model. 
>> This is a problem for many reasons: data analysis, ease of updates, 
>> year over year changes, etc...
>> * Users are updating the same Deployment and Survey rows year over 
>> year. Literally we're writing over historical data, which eliminates 
>> our ability to track data trends for companies and deployments.
>> * Due to the current data model, updating the survey must be done by 
>> someone familiar with Silverstripe. I would propose a survey builder, 
>> built around the needs of the most current survey. This should allow 
>> the User Committee to create/edit their own questions and answers, 
>> including the style of the question (e.g. radio buttons, checkbox 
>> list, ranking of answers, etc...)
>>
>> We would be happy to put together a blueprint of what we're thinking, 
>> but I'd like to first get general feedback from you all. You're much 
>> more familiar with both the data and what you want to do with it than 
>> we could ever be, so we welcome any input you might have in improving 
>> the process of both creating the surveys and managing the data.
>>
>> Thank you!



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/user-committee/attachments/20150407/221848ac/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/user-committee/attachments/20150407/221848ac/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1142 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/user-committee/attachments/20150407/221848ac/attachment-0003.jpg>