Skip to content
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

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from
Draft

Seasonal income classes #198

wants to merge 5 commits into from

Conversation

plocket
Copy link
Collaborator

@plocket plocket commented Oct 11, 2023

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.

Copy link
Member

@nonprofittechy nonprofittechy left a 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.

Comment on lines +26 to +29
month_names = [
"january", "february", "march", "april", "may", "june",
"july", "august", "september", "october", "november"
]
Copy link
Member

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.

Copy link
Collaborator Author

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.

Copy link
Member

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.

Copy link
Collaborator Author

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.

seasonal_income_demo.txt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants