Create manual_test_rule_template

[HelenBurge]

Adding a first go at the manual test rule template (same as the others but with extra guidance at the start)

Starting on the work for the new manual test rules

Closes issue(s):

Need for Call for Review:
This will not require a Call for Review - it is a template

---

Pull Request Etiquette

When creating PR:

• Make sure you're requesting to pull a branch (right side) to the develop branch (left side).
• Make sure you do not remove the "How to Review and Approve" section in your pull request description

After creating PR:

• Add yourself (and co-authors) as "Assignees" for PR.
• Add label to indicate if it's a Rule, Definition or Chore.
• Link the PR to any issue it solves. This will be done automatically by referencing the issue at the top of this comment in the indicated place.
• Optionally request feedback from anyone in particular by assigning them as "Reviewers".

When merging a PR:

• Close any issue that the PR resolves. This will happen automatically upon merging if the PR was correctly linked to the issue, e.g. by referencing the issue at the top of this comment.

How to Review And Approve

• Go to the “Files changed” tab
• Here you will have the option to leave comments on different lines.
• Once the review is completed, find the “Review changes” button in the top right, select “Approve” (if you are really confident in the rule) or "Request changes" and click “Submit review”.
• Make sure to also review the proposed Call for Review period. In case of disagreement, the longer period wins.

[Jym77]

The file should be moved together with the other templates.

[carlosapaduarte]

With a small suggestion. Feel free to leave it out.

[Jym77]

There is a problem with the tests 🙈
Due to the text at the start, before the first ---, the frontmatter is not seen by the parsing (.use(remarkFrontmatter) in getMarkdownData). In turn, this means that

• prettier tries to re-pretties it and break the correct indentation it should have (mildly annoying).
• spell check tries to spell-check the frontmatter and complains about forConformance or similar keys (very annoying since it breaks tests and we cannot merge).

Easy solutions:

• Move instructions inside (or after) the frontmatter. This may be a bit more annoying for rule writers, but would solve both problems.
• Add spelling exceptions. A bit dirty but working to solve the second problem. The first stays.
• Ignore this file in describe-page.js and in the prettier hook. Could also work; not sure how to ignore it in the prettier hook, though.

@HelenBurge Do you think that moving the instructions inside, or after the frontmatter (after the first or second ---) would be OK? Essentially, there cannot be anything before the first --- in the file.

[HelenBurge]

There is a problem with the tests 🙈 Due to the text at the start, before the first ---, the frontmatter is not seen by the parsing (.use(remarkFrontmatter) in getMarkdownData). In turn, this means that

• prettier tries to re-pretties it and break the correct indentation it should have (mildly annoying).
• spell check tries to spell-check the frontmatter and complains about forConformance or similar keys (very annoying since it breaks tests and we cannot merge).

Easy solutions:

• Move instructions inside (or after) the frontmatter. This may be a bit more annoying for rule writers, but would solve both problems.
• Add spelling exceptions. A bit dirty but working to solve the second problem. The first stays.
• Ignore this file in describe-page.js and in the prettier hook. Could also work; not sure how to ignore it in the prettier hook, though.

@HelenBurge Do you think that moving the instructions inside, or after the frontmatter (after the first or second ---) would be OK? Essentially, there cannot be anything before the first --- in the file.

I have amended the instructions to be after the ---

[carlosapaduarte]

Changes proposed by Jean-Yves need to be applied