Explore unifying DMN storage and execution path for custom and library checks
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Refactor
- Clarity
- Needs clarification
- Activity status
- Quiet
- Domain
- full-stack
Research direction
Start by mapping how custom and library checks are created, edited, stored, and used in the web app, then review the constraints of keeping the library as a standalone API. Done would require a decided unified library model, with permissions and sharing differences defined and the DMN editing experience addressed.
Written by the indexing model from the issue text.
Description
We have complexity arising from the differences in how custom checks and library checks are created, edited, stored, and used in the web app.
Assumption/ideal to explore: All checks should exist under a single "library" paradigm. They should be implemented as similarly as possible and managed via web interface. The difference between "custom" and "library" should come down to permissions and sharing logic.
Advantages:
- less complexity in the web app's code paths and in the "eligibility check" concept. (one paradigm instead of two)
- one interface for creating/managing
- opens up interesting features like sharing checks, duplicating/modifying library checks, promoting custom checks to the library, using existing library checks within a custom check, etc.
Probable challenges:
- keeping the library usable as a standalone API
- the difference between how custom and library checks are currently implemented (e.g. more boilerplate and DMN know-how are required for library checks)
- significant UX challenges to ensure proper editing of checks with guardrails necessary (simplifying or otherwise improving the default DMN-editing experience)
- Dominant language
- Java
- Stars
- 16
- Forks
- 5
- Avg merge
- 1d 26m
- Merged PRs (30d)
- 25
Getting set up
We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CodeForPhilly/benefit-decision-toolkit
-
documentation Good for newcomer quick win
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
CodeForPhilly/benefit-decision-toolkit#519 ·
Maintainers usually reply within 1 day
-
documentation quick win
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
CodeForPhilly/benefit-decision-toolkit#445 ·
Maintainers usually reply within 1 day
-
Make issue templatesOpen
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
CodeForPhilly/benefit-decision-toolkit#425 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
CodeForPhilly/benefit-decision-toolkit#525 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
CodeForPhilly/benefit-decision-toolkit#524 ·
Maintainers usually reply within 1 day
All issues in CodeForPhilly/benefit-decision-toolkit
Similar issues
-
P2 testing
Difficulty 1/5 Under an hour Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
area/core kind/bug status/triage team/core-shared
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
checkstyle/checkstyle#21755 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
spring-projects/spring-integration#11495 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day