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

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

@@ -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.