How to contribute to Lynx

Ensure the bug has not already been reported by searching GitHub Issues. If there's already an open issue, feel free to add any extra information you might have about the issue.
If you're unable to find an open issue matching the problem, open a new one. Be sure to include a title and clear description, as much relevant information as possible, and a code sample, screenshot, or a test case demonstrating the expected behavior that is not occurring.
Where possible, use the bug report templates to create the issue. Avoid including descriptions like "bug", "feature", etc in the issue title as these will be handled by labels.

Great! Open a new GitHub pull request with the patch.
All development occurs on the dev branch and new PRs should be forked from here.
The command npm run example can be used to test local changes using the example site.
Ensure the PR description clearly describes the problem and solution. Include the relevant issue number, if applicable.
Before submitting, check the coding conventions section below to learn more about coding and commit message expectations.

Enhancements are welcome but before implementing any features, be sure to suggest your change by opening a new discussion about your idea. Enhancements are discussed to ensure they fit with the project's design intent and overall roadmap.
Before opening a discussion, check to see if a similar idea is already being discussed.
All ideas and suggestions are welcome and will be judged on their merits.
If the community supports your idea, go ahead and submit a PR with the implemented feature.

If you have a general question, these should be asked using GitHub Discussions. Feel free to open a new discussion to ask your question using the "Q&A" category.
Be sure to check if your question has already been answered by searching existing Q&A discussions.

Indent using 2 spaces (soft tabs).
Put spaces between list items (ie. [1, 2, 3], not [1,2,3]), around operators (ie. 1 + 1, not 1+1) and inside go templating tags (ie. {{< alert >}}, not {{<alert>}}).
Avoid code reuse in templates by extracting components into partials.
Layout code in a logical manner that prioritises readibility.
Add comments when the intent of the code isn't immediately apparent or to break up large blocks of logic.
Use relative paths to assets without including the preceeding slash but, when referring to a folder, including a trailing slash (ie. static/img/, not /static/img/ or /static/img).
Any static text must be referenced using the i18n methods and included in the localisation assets.
Commit often, preferring incremental changes rather than bundling everything into a single, large commit.

The project includes a Prettier config that helps to format code in line with these guidelines.

Use Gitmoji in commit messages to provide context.
Clearly describe the change with a short summary in the first 72 characters.
Place more detailed explanations in paragraphs below the summary, separated by a blank line.
Use imperative language (ie. "Fix bug", not "Fixed bug" or "Fixes bug").
Do not end the summary line with a period.
Reference any issues fixed using their GitHub issue number.

Provide feedback