[User-committee] OpenStack Surveys moving forward

Jimmy Mcarthur jimmy at tipit.net
Wed Apr 1 15:19:48 UTC 2015


> 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/20150401/6890f29b/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/20150401/6890f29b/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/20150401/6890f29b/attachment-0003.jpg>


More information about the User-committee mailing list