This document describes the current guidelines for assigning priorities to Web Kit bugs in Bugzilla. The relevant bugs are all of those whose product is “WebKit”.
Standard priority rules
Each bug is assigned the first appropriate priority listed below from top to bottom.
- Any reproducible crash or hang.
- Any regression from a previous publicly released version of WebKit.
- Serious problem on important site due to site change or newly-important site.
- Serious security issue.
- Site that does not function in some non-trivial way.
- Serious performance complaints.
- Site that has really bad cosmetic problems (e.g., content overlapping such that it’s very hard to read).
- Unreproducible crash or hang that has been reported many times.
- Site that works but has some cosmetic problems.
- Minor performance complaints, such as trivial memory leaks.
- Architecture issues that could help with correctness or performance but are not a clear win in advance.
- Unreproducible crash or hang.
- All enhancement requests and feature requests not covered the criteria for p1, p2, or p3.
- P5 is not used for WebKit bugs. WebKit shares its Bugzilla with other projects who might use it, that’s why it’s still there.
Common adjustments to priority
- If there is a workaround, the priority may be moved down.
- If a bug gets a lot of duplicates, the priority may be moved up.
- If a bug is getting a lot of public attention, the priority may be moved up.
- If a bug is on a very important site, the priority may be moved up.