Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

How to best support a "work requirements exemption" screener

Đang mở
  • Có gì không ổn?
#513 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Lĩnh vực
backend, documentation

Hướng nghiên cứu

Start by reviewing the existing SNAP and Medicaid work-requirements screener approach described in the issue, including its eligibility checks and expression-based OR logic. Compare a few implementation approaches and document their tradeoffs, then evaluate guidance options such as a tutorial or creation wizard. Done means the approaches and analyst guidance are tested against realistic complex screeners.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

big lift research

For the recent (SNAP) and upcoming (Medicaid) work requirements, we need to find a good way to support this concept in our platform.

It feels like the concept of a "benefit" is tenuous here - I'm thinking of Openfisca and how everything is a variable and variables exist in a hierarchy of many other variables.

In that OF conceptual framework, "Meets SNAP Work Requirement" would be a variable that we would either test on its own, or have it be included under the umbrella of the overall "Eligible for SNAP" umbrella.

What this would mean in our project is dissolving the difference under the hood between a "benefit" and an "eligibility check". Both would be variables and you would select a variable to behave as a benefit for the purposes of a screener. Then it's immediate "children" variables would become the eligibility checks.

I'm not convinced (yet) that we need to do the above - i think there is advantage (to analysts building screeners or library logic) in things being as simple (constrained) and straightforward as they are right now.

My belief in keeping constraints extends to the discussion about whether to open up the logical possibilities for eligibility checks beyond the current paradigm (supporting more complexity than "these N number of eligibility checks need to be all true for the benefit to be eligible).

The logical complexity will need to happen somewhere, of course, but I'd like the complexity to be in a single predictable place, if that is possible, by default... with eventual ability to open "escape hatches" to do whatever you want...

That said, there is little guidance in the app to help an analyst architect these different pieces to fit the paradigm... And we still have to prove that real (and complex) screeners can actually be built this way.

So, for this issue I'd like to do two things:

  1. Think through (and/or actually build) a couple of ways to do the SNAP/MA work requirements screeners. What are the pros and cons of each approach?
  2. Experiment with a few ways to guide analysts in how to think of the "benefit", the associated checks, and how the logic could be architected.
  • ideas:
    • AI-assisted "benefit creation wizard", resulting in a skeleton/draft of the benefit and checks needed.
    • Traditional tutorial that walks through the different UI elements and how to map benefit logic into our paradigm via a simple example.
    • AI-assisted "eligibility check creation" that asks for a description of the check (a prompt) and then offers a draft implementation in the app.

Sara's original notes:

Under the current set up, all benefit checks must be true for a benefit to be eligible. For this exemption screener, only one TRUE is needed. I summed all the results into a list, then used expressions to evaluate the results. That's why there is only one 'meets work requirements or exemption' check, which is using either the maQuestionList or snapQuestionList to determine eligibility. This is related to previous discussions we've had about a need for a way to add OR and AND conditions. This is basically one long list of ORs.

Image Image
Ngôn ngữ chính
Java
Star
16
Fork
5
Merge trung bình
17 giờ 24 phút
Pull request đã merge (30 ngày)
23

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

  • Không có Dockerfile hay tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của CodeForPhilly/benefit-decision-toolkit

Tất cả issue của CodeForPhilly/benefit-decision-toolkit

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.