Chromium Issue Tracker Guidelines for Google employees

The new Chromium issue tracker will be used by lots of Google teams, and is very flexible in terms of workflows. This documents guidance for Chrome teams within Google that is in alignment with our open source project norms. It’s important to Chrome that we preserve our culture of being open by default.

Guidelines

• Bugs should be open by default, unless there is specific information that should be restricted to Googlers. Chromium is an open-source project.

• Even security bugs should not normally be restricted to Googlers. Chromium’s reputation depends upon us being open across all our open-source contributors. Security bugs start as restricted to the Chromium security team, instead of being restricted to Googlers. (Unless embargoed, security bugs are made public after their fix is rolled out.)

• Use the Chromium issue tracker not the internal Google view, where possible. If you see this banner, click the button:
  
  Using Google’s internal view of the same bugs will result in new bugs or attachments being hidden from the open source community by default.
  
  

• If you use the Google bug tracker (b.corp.google.com) please take extra steps to make things open: For issues: change this setting
  
  For comments adding attachments: change this setting
  

• Using Google-internal tools is fine, but ensure sufficient information is available externally. Some Google-internal tools will store metadata on bug entries that may not be available outside Google. Consider if that’s appropriate. Just as seriously, such tools may direct you towards Google’s internal view of the bug entries, which may cause you to run into the previous problems. Be careful!

• When referencing issues in the Chromium tracker please use the external/Chromium tracker link: use crbug.com or issues.chromium.org rather than b/ or g-issues.chromium.org. Internal / g-issues.chromium.org links may redirect to a Google SSO login page and create an inefficient and sub-optimal workflow for non-Googlers. Similarly, other corp.google.com links are not OK, e.g. crbug/.

  When referencing issues in corp Buganizer (that are only accessible to Googlers) in commit messages or code, it is preferred to use the b/XXX format. However, make every effort to use public issues to track work in Chromium.

• Usage of severity and Priority should align with Chromium severity and priority guidelines, not Google guidelines. For example, severity and priority for security bugs should align with Chromium Security Severity Guidelines, with S0 = Critical Severity, S1 = High Severity, S2 = Medium Severity, and S3 = Low Severity. S4 should be considered the lack of a security severity (equivalent to the absence of a severity label on Monorail.)

• There should be only one, canonical version of a Chromium issue rather than an external version and an internal version. Any duplicate issues should be merged as Duplicate to the older or other canonical version of the issue.

  • Duplicate internal versions should not be created as a means for restricting access, please use the appropriate visibility / Issue Access levels.

• Avoid using go/links to link to templates - they’re not accessible externally.

• When flipping a bug from Vulnerability to Bug (i.e. from a security bug to a functional bug), also flip visibility to Default Access. Don’t just remove the security@chromium.org collaborator, because then it will become an orphan bug which needs to be rescued.

• Any additional issues, please reach out to chromium-issue-tracker-admins@google.com