Bug Wrangler Duties - openssl/project GitHub Wiki

Duty Roster

  • Rotation Period: Every two weeks.
  • Rotation Policy: Engineers are rotated regularly to ensure fresh perspectives and prevent burnout.
  • The respective Bug Wrangler issues on the Development Board represents a person on duty.

Responsibilities

The responsibilities of the Bug/PR Wrangler fall into two halves:

  • Handling new/current issues/PRs
  • Reviewing old issues/PRs

Handling new/current issues/PRs

The responsibilities for new/current issues/PRs listed here can be performed by any committer. However it is the Wrangler's responsibility to be the fallback person, i.e. if no one else has done this for an issue/PR within a reasonable time frame (e.g. one business day), then the Wrangler should do it.

Issues

Every issue that is raised should be triaged.

  • Obvious spam or nonsensical issues should simply be closed. Optionally, you may include some warning or guidance to the poster in the closure message if appropriate. In the case of obviously offensive or advertising content, or in the case of repeat offenders, consider blocking the user.
  • Questions about OpenSSL usage should be converted into a discussion in the "Q & A" Category
  • Other issues should be categorised into one of:
    • Bug. The issue is reporting a bug in OpenSSL code
    • Cleanup. The issue deals with cleanup of comments/docs (i.e. not requiring code to be altered significantly)
    • Design. The issue deals with a design document
    • Documentation. The issue reports problems with documentation
    • Feature. The issue requests a new feature
    • Performance. The issue is related to performance
    • Refactor. The issues proposes or discusses code refactoring

Each issue when opened will typically have an "issue: *" label automatically applied to it when the issue was created (depending on which issue template the original poster used when creating the issue). In some cases there may be no label at all if the user chose to open a "blank" issue. This label can be used as a "hint" as to the content contained within the issue according to the original poster. However these are often wrong, so treat them with caution. You should remove the "issue: *" label and replace it with a "triaged: *" label as appropriate for the category that you decided above.

Consider the severity of the issue. If the issue describes a bug that is newly introduced compared to a previous version then apply the "severity: regression" label. If the issue describes something important or significant justifying priority attention from the contractor team then apply the "severity: important" label.

For well defined issues with a clear resolution that are unlikely to be considered a priority by the contractor team apply the "help wanted" label. If the resolution is likely to be very simple and easily understood by newcomers to the project then additionally apply the "good first issue" label.

Where the report is clearly related to a specific branch then apply the relevant "branch: *" labels.

Where appropriate, consider who might be best placed to help the poster or progress the issue in some way. Tag those people in a message in the issue. Where the issue appears to be specific to a given platform then tag the platform maintainers (if any) as shown in the platform policy tables

Tracking issues

Issues should be tracked on the Bug Wrangler board, described below. The Bug Wrangler should categorize incoming issues to one of the available categories via the boards kanban view. The categories and their descriptions are:

  • Investigating

    Issues for which a disposition cannot be immediately determined should go here. Placing an issue here typically entails adding a comment to the issue asking a clarifying question to enable determination of where the issue should be further categorized to. As part of the Bug Wrangler duties, this category should be regularly revisited to see if a reporter has updated the issue with the requested information to further determine its disposition

  • Consider For Current Release

    Issues which appear to be sufficiently important that we should consider making room for them during the current development cycle should get categorized here. During our Refinement meeting, as time/capacity allows, issues will be drawn from this list and added to the development and project planning boards for refinement and scheduling.

  • Consider For Future Minor Release

    Issues which appear to be needing attention from the core openssl team, but are not especially time sensitive may be placed here, and will be drawn from during the construction of future project plans.

  • Consider for Future Major Release

    Issues may be placed here if they both require work from the core openssl staff, and, for whatever reason are considered not feasible for a minor release. These include issues for which the needed change would be ABI breaking, or are otherwise inappropriate for minor release inclusion. Issues from this list will be considered during the construction of major release project planning.

  • Community

    Issues may be placed in this category if the issue is valid, but it is deemed that the core openssl staff is not likely to commit time or resources to the issue. Issues categorized here should also have the "help wanted" label applied to them

  • Inactive

    Issues may be placed here if the reporter has not responded to a request for information, or the issue has for whatever reason, appeared to go stale. Current rule of thumb is an issue without an update for 6 months can be considered stale. Issues placed in this category should also have the "inactive" label applied, and a comment added by the Wrangler indicating that the issue is considered stale, and will be closed at the completion of the current development cycle, baring an update from the reporter between the time of the comment and the end of the development cycle. The inactive list should be periodically reviewed for such incoming comments and, if such a comment is received, the issue should be re-triaged.

Resolving Issues

Issues that will be fixed by a PR should be automatically closed when the PR fixing the issue is merged (via the "Fixes" keyword in the commit). Sometimes this doesn't work correctly (for example if the PR omits the "Fixes" keyword, or if the PR is only applied to release specific branches and not master). In such cases the issue should be closed manually, noting the PR that fixed the issue.

In other cases a natural resolution to the issue has been found. In these cases apply one of the relevant "resolved" labels:

  • Not a bug. In cases where an issue is reporting a bug (i.e. it has the "triaged: bug" label), but the reported issue is in fact not actually a bug, then apply the "resolved: not a bug" label.
  • Won't fix. In some cases we will decide not to fix an issue. For example because it is only present in branches that are no longer supported. In these cases apply the "resolved: wont fix" label.

Sometimes an issue is identified as being a duplicate of some other issue. In these cases one of the issues will be closed in favour of the other one. Typically the older issue is left open and the newer issue is closed. However this may not always be appropriate (for example if there was significant investigation and notes made in the newer issue compared to an older issue). Select which issue to close and mark it with the "Duplicate of #XXXX" message (replacing XXXX with the number of the other issue).

Typically you should not use the "resolved: fixed" or "resolved: duplicate" labels (you should just close the issues as described above).

The "resolved: answered" label may also be used in some cases. Questions should typically have been converted to discussions and are therefore no longer being tracked as an issue (and so don't need this label). Historical issues that were triaged as questions may still exist. Or sometimes an issue is reclassified as a question after first having been triaged as something else. If the question has been answered then apply the "resolved: answered" label.

PRs

Newly opened PRs should be assessed and appropriate labels applied to them.

Unless a PR has been marked as draft or "WIP" then it should have the labels "approval: otc review pending" and "approval: review pending" applied to it. Approvers are expected to remove these labels as approvals are achieved.

Consider the branches that the PR is relevant to and apply the appropriate "branch: *" labels. In some cases it is not clear which branches the author intended the PR to be for. In this case ask the author for clarification.

All PRs should typically have tests associated with them except where indicated by the testing policy. That policy defines three "tests: *" labels that may be applied to a PR:

  • tests: present
  • tests: exempted
  • tests: deferred

Consider and apply the appropriate label as per the policy. If no tests are present (and the PR is not exempted, and tests are not being deferred as per the policy) then apply the "hold: tests needed" label.

Apply one of the "triaged: *" labels as described for issues above depending on whether the PR is fixing a bug, implementing a feature, providing documentation, etc.

Consider the severity of the issue the PR is addressing and, if appropriate, apply one of the "severity: regression" or "severity: important" labels as described for issues above.

If the author of the PR does not have a CLA on file and is seeking for their submission to be treated as trivial apply the "cla: trivial" label. If the submission is clearly not trivial then provide guidance to the author on how to submit a CLA.

As for issues, consider who might be best placed to review the PR. If someone specific would be good then assign that person as a reviewer. Where the PR appears to be specific to a given platform then assign the platform maintainers (if any) as shown in the platform policy tables

Reviewing old issues/PRs

Old issues and PRs should be periodically reviewed to see if they can be closed.

Issues that have been marked with a "resolved" label and have seen no activity for four weeks can simply be closed - typically with a message indicating that the issue is being closed because it has been resolved.

Consider whether old issues/PR are still relevant. It may be appropriate to ask the original poster/author whether the issue/PR is still relevant to them.

Clearly identified bugs/documentation problems should not be closed unless they are fixed or otherwise marked as resolved.

Sometimes features are later implemented, but an original issue requesting the feature is never closed. Consider old feature requests and close them if the feature is now available in recent versions of OpenSSL (or in master).

Bug Wrangler board

The Bug Wrangler Project Board is there to help Bug Wranglers to perform their duties. Every new issue and PR in openssl/openssl repository is being added to this project board automatically in the Todo state. To see which issues and PR need a review by the Bug Wrangler, just look at the Todo state at the Bug Wrangler board.

Removal of PRs and issues from the Bug Wrangler board:

  • Issues should be removed from the Bug Wrangler board when they are present on / processed by another board (like the Development Board or any Project Board x.y.z Planning)
  • PR's which have been triaged according to the documentation in "PRs" above no longer need to be wrangled, and should be removed from the board. There is a "PR's for review/merge column" on the bug wrangler board where prs can be assigned for batch removal if that is convenient for the wrangler