Add note about small edits

Author: rylev

posts/inside-rust/2022-05-19-governance-update.md

@@ -8,10 +8,12 @@ Last month, the core team, all the leads of top-level teams, the moderators, and
 
 As is detailed in the update, this report follows extensive conversations with many inside of the project and will continue as we encourage others in the project to reach out should they have feedback or want to get involved. 
 
-Since proper governance of the Rust project impacts all users of Rust, we thought it appropriate to also make this summary public which we have done below in an unaltered form. 
+Since proper governance of the Rust project impacts all users of Rust, we thought it appropriate to also make this summary public. While typos and grammatical fixes have been made since the original post, the text is otherwise unaltered. [^1]
 
 As is noted in the summary, the next steps are to take the findings we have so far and begin crafting proposals for how the Rust project will be governed in the future. This will eventually lead to RFCs or similar documents with concrete proposals.
 
+[^1]: See [rust-lang/blog.rust-lang.org#974](https://github.com/rust-lang/blog.rust-lang.org/pull/974) for the full history of changes to the original email.
+
 > From: Ryan Levick\
 > To: All members of the Rust project\
 > Date: Mon, 11 Apr 2021 18:27:00 UTC\
@@ -68,7 +70,7 @@ As is noted in the summary, the next steps are to take the findings we have so f
 > * **Project self-reflection**: instead of waiting for a crisis to occur before addressing issues, the governance structures should have mechanisms for automatically self correcting (i.e., doing the work that Mara and Ryan are doing now on a more regular basis)
 > * **Reporting progress**: there is a *lot* that happens in the Rust project much of which is not reported on. Having some mechanism for better ensuring that everyone has a good overview of what is happening in the project.
 > * **Active community management**: actively fostering the culture of the Rust project
-> * **Marketing**: the project had previously done more marketing around Rust usage - this work has largely moved to being preformed exclusively by individuals
+> * **Marketing**: the project had previously done more marketing around Rust usage - this work has largely moved to being performed exclusively by individuals
 > * **Public relations**: The Rust project has obligations to speak to the outside world (i.e., press, companies, educational institutions, other OSS projects, etc.)
 > * **User outreach**: while PR is a push mechanism, the project also needs some sort of pull mechanism for engaging with users and understanding their needs rather than solely relying on the individual insights that contributors bring.
 > * **Vision work**: establishing high level project wide goals that cross between team boundaries.
@@ -79,7 +81,7 @@ As is noted in the summary, the next steps are to take the findings we have so f
 > 
 > * **Lack of resources for admin/project management work**: Administrative and project management work is typically less resourced than technical work. Volunteers are typically more drawn towards technical work, and companies tend to fund technical work since they will more easily see a return on that investment. A properly running project is viewed as “table stakes” and thus less likely to see investment without purposeful resource allocation. A failure mode would be not having admin/project management functions be funded and eventually withering away leaving that work not done or done by those who are already busy with other concerns.
 > * **Project leadership not held accountable**: Many teams depend on the work of other teams for their own success. When a team feels another team is not delivering on what they need to succeed, this can lead to cascading failures or even outright conflict. Holding others accountable can be difficult because it requires clear expectations, channels for delivering clear and actionable feedback, consequences for consistently not living up to expectations, and mechanisms for handling conflict should it arise.
-> * **Project leadership detached from project**: As the project grows in complexity so does that admin/project management overhead. It is possible for a project wide decision making body to lose touch with goings on in the project as they become busy due to this overhead. There are two ways this can manifest itself: the leadership body fails to keep up with what’s happening in the project and/or the project members lose sight of the leadership body leading to degraded authority. A failure mode would be that the project leadership body becomes detached from the project and the two effectively start acting independently.
+> * **Project leadership detached from project**: As the project grows in complexity so does that admin/project management overhead. It is possible for a project wide decision making body to lose touch with goings-on in the project as they become busy due to this overhead. There are two ways this can manifest itself: the leadership body fails to keep up with what’s happening in the project and/or the project members lose sight of the leadership body leading to degraded authority. A failure mode would be that the project leadership body becomes detached from the project and the two effectively start acting independently.
 > * **An overworked leadership body**: Many of the requirements described above assume a leadership body with the authority to make decisions. Additionally, the leadership body needs to derive its authority from its members involvement in the rest of the project. A possible failure mode is that the leadership body is tasked with more and more responsibility making it harder for its members to keep up with their responsibilities both inside and outside of that leadership body. The more members begin to focus on their work inside the leadership body, the less they can derive their authority from their work outside that body. Additionally, authority should be largely distributed and so an overworked leadership team is a sign of a failure to properly delegate authority.
 > * **Lack of delegated authority**: Some administration and project management tasks require a combination of both authority and large amounts of time to be completed. If authority can only be derived through involvement in technical matters in the project, there is a risk that those charged with that work will not be able to do the work. For example, in the list of under resourced work items above both “identifying gaps” and “project self reflection” require a certain level of authority to have the findings make an impact. It would be necessary for the groups doing that work to somehow gain the level of authority needed to get that work done.
 > * **Lack of transparency**: Project governance is composed of activities that live on a spectrum of how sensitive in nature they are. Some activities must be kept private as they directly involve the personal matters of individuals. On the other hand, some activities clearly need the involvement of the entire Rust project from the get-go. Many activities live somewhere in between. A potential failure mode is not consistently ensuring that information that can be made public is regularly made so. Even though this can in practice be very difficult and can make it difficult for some to participate in leadership positions, not doing so can lead to diminishing trust in leadership and a growing lack of accountability.