-
Notifications
You must be signed in to change notification settings - Fork 2
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
Seasonal income classes #198
base: main
Are you sure you want to change the base?
Conversation
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 is looking pretty reasonable to me. I'm just wondering if months is the right level to chunk on. It's still going to require most folks to do their own math, isn't it? Since people will have bi-weekly paystubs most of the time, not monthly.
month_names = [ | ||
"january", "february", "march", "april", "may", "june", | ||
"july", "august", "september", "october", "november" | ||
] |
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.
Same question as above. I'm just curious if this needs to be limited to chunking by month. Biweekly pay is a bit more common for most folks.
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.
That's a good question. @CaroRob and I have been thinking about that discussion. I had hesitated to go beyond months since some seemed reluctant about getting even this granular, but if folks are open to that discussion, I am too.
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.
Think about whether limiting it to months helps achieve any of the goals. It might, but I'm not sure. I think you discussed letting people avoid math. Monthly chunking doesn't seem like it would save any math.
Maybe letting users enter a date range? E.g., teachers usually have 9 month contracts, although they don't always have the choice to get paid over 9 months rather than 12.
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.
I've made it more flexible. Will wait to fully adjust the demo till I get the go-ahead. Here's a sample file that shows the most basic application (you must answer that, yes, your job is seasonal). It's .txt and you have to have to change it to .yml because GitHub won't let me upload a .yml.
Only partly implemented to check in on the model.
It's messy, as we knew it would be. I'd appreciate feedback if folks have the time. I've created an experimental yml for implementation, but I'm unable to get it working in the ways I'd expect it to work. I keep triggering default questions instead of month questions. Missing something fundamental.
I'm concerned about
.is_hourly
and.hours_per_period
. Somewhere along the way they started getting required. I tried to restore them to their previous optional status as they were giving me trouble for a non-hourly job, but I may be missing context. May need live discussion.It also looks like the
holidays
dependency has something going on as tests are failing on it.