Add CONTRIBUTING and issue templates to the skeleton

[HafizMMoaz]

Ship community health files with the App project.

[goitsemangmajaga]

Hi, I’m interested in working on this issue as my first open-source contribution. May I take it? Please let me know if there are any specific requirements for the CONTRIBUTING guide and issue templates. Thank you.

[HafizMMoaz]

Hi, I’m interested in working on this issue as my first open-source contribution. May I take it? Please let me know if there are any specific requirements for the CONTRIBUTING guide and issue templates. Thank you.

Assigned. contact me at hafizmoazkhalid@gmail.com will share details

[HafizMMoaz]

Thanks for picking this up, and welcome. Here is the full spec so you know exactly what "done" looks like.

Scope

Add community health files to the webisters/app skeleton. Same set will later be rolled out to the other Webisters repos, so please keep the wording generic where possible.

Files to add

CONTRIBUTING.md
CODE_OF_CONDUCT.md
.github/PULL_REQUEST_TEMPLATE.md
.github/ISSUE_TEMPLATE/config.yml
.github/ISSUE_TEMPLATE/bug_report.yml
.github/ISSUE_TEMPLATE/feature_request.yml
.github/ISSUE_TEMPLATE/documentation.yml

SECURITY.md already exists, do not change it. .github/workflows/ci.yml already exists, do not touch it.

CONTRIBUTING.md must cover

1. Ways to contribute, and the rule that you comment on an issue and wait to be assigned before starting.
2. Security issues go to thewebisters@gmail.com via SECURITY.md, never a public issue.
3. Requirements: PHP >= 8.2, Composer 2.x, extensions intl, sodium, gd, json, fileinfo, curl, mysqli, simplexml, dom, libxml, MariaDB/MySQL for database tests.
4. Setup and commands, all run from the repo root:
   • composer install
   • vendor/bin/phpunit, plus single-file and --filter examples
   • vendor/bin/php-cs-fixer fix and --dry-run --diff
   • php webisters start for the dev server
5. Coding standard: style comes from webisters/coding-standard via .php-cs-fixer.dist.php. Every PHP file starts with <?php declare(strict_types=1); plus the standard licence header, which php-cs-fixer manages and must not be hand-edited. Namespaces: Framework\<Component> for libraries, App\ for project code, Tests\ for tests.
6. Branch/commit/PR workflow, imperative commit subjects under 72 chars, one logical change per PR, Closes #123.
7. Backwards compatibility note: libraries follow semver, public API breaks must be flagged in the PR description.
8. Contributions accepted under MIT.

Issue templates

Use GitHub's YAML issue forms (.yml), not the old markdown templates.

• bug_report.yml - labels bug, title prefix [Bug]: . Required: duplicate-search checkbox, what happened, expected behaviour, steps to reproduce, PHP version, package version, OS dropdown. Optional: error output (render: shell), extra context. Include a note at the top that security issues do not belong here.
• feature_request.yml - labels enhancement, title prefix [Feature]: . Required: problem/use case, proposed solution, BC-break dropdown (No/Yes/Not sure). Optional: alternatives, willing-to-PR checkbox.
• documentation.yml - labels documentation, title prefix [Docs]: . Required: location, what is wrong. Optional: suggested wording, willing-to-PR checkbox.
• config.yml - blank_issues_enabled: false plus contact links to the forum (https://github.com/webisters/forum), the docs (https://webisters.com), and SECURITY.md.

PR template

Summary, Closes #, type-of-change checkboxes, and a checklist covering: read CONTRIBUTING, phpunit passes, php-cs-fixer clean, tests added/updated, docs updated, BC preserved. Plus a short "backwards compatibility notes" section.

Acceptance criteria

• All seven files present at the paths above.
• The three issue forms render correctly in GitHub's new-issue picker (you can verify on your fork before opening the PR) and the blank option is disabled.
• Labels referenced in the templates (bug, enhancement, documentation) already exist in the repo, so no new labels needed.
• Markdown files wrap at a sensible width and use hyphens, not em dashes.
• No changes to any PHP file, composer.json, or the CI workflow in this PR.

One PR against main, please. Ping me here if anything is ambiguous.