- Metadata: Correct and Complete
- Notify Relevant/Interested Contributors
- Closed/Closing Issues
- Ports Specific
- Base Specific
- Get things merged: Updates that are bugfix releases
- Get things merged: Updates that are security releases
- Get things merged: Updates that might be relevant to quarterly users
- Updates without QA
- Updates without changelog link
- Reporter is not MAINTAINER, doesn't set maintainer-approval (to ?)
- Reporter is MAINTAINER, doesn't set maintainer-approval (to +)
- Reporter is MAINTAINER, sets maintainer-feedback (to +)
- Reporter is a committer, doesn't self-assign, MAINTAINER is not committer
- Closing an issue with !FIXED resolution (in particular ''Unable to Reproduce'')
- Commit references the issue (``PR: XXXX``), but committer has not assigned themselves
- [tags] are used in issue Summary
- Issue is a 'general support' question
- Reporter is Committer but without a specific repository bit
Used for training new triagers and up-skilling existing project developers on a group basis, rather than individually (scale!).
Specific examples demonstrating each will be added in future iterations
Field names and values are in italics
When making changes that aren't self-explanatory, add a (terse, factual) comment in ^Triage: <comment> format
- Don't add comments unless necessary
- Make as many changes as possible before Submit'ing (Reduces email spam)
- Assume nothing, verify everything
- Teach/educate others while you triage (See #teach items below)
- If/when CC'ing people on issues, err on the side of doing it when its clear and obvious that they need or would like to be notified
Check issue History link, don't re-add users to CC if they've removed themselves previously
Assignee can only be @FreeBSD.org contributors, or triagers (when closing issues with !FIXED resolutions)
- New: New issue, not yet triaged.
- Open: Initial triage complete (correct category, classification, metadata)
- In Progress: Has a committer assignee, and work has started (a patch, a review, etc)
Closed: Initial issue as reported is no longer true (by way of rectification, obsolescence, duplication, invalidation, etc)
Ideally this is confirmed by the original Reporter prior to close.
FIXED: Issue resolved by way of a change that has been made, a commit, documentation update etc.
- Not appropriate for issues that are no longer reproducible where a change cannot or has not been identified.
- Overcome By Events: Issue as reported or proposed course of action is no longer useful or relevent due to external events.
- Works as Intended: Behaviour as described/reported is explicitly intentional and can not or will not be modified. See Also: Not A Bug
- Not Enough Information: Insufficient information to triage, assign, reproduce or resolve. Note: See Also: Unable to Reproduce.
- Unable to Reproduce: Given available (sufficient) information, issue as reported cannot be reproduced
- Not Accepted: An issue as reported, with a proposed change (eg: patch), has been assessed, reviewed and a decision made not to accept the change.
- Not A Bug: Issue or behaviour as reported is not is 'not actually an issue'. Use also for 'general support' requests
- DUPLICATE: An existing, previously reported and separate issue is exactly the same (conditions, behaviour, etc) as this one.
- Feedback Timeout: Additional information has been explicitly sought, and has not been received in a timely manner.
Metadata: Correct and Complete
These items apply to all issues, in all (any) state
Clean up & "normalize" issue Summary
- Example: Remove [tags]
- Improve summary where possible
- Shorter is better, unless it removes meaning or reduces clarity
- As complete a description of bug / issue as possible
- Remove superfluous verbiage
Check for correct & fix incorrect Product & Component
- Check comments for items that should be in fields. Eg:
FreeBSD version mentioned, but Version field not set
Architecture mentioned, Hardware field(s) not set (be careful, just because it was reported for amd64, doesn't mean it only applies to amd64)
Changelog URL mentioned, not set in URL field
External bug/commit/PR references mentioned, not added to See Also field
Check for "related issue ID's" in comments. Add to See Also, Depends On, or Blocks fields
Add relevant Keywords
Set Importance fields (Priority, Severity) based on scope.
Security issues get Normal priority, everything else the default (---)
Feature/Version Updates, Severity -> Affects only me
Bugs Unverified or Unknown Scope, Severity -> Affects only me
Bugs that are Conditional Scope, Severity -> Affects some people
Bugs that are Unconditional Scope, Severity -> Affects many people
Set Assignee if maintainer is @FreeBSD.org developer. Request/set maintainer-feedback ? <maintainer-email> flag, if not set
If commit revisions are mentioned, add committers of those revisions to CC, if relevant.
If you know certain people are interested in, or should be notified of issues "like this", add those people to CC. Eg:
- One or more primary and recent committers to the port or base component in question
- ports-secteam for security issues
- python@ for new, or updates to, python ports
Notify Relevant/Interested Contributors
- Add contributors (MAINTAINERS, Committers, Teams) to CC if they are/were involved or relevant to the issue
Bug 235890: Circular dependency in emacs/mailutils (See Comment 3 and 4)
- Issue has a real person Assignee when closed
Assign to user that resolved the issue
Resolved means resolved by way of a change (commit, etc), or resolved by way of Closing the issue (Status -> Closed)
Issues closed with Resolutions *not* FIXED, set Assignee to user that closed (or commented that it should be closed)
Use the most correct/accurate Resolution possible. Note: Some resolutions do overlap sometimes, use informed/rational judgment.
When closing Duplicate issues, always close the newer issue as a duplicate of the older issue, unless the newer issue has most/all of the information/patches/comments
If Reporter is MAINTAINER, set maintainer-approval attachment flag value to + (#teach)
- Version update:
- Check for upstream changelog URL, add to URL field
Bugfix or security release: Set merge-quarterly flag to ?
- Security release: Request VuXML entry (#teach)
If port Makefile gives an error, specify target in summary, like: Fails to <target>: $error-summary
Where version branch(es) is/are verified to be affected, add/set mfc-stableXX issue flag(s) to ?
Create a Bugzilla account if you don't have one (email is public, recommend: use a dedicated account)
Set your Real Name in user preferences
- Get added to the Triager Group in bugzilla (for editbugs permissions)
Get things merged: Updates that are bugfix releases
Set: merge-quarterly: ?
^Triage: Bugfix release, merge to quarterly branch
Get things merged: Updates that are security releases
Severity: Affects Many People
Set: merge-quarterly: ?
^Triage: Security release, merge to quarterly branch
Get things merged: Updates that might be relevant to quarterly users
^Triage: Are quarterly users affected? If so, please set merge-quarterly flag to: ?
Updates without QA
^Triage: Please confirm this change passes QA (portlint, poudriere at least) For details and instructions, see: https://docs.freebsd.org/en/books/porters-handbook/#testing
Updates without changelog link
^Triage: If there is a changelog or release notes URL available for this version, please add it to the URL field
Reporter is not MAINTAINER, doesn't set maintainer-approval (to ?)
^Triage: Please set the maintainer-approval attachment flag (to ?) and set the requestee field to the e-mail address of the maintainer to ask for maintainer approval Attachment -> Details -> maintainer-approval [?]
Reporter is MAINTAINER, doesn't set maintainer-approval (to +)
^Triage: Please set the maintainer-approval attachment flag (to +) on patches for ports you maintain to signify approval Attachment -> Details -> maintainer-approval [+]
Reporter is MAINTAINER, sets maintainer-feedback (to +)
Set: maintainer-feedback: X
^Triage: Maintainer-feedback flag (+) not required unless requested (?) first
Reporter is a committer, doesn't self-assign, MAINTAINER is not committer
^Triage: Reporter is committer, assign accordingly.
Closing an issue with !FIXED resolution (in particular ''Unable to Reproduce'')
Resolution: <as appropriate>
^Triage: If this is still reproducible, please re-open this issue with additional information and steps to reproduce if not already provided
Commit references the issue (``PR: XXXX``), but committer has not assigned themselves
Status: In Progress
^Triage: Assign to committer resolving
Note: Keep/Add original Assignee on CC list if its a group or mailing list (like net@, python@, etc)
[tags] are used in issue Summary
- Remove tag (except [NEW PORT]) from summary
^Triage: [tags] in issue Titles are deprecated
Issue is a 'general support' question
Resolution: Not A Bug
^Triage: Thank you for your report. Our issue tracker is used for issues identified to be bugs and enhancements. For general support, questions and issues, the following channels are available to the community: https://www.freebsd.org/support.html If your issue is isolated to be a bug and is reproducible on an up-to-date and supported FreeBSD version, please re-open this issue with additional information and steps to reproduce.
Reporter is Committer but without a specific repository bit
^Triage: Reporter is committer, assign accordingly Any committer may commit to any repository with an accepted review from any committer with existing access to that repository. Committers may obtain review via a Differential in Phabricator, adding the "Contributor Reviewers ($Repository)" group as a Reviewer, reaching out to other committers; directly or via mailing lists, or setting the attachment flag to: maintainer-approval ? <person-youd-like-to-review>