Fix typos (#7192)

meetings/working-groups/collection-literals/CL-2023-05-10.md

@@ -22,7 +22,7 @@ The natural type would be anonymous. The compiler would realize the collection b
 
 The extra builder concept changes how users would think about naturally-typed collection literals. This could make the mental model more complex. An explicit 'build' called out somehow in syntax might even be preferable over passing the variable implicitly as the targeted collection type.
 
-We briefly considered whether there would be merits to making the type speakable, a new framework collection builder type that could be passed around. It would be yet another collection/builder type to teach people about. If the new builder type was itself capable of doing the building on the stack, it wouldn't be able to be captured or used across awaits. It would also be an advanced type which we wouldn't want normal users to be working with every time they use a naturally-typed collection literals.
+We briefly considered whether there would be merits to making the type speakable, a new framework collection builder type that could be passed around. It would be yet another collection/builder type to teach people about. If the new builder type was itself capable of doing the building on the stack, it wouldn't be able to be captured or used across awaits. It would also be an advanced type which we wouldn't want normal users to be working with every time they use a naturally-typed collection literal.
 
 #### Conclusion
 
@@ -62,7 +62,7 @@ collection.Add(1);
 
 Building a collection by starting without items is common, and this would enable users to use `var` instead of `List<int>` or creating some other builder.
 
-Choosing the element type by examining calls and usages of the collection itself could result in errors which are hard for users to figure out. It would be similar to lambda return type inference. Lambda return type inference usually works well, but inference errors while editing are sometimes create really confusing diagnostics far away. Would we be making this poor kind of experience more common?
+Choosing the element type by examining calls and usages of the collection itself could result in errors which are hard for users to figure out. It would be similar to lambda return type inference. Lambda return type inference usually works well, but inference errors while editing can sometimes create really confusing diagnostics far away. Would we be making this poor kind of experience more common?
 
 #### Conclusion
 
@@ -70,7 +70,7 @@ The working group was reluctant to embrace forward inference of element types un
 
 ### Conversions from `List<T>` to other collections
 
-One of the things that the builder option would have done is allow naturally-typed collections to be passed as a specific collection type later. If we go with option 2 instead, would we want to retain this ability by allowing `List<T>` to implicitly or maybe explicitly convert to any other collection type?
+One of the things that the builder option would have done is allow a naturally-typed collection to be passed as a specific collection type later. If we go with option 2 instead, would we want to retain this ability by allowing `List<T>` to implicitly or maybe explicitly convert to any other collection type?
 
 ```cs
 var collection = [1, 2];