Orleans Announcement

## Announcement
Orleans framework has moved over to the .NET team. To make sure we tackle issues in a consistent way, we plan to align processes in this repo with dotnet/AspnetCore issue management and release processes. The sections below list all the processes that we plan to either introduce or change in this repo.

### Closing Stale Issues

In preparation for Orleans bottom-up work for .NET7, we plan to close all the issues that have not had any activity for the past 6 months.
The issues will be marked as `stale` by our bot and closed within two weeks of further inactivity. In case you still have an interest in the closed issue, please create a new issue and reference the closed issue to help us track the past conversation's history. Moving forward, we plan to triage all the new issues and decide prioritization based on customer value, upvotes and team resources.

### New Labels and Milestones

We will also be introducing new labels and milestones to align with other .NET open-source repositories such as `aspnetcore `.

`area-grains `, `area-silos`, `area-clients`, `area-streaming`, `area-persistence`, `area-deployment `, `area-testing`, `area-performance`, `area-security` Will indicate the category to which the issue belongs.

### New Triage process

#### Needs Triage
As issues get created, they will be labelled as `needs-triage` by our bot. If the issue is clear to our engineers during triage, we may add category and other informative labels (`area-grains `, `area-silos`, `area-clients`, `area-streaming`, `area-persistence`, `area-deployment `, `area-testing`, `area-performance`, `area-security`, `bug`, `question`, etc.).

#### Bugs

If it's clear that the issue is a bug in the framework, we apply the `bug` and the category area labels.

#### Investigation

If the issue is not immediately clear to our engineers during triage, we label the issue as `needs-investigation` and will assign it to an engineer based on priority.

#### Needs author feedback

During triage or investigation, we may need additional user input. In this case, we mark the issue as `needs-author-feedback`. If we do not receive enough information from the user in a timely manner (3 days), the issue will be closed by our bot.

#### Documentation

Some issues are created due to a lack of documentation in a particular area or confusion on how to do something in Orleans. In this case, we will mark the issue as `needs-documentation` and decide the milestone.

#### New feature request

During triage, the team may identify an issue as a new feature request and mark it as an `enhancement`. We may need to collect further information from the user/community on the feature request before deciding the prioritization and milestone. New feature requests get prioritized based on the following conditions:

- Clear understanding of customer value
- Community upvotes or past similar requests
- Cost (time and eng. resources availability)
- Alignment with Orleans's long-term goals

#### Question

We receive a lot of questions on how to do configurations, deployment, or other things in Orleans. If it's immediately clear the issue is a question, we will label it as a `question` and put it in the discussion milestone. We do our best to reply to these issues in a timely manner. Once we reply, we will mark the issue as `needs-author-feedback `. To ensure the user has had a chance to review our response, we keep the issue open for a week before our bot closes it with the label `Resolution: Answered`.

#### Process

We hold triage meetings every Tuesday and Thursday and our team discusses the issues with `needs-triage ` label during those meetings. We then categorize the issue based on the area, importance and add additional informative labels such as `bug`, `question`, `needs-design`, and decide based on customer value and cost in which milestone we can get the work completed. We will follow the standard `.NET7 milestones`. Since we have limited resources, we may label certain issues as `needs-help` and/or `good-first-issue` and put them in the backlog milestone.

No source files, tests, or entry points are named. This is a process announcement rather than a scoped implementation task, and it provides no concrete completion criterion for a newcomer to verify.

Written by the indexing model from the issue text.