Refine PULL_REQUEST_TEMPLATE.md

[koppor]

Minor tweak to make it clear what unchecked TODO boxes mean in our context.

Mandatory checks

• I own the copyright of the code submitted and I license it under the MIT license
• [/] Change in CHANGELOG.md described in a way that is understandable for the average user (if change is visible to the user)
• [/] Tests created for changes (if applicable)
• [/] Manually tested changed features in running JabRef (always required)
• [/] Screenshots added in PR description (if change is visible to the user)
• [/] Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
• [/] Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[calixtus]

im still not so happy with unchecking by putting sthg into the boxes. Github does not understand them. If they are empty, you can click on them in github ui to check/uncheck them. If you put sthg inside but an x, you cannot click them anymore...

[koppor]

im still not so happy with unchecking by putting sthg into the boxes. Github does not understand them. If they are empty, you can click on them in github ui to check/uncheck them. If you put sthg inside but an x, you cannot click them anymore...

Exactly as intended. The / denotes not-applicable.

If we say to a contributor: Please do it, we cannot simply uncheck a box, we need to tell him in other ways.

For me, it helps that a checked box means "done" in the sense of a change of the global JabRef state (code changed, documentation changed, issue created) - and not "done or invalid or not-done, but thought of",

[subhramit]

im still not so happy with unchecking by putting sthg into the boxes. Github does not understand them. If they are empty, you can click on them in github ui to check/uncheck them. If you put sthg inside but an x, you cannot click them anymore...

Our thought process during the decision:
We did that to differentiate if people have read the section or not. When writing the initial description from the template, the contributor uses the keyboard instead of mouse - so they are to remove the dot inside [.] and choose as applicable.

Ideally, the boxes should contain only [ ] or [x]. Only disagreement may be in case of not applicable - whether it should be a [/] or a strikethrough (although that may be a bit extra instruction for the contributor). Both are not recognized by github markdown as valid clickable checkboxes.
GitHub counts the number of "applicable" tasks done that way as well:

Do you propose anything different?

[trag-bot]

@trag-bot didn't find any issues in the code! ✅✨

[calixtus]

clueless too. @koppor has a valid point. we expect the contributors to read the text. And i would not want to have or maintain a cla like oracle.

[calixtus]

lets not make this a problem now, maybe we see sthg better eventually and discuss it then.