Issue Process

Principles

• Single source of truth: GitHub is the primary source of information for bugs, issues, and work in progress (enhancements).
• Open: Default to open and keep as much conversation in Github as possible.
• Protect private information: Do not include private information anywhere in bug reports, pull requests, comments, commit messages, or the actual code. This includes private URLs that won’t work for everyone.
• Secure: Any vulnerabilities or security issues are reported on a private GitHub mirror repo (dedicated for this purpose only). (See below.)

Walkthrough – typical issue

1. Discover the problem, e.g. as part of testing, or raised by a customer in support.
2. Understand how the problem impacts the product – what flows are broken? How are users affected?
3. Reproduce the issue on a minimal site (WooCommerce + Pinterest + default theme).
4. Log an issue in GitHub using the template and providing as much detail as possible.

Walkthrough – security issue

A private GitHub repository is maintained specifically for handling security issues. This allows these (rare) issues to be addressed using similar processes, while minimising leaking details about the vulnerability until it’s patched.

1. Discovery – issue is raised via community, dev team, HackerOne, or a regular (public) issue.
2. If issue is logged on an open GitHub repo, delete the issue immediately.
3. Open an issue on the private GitHub repo.
4. Sync the private repo with the public repo (i.e. update trunk).
5. Work to address the issue, communicating regularly with all relevant parties (e.g. keep HackerOne updated with comments, etc).
6. All the security fixes should be added to the public repo only right before the fix release.
7. Avoid detailed commit messages when adding commits to public repository.