Update docs screenshots to reflect new navigation design and use the actual in-app example screener
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 55/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- java
- Domain
- documentation, tooling
Research direction
After #522 and #525 are complete, inspect the screenshot automation scripts in e2e and compare the current docs example with the in-app example screener. Done means the screenshots and any affected docs text reflect the new navigation and actual screener; also document whether combining the scripts or sharing setup is worthwhile.
Written by the indexing model from the issue text.
Description
Depends on #522 and #525 being complete first!
There are a couple of scripts (in e2e I believe) that automate creating screenshots, so maybe that can streamline this task.
Will probably need to update the scripts (and maybe some of the docs text too?) to reflect the content of the in-app example screener instead of the dummy screener that currently is used for docs. (Sanity check that this makes sense before beginning! - is there something gained by keeping the two separate (docs example vs. in-app example).
Bonus: combine the existing screenshot automation scripts into one script (or maybe separate scripts with a common setup? Not sure, but investigate what is best)
- 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
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
CodeForPhilly/benefit-decision-toolkit#524 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
CodeForPhilly/benefit-decision-toolkit#523 ·
Maintainers usually reply within 1 day
All issues in CodeForPhilly/benefit-decision-toolkit
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
geonetwork/geonetwork#227 ·
Maintainers usually reply within 3 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Netcracker/qubership-testing-platform-tdm3#138 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
synthetichealth/synthea#1726 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
bisq-network/bisq#8097 ·
Maintainers usually reply within 1 day
-
area/frontend good first issue kind/cooldown
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day