Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Diversity survey 2017 #13884

Merged
merged 10 commits into from
Mar 23, 2017
Merged

Diversity survey 2017 #13884

merged 10 commits into from
Mar 23, 2017

Conversation

breville
Copy link
Member

@breville breville commented Mar 20, 2017

The diversity survey returns for 2017.

screenshot 2017-03-20 16 59 09
screenshot 2017-03-20 16 59 16

It can now be submitted without any answers.

Copy link
Contributor

@tanyaparker tanyaparker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Touches the next section: image

Prefer not to answer just scrolled me up instead of hiding.

I submitted and saw the button to google survey. On refresh I still see the diversity survey.

When I clicked through google survey it didn't have my ID?

}
else
{
$("#survey")[0].reset();
$(".survey").hide();
$("#diversity-survey").hide();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be #diversity_survey?

$(this).val($(this).val().replace(/[^0-9]/g, ''));
});

if (submittedValue)
{
$("#surveybody").hide();
$("#surveythanks").show();
$("#surveythanks").fadeIn();
}
else
{
$("#survey")[0].reset();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this reset both #surveythanks and #surveybody? Like where is the just #survey element?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This just resets the survey form. The form_for line specifies an id of survey for the form.

false unless current_user
false unless language == "en"
false if current_user.under_13?
false if existing_diversity_survey_result?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The wording of this confused me at first because I thought it meant that if there was an existing one, even from 2016 that we wouldn't allow. Suggest something more like already_submitted_diversity_2017 ?

@@ -10,7 +10,7 @@
cursor: auto;
}

- if show_survey?
- if show_nps_survey?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this check both here and in the home/index view? Can't it just be here?

Copy link
Contributor

@ashercodeorg ashercodeorg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Taking a step backward, I think there are some fundamental issues with this PR.

  • Given that SurveyResult.kind encapsulates when the survey was administered, I feel like including the year in the DIVERSITY_ATTRS is a mistake. Any reason we shouldn't not include the year, doing an appropriate data fix to remove the year from the 2016 diversity survey data? If so, I'd be happy to own the 2016 data fix and associated fallout. Without this, there is no programmatic way to access the 2016 constants.
  • Related, this seems like a lot more work than it should be. Assuming no changes to styling, wording, and such, I would expect this PR to create a new SurveyResult.kind, change the diversity survey to submit this new kind, and remove an early exit return false from the should-show-survey-method. Is there any reason we shouldn't make the appropriate changes so that disabling and reenabling is this simple moving forward?

false if current_user.under_13?
false if existing_diversity_survey_result?
false unless account_existed_14_days?
false unless teacher?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I find current_user.teacher? more readable, as it isn't obvious how or what teacher? is defined by in the helper.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact, I think it would be more readable (simpler) if all the one liners were not abstracted away into methods below (as all of them are super clear and readable).

return true
end
def existing_diversity_survey_result?
SurveyResult.where({user_id: current_user.id, kind: SurveyResult::DIVERSITY_2017}).exists?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Though I'm totally fine with the braces, typically we omit hash braces on the last parameter, e.g., where(user_id: current_user.id, kind: SurveyResult::DIVERSITY_2017).

stubs(:current_user).returns(@teacher)

assert teacher?
assert_equal account_existed_14_days?, false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For assert_equal, the syntax is assert_equal expected, actual so that an appropriate error message is shown on failure. That said, here and below, I'd encourage using refute account_existed_14_days?.

@@ -0,0 +1,63 @@
require 'test_helper'

class SurveyResultsHelperTest < ActionView::TestCase
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be great if the common setup was moved to the setup method. E.g.,

  def setup
    @teacher = create(:teacher, created_at: 3.weeks.ago)
    sign_in @teacher
  end

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Related, is there a reason to stub current_user rather than sign-in the teacher?

create(:follower, section: @section, student_user: @student)
stubs(:current_user).returns(@teacher)

assert has_any_students?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be shortened to (assuming the common setup)

follower = create :follower, user: @teacher

assert has_any_students?

stubs(:current_user).returns(@teacher)

assert has_any_students?
assert_equal has_any_student_under_13?, false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shorter (with common setup):

follower = create :follower, user: @teacher
follower.student_user.update!(age: 10)

assert has_any_students?
refute has_any_student_under_13?

%a{href: survey_url, target: "_blank"}
%button.btn-primary
Go to survey
- survey_url = "https://docs.google.com/a/code.org/forms/d/e/1FAIpQLSd7MppqXJi4FpURELDH3RyMG6PgevBVPaH373K0h-FSI_3FUg/viewform"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems odd (bad UX) that there is exactly one required question in this survey.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, both of them should be optional.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This refers to the Google Forms survey?

@breville
Copy link
Member Author

Thanks @ashercodeorg. On your first bullet, I had a similar concern and am glad you feel this way. I've removed the years from the attributes. Thanks for owning the data cleanup. On the second bullet, the intention going forward is certainly that we can easily adjust the criteria to show whichever survey comes next, and that it's easier to add more types in the future.

Conflicts:
	dashboard/app/models/survey_result.rb
Copy link
Contributor

@ashercodeorg ashercodeorg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost! Should I proceed with the data fix to remove the year from the diversity survey JSONs?

@@ -1,38 +1,45 @@
module SurveyResultsHelper
def show_survey?
# rubocop:disable Lint/UnreachableCode
def show_diversity_survey?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this become more reusable (for future years) if this accepts a kind parameter, that in turn gets passed through via existing_diversity_survey(kind)?

Ideally, I'd like to see this helper not need any modification for future years (except perhaps adding or removing a return false at the top of this method).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. Between this change and the earlier work in #12583 the goal has certainly been to make it trivial to turn these surveys on and off.

end

test 'teacher account newer than 14 days' do
@teacher.update(created_at: 1.week.ago)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Use @teacher.update! to facilitate debugging if per chance the update fails.

end

test 'teacher account has no student under 13' do
create :follower, user: @teacher
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't rely implicitly on FactoryGirl giving you a follower with a young_student. Prefer something like create :follower, user: @teacher, student_user: (create :young_student).

end

test 'teacher account has student under 13' do
follower = create :follower, user: @teacher
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, though it seems you may need to add old_student to FactoryGirl.

@breville
Copy link
Member Author

@ashercodeorg Please go ahead with the data fix, though presumably it should be merged after this change goes to production.

@ashercodeorg
Copy link
Contributor

LGTM (for ruby). And I'll send you a data fix PR in the upcoming future.

Copy link
Contributor

@tanyaparker tanyaparker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not blocking merging in this PR, but may be good to add an "x" to dismiss the second diversity section.

image

@breville breville merged commit d0d050f into staging Mar 23, 2017
@breville breville deleted the diversity-survey-2017 branch March 23, 2017 16:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants