Merge pull request #34 from wesleywiser/patch-1

Fix a few dangling sentence fragments

content/blog/2023-11-28-project-goals.markdown

@@ -55,7 +55,7 @@ Project goal RFCs are not appropriate for all projects. In fact, they're not app
 * The Foundation has run several project grant programs, and one of the challenges has been trying to choose projects to fund which will be welcomed by the project. As I've been saying, we don't really have a mechanism for making those sorts of decisions.
 * The embedded working group or the Rust For Linux folks have a bunch of pain points. I think it's been hard for us to manage cooperation between those really important efforts and the other Rust teams. Developing a joint project goal would be a way to highlight needs.
 * Someone who wants to work on Rust at their company could work with a team to develop an official goal that they can show to their manager to get authorized work time.
-* Companies that want to invest in Rust to close gaps could propose project goals. For example, Microsoft recently authored an I frequently get asked how a company can help move custom allocators forward. One candidate that comes up a lot is support for custom allocators or collections with fallible debugging. This same mechanism would also allow larger companies to propose goals that they'd like to drive. For example, there was a [recent RFC on debugger visualization aimed at better support for debugging Rust in Windows](https://rust-lang.github.io/rfcs/3191-debugger-visualizer.html). I could imagine folks from Microsoft proposing some goals in that area.
+* Companies that want to invest in Rust to close gaps could propose project goals. For example, I frequently get asked how a company can help move custom allocators forward. One candidate that comes up a lot is support for custom allocators and collections with fallible allocation. This same mechanism would also allow larger companies to propose goals that they'd like to drive. For example, there was a [recent RFC on debugger visualization aimed at better support for debugging Rust in Windows](https://rust-lang.github.io/rfcs/3191-debugger-visualizer.html). I could imagine folks from Microsoft proposing some goals in that area.
 
 
 ## Anatomy of a project goal RFC
@@ -131,4 +131,4 @@ My next step is that I am going to fashion an RFC making the case for project go
 
 There are some follow-up questions worth discussing. One of the ones I think is most interesting is how to manage the quarterly project updates. This deserves a post of its own. The short version of my opinion is that I think it'd be great to have an open source "reporting" team that has the job of authoring this update and others of its ilk. I suspect that this team would work best if we had one or more people paid to participate and to bear the brunt of some of the organizational lift. I further suspect that the Foundation would be a good place for at least one of those people. But this is getting pretty speculative by now and I'd have to make the case to the board and Rust community that it's a good use for the Foundation budget, which I certainly have not done.
 
-It's worth noting that I see project goal RFCs as just one piece of a larger puzzle that is giving a bit more structure to our design effort. One thing I think went wrong in prior efforts was that we attemped to be too proscriptive and too "one size fits all". These days I tend to think that the only thing we *must have* to add a new feature to stable is an FCP-binding decision from the relevant teams(s). All the rest, whether it being authoring a feature RFC or creating a project goal RFC, are steps that make sense for projects of a certain magnitude, but not everything. Our job then should be to lay out the various kinds of RFCs one can write and when they are appropriate for use, and then let the teams judge how and when to request one.
+It's worth noting that I see project goal RFCs as just one piece of a larger puzzle that is giving a bit more structure to our design effort. One thing I think went wrong in prior efforts was that we attemped to be too proscriptive and too "one size fits all". These days I tend to think that the only thing we *must have* to add a new feature to stable is an FCP-binding decision from the relevant teams(s). All the rest, whether it be authoring a feature RFC or creating a project goal RFC, are steps that make sense for projects of a certain magnitude, but not everything. Our job then should be to lay out the various kinds of RFCs one can write and when they are appropriate for use, and then let the teams judge how and when to request one.