Update contribution guideline for minor API proposals

Evolution.md

@@ -6,6 +6,8 @@ A group of core contributors and stakeholders form the _Foundation Workgroup_, w
 
 ### How to propose a change
 
+*This section outlines the general process for features with a larger scope. For minor API proposals, please refer to the [Abbreviated review for minor proposals](#abbreviated-review-for-minor-proposals) section.*
+
 * **Consider the goal**: Before proposing a change, please consider how your idea fits into the goals and themes for the upcoming release. 
 * **Socialize the idea**: Propose a rough sketch of the idea in the "pitches" section of the Swift forums, the problems it solves, what the solution looks like, etc., to gauge interest from the community.
 * **Develop the proposal**: Expand the rough sketch into a complete proposal, using the [proposal template](Proposals/0000-template.md), and continue to refine the proposal on the forums. Prototyping an implementation and its uses along with the proposal is required because it helps ensure both technical feasibility of the proposal as well as validating that the proposal solves the problems it is meant to solve.
@@ -14,6 +16,8 @@ A group of core contributors and stakeholders form the _Foundation Workgroup_, w
 
 ### The review process
 
+*This section outlines the review process for features with a larger scope. For minor API proposals, please refer to the [Abbreviated review for minor proposals](#abbreviated-review-for-minor-proposals) section.*
+
 The review process for a particular proposal begins when a member of the Foundation Workgroup accepts a pull request of a new or updated proposal into the repository. That Foundation Workgroup member becomes the review manager for the proposal. The proposal is assigned a proposal number (if it is a new proposal), and then enters the review queue.
 
 The review manager will work with the proposal authors to schedule the review. Reviews usually last a single week, but can run longer for particularly large or complex proposals.
@@ -22,3 +26,13 @@ When the scheduled review period arrives, the review manager will post the propo
 
 After the review has completed, the Foundation Workgroup will make a decision on the proposal. The review manager is responsible for determining consensus among the Foundation Workgroup members, then reporting their decision to the proposal authors and forums. The review manager will update the proposal's state in the repository to reflect that decision.
 
+### Abbreviated review for minor proposals
+
+Minor API enhancement ideas that have gained community interest through GitHub issues or forum threads may take a shorter review process. Examples include extending existing types with new functions or variables, or adding new `case` to `enum`. Instead of requiring both a pitch thread and a review, these changes can be proposed directly with a proposal document on a pitch thread. The workgroup has appointed an API champion (currently @itingliu) to oversee this process. Here's what you would do:
+
+* **Develop the proposal**: Prepare the proposal using the [proposal template](Proposals/0000-template.md) with a prototype.
+* **Request an abbreviated review**: Initiate a pull request to the swift-foundation repository to indicate to the workgroup that you would like the proposal to be reviewed. Meanwhile, post the pull request on the "pitches" section of the Swift forums. Upon seeing the pitch on the forum, a workgroup member will be assigned to manage the review. 
+* **Address feedback**: Be responsive to questions and feedback and continue to refine the proposal as needed.
+
+At the end of the review period, the review manager will accept the proposal if there is a broad agreement among workgroup members and the community.
+