Welcome to king Discussions!

[debuggerone]

Community

Thank you for your interest in King.

King is an ambitious systems-focused PHP extension. That means discussion quality matters: correctness, reproducibility, and technical clarity are more useful here than volume. This document explains how to participate constructively.

What this project values

We want contributions and discussion that improve one or more of the following:

• correctness
• safety
• reproducibility
• observability
• performance
• API clarity
• operational simplicity
• release quality

Strong opinions are welcome. Hand-waving is not.

Before opening an issue

Please do the following first:

1. Read the README and any design or status documents in the repository.
2. Check whether the issue is already reported.
3. Reduce the problem to the smallest reproducible case you can.
4. Include versions, platform details, and exact steps.

Useful reports save time. Vague reports create noise.

Good bug reports

A good bug report usually includes:

• King version or commit SHA
• PHP version
• OS and architecture
• build/install method
• minimal reproduction
• expected behavior
• actual behavior
• logs, backtraces, sanitizer output, or test failures if available

If the problem is performance-related, include:

• workload description
• baseline
• measurement method
• hardware/runtime context

Feature requests

Feature requests should describe:

• the concrete problem
• why existing APIs are insufficient
• the expected user-facing behavior
• tradeoffs or constraints
• whether this changes public API, wire behavior, or runtime guarantees

Requests framed as real use-cases are much easier to evaluate than generic wishlists.

Pull requests

Pull requests are welcome when they are focused and technically justified.

Please aim for:

• one logical change per PR
• clear commit history
• tests for new behavior
• updates to docs where behavior or APIs change
• no unrelated refactors bundled into the same PR

A PR should explain:

• what changed
• why it changed
• how it was tested
• any compatibility or operational impact

Large changes should start with discussion first.

Code quality expectations

This project is systems software. Changes should respect that.

Contributors should prioritize:

• explicit behavior
• defensive error handling
• predictable memory/resource management
• minimal public surface area
• measurable performance claims
• test coverage for edge cases and regressions

Do not merge complexity without necessity.

Testing

If you submit a code change, run the relevant test suites and include the results in the PR description.

Where appropriate, include:

• PHPT coverage
• unit/integration results
• sanitizer output
• fuzz or stress evidence
• platform-specific notes

If you cannot test something locally, say so plainly.

Security

Do not open public issues for security vulnerabilities.

Instead, report vulnerabilities privately using the security process documented in this repository. If no dedicated process is yet published, contact the maintainer privately and include:

• affected component
• impact
• reproduction details
• proof-of-concept if necessary
• suggested mitigations, if known

Please allow time for validation and remediation before public disclosure.

Discussions and conduct

Be direct, technical, and respectful.

Expected behavior:

• criticize ideas, not people
• back claims with evidence
• state uncertainty clearly
• prefer minimal reproductions over rhetoric
• keep discussions on-topic

Unacceptable behavior includes:

• personal attacks
• harassment
• bad-faith argumentation
• spam
• repeated low-signal commentary
• ideological derailment unrelated to the code or design

Maintainers may moderate, close, or remove discussions that reduce signal.

Scope discipline

King has a broad surface area. That makes scope discipline essential.

Not every technically possible addition belongs in core.

When proposing changes, prefer:

• sharper boundaries
• fewer primitives with stronger guarantees
• composable APIs
• clear operational semantics

A finished system is more valuable than an endless one.

Documentation contributions

Documentation improvements are welcome, especially when they improve:

• installation clarity
• API explanations
• examples
• operational guidance
• failure-mode documentation
• migration notes
• testability and reproducibility

Accuracy matters more than polish.

Maintainer decisions

The maintainer may reject changes that are:

• out of scope
• insufficiently tested
• too large to review safely
• inconsistent with the project’s architecture
• costly to maintain relative to their value

That is normal project stewardship, not hostility.

Recognition

Contributors who improve the project through code, tests, design feedback, docs, bug reports, reproducible benchmarks, and security reporting are appreciated.

High-signal contributions matter.

Final note

This project is trying to build something difficult.

That only works if the community optimizes for truth, precision, and finished work.