[RFC]: .github: improve the PR template

[paper42]

Filling out the "Does it run and build successfully" section is
necessary only when the CI is skipped, but this is easy to miss.
Separate it from the rest of the text to make it clearer.

cc @ailiop-git

[ericonr]

Want to couple this with not making them tick boxes anymore? Having all PRs with checklists is a bit bothersome.

[paper42]

Want to couple this with not making them tick boxes anymore? Having all PRs with checklists is a bit bothersome.

I made a draft of how it could look. It needs a grammar review and we also need to decide if this is the right way to go. @void-linux/pkg-committers

[Piraty]

some of the usual suspects already miss the point of why this was added in the first place, i'm all for cleaning it up

[paper42]

I removed the options we don't want to encourage - "I did not test this PR" and "This package doesn't conform to the quality requirements".

[paper42]

Is this fine or is it too harsh?

[Chocimier]

Policy is just right, statement is kind of implied by previous one.

[Piraty]

not harsh and to the point.

how about something like *YES*|*NO* (in bolds) to make it both (even more) obvious to contributor that an answer is required and obvious to maintainer if it wasn't answered (like not checking any checkbox before).

[Chocimier]

good idea of yes|no

[paper42]

Policy is just right, statement is kind of implied by previous one.
not harsh and to the point.

I think I will leave it there even though it's implied by the first comment just to be explicit.

how about something like YES|NO (in bolds) to make it both (even more) obvious to contributor that an answer is required and obvious to maintainer if it wasn't answered (like not checking any checkbox before).

Something like this?

#### Testing the changes
- I confirm this PR works for me: **YES**|**briefly**|**NO**

#### New package
- This new package conforms to the quality requirements: **YES**|**NO**

#### Local build testing
- I built this PR locally for my native architecture, (ARCH-LIBC)
- I built this PR locally for these architectures (if supported. mark crossbuilds):
  - aarch64-musl
  - armv7l
  - armv6l-musl

This way we can not differentiate between well tested and lightly tested PRs. The last section can not be adapted to this form, so it will be inconsistent with the rest of the PR template.

[Gottox]

Looks good to me.

• Maybe link the quality requirements, so new committers can find them
• Give committers instructions when it's okay to remove a statement and which are mandatory to open a PR.

[Chocimier]

Second thought: separate lines are easier to edit, thus better for permanent contributors.
Could that be changed to something keyboard-friendly like ** YES briefly NO **, at least?

[paper42]

Removing lines has an unfortunate consequence - it's not immediately obvious which option was selected compared to the current way (checkboxes). This might make PR template useless if we don't figure out how to clearly distinguish the options - different words at the start, different length, etc.

I would be in favor of the YES NO way because it's clear where to look when reviewing a PR.

[Chocimier]

Let's try to distinguish, with decoupling "tested" from "using" on top.

#### Testing the changes
- I regularly use the affected package
- Just contributing with package I use sporadically to never

- I tested the changes in this PR by using package with changes for some time
- Automated `do_check` passed, nothing can possibly go wrong

#### New package
- This new package conforms to the [quality requirements](https://github.com/void-linux/void-packages/blob/master/Manual.md#quality-requirements)
- Excuse to not conform to the quality requirements is ...

[Piraty]

fine, everyone?

[Vaelatern]