Search the existing issues before logging a new one.

Some search tips:

• Don't restrict your search to only open issues. An issue with a title similar to yours may have been closed as a duplicate of one with a less-findable title.
• Search for the title of the issue you're about to log. This sounds obvious but 80% of the time this is sufficient to find a duplicate when one exists.
• Read more than the first page of results. Many bugs here use the same words so relevancy sorting is not particularly strong.
• If you have a crash, search for the first few topmost function names shown in the call stack.

When logging a bug, please be sure to include the following:

• What version of the package/plugin are you using
• If at all possible, an isolated way to reproduce the behavior
• The behavior you expect to see, and the actual behavior

We also accept suggestions in the issue tracker. Be sure to search first.

In general, things we find useful when reviewing suggestions are:

• A description of the problem you're trying to solve
• An overview of the suggested solution
• Examples of how the suggestion would work in various places
  • Code examples showing e.g. "this would be an error, this wouldn't"
  • Code examples showing usage (if possible)
• If relevant, precedent in other frameworks or libraries can be useful for establishing context and expected behavior

Faust.js doesn't keep a roadmap. Work comes from what people run into: security fixes and compatibility with new WordPress, WPGraphQL, Next.js and Node.js releases first, then confirmed bugs, then features people ask for in issues. If something is missing or broken for you, open an issue.

0. A bug or feature you want to work on! If you have found a new bug or want to propose a feature, please create an issue before starting a pull request.
1. A GitHub account.
2. A working copy of the code. See DEVELOPMENT.md.
3. A pull request title that follows Conventional Commits, such as fix(core): handle expired tokens. We use it to version packages and write changelogs. See DEVELOPMENT.md.

Your pull request should:

• Include a description of what your change intends to do

• Reference any open issues that the PR addresses

• Be based on reasonably recent commit in the canary branch

• Include adequate tests

  • At least one test should fail in the absence of your non-test code changes. If your PR does not match this criteria, please specify why
  • Tests should include reasonable permutations of the target fix/change
  • Include baseline changes with your change

• Have a title that follows Conventional Commits. We squash and merge, so the title becomes the commit message on canary and release-please uses it to build the changelog:

  <type>(<scope>): <short summary>
    │       │             │
    │       │             └─> Summary in present tense. Not capitalized. No period at the end.
    │       │
    │       └─> Scope (optional): eg. core, cli, blocks, faustwp, deps
    │
    └─> Type: build, chore, ci, docs, feat, fix, perf, refactor, revert, style, or test.
  

• To avoid line ending issues, set autocrlf = input and whitespace = cr-at-eol in your git configuration