luci: updates to Pull Request template and CONTRIBUTING.md

[owlsy]

As a new person to contributing on GitHub, I noticed the Pull Request template and CONTRIBUTING.md missing some important information that I would not have known until I tried my first Pull Request, such as the character limits and email requirements. I've seen others also get tripped up by this too, as they also were not aware until afterwards. So, I have tried to include the common ones into:

• the Contributing Guidelines, along with some minor capitalisation updates for consistency.
• the Pull Request template. I have also prepared a layout that would ensure a more uniform experience when looking through Pull Requests, with expected headings and the ability to provide the instruction to users of what to put under each heading. Minor grammar and punctuation edits as well.

The justification for combining the changes above are due to the intention of the edits — it is to ensure the user has an understanding of what is expected in order to contribute:

1. Reads CONTRIBUTING.md, is aware of what to do for commits
2. Makes commits and wants to create Pull Request
3. Reads the HTML comments of the Pull Request template, is reminded of what is expected and feels supported with completing the Pull Request with dedicated sections.

Regardless of the rationale above, if the layout is preferred as a seperate Pull Request, let me know and I will do so.

For feedback,

• @systemcrash for Pull Request template.

• @jow-, possibly @hnyman @stokito @systemcrash for CONTRIBUTING.md file.

• This PR is not from my main or master branch 💩, but a separate branch ✅

• Each commit has a valid ✒️ Signed-off-by: <my@email.address> row (via git commit --signoff)

• Each commit and PR title has a valid 📝 <package name>: title first line subject for packages

• Incremented 🆙 any PKG_VERSION in the Makefile (Not applicable)

• Tested on: (architecture, openwrt version, browser) ✅ (Not applicable)

• ( Preferred ) Mention: @ the original code author for feedback

• ( Preferred ) Screenshot or mp4 of changes: (Not applicable)

• ( Optional ) Closes: e.g. openwrt/luci#issue-number (Not applicable)

• ( Optional ) Depends on: e.g. openwrt/packages#pr-number in sister repo (Not applicable)

• Description: (describe the changes proposed in this PR)

[owlsy]

For a proof of concept as well, the next comment is what the template would look like with the same information.

[owlsy]

Pull Request details

Description

As a new person to contributing on GitHub, I noticed the Pull Request template and CONTRIBUTING.md missing some important information that I would not have known until I tried my first Pull Request, such as the character limits and email requirements. I've seen others also get tripped up by this too, as they also were not aware until afterwards. So, I have tried to include the common ones into:

• the Contributing Guidelines, along with some minor capitalisation updates for consistency.
• the Pull Request template. I have also prepared a layout that would ensure a more uniform experience when looking through Pull Requests, with expected headings and the ability to provide the instruction to users of what to put under each heading. Minor grammar and punctuation edits as well.

The justification for combining the changes above are due to the intention of the edits — it is to ensure the user has an understanding of what is expected in order to contribute:

1. Reads CONTRIBUTING.md, is aware of what to do for commits
2. Makes commits and wants to create Pull Request
3. Reads the HTML comments of the Pull Request template, is reminded of what is expected and feels supported with completing the Pull Request with dedicated sections.

Regardless of the rationale above, if the layout is preferred as a seperate Pull Request, let me know and I will do so.

Screenshot or video of changes (If applicable)

Maintainer (Preferred)

• @systemcrash for Pull Request template.
• @jow-, possibly @hnyman @stokito @systemcrash for CONTRIBUTING.md file.

---

Tested on

OpenWrt version: OpenWrt 25.12.2 (r32802-f505120278)
LuCI version: LuCI openwrt-25.12 branch (26.090.82136~bee369c)
Web browser: Safari Version 26.5 (21624.2.1.11.1)

---

Checklist

• This PR is not from my main or master branch 💩, but a separate branch. ✅
• Each commit has a valid ✒️ Signed-off-by: <my@email.address> row (via git commit --signoff).
• Each commit and PR title has a valid 📝 <package name>: title first line subject for packages.
• Incremented 🆙 any PKG_VERSION in the Makefile.
• (Optional) Includes what Issue it closes (e.g. openwrt/luci#issue-number).
• (Optional) Includes what it depends on (e.g. openwrt/packages#pr-number in sister repo).

[systemcrash]

Some of those field lengths aren't very helpful sometimes, and it's necessary to ignore them. The automated checks are a good rule of thumb, but they change, so we can skip mentions of length checks. It's probably enough to point a link to contributing.md in the template.

[owlsy]

Ah, good to know that those field lengths and length checks aren't enforced for a PR to be approved. It does seem to feel that way with how aggressive the "failure" is if it is over.

I'll remove those mentions about length checks and tidy other mentions of it up.

[owlsy]

Should be good to go now, @systemcrash.

[github-actions]

Warning

Some formality checks failed.

Consider (re)reading submissions guidelines.

Failed checks

Issues marked with an ❌ are failing checks.

Commit 5aedb22

• 🔶 Commit(ter) name must be either a real name 'firstname lastname' or a nickname/alias/handle
  Actual: Owl seems to be a nickname or an alias
  Expected: a real name 'firstname lastname'
• ❌ Commit(ter) email must not be a GitHub noreply email
  Expected: a real email address

Commit 2ba9546

• 🔶 Commit(ter) name must be either a real name 'firstname lastname' or a nickname/alias/handle
  Actual: Owl seems to be a nickname or an alias
  Expected: a real name 'firstname lastname'
• ❌ Commit(ter) email must not be a GitHub noreply email
  Expected: a real email address

For more details, see the full job log.

_{Something broken? Consider providing feedback.}