Skip to content

Bugz

Jump to bottom
Rolf Bjarne Kvinge edited this page Feb 25, 2025 · 1 revision

Bugs!

Warning

This document is for the team working in this repository.

Fixing bugs is a continuous task for everyone that must be done in parallel with any other features being developed.

TL;DR

Review these queries daily and make sure they're empty:

Priorities

  1. Bugs that are assigned to you
  2. Any other unassigned bug

Triaging

Every week someone from the iOS/Mac team will be tasked to triage feedback and bug reports.

It should be between 10-20% of a week work to do triaging. The higher end happening when new stable releases are published or when a QA pass was done. If this takes more than 2 hours in your day then you're doing it wrong and let's discuss this asap :-)

GitHub issue mover

Issues can be transferred between repositories if both repositories are in the dotnet organization.

Otherwise, please use https://github.com/rolfbjarne/github-issue-mover to move GitHub issues between repositories automatically.

The tool is super simple, once built (make), run ./move-github-issue <issuelink> org/repo.

It then:

  • Copies the issue and the comments to the destination repo.
  • Adds references between the issues.
  • Closes the original issue.

Caveats:

  • Labels will not be copied.

NEW

Goal: no new issues older than one business day.

Non-goal: Fixing the issues - it's important but it's not triaging. Still whenever it's obvious (e.g. missing null check) then please fix it before continuing the triage.

Frequency: Every working day

  1. Use these new query links:

  2. Review and update the bug information. That will ease searching thru bugs later... in order of appearance

    • Assignees: Do not assign bugs, unless it's a self-assignment. You can ping @people inside your comment to make some people aware of an issue.

    GitHub

    • Labels: Use the appropriate labels, minimally the OS/product, based on the customer's description. See further below if the issue is not ours.

      All issues must have these labels:

      • Product: iOS, macOS, tvOS or Mac Catalyst.
      • Type: bug, enhancement, question, support or invalid.
      • ⚠️ Bonus: Add good first issue or help-wanted if you feel like it is!

    • Projects: Do not use;

    • Milestone: If a specific milestone is obvious (say xcode18.0), use tha, otherwise set to Future - that will remove it from the new bug query;

    Azure DevOps

    • If this is a bug in the SDK, move to GitHub issues. Otherwise see further below if the issue is not ours.
      • First create the new GitHub issue with the informations from Azure DevOps.
      • Feedback Ticket:
        • Then change the State of the Feedback Ticket to DC - Closed - Other Product.
        • That will automatically populate the comment section with a template.

          Thank you for your feedback. We have determined that this issue belongs to product name. Please go to link to continue tracking the issue. Thank you for helping us build a better Visual Studio.

        • Link to the GitHub issue you created.
        • Save and that will close the Feedback ticket as well as the DevCom post.
      • Bug:
        • Change the State of to Resolve.
        • Update Duplicate/Backlog ID with the url of the new GitHub issue.

  3. Is it a feature request or a suggestion?

    GitHub

    • Apply the enhancement label

    • Add the following comment

      We acknowledge this enhancement request, therefore marked it as CONFIRMED.

However, this does not necessarily mean we will take actions on it as we still need to discuss its feasibility internally and make sure it is not conflicting with other features.

  4. If the issue can be reproduced

    GitHub

    • Apply the bug label

  5. If the issue is incomplete...

    • Add a comment about what's missing and/or what would be needed to continue diagnosis.

      ⚠️ For Azure DevOps: change the state first before adding the comment. Remove the pre-populated text.

      Example text (modify according to the reported issue: for instance it does not make sense to ask for crash reports if the app doesn't crash, nor does it make sense to ask for full build logs when the reporter already provided build logs, but what we need is a test project).

      Thank you for your feedback!

For us to investigate this further, could you please provide:

* [Full build logs](https://github.com/dotnet/macios/wiki/Diagnosis#binary-build-logs).
* Any [crash reports](https://github.com/dotnet/macios/wiki/Diagnosis#crash-reports).
* [A test project (to reproduce)](https://github.com/dotnet/macios/blob/main/docs/bug-repro.md).
* All your [version information](https://github.com/dotnet/macios/wiki/Diagnosis#version-information).

We look forward to hearing from you!

    GitHub

    • Apply the need-info label

      If the issue only needs a test project, then you can apply the need-repro label, which will automatically add a detailed comment explaining that we need a complete repro project.

      Issues with either the need-info or the need-repro label will auto-close after a few days if the reporter doesn't answer.

    Azure DevOps Feedback Ticket

    • State: Set to DC - Need More Info

    Azure DevOps Bug

    • Sub Status: Set to Need Repro

  6. If the issue is not ours, the treatment depends on whose it is. The general rule is that we transfer/move the GitHub issue to the corresponding public repository, if possible.

    Azure DevOps

    • Area path: If the issue is against an other product, change the Area path to correct product. Ours is DevDiv\VS Client - Runtime SDKs\iOS and Mac.

    GitHub

    • .NET (BCL or runtime for instance): transfer the issue to the dotnet/runtime or dotnet/sdk repository.

    • Objective Sharpie: apply the external-objective-sharpie label.

    • Visual Studio: apply the move-to-vs-feedback label. This will automatically add a comment asking the reporter to file the issue using their IDE's reporting mechanism. These issues will also automatically close after a few days.

    • VSCode: move the issue to the microsoft/vscode-dotnettools repository.

  7. If it's not a bug, but someone who needs help instead

    Redirect the customer to the .NET forums or StackOverflow with a nice message. Here's a template:

    The broader developer community would be the best and quickest place for additional troubleshooting help on this issue. 
Posting a question on Stack Overflow [0] or the .NET on Q&A Forum [1] would be the best next step.

[0] https://stackoverflow.com/questions/tagged/xamarin
[1] https://docs.microsoft.com/en-us/answers/products/dotnet

(Investigation by this team for an issue like this would usually require that the reporter include additional background info to hint that a .NET project using the iOS/tvOS/macOS/MacCatalyst SDK is behaving differently compared to Xcode.)

  8. When you need to tell users to wait a bit more for the fix (slightly different than above)

    We have not yet had the opportunity to revisit this issue, but it is in our queue and we will get back to you as soon as possible.

In the meantime, the broader developer community might have some good ideas about how to work around the issue or possibly even what changes to make in a pull request to fix it.

You can post a question for the community on Stack Overflow [0] or the .NET on Q&A Forum [1].

[0] https://stackoverflow.com/questions/tagged/xamarin
[1] https://docs.microsoft.com/en-us/answers/products/dotnet

NEEDINFO

Any issues with the need-info label will automatically get the need-attention label when someone comments on the issue (and the need-info label will be removed).

These issues must then be reviewed, and the appropriate label applied (if the issue is still lacking information, then re-add the need-info label, etc.)

Frequency: once a day

Use these query links:

Antivirus Issues

In the rare event that an antivirus product is to blame follow the steps here: https://osgwiki.com/wiki/Microsoft_Virus_Initiative

E-mail your newly created issue to the Windows Defender team, as it is very easy to misfile these issues, and they can not be fixed easily.

Security Issues

Security issues should be filed as described here.

In the rare event that a security issue is reported publicly, please escalate it to the manager immediately.

Special circumstances

For special cases (confusing and/or emotively charged) then add the bug to a list for discussion in your 1:1. If needed it will be discussed on the next weekly call (Monday).

Follow up

You're added on the c.c. of the issues you triage. When need-info issures are updated, you need to check if what you asked was provided (even if you're not triaging that week).

Who to ask about what ?

See https://github.com/dotnet/macios/tree/master/CODEOWNERS.

This list is not exclusive owners and is based on who worked recently on the domain. Feel free to add yourself to any item (but ping your manager before removing yourself).

Contributing

Bindings

Tips & tricks

Clone this wiki locally