From be43d2b0fd3a07d774c367d6e98ab0e98ebb7c11 Mon Sep 17 00:00:00 2001 From: Vinamrata Singal Date: Fri, 3 Nov 2017 17:05:03 -0700 Subject: [PATCH] docs(new-audits.md): Principles and guidance for new audits (#3617) --- docs/new-audits.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 docs/new-audits.md diff --git a/docs/new-audits.md b/docs/new-audits.md new file mode 100644 index 000000000000..88b1c9c7314a --- /dev/null +++ b/docs/new-audits.md @@ -0,0 +1,30 @@ +So, you want to create a new audit? Great! We're excited that you want to add to the Lighthouse project :) The goal of this +document is to help you understand what constitutes as a "good" audit for Lighthouse, and steps you can follow if you want +to propose a new audit. + +## New audit principles +Lighthouse audits that surface in the report should be: +- Applicable to a significant portion of web developers (based on scale and severity of impact) +- Contribute significantly towards making the mobile web experience better for end users. +- Not have a significant impact on our runtime performance or bundle size. +- Something that is new, and not something that is already measured by existing audits. +- Important for our strategic goals as a product (i.e. could other Lightrider customers benefit from this? What about other GBO teams?) +- Measurable (especially for performance audits) or have clear pass/fail states. +- Not use 3rd party APIs for completing the audit check. + +*Note: it's possible to submit a new audit proposal for something that you as a contributor feel very passionate about, but the Lighthouse team feels that it wouldn't add value to a significant portion of the Lighthouse users. In this case, we'd be open to having your audit be a part of the report when run with the full config on the Command Line.* + +## Process for creating a new audit +1. Briefly scan the criteria we’ve laid out above. If you think the principles match with your proposed new audit, then proceed! +2. Next step is to create an issue on Github with answers to the following questions: + - Description of audit and audit category (please include pass/fail states, and how it might be measured) + - Explanation of how it’s different from other audits + - What % of developers/pages will this impact (estimates OK, data points preferred) + - How is the new audit making a better web for end users? (data points preferred) + - What is the resourcing situation (who will create the audits, maintain the audits, and write/maintain the documentation) + - Do you envision this audit in the Lighthouse report or the full config in the CLI? If in the report, which section? + - How much support is needed from the Lighthouse team? + - Any other links or documentation that we should check out? +3. Once the proposal is submitted, then Lighthouse team will take a look and followup. We will discuss possible implementation approaches, and associated runtime overhead. +With this new information we can better understand the impl cost and effort required and prioritize the audit into our sprint/roadmap. +4. Depending on the prioritization, we'll then work with you to figure out the necessary engineering/UX/product details.