- This topic has 0 replies, 1 voice, and was last updated 1 year, 3 months ago by .
Viewing 0 reply threads
Viewing 0 reply threads
- You must be logged in to reply to this topic.
The latest EdReady update went through on Saturday morning, Nov 3. There have also been a few minor updates since the last community posting.
We are now capturing resource-activity data per session, which means that we will be able to see exactly how much time each student is spending studying any given resource session by session. Previously, those data were being captured in aggregate. This new feature gives us much greater capability to analyze how students are spending their time when they are trying to learn a topic, and also to evaluate the efficacy of individual resources for different students.
At a higher level, this additional data capture effectively completes our long-term roadmap for data capture protocols for the EdReady platform. We will continue to capture new data points, and we will continue to build or enhance reports and charts based on these and other data. But we are now capturing all of the key data flows at the right level of detail so that we don’t have any gaps in the database. Note that these new session-specific data have only just begun to be captured, so any students who have already been using EdReady prior to this weekend will not have complete data for that aspect of the system. As time passes, this discrepancy will fade away.
In addition to this feature, we added some new information to some of the existing reports, such as the date on which a student reached the target score (on the enrollment report), and we corrected some information which was not rendering correctly (such as student status on the enrollment report). We also added some additional validations and improved error messaging to better handle situations where students are inadvertently removed from a goal, or deactivated.
Prior to this release, some of you are probably aware that we had a data-loss incident which took us by surprise. Since then, we have added a number of additional safety checks on all of our run-time administrative tasks, and we are updating our incident-response protocols. While there is no way to achieve a zero-risk state, we are quite confident that this sort of data-loss issue will not occur again.
Finally, completely unrelated to that incident (as it turns out), we discovered that there is a bug in one of the configuration options for the study paths which was propagating through the system when cloned. We squashed the bug and have almost finished cleaning up the affected study paths across all users. That process revealed some opportunities for further improvement to significantly reduce the likelihood of these types of bugs occurring again in the future. As usual, we will be balancing these types of improvements against the features that are already under development to try to move both aspects of our ongoing development work forward at a measured pace. Look for another update in December.