-
Notifications
You must be signed in to change notification settings - Fork 3
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
Implement Riders narrative #576
Conversation
Pull Request Test Coverage Report for Build 2711312681Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
So, I has implemented Riders configuration with existing charts & metrics. @hobuobi @macfarlandian Is there specific data fixtures for this narrative? If yes, we need only to paste them into the project and correct the metrics in |
Hey @nasaownsky – great work! @macfarlandian and I chatted and figured that this work will definitely need more time. As such, I think we can ignore the original Monday deadline and take whatever time is necessary to do it right! Regarding the charts involved, I think the following are relevant, though I would fall back to @macfarlandian 's guidance.
Most of the mock data can still be found here. We should be able to get you CSVs with the actual data very soon (cc @samanthahuff). |
@nasaownsky I will add some more detail to the ticket with implementation suggestions for the points Humphrey mentioned above, just to limit the noise here. You also may wind up wanting to separate it into multiple pull requests because it's going to be a lot (as I am sure you have already discovered for yourself!) |
Hey @hobuobi @macfarlandian, happy Independence Day guys! So, I'm adding 1st and 3rd sections of Riders narrative, they all pretty much done. A few nits & questions:
Thanks, guys, and have a great weekend. |
// get unknowns(): UnknownsByDate | undefined { | ||
// const { allRecords } = this; | ||
|
||
// if (!allRecords) return undefined; | ||
|
||
// const countsByDate = groups(allRecords, (r) => r.date) | ||
// .map(([date, records]) => ({ | ||
// date, | ||
// unknowns: countRiderUnknowns(records, (groupedRecords) => | ||
// sum(groupedRecords, (r) => r.count) | ||
// ), | ||
// })) | ||
// .filter((item) => hasUnknowns(item.unknowns)); | ||
|
||
// return countsByDate.length ? countsByDate : undefined; | ||
// } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This unknowns
method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nasaownsky I think you're on the right track in that you probably do need a separate count function because this record type does not include demographic fields like the others. You could just have it accept a HistoricalPopulationByCategoryRecord
as input or it could be more generic and accept anything that extends {category: string}
or something like that ... it can be a little simpler than the countUnknowns
function in that it only has to check for unknowns in one field, the category
field, and the return type could probably just be a number? (you could probably give it a more generic name also since there is nothing Rider-specific about this logic.)
Essentially a version of this one-line function is all you really need here ... if you wanted to go a step further you could factor that out into something that will generically check any field for unknowns, but I think it's fine to just copy and update it also since it's so simple.
Does that help? Let me know if there are any more specific questions I can answer to assist with this.
@hobuobi Added 2nd section. Also, paying your attention that the data is builded not accurately. For example: |
…into nasaownsky/518-riders-narrative
Thanks Ilya! Apologies for the late response, was out of the office for some family things.
|
@hobuobi Sure, here you go: https://www.loom.com/share/5c406cc07a534082a6700c0ea2e32edf . Also, you can try run the App in demo mode by using @macfarlandian I don't understand why |
Wow, this is looking AMAZING. Thank you for all your help with this. Regarding functionality: I think this is actually almost perfect based on the video! My only comments (neither of which should block your PR, but should be addressed before launch):
Regarding copy: @ldfielding and I will work on refining this, and it should not block merging the PR (another team member can refine this later if necessary). |
Nothing is really jumping out at me either. I thought maybe it was objecting to some upstream change but I don't really see what that could be, and the error messages are not very informative ... looks like it will require some good old fashioned debugging |
@hobuobi I assume I should use |
@hobuobi I've played with implementation and this treatment not working properly because of complex logic of the new chart and its highlighting. I think it takes some time to figure out how to make it work properly, so it's on you to decide. |
@macfarlandian Things are really strange, if I add |
the "timeout" error messages are confusing but common, they really just indicate that the test was waiting for a promise that never resolved (which would be one of the async functions called within ... it doesn't really tell you where it stalled unfortunately so if there is more than one With intermittent failures like this the things I would probably investigate first include the test environment (including the global setup) and any known shared state across tests (e.g. demo data, the singleton RootStore). For me they fail even when running them individually so I actually don't really suspect a state leak across tests so much. Maybe it's more likely to be a problem with the test configuration? I spent a little more time poking at it this morning but honestly I still have no real leads on it |
The reason for the decimals is that this is the average daily population for each month. It looks like spotlight potentially counts total distinct people per month from what I can tell from the incarceration_population_by_prioritized_race_and_ethnicity_by_period view. I originally modified a query that Kris sent me that was modeling the Key Sessions looker dashboard I believe, but I'm circling back with him about where that query came from. Would it be better to have total distinct people per month? |
This is correct, we use distinct person counts everywhere in Spotlight (either in point-in-time snapshots or aggregated over some time window). There's nothing to say we couldn't introduce average counts but you will definitely find that the UI always assumes these kinds of counts will be integers and person counts so we will probably at least want to do a thorough check that they're labelled correctly wherever they appear and that we're happy with how they're formatted |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of this looks good to me! Pending changes (to be handled separately):
- Methodology for these sections
- Copy for the final section
- Small numbers treatment for the reincarceration plot
Other than that, should be good to go! Will await a technical team member's official signoff.
@macfarlandian It seems like it crashes only because of |
Makes sense! I sent an updated csv to Humphrey with distinct totals. Code for that change can be found in the PR for the Rider analysis. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@macfarlandian It seems like it crashes only because of
demographic data
section ofSupervisionSuccessRateMetric.test
(line 220). If disable it, the tests passes just fine.
Fascinating. I am still totally stumped by this, but since the metric itself seems to be working fine in the application and this is totally unrelated to your work I think you should just disable it and move on. Please leave a comment on the disabled tests that references this issue I just created for it: #589
I am doing one last review before approving, so just marking this as "request changes" to put a hold on it in the meantime! I am doing this now though so hopefully will be able to approve shortly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noted a couple of very minor things I think you should address but nothing blocking. Great work!
import React from "react"; | ||
import CategoriesByDemographicMetric from "../contentModels/CategoriesByDemographicMetric"; | ||
import DemographicFilterSelect from "../DemographicFilterSelect"; | ||
import BarChartPair from "../RacialDisparitiesNarrativePage/BarChartPair"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because this component is not specific to the Racial Disparities narrative anymore I would move it out into its own folder (src/BarChartPair
)
justify-content: flex-end; | ||
`; | ||
|
||
type BarChartClucterProps = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
*Cluster
@@ -23,29 +23,31 @@ import { | |||
import Metric from "./Metric"; | |||
import { MetricMapping, MetricRecord } from "./types"; | |||
|
|||
type NarrativeTypeId = SystemNarrativeTypeId; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this change doesn't really seem necessary
…into nasaownsky/518-riders-narrative
…into nasaownsky/518-riders-narrative
@macfarlandian @hobuobi Should be ready to go now! |
Description of the change
Implemented base Riders narrative
Type of change
Closes #518
Checklists
Development
These boxes should be checked by the submitter prior to merging:
Code review
These boxes should be checked by reviewers prior to merging: