walls of text

documentation/proposals/Proposal - Project Governance, Bindings Expansion and Ownership.md

@@ -56,13 +56,31 @@ Fundamentally, Silk.NET's mission has always been to be the one-stop-shop for al
 
 There is no doubt that adding more bindings under the current governance structure will lead to an absurd and insurmountable quantity of significant maintenance burden on the Silk.NET maintenance team, which threatens the ongoing quality of such inclusions in addition to the existing portfolio of bindings. Therefore, the governance structure must also change with the change in criteria. To address this, a new role of "Bindings Owner" is proposed. To understand its relationship with the project going forward, we must also propose an amended definition of the existing project roles going forward.
 
-A maintainer **shall** be responsible for all changes to project governance and directly responsible for all governance not explicitly delegated to any other party as part of this proposal prior to its supersession. They **should** review any incoming pull request to the Silk.NET monorepo affecting core functionality, core bindings, or other areas not delegated as part of this proposal. The maintainer is, of course, welcome to review other pull requests that don't fall under this definition, as with any community member. A maintainer **must not** approve and/or merge any pull request that contains breaking changes that have not been justified under the guidance in the SDP [4]. A maintainer **must not** allow or make any substantial changes to the High Level Utilities (HLUs) available to users without a proposal approved by the Working Group. A maintainer also **must not** allow or make any changes that fundamentally affect how larger portions of the library are developed and/or used without a proposal approved by the Working Group. For the purposes of this proposal, a HLU is defined as a C#-friendly API that eases the usage of bindings provided by Silk.NET that either deviates noticeably from the original API on which the API is based or that is targeting wider applicability outside of the context of a single binding. The addition or removal of a maintainer **must** be approved by a majority of all existing maintainers. There is no defined process for conflict resolution in the event of a vote failing to form a conclusive answer, but it is **recommended** that the maintainers communicate with the Working Group in these cases. For all other governance or project direction topics, the maintainers **must** obtain approval from the Working Group, ideally through a proposal. For the avoidance of doubt, Silk.NET.Core is not a HLU but a maintainer **should not** allow any functionality that is not applicable to more than one Silk.NET project to be included in this project. Maintainers **must** ensure that all .NET Foundation project guidance is being followed. Maintainers **must** ensure that the project contains a contribution guide representative of current processes. Any responsibilities not explicitly defined in this proposal **shall** vest in the maintainers. The maintainers **shall** carry these responsibilities until their resignation or until they are changed, where changes **must** be approved by both the maintainers and the Working Group (e.g. in proposals such as this one).
+A maintainer **shall** be responsible for all changes to project governance and directly responsible for all governance not explicitly delegated to any other party as part of this proposal prior to its supersession. They **should** review any incoming pull request to the Silk.NET monorepo affecting core functionality, core bindings, or other areas not delegated as part of this proposal. The maintainer is, of course, welcome to review other pull requests that don't fall under this definition, as with any community member.
+
+A maintainer **must not** approve and/or merge any pull request that contains breaking changes that have not been justified under the guidance in the SDP [4]. A maintainer **must not** allow or make any substantial changes to the High Level Utilities (HLUs) available to users without a proposal approved by the Working Group. A maintainer also **must not** allow or make any changes that fundamentally affect how larger portions of the library are developed and/or used without a proposal approved by the Working Group. For the purposes of this proposal, a HLU is defined as a C#-friendly API that eases the usage of bindings provided by Silk.NET that either deviates noticeably from the original API on which the API is based or that is targeting wider applicability outside of the context of a single binding.
+
+The addition or removal of a maintainer **must** be approved by a majority of all existing maintainers. There is no defined process for conflict resolution in the event of a vote failing to form a conclusive answer, but it is **recommended** that the maintainers communicate with the Working Group in these cases.
+
+For all other governance or project direction topics, the maintainers **must** obtain approval from the Working Group, ideally through a proposal.
+
+For the avoidance of doubt, Silk.NET.Core is not a HLU but a maintainer **should not** allow any functionality that is not applicable to more than one Silk.NET project to be included in this project.
+
+Maintainers **must** ensure that all .NET Foundation project guidance is being followed. Maintainers **must** ensure that the project contains a contribution guide representative of current processes. Any responsibilities not explicitly defined in this proposal **shall** vest in the maintainers.
+
+The maintainers **shall** carry these responsibilities until their resignation or until they are changed, where changes **must** be approved by both the maintainers and the Working Group (e.g. in proposals such as this one).
 
 A contributor **may** submit changes to the Silk.NET project for inclusion as a contribution as defined in the contribution guide provided by the maintainers, requesting approval as necessary. A maintainer **should** be an active contributor. For any code changes that a maintainer can't approve without a proposal as defined in the role of the maintainer, the contributor **should** provide a proposal (ideally before implementing such code changes). A contributor **must** follow all guidance outlined in the contribution guide.
 
-The .NET Foundation **shall** be responsible for continuity of the project beyond any one maintainer, and **should** allow a .NET community member to gain access to all project resources and become a maintainer should all maintainers be uncontactable, unavailable, and/or otherwise unable to perform their duties as defined in this proposal. The .NET Foundation **must** follow any processes and/or guidelines defined by the .NET Foundation Projects Committee for determining how and when to act in its role defined here. The .NET Foundation **may** provide additional project resources in line with the resources available to its Project Committee and the support provided to other .NET Foundation projects, following processes and guidelines defined by the Projects Committee. The .NET Foundation **must** provide a process for requesting project support. Maintainers **must** ensure that .NET Foundation operators have access to all resources created in the project's name. The .NET Foundation **must** ensure all maintainers are part of the [dotnet/silk-dotnet](https://github.com/orgs/dotnet/teams/silk-dotnet) team or otherwise have administrative access to all GitHub resources, and **must** allow existing maintainers to elect new maintainers as defined in this proposal. All copyright **shall** vest in the .NET Foundation, and the .NET Foundation **shall** carry any legal responsibilities conveyed by the project's license.
+The .NET Foundation **shall** be responsible for continuity of the project beyond any one maintainer, and **should** allow a .NET community member to gain access to all project resources and become a maintainer should all maintainers be uncontactable, unavailable, and/or otherwise unable to perform their duties as defined in this proposal. The .NET Foundation **must** follow any processes and/or guidelines defined by the .NET Foundation Projects Committee for determining how and when to act in its role defined here.
+
+The .NET Foundation **may** provide additional project resources in line with the resources available to its Project Committee and the support provided to other .NET Foundation projects, following processes and guidelines defined by the Projects Committee. The .NET Foundation **must** provide a process for requesting project support. Maintainers **must** ensure that .NET Foundation operators have access to all resources created in the project's name.
+
+The .NET Foundation **must** ensure all maintainers are part of the [dotnet/silk-dotnet](https://github.com/orgs/dotnet/teams/silk-dotnet) team or otherwise have administrative access to all GitHub resources, and **must** allow existing maintainers to elect new maintainers as defined in this proposal. All copyright **shall** vest in the .NET Foundation, and the .NET Foundation **shall** carry any legal responsibilities conveyed by the project's license.
+
+The Silk.NET Working Group **shall** consist of anyone who would like to be involved in conversations shaping the future of Silk.NET, typically indicated by participation in Working Group meetings or expressing interest in doing so. A Working Group member **should** discuss incoming proposals on topics defined in this proposal in meetings initiated by maintainers. A Working Group member **may** voice objections to such proposals and cast votes on maintainer-initiated votes.
 
-The Silk.NET Working Group **shall** consist of anyone who would like to be involved in conversations shaping the future of Silk.NET, typically indicated by participation in Working Group meetings or expressing interest in doing so. A Working Group member **should** discuss incoming proposals on topics defined in this proposal in meetings initiated by maintainers. A Working Group member **may** voice objections to such proposals and cast votes on maintainer-initiated votes. Lacking any objections to a proposal from any Working Group member or, where there are objections, justification by the majority of participants in the Working Group at that time; a proposal **shall** be deemed approved. In the case of objections, the Working Group **must** give detailed feedback rather than being an unelaborated rejection of a proposal. Maintainers and contributors submitting proposals **should** reissue the proposal with that feedback taken into consideration if it is not withdrawn.
+Lacking any objections to a proposal from any Working Group member or, where there are objections, justification by the majority of participants in the Working Group at that time; a proposal **shall** be deemed approved. In the case of objections, the Working Group **must** give detailed feedback rather than being an unelaborated rejection of a proposal. Maintainers and contributors submitting proposals **should** reissue the proposal with that feedback taken into consideration if it is not withdrawn.
 
 Given the above definitions, we can identify the following key points: