Open Stack

We'll be moving forward with this, starting with the data normalization.
>From there, we'll plan to modify the existing SilverStripe form builder to
tailor the needs to the Foundation.

I'll continue to post regular updates and solicit feedback as the project
moves forward.

Thanks for your time and input!

--
Jimmy McArthur / Tipit.net < jimmy at tipit.net>
512.965.4846


On Tue, Apr 7, 2015 at 11:09 AM, Jimmy Mcarthur <jimmy at tipit.net> wrote:

> Hi all. Just wondering if there were any additional
> questions/concerns/thoughts on this matter?
>
> Thank you,
> --
> Jimmy McArthur / Tipit.net < 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 <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 <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 < jimmy at tipit.net>
> m: 512.965.4846
>
> o: 512.481.1161
>
>
>
>    Jimmy Mcarthur <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 <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 < jimmy at tipit.net>
> m: 512.965.4846
>
> o: 512.481.1161
>
>
>
>   Tim Bell <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 <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 < jimmy at tipit.net>
> m: 512.965.4846
>
> o: 512.481.1161
>
>
>     Jimmy Mcarthur <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/20150414/87133a82/attachment-0001.html>
-------------- 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/20150414/87133a82/attachment-0002.jpg>
-------------- 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/20150414/87133a82/attachment-0003.jpg>