Remove historical notes and Code of Conduct references

Signed-off-by: killianmuldoon <kmuldoon@nvidia.com>

GOVERNANCE.md

@@ -1,74 +1,10 @@
 # Network Plumbing Working Group Governance
-Proposal, July 2020
-
-## NOTES / CHANGES
-* July 16th 2020
-Action Doug: Add language for adding a new project, ask for contributors to add item to agenda describing how it's related (implements specifications, is related technology etc), and a description of the project, and we'll bring it up for a vote.
-Action Doug: Mission statement to guide relevance of pull requests (leave some wiggle room, add language about tooling and PoC's)
-Action Adrian.C : Add project contributor expectations (will leave a comment) DONE
-Action Doug: Look into process for official Kubernetes working groups
-SIG Network proposes to the ToC
-If the TOC doesn't reject it, SIG-Network adds a document
-We could then add one or more projects as a sandbox
-The new Sandbox is perfect for "experimental" projects like this
-* July 21st 2020
-Doug, thoughts on roles:
-Josh makes a good point about establishing "roles", such as the role of being a member, a maintainer, etc. Doug is highly in favor of having a member role, to more easily establish who vote.
-Specs: need to be voted on by maintainers group?
-Define bi-weekly meeting
-What's quorum? No over representation from a single org.
-Add a link to the calendar.
-Can you vote on stuff that's not on the agenda this week?
-Could be pushed
-Periodic review of meeting time for timezones
-
-
-Checklist for "complete basic governance": https://docs.google.com/document/d/1JjRhcLBJQbbRCpKwYx_VcS_JzsqkznYj7GnYXpQkF8M/edit?usp=sharing
-##### July 23rd 2020
-    Added mission statement (earlier in the week), add portion on responsibilities of the group.
-    Update language to meet new idea of "roles" - member / maintainer
-    Updated section on maintainer responsibilities (thanks Adrian for getting that started!)
-    Closed a number of comments (which were very helpful!) that were out of date after having been addressed.
-    Added section about process for approving pull requests.
-    This could probably use some eyes & ideas.
-    Added section about meetings and voting
-    Doug needs input on quorum.
-
-##### August 11th 2020
-    Created a paragraph about maintainers meetings and decisions in the "maintainer responsibilities" section.
-    Add to mission statement regarding having goal of moving towards having technologies in Kubernetes itself, where appropriate.
-    Added phrasing for "vendor-neutral technologies"
-    Added location for list of members & maintainers as the /community repo
-    Addressed some typographical & grammatical errors.
-    Still need input on voting in section D.
-    Updated language for accepting pull requests to note that maintainers may approve their own pull requests, but require at least one other maintainer to give a LGTM.
-
-##### August 26th 2020
-    Peter Mangan has comments on voting rights for members vs. public participation, do we need updates to the language for being a member?
-    Clean up language for "maintainer" (which was using "core contributor" in places)
-    Updated language for "verbally agree" to "verbally (or otherwise) agree" to use language that accounts for people of all abilities.
-    Changed quorum to 3 members to vote. 5 members to change the governance document.
-    Added example for quorum and representation by a single given corporate entity.
-
-##### Sept 3rd 2020
-    Added note that maintainers still have the same rights and privileges as members (e.g. they're both maintainers and members, as they have to start as members)
-    Added new section "GitHub Organization Ownership"
-    Gist is that there should be no more than 50% of owners from the same employer, and that we vote to make someone an owner.
-    Clean up resolved comments.
-    Attempted to normalize some of the language between sections.
-
-##### August 25th 2021
-
-    Updates for two maintainers to accept a repository.
-
 
 ## OVERVIEW
 This document is intended as a proposal for how we govern the contributions to repositories under the Network Plumbing Working Group (NPWG). It's intended to document how people can join the project and become project core contributors, and will address further issues as need be.
 
 The intention is to provide a common ground for GitHub software repositories @ https://github.com/k8snetworkplumbingwg. These repositories encompass the work that's being done across the working group. As the group grows in size and as the stakeholders diversify, having a solid framework for contribution should benefit the group as a whole.
 
-In tandem, it's proposed that we accept a "code of conduct", which would be included in each repository in markdown format. In the "CODE OF CONDUCT" section, there is a proposed code of conduct which is adapted from: https://www.contributor-covenant.org/version/2/0/code_of_conduct/.
-
 Note: The original version of this document is at https://docs.google.com/document/d/1lIWOK-W6fb1VZiSjO1BoFUs0TmoVwgd4XuVc6mtJk2c
 
 ## MISSION STATEMENT
@@ -85,8 +21,6 @@ To become a member, one must have demonstrated contributions to the group (docum
 
 Members shall be documented in the community repository.
 
-Interactions in this working group are covered by the Code of Conduct.
-
 ### Section B: Becoming a maintainer
 A "maintainer" to the Network Plumbing Working Group includes the right to merge code into a specific repository.
 
@@ -106,8 +40,6 @@ Maintainers shall be documented in the community repository. A maintainer still
 * Meeting attendance when necessary or required.
 Project contributors and maintainers may meet and make decisions regarding a given repository. However, if consensus cannot be reached on a given topic, maintainers must bring these topics to the NPWG bi-weekly meeting for discussion, and if necessary a vote. If project meetings occur with regularity, the meeting details should be shared on the NPWG bi-weekly meeting agenda.
 
-Each repository shall have a copy of the Code of Conduct included.
-
 #### Process for accepting pull requests
 Pull requests should be approved by 2 or more maintainers employed by distinct employers before pull requests are merged. Maintainers may approve their own pull requests, however these pull requests must also be reviewed and approved by one or more other maintainers.