Project Meeting 2023.09.19 - ActivitySim/activitysim GitHub Wiki
Agenda
Updates
Input Checking (RSG)
Configuration Documentation & Input Checking (CS)
Component Documentation (CS)
User's Guide (CS)
Admin
Partner payment update
Meeting Notes
Technical Task Updates
Input Checking (RSG)
SEMCOG received the input checker about two weeks ago. There were some hurdles to get through, since they used the new orca removal code. SEMCOG not able to join today, but they are testing out the input checker.
Remaining tasks will be finalized after SEMCOG's review.
TBD for next check-in. Michelle to ask SEMCOG about timing for review.
Configuration and Component Documentation (CS)
Jeff provided an overview of how components can be documented, noting that the main effort will be pulling from the docstring. Underlying file that defines the documentation includes a short amount of information and mostly pulls content from the code itself: the docstrings and functions.
Documentation has been completed for accessibility, auto ownership, free parking eligibility, school location, trip destination, work from home and work location. Others are in progress.
CS emphasized that we are not generating new content for these components but instead pulling existing documentation from the code. CS wanted to note that there is a lot of existing information that is out of date. For example, some documentation is very specific to the original MTC example (implementation-specific) and not the generic feature for any implementations of that component. We may need to spend some effort on curating the content to be more up-to-date.
CS to complete the basic documentation and then reassess funds available for updating that out-of-date information. At a low-end effort, we would just delete those implementation-specific information. At a higher end, we can revise the text to be more generic for any implementation (which may require using some funds from the general code review bucket). A path forward will be reassessed later.
User's Guide (CS)
CS summarized the overall plan for the update. The primary effort will be to reorganize and simplify where relevant, to produce a more easily digestible User's Guide. This will include moving existing content to the reorganized User's Guide or to the Developer's Guide.
There are different tiers of ActivitySim users. This User's Guide will focus on the every day running / application of ActivitySim, with a more model developer-focused version being separate.
First steps for CS is to create a proposed restructuring and provide that outline to the consortium for their review. Michelle showed the start of an example of what it would look like.
We'll put some thought into understanding the needs of the every day user. For example, we are assuming someone is going to pick up an established example and want to apply it, and we will consider the critical things that they'll need to know to run that model.
Questions from the consortium
Will the guide by more like read a wiki or have some interactive components? Interactive components might be out of scope at this time, and priority will be to retain much of what is there, as it is relevant.
Will chunking and sharrow would be included in the User's Guide? Chunking does seem like something that every day users would need to know but unsure about sharrow, that might be more for developers.
It was also noted that this User's Guide will not include any implementation-specific information. Down the road, when we have 2-3 well-maintained example models, we can produce implementation-specific content for those models that the consortium will be maintaining.
TO DO: Michelle to send out a proposed restructuring/outline of User’s Guide and allow Consortium to add comments/edits. Next update in 2-3 weeks, TBD.
Admin
Partner Payment update
For Phase 9 there is about $420k with 12 partners on ($455k if a 13th partner joins)
No one reported any issues on the partner-side related to payment
Many issues were posted to GitHub
Newly added issues were for bench and partners to track considerations for future potential scoped items.
Intention is to allow us to narrow focus on what different tasks actually mean.
As features are agreed upon as a priority, use that issue to track development.
These discussions can be moved to issues as partners think about future phases of work and have the info readily available.
At some point, we may want to consider how to designate issue to different model version.