almartin82 / map-visuals Goto Github PK

when there is no end of year/current data (eg second term) haid_plot throws an error related to end_quartiles

This is dated information, but I'm adding per Andrew's request so we don't lose the info.

More importantly, I just merged some new functions into the main branch:

• dots(), an internal function to capture unevaluated dots arguments in a function
• nwea_growth(), gets any or all NWEA norms using grade, start.rit, and measurementscale vectors. This uses dots() internally to ask for any of the norms (R22, S42, T12, etc.).
• kipp_quartile, calculates the foundation dumb quartile (or not! if you want it calculate real quartiles!) given a vector of percentiles. Returns a vector of integers or factors (your choice!)
• tiered_growth(), given a vector of quartile and another vector of grade levels, returns a vector of KIPP Tiered Growth factors/multipliers
  s2s_match(), given a long-format map assessments data.frame, and two season as a growth period, the functions creates two subsets by season in a given year and merges them with an inner join on on student id and measurement scale, then returns that data.frame with smartly labeled column for the second season in a pair. If you ask nicely will also calculate typical growth, typical growth targets, and a typical growth met/exceeded indicator. Ditto college ready growth, targets, and indicators. Though for these you'll need some properly named columns right now.
  Oh, and s2s_match is super duper fast. Using the the three previous functions on the three years of long data and then using s2s join on each year for five (5!) "growth seasons" (f-s, s-s, f-w, w-s, f-f) and then binding all that up took like 1/2 a second. Seriously. That is totally rad.

mapvizr or mapvizier

I like the latter cause it is so Hadley-esque (i'd go with the mapvizier pronunciation). That sad, mapvizier has a nice ring to it and most will pronounce it correctly.

So all of that said, why don't we stick with the latter.

At this point I think we should rename the package and perhaps move it to the @kippdata repo. I think we'd simply fork this branch to that repo and then anyone developing should start a new remote directory and clone from the @kippdata version. Put another way, we freeze development on this repo, fork it to @kippdata, and continue development from that fork by individuals forking from there.