diff --git a/README.md b/README.md index e2befa4b8c21..6a07d025e7b3 100644 --- a/README.md +++ b/README.md @@ -13,7 +13,7 @@ ## Overview -.NET Multi-platform App UI (.NET MAUI) is the evolution of Xamarin.Forms that expands capabilities beyond mobile Android and iOS into desktop apps for Windows and macOS. With .NET MAUI, you can build apps that perform great for any device that runs Windows, macOS, Android, & iOS from a single codebase. Coupled with Visual Studio productivity tools and emulators, .NET and Visual Studio significantly speed up the development process for building apps that target the widest possible set of devices. Use a single development stack that supports the best of breed solutions for all modern workloads with a unified SDK, base class libraries, and toolchain. [Read More](https://docs.microsoft.com/dotnet/maui/what-is-maui) +.NET Multi-platform App UI (.NET MAUI) is the evolution of Xamarin.Forms that expand capabilities beyond mobile Android and iOS into desktop apps for Windows and macOS. With .NET MAUI, you can build apps that perform great on any device that runs Windows, macOS, Android, & iOS from a single codebase. Coupled with Visual Studio productivity tools and emulators, .NET and Visual Studio significantly speed up the development process for building apps that target the widest possible set of devices. Use a single development stack that supports the best-of-breed solutions for all modern workloads with a unified SDK, base class libraries, and a toolchain. [Read More](https://docs.microsoft.com/dotnet/maui/what-is-maui) ![.NET MAUI Weather App on all platforms](Assets/maui-weather-hero-sm.png) @@ -26,7 +26,7 @@ Follow the [.NET MAUI Blog](https://devblogs.microsoft.com/dotnet/category/net-m ## FAQs -Do you have questions? Do not worry, we have prepared a complete [FAQ](https://github.com/dotnet/maui/wiki/FAQs) answering the most common questions. +Do you have questions? Do not worry; we have prepared a complete [FAQ](https://github.com/dotnet/maui/wiki/FAQs) answering the most common questions. ## How to Engage, Contribute, and Give Feedback diff --git a/SECURITY.md b/SECURITY.md index db7e81c4b916..762ff98a9464 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -14,7 +14,7 @@ You should receive a response within 24 hours. If for some reason you do not, pl Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue: - * Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.) + * Type of issue (e.g., buffer overflow, SQL injection, cross-site scripting, etc.) * Full paths of source file(s) related to the manifestation of the issue * The location of the affected source code (tag/branch/commit or direct URL) * Any special configuration required to reproduce the issue diff --git a/docs/CodeDocumentationGuidelines.md b/docs/CodeDocumentationGuidelines.md index bebff90cf51a..b849b8452023 100644 --- a/docs/CodeDocumentationGuidelines.md +++ b/docs/CodeDocumentationGuidelines.md @@ -1,36 +1,36 @@ # Code Documentation Guidelines -In this document you will find the guidelines for adding XML comments to our codebase. By adding consistent and well-formatted comments to our code we benefit on all fronts: the online API docs are a useful reference for people looking up our APIs, the IntelliSense inside of Visual Studio will help developers understand our product better, and contributors and maintainers of this repository will have all the documentation at hand. +In this document you will find the guidelines for adding XML comments to our codebase. By adding consistent and well-formatted comments to our code, we benefit on all fronts: the online API docs are a useful reference for people looking up our APIs, the IntelliSense inside of Visual Studio will help developers understand our product better, and contributors and maintainers of this repository will have all the documentation at hand. ## Guidelines -For what kind of comments to our code we mainly follow the [recommended XML tags documentation](https://learn.microsoft.com/dotnet/csharp/language-reference/xmldoc/recommended-tags) by Microsoft. This is also what is best supported by Visual Studio. As a rule of thumb: complete your code first and just start typing a triple slash (`///`) above your code. That will suggest all the attributes that we want to see. Which attributes will show up is inferred from your code. +For comments on our code, we primarily follow the [recommended XML tags documentation](https://learn.microsoft.com/dotnet/csharp/language-reference/xmldoc/recommended-tags) by Microsoft. These tags are also best supported by Visual Studio. As a rule of thumb, complete your code first and just start typing a triple slash (`///`) above your code. This will suggest all the attributes we expect to see. The attributes that appear are inferred from your code. -If you're unsure about how to document a certain element, have a look the [.NET API docs wiki](https://github.com/dotnet/dotnet-api-docs/wiki) which has a very extensive description on what kind of comment to add on which element in the code. We would highly recommend going through that and applying the same style of comments everywhere. +If you're unsure about how to document a certain element, have a look at the [.NET API docs wiki](https://github.com/dotnet/dotnet-api-docs/wiki) which has a very extensive description of what kind of comment to add on which element in the code. We would highly recommend going through that and applying the same style of comments everywhere. These are the tags that we would like to see when applicable: ``, ``, ``, ``, ``, ``, ``, ``. * All public members should have at the very least a `` * Add "This is a bindable property." to the end of the summary of the regular C# properties that are bindable properties. * Keep the descriptions short and concise - * 1-2 lines typically, no screenshots or long code-blocks (those belong in the conceptual docs) + * 1-2 lines typically, no screenshots or long code blocks (those belong in the conceptual docs) * Make sure the spelling is correct -* Add the descriptions at the highest base class/interface level. On an implementing type add `` on each member - * If the implemented member differs too much you can choose to override the comments; typically this shouldn't be necessary +* Add the descriptions at the highest base class/interface level. On an implementing type, add `` on each member + * If the implemented member differs too much, you can choose to override the comments; typically this shouldn't be necessary * When adding `` on a class where you want to inherit the comments from an interface, you will have to be explicit about which interface to inherit from. Even if the class only implements one interface. For example: `` will inherit the comments from the `IEntry` interface. - * Do **not** add `` to overridden members, this will potentially cause issues in the online API docs system and doesn't add any value. The documentation is inherited implicitly. -* Where applicable make references to other types and parameters with the appropriate tags (`` and `` respectively). This will create links in IntelliSense and online API docs -* Reference all C# keywords with a `` tag. For example for `true`: `` -* If you do want to add a minimal amount of code in your comment, use the `` tags which formats it as code + * Do **not** add `` to overridden members; this will potentially cause issues in the online API docs system and doesn't add any value. The documentation is inherited implicitly. +* Where applicable, make references to other types and parameters with the appropriate tags (`` and `` respectively). This will create links in IntelliSense and online API docs +* Reference all C# keywords with a `` tag. For example, for `true`: `` +* If you do want to add a minimal amount of code in your comment, use the `` tags, which format it as code * Think of things you'd like to know as a developer/future-you maintainer: * default values that are not obvious * in which scale a value should be (seconds or milliseconds, 0.0 is nothing 1.0 is everything) - * what exceptions can you expect and what triggers them + * what exceptions can you expect, and what triggers them? -If you are looking for examples, browse through the codebase, searching for the `` tag or `///` should give you all kinds of examples. +If you are looking for examples, browsing through the codebase, searching for the `` tag or `///` should give you all kinds of examples. ## "Testing" the documentation -You can "test" the docs by simply hovering over the type in Visual Studio. The IntelliSense updates should be instantaneous when you have edited something. See image below for an example. +You can "test" the docs by simply hovering over the type in Visual Studio. The IntelliSense updates should be instantaneous when you have edited something. See the image below for an example. ![Partial screenshot of the Visual Studio text editor showing comments being edited and changes immediately showing up in the tooltip of the relevant type.](assets/EditingDocumentationVisualStudio.png) diff --git a/docs/DevelopmentTips.md b/docs/DevelopmentTips.md index 0d59b6fc8f4f..71a06c29c5f8 100644 --- a/docs/DevelopmentTips.md +++ b/docs/DevelopmentTips.md @@ -1,13 +1,13 @@ ### Reproducing an Issue/Debugging .NET MAUI Code Open the .NET MAUI [workspace](https://code.visualstudio.com/docs/editor/workspaces) in VS Code by simply opening the root of your locally cloned .NET MAUI repository folder. VS Code will detect the workspace automatically and suggest that you open it. -In VS Code, select the device that you will be testing on. Using the Command Palette (CTRL + Shift + P or on macOS Command + Shift + P) type `pick device` and you will be presented with a set of choices for your target device (Android, iOS, etc). First select the option that describes the platform you want to run the project on, and then select the device that is available for that platform in the next menu. +In VS Code, select the device that you will be testing on. Using the Command Palette (CTRL + Shift + P or on macOS Command + Shift + P) type `pick device` and you will be presented with a set of choices for your target device (Android, iOS, etc.). First select the option that describes the platform you want to run the project on, and then select the device that is available for that platform in the next menu. ![VS Code Command Palette to pick a target device](https://github.com/dotnet/maui/assets/939291/d008102f-0295-4034-a60a-8c2b58f86641) There is a sample project in `src/Controls/samples/Controls.Sample.Sandbox`. This is an empty project, which directly references the .NET MAUI code. In this project you can add your code to reproduce an issue while allowing you to set breakpoints in .NET MAUI source code and debug through it easily. -To let VS Code know this is the project you want run, select the Sandbox project by going to the Command Palette (CTRL + Shift + P or on macOS Command + Shift + P) and start typing `pick startup` and select ".NET MAUI: Pick Startup Project" and then select the Sandbox project. +To let VS Code know this is the project you want to run, select the Sandbox project by going to the Command Palette (CTRL + Shift + P or on macOS Command + Shift + P) and start typing `pick startup` and select ".NET MAUI: Pick Startup Project" and then select the Sandbox project. ![VS Code Command Palette to pick the startup project](https://github.com/dotnet/maui/assets/939291/eae00559-4811-4034-95ae-b6fd1ea6d1b7) @@ -67,7 +67,7 @@ dotnet cake --target=VSCode #### Testing branch against your project `--sln=` -- This will pack .NET and then open a VS instance using the local pack. This is useful if you want to check to see if the changes in a branch will address your particular issues. Pack only runs the first time so you will need to explicitly add the `--pack` flag if you make changes and need to repack. +- This will pack .NET and then open a VS instance using the local pack. This is useful if you want to check to see if the changes in a branch will address your particular issues. Pack only runs the first time, so you will need to explicitly add the `--pack` flag if you make changes and need to repack. ```dotnetcli dotnet tool restore @@ -83,7 +83,7 @@ dotnet tool restore dotnet cake --target=VS --pack --sln="\MauiApp2\MauiApp2.sln" ``` -Create new .NET MAUI app using your new packs +Create a new .NET MAUI app using your new packs ```dotnetcli dotnet tool restore dotnet cake --pack @@ -120,8 +120,8 @@ You will see the following prompt. Waiting for debugger to attach (dotnet PID 13001). Press enter to continue... ``` -You can then use VS or VSCode to attach to this process and debug you tasks. -You can start your test app with the `dotnet-local` script (so it uses your maui build) +You can then use VS or VSCode to attach to this process and debug your tasks. +You can start your test app with the `dotnet-local` script (so it uses your MAUI build). ### [MacOS](#tab/macos) @@ -146,26 +146,26 @@ set MSBUILDDEBUGONSTART=2 Note: the `-m:1` is important as it restricts MSBuild to 1 node. -Once MSBuild starts it will print the following +Once MSBuild starts, it will print the following ```dotnetcli Waiting for debugger to attach (dotnet PID xxxx). Press enter to continue... ``` -You need to copy the PID value so we can use this in the IDE. For Visual Studio you can use the `Attach to Process` menu option, while you have the Microsoft.Maui.sln solution open. For VSCode open the workspace then use the `Attach to Process` Run and Debug option. You will be prompted for the PID and it will then connect. +You need to copy the PID value so we can use this in the IDE. For Visual Studio, you can use the `Attach to Process` menu option while you have the Microsoft.Maui.sln solution open. For VSCode, open the workspace, then use the `Attach to Process` Run and Debug option. You will be prompted for the PID and it will then connect. -Once connected go back to your command prompt and press ENTER so that the MSBuild process can continue. +Once connected, go back to your command prompt and press ENTER so that the MSBuild process can continue. You will be able to set breakpoints in Tasks (but not Targets) and step through code from this point on. -If you want to test in-tree in VSCode the `Build Platform Sample` command will ask you if you want to debug MSBuild tasks and fill in the `MSBUILDDEBUGONSTART` for you. The PID text will appear in the `Terminal` window in VSCode. You can then use the `Attach to Process` Run and Debug option to attach to the process. +If you want to test in-tree in VSCode, the `Build Platform Sample` command will ask you if you want to debug MSBuild tasks and fill in the `MSBUILDDEBUGONSTART` for you. The PID text will appear in the `Terminal` window in VSCode. You can then use the `Attach to Process` Run and Debug option to attach to the process. ### Integration Tests -The Integration test project under `src/TestUtils/src/Microsoft.Maui.IntegrationTests` contains tests which build and/or run MAUI templates or other projects. +The Integration test project under `src/TestUtils/src/Microsoft.Maui.IntegrationTests` contains tests that build and/or run MAUI templates or other projects. -These tests can be ran using the test explorer in VS, or from command line with `dotnet test`. Here's how to run an individual test with parameters from command line: +These tests can be run using the Test Explorer in VS, or from the command line with `dotnet test`. Here's how to run an individual test with parameters from command line: ```bash dotnet test src/TestUtils/src/Microsoft.Maui.IntegrationTests --logger "console;verbosity=diagnostic" --filter "Name=Build\(%22maui%22,%22net7.0%22,%22Debug%22,False\)" diff --git a/docs/IssueManagementPolicies.md b/docs/IssueManagementPolicies.md index 5755fe520af5..a83fde2f3b6d 100644 --- a/docs/IssueManagementPolicies.md +++ b/docs/IssueManagementPolicies.md @@ -12,16 +12,16 @@ In general, we recommend you open a new issue if you have a bug, feature request If a contributor reviews an issue and determines that more information is needed from the author, they will post a comment requesting that information and apply the `s/needs-info` label. This label indicates that the author needs to post a response in order for us to continue investigating the issue. -If the author does not post a response within **7 days**, the issue will be automatically closed. If the author responds within **7 days** after the issue is closed, the issue will be automatically re-opened. We recognize that you may not be able to respond immediately to our requests, we're happy to hear from you whenever you're able to provide the new information. +If the author does not post a response within **7 days**, the issue will be automatically closed. If the author responds within **7 days** after the issue is closed, the issue will be automatically re-opened. We recognize that you may not be able to respond immediately to our requests; we're happy to hear from you whenever you're able to provide the new information. ### PR: pending author input -Similar to the `Needs Author Feedback` process above, PRs also require author input from time to time. When a member of our team asks for some follow-up changes from the author, we mark these PRs with `s/pr-needs-author-input` label. After doing so, we expect the author to respond within 14 days. +Similar to the `Needs Author Feedback` process above, PRs also require author input from time to time. When a member of our team asks for some follow-up changes from the author, we mark these PRs with the `s/pr-needs-author-input` label. After doing so, we expect the author to respond within 14 days. If the author does not post a response or updates the PR within **14 days**, the PR will be automatically closed. If the author responds within **7 days** after the PR is closed, the PR will be automatically re-opened. We recognize that you may not be able to respond immediately to our requests, we're happy to hear from you whenever you're able to provide the new information. ## Duplicate issues -If we determine that the issue is a duplicate of another, we will close the issue and comment with the issue we believe is a duplicate one. Note that we might close an issue as duplicate which is not the one that has been reported the earliest. We might close an issue that has been reported earlier because the later issue has more relevant information and/or discussion. +If we determine that the issue is a duplicate of another, we will close the issue and comment with the issue we believe is the duplicate one. Note that we might close an issue as duplicate which is not the one that has been reported the earliest. We might close an issue that has been reported earlier because the later issue has more relevant information and/or discussion. ## Locking closed issues -After an issue has been closed and had no activity for **30 days** it will be automatically locked as *resolved*. This is done in order to reduce confusion as to where to post new comments. If you are still encountering the problem reported in an issue, or have a related question or bug report, feel free to open a *new issue* and link to the original (now locked) issue! \ No newline at end of file +After an issue has been closed and had no activity for **30 days** it will be automatically locked as *resolved*. This is done in order to reduce confusion as to where to post new comments. If you are still encountering the problem reported in an issue or have a related question or bug report, feel free to open a *new issue* and link to the original (now locked) issue! \ No newline at end of file diff --git a/docs/README.md b/docs/README.md index 7d384c29dd03..ad3f7930931d 100644 --- a/docs/README.md +++ b/docs/README.md @@ -11,6 +11,6 @@ The table below outlines the different docs in this folder and what they are hel | Documentation | What is it about? | Who is it for? | |----------------------|---------------------|---------------------| | [Code Documentation Guidelines](CodeDocumentationGuidelines.md) | Overview of the guidelines for the inline code documentation | Community members and collaborators looking to understand how to add good inline code comments that fuel our IntelliSense and online API docs | -| [Issue management](IssueManagementPolicies.md) | Overview of policies in place to manage issues| Community members and collaborators looking to understand how we handle closed issues, issues that need author feedback, etc | +| [Issue management](IssueManagementPolicies.md) | Overview of policies in place to manage issues| Community members and collaborators looking to understand how we handle closed issues, issues that need author feedback, etc. | | [Release Schedule](ReleaseSchedule.md) | Overview of .NET MAUI version releases | Anyone who is interested in .NET MAUI versions and release dates | | [Triage process](TriageProcess.md)| Overview of the issue triage process used in the repo | Anyone looking to understand the triage process on the repo | diff --git a/docs/TriageProcess.md b/docs/TriageProcess.md index db32514793f1..108932e52cd8 100644 --- a/docs/TriageProcess.md +++ b/docs/TriageProcess.md @@ -22,56 +22,56 @@ We will first categorize the issues and further handle these depending on the ca ### Information Gathering -In this phase we instruct the user on how to collect the appropriate diagnostics and see if they are able to address the issue with that additional information. When we need user input we will mark the issue with `s/needs-info` label. Issues in this phase may be closed automatically if we do not receive timely responses, they often do not provide enough information for us to investigate further. +In this phase we instruct the user on how to collect the appropriate diagnostics and see if they are able to address the issue with that additional information. When we need user input, we will mark the issue with the `s/needs-info` label. Issues in this phase may be closed automatically if we do not receive timely responses; they often do not provide enough information for us to investigate further. We'll try to respond quickly to such issues (within days). If a user has collected all of the relevant diagnostics and the issue is still not apparent, then we will consider it for further [investigation](#investigations) by the team. ### Feature requests -As soon as we identify an issue represents an ask for a new feature, we will label the issue with the `t/enhancement ☀️` label. +As soon as we identify an issue that represents an ask for a new feature, we will label the issue with the `t/enhancement ☀️` label. Most of the time, we will automatically move these issues into the `.NET V Planning` (where V is the .NET version we're planning this for) milestone for further review during one of our [sprint planning meetings](#milestone-planning). If we think the feature request is not aligned with our goals, we may choose to close it immediately. In some situations, however, we may choose to collect more feedback before acting on the issue. In these situations we will move the issue in the `Backlog` so that we can review it during the [release planning](#release-planning). ### Bug reports -If it's immediately clear, that the issue is related to a bug in the framework, we will apply the `bug` label to the issue. +If it's immediately clear that the issue is related to a bug in the framework, we will apply the `bug` label to the issue. -At this point, we will try to make a call regarding it's impact and severity. If the issue is critical, we may choose to include it in our current milestone for immediate handling or potentially patching. +At this point, we will try to make a call regarding its impact and severity. If the issue is critical, we may choose to include it in our current milestone for immediate handling or potentially patching. If the bug is relatively high impact, we will move the issue into the `.NET V Planning` (where V is the .NET version we're planning this for) milestone to review during our [sprint planning](#milestone-planning) meeting. -If the impact is unclear or the is a very corner case scenario, we may move it to a next `.NET V Planning` or `Backlog` milestone to further evaluate the impact by reviewing customer up-votes / comments at a later time. +If the impact is unclear or there is a very corner case scenario, we may move it to the next `.NET V Planning` or `Backlog` milestone to further evaluate the impact by reviewing customer up-votes/comments at a later time. ### Investigations -In many situations it's not immediately clear whether a specific issue reported is a bug or not. To be certain, the team will need to spend time to investigate it before making a call regarding the faith of the issue. In these situations we will apply the `investigate` label to the issue. -In many situations, these issues turn out to be a result of some kind of misconfiguration in the user code. -In some rare situations, however, these turn out to be caused by very impactful issues. So we will make a call during the triage whether we need to immediately investigate certain issues or not. -If not, we will move the investigation to the `.NET V Planning` (where V is the .NET version we're planning this for) to review during one of the upcoming [sprint planning meetings](#milestone-planning). +In many situations, it's not immediately clear whether a specific issue reported is a bug or not. To be certain, the team will need to spend time investigating it before making a decision about the fate of the issue. In these situations we will apply the `investigate` label to the issue. +Often, these issues turn out to be a result of some kind of misconfiguration in the user code. +However, in rare cases, they are caused by highly impactful problems. During triage, we will decide whether certain issues require immediate investigation. +If not, we will move the investigation to the `.NET V Planning` (where V represents the .NET version we're planning this for) to review during one of the upcoming [sprint planning meetings](#milestone-planning). ### Documentation requests Some issues turn out to indicate user confusion around how to configure different aspects of the framework. When we determine such issues, we will mark these with the `Docs` label and move them into the `.NET V Planning` (where V is the .NET version we're planning this for) milestone to handle at a later time. The goal here will be to fill in the gaps or clarify our documentation, so that customers can be successful by using the guidance provided in the documentation. -If we identify a documentation issue which too many customers are having trouble with, we may choose to address that in current milestone. +If we identify a documentation issue that too many customers are having trouble with, we may choose to address that in the current milestone. ## Milestone Planning Our milestones are usually a month long. -Before each milestone we have one or more planning meetings, where we look through all the accumulated issues in the `.NET V Planning` (where V is the .NET version we're planning this for) milestone and choose the most important and impactful ones to handle during the next milestone. This will be a mixture of feature requests, bug fixes, documentation issues as well as some investigations. +Before each milestone, we have one or more planning meetings, where we look through all the accumulated issues in the `.NET V Planning` (where V is the .NET version we're planning this for) milestone and choose the most important and impactful ones to handle during the next milestone. This will be a mixture of feature requests, bug fixes, documentation issues, as well as some investigations. -Note, that we will investigate only issues, which have accumulated more than certain number of up-votes and/or comments, which will indicate that there is some wider impact associated with it. -We may not investigate issues which haven't received many votes/comments and choose to close these. The reason is that the impact is very scoped and potentially something is wrong in the user code. Consider asking these questions on StackOverflow, or if a bug is super important to you, please consider contributing to our project yourself. +Note that we will investigate only issues that have accumulated more than a certain number of up-votes and/or comments, which will indicate that there is some wider impact associated with it. +We may not investigate issues that haven't received many votes/comments and choose to close these. The reason is that the impact is very scoped, and potentially something is wrong in the user code. Consider asking these questions on StackOverflow, or if a bug is super important to you, please consider contributing to our project yourself. -For some feature requests and bug reports, depending on the user involvement, we may choose to move these to the backlog at this point. What this means, is that they will not be looked at again up until the next major release planning. +For some feature requests and bug reports, depending on the user involvement, we may choose to move these to the backlog at this point. What this means is that they will not be looked at again up until the next major release planning. ## Release Planning -Once we approach to the end of the release cycle (.NET Core 3, .NET 5) we will look through the accumulated issues in the `Backlog` milestone. This is a long process as the amount of issues accumulated in this milestone is quite large. +Once we approach the end of the release cycle (.NET 8, .NET 9), we will look through the accumulated issues in the `Backlog` milestone. This is a long process, as the amount of issues accumulated in this milestone is quite large. -We will try to prioritize issues with most community requests / up-votes assuming these are aligned with our goals. -Issues, which we will think are candidates for the upcoming release, will be moved to the `.NET V Planning` (where V is the .NET version we're planning this for) milestone. This process is documented in more details in the [Release Planning](ReleasePlanning.md) document. +We will try to prioritize issues with the most community requests/up-votes assuming these are aligned with our goals. +Issues, which we will think are candidates for the upcoming release, will be moved to the `.NET V Planning` (where V is the .NET version we're planning this for) milestone. This process is documented in more detail in the [Release Planning](ReleasePlanning.md) document. ## Cleanup -As we go through all the issues in the Backlog milestone as part of our release planning process, we will also cleanup the milestone by closing low priority issues, which have stayed in the backlog for more than 2 releases. While some of these issues may seem reasonable, the fact that those haven't been addressed for such prolonged period of time indicate that they're not as important for the product as they may seem to be. +As we go through all the issues in the Backlog milestone as part of our release planning process, we will also clean up the milestone by closing low-priority issues, which have stayed in the backlog for more than 2 releases. While some of these issues may seem reasonable, the fact that they haven't been addressed for such a prolonged period of time indicates that they're not as important for the product as they may seem to be. ## Process Visualization