#2276: Add Backlog section documenting how to find a new story

[krystynaShatkovska]

This PR fixes #2276

Implemented changes:

• Added a new "Backlog" section to documentation/contributing/issue.adoc with a step-by-step guide on how to find and pick a new story from the project backlog — including the
  issue query link, explanation of ready-to-implement and good-first-issue labels, consideration of Priority/Size for experienced contributors, and a reminder to self-assign
  before starting work

---

Testing instructions

1. Open documentation/contributing/issue.adoc and verify that the new == Backlog section appears before == Working on an Issue
2. Check that the linked issue query URL opens the correct filtered issue list:
   https://github.com/devonfw/IDEasy/issues?q=is%3Aissue%20state%3Aopen%20no%3Aassignee%20label%3Aready-to-implement
3. Verify that the cross-reference link to project-board.adoc resolves correctly
4. Confirm that no content from the existing "Working on an Issue" section was lost or broken

---

Checklist for this PR

Make sure everything is checked before merging this PR. For further info please also see
our DoD.

• When running mvn clean test locally all tests pass and build is successful
• PR title is of the form #«issue-id»: «brief summary» (e.g. Bump jackson.version from 2.18.0 to 2.18.2 #921: fixed setup.bat). If no issue ID exists, title only.
• PR top-level comment summarizes what has been done and contains link to addressed issue(s)
• PR and issue(s) have suitable labels
• Issue is set to In Progress and assigned to you or there is no issue (might happen for very small PRs)
• You followed all coding conventions
• You have added the issue implemented by your PR in CHANGELOG.adoc unless issue is labeled
  with internal
• You have formulated clear instructions on how to test your contribution under "Testing instructions"

---

Notes:

• I removed the "Checklist for tool commandlets" section since this PR doesn't add a commandlet (as instructed)
• Don't check the boxes yet — the instructions say to check them after the PR is created
• The PR title should be: Create documentation how to find story from Backlog #2276: Add Backlog section documenting how to find a new story

[coveralls]

Coverage Report for CI Build 31161585568

Coverage increased (+0.02%) to 72.891%

Details

• Coverage increased (+0.02%) from the base build.
• Patch coverage: No coverable lines changed in this PR.
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	17493
Covered Lines:	13298
Line Coverage:	76.02%
Relevant Branches:	7727
Covered Branches:	5085
Branch Coverage:	65.81%
Branches in Coverage %:	Yes
Coverage Strength:	3.23 hits per line

---

💛 - Coveralls

[Hiepiscus]

@krystynaShatkovska Looks good to me. The new section clearly explains how to find a suitable issue from the backlog and covers all points from the issue description. One thing I noticed, I think there is a typo in the rendered URL, so the project board link does not resolve correctly.

[hohwille]

@krystynaShatkovska thank you for your PR. This is a great improvement. 👍
I only have marginal nice-to-have suggestions for you.

[hohwille]

Please avoid this legacy link syntax:

Suggested change

	See <<working-on-an-issue, Working on an Issue>> for the detailed steps.
	See xref:working-on-an-issue[Working on an Issue] for the detailed steps.

For links use:

https://external.link.com[external link]
link:other-file.adoc[other-file-link]
xref:section-ref[link-to-section-in-same-file]
link:other-file.adoc#section-reference[link-to-section-in-other-file]

Please note that we also generate PDFs from AsciiDoc and there we need to transform all kind of links to work inside the PDF was is unfortunately not supported by AsciiDoctor out of the box.
Therefore we had to implement our own logic to process and reformat such links for PDF generation (see documentation/pom.xml).
That is not relevant for this specific file but we should try to do this consistently across all AsciiDoc files because it is hard to explain every developer what file ends up in the PDF and what not.

Long time ago I wrote some AsciiDoc Guidelines for devonfw:
https://github.com/devonfw/docgen/blob/master/documentation/guidelines.asciidoc

They may not be fully up-to-date but we should maybe add our own IDEasy copy of this documentation in the contributing area to make all these things more transparent.

[hohwille]

It seems that you created your own way to support footnotes.
FYI: AsciiDoc has official support for it here.
However, it is most likely not supported by the GitHub AsciiDoc renderer so your pragmatic approach is fine.

But could you avoid these leading and or trailing dots that seem a little inconsistent/confusing to me?