Clarify check renaming and streamline the publishing workflow
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
Research direction
Start by tracing the existing check-renaming and publishing workflow and documenting where the UI shows the current publication state. Resolve whether automatic publishing, a prompt, or clearer separate publishing guidance best meets the stated outcome, then define acceptance criteria showing that users understand whether a rename is live and whether further action is required.
Written by the indexing model from the issue text.
Description
Problem
Renaming a check currently requires a separate republish step. New users may reasonably expect the rename to take effect without realizing that they must also publish a new version.
This raises a broader usability question: is the requirement to publish checks clear, and can that workflow be streamlined?
Questions to resolve
- Should renaming a check automatically publish a new version?
- Should the user be prompted to choose what to do after renaming?
- If publishing remains a separate step, how should the UI make that requirement and the current publication state obvious?
- Can check publishing generally be streamlined or better explained for new users?
Desired outcome
Define and implement a clear rename/publishing experience so users understand whether their rename has taken effect and whether another action is needed. Automatic publishing and prompting are options to evaluate, rather than decisions already made.
- Dominant language
- Java
- Stars
- 16
- Forks
- 5
- Avg merge
- 14h 45m
- Merged PRs (30d)
- 25
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
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
-
Update docs screenshots to reflect new navigation design and use the actual in-app example screenerOpen
Difficulty 3/5 1-2 days Newbie friendliness 55/100
CodeForPhilly/benefit-decision-toolkit#528 ·
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
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
beehive-lab/TornadoVM#1151 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
FasterXML/jackson-dataformats-binary#823 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day