PR: tag-storage overhaul

.github/settings.yml

@@ -37,3 +37,6 @@ collaborators:
 
   - username: lpabon
     permission: admin
+
+  - username: dutchshark
+    permission: admin

CODE-OF-CONDUCT.md

@@ -0,0 +1,124 @@
+# Code of Conduct
+
+We follow the [CNCF Code of Conduct][cncf-coc].
+
+As part of our pledge to respect all people, in both live in-person and online
+interactions, we are committed to providing a friendly, safe and welcoming
+environment for all, regardless of gender, gender identity and expression,
+sexual orientation, disability, physical appearance, body size, race, religion,
+native language, operating system choice, current software stack or prior
+experience.
+
+In keeping with this commitment, we offer the following guidelines:
+
+* Welcome newcomers at any stage of expertise.
+  * Everyone has something to contribute.
+  * Everyone deserves access to materials and community that will help them
+       learn.
+  * As long as an individual can be respectful and not disruptive to other
+       participants, they deserve to participate.
+* Provide open and free material.
+* Be kind and courteous.
+  * Interpret the arguments of others in good faith, offering private
+       constructive feedback when communication style bears improvement.
+  * Leave space for quieter voices.
+* Consider who is not in the room.
+  * Invite participation from experts or user community representatives
+       outside of the working group.
+  * Participate in online forums to be inclusive of those who cannot attend
+       meetings.
+* Work performed within this group, either finalized or in draft, is to be
+     used in accordance with the group [Mission and
+     Charter][charter],
+     the open source license, and to be used for the equal benefit of all
+     members of the community.  Further information on use of work may be found
+     in [Security Reviews:
+     Outcome][review-outcome]
+
+## Incident handling and escalation
+
+Content for the purposes of the code of conduct as well as incident is defined
+not only as published or draft content but also online discourse, such as slack
+messages or emails, and interactions at in-person events.  If an incident
+involving community conduct occurs, please follow the guidelines below on how to
+handle and report the issue:
+
+* If you see content that clearly does not meet the official Code of Conduct,
+  please send an e-mail to the Co-Chair/TL mailing list
+  (cncf-tag-security-leads@lists.cncf.io) and the creator of the content. (For
+  more details refer to the [CNCF Code of Conduct][cncf-coc]).  If it is
+  regarding a co-chair, reach out to the two other chairs directly if you are
+  uncomfortable using the mailing list.
+* If you are uncomfortable with a piece of content (but it may not necessarily
+  violate the code of conduct), we suggest sending a private message to the
+  content owner expressing your concerns. If this is not resolved, you may wish
+  to request the help of a Co-Chair/TL via cncf-tag-security-leads@lists.cncf.io
+  to help mediate the situation.
+* Discussions about these potential code of conduct violations and concerns are
+  important, and there are great avenues to discuss them. This includes bringing
+  up concerns to the [CNCF TOC][cncf-toc] (which can be done through discussion
+  with Security TAG leadership) or talking to Security TAG leadership about
+  moderating a post. To help ensure that we can give focus to these issues and
+  not tangle them up with technical discussions, we should keep these
+  discussions separate from channels which are focused around technical
+  exchange.
+
+For content creators:
+
+* Content must strive to remain _on-topic_, particularly where video and images
+  are provided.  Use of emojis and gifs as responses are content in and of
+  themselves need to be relevant to the particular post. For examples please
+  refer to the reference section below.
+* If you receive a notice about a piece of content you've created, please seek
+  to understand that in some cases you may not agree with a decision or request.
+  Being able to practice tolerance and mindfulness is just as important to keep
+  the community working towards a common goal. The mediation and resolution
+  system that we have in place aims to handle this with the hope that both
+  content creators and consumers are heard and represented. These situations are
+  not zero sum, and often we aim to reach an agreeable compromise where a
+  discussion of a topic can happen without making members of the community feel
+  uncomfortable.
+* In the event where there is disagreement, we have some guidelines that can
+  help prevent escalation
+  * Do not bring the discussion out of context.
+  * Do not rationalize the actions you take. We do not expect anyone to
+    understand what everyone else feels towards certain things (e.g. the same
+    gestures in certain cultures are good and bad in others). Understand that
+    something may not be wrong, but it may affect others.
+
+In summary, be nice, inclusive and welcoming. Misunderstandings, mistakes and
+oversights happen, and when they do, there are some good ways to go about having
+a conversation with colleagues to make our community inclusive and welcoming to
+everyone!  
+
+## Reference
+
+Example of reasonable gif: Group is close to wrapping up deliverable, as part of
+an update, the lead posts a "nearly done" gif.  
+
+Example of reasonable emoji:  Post in the group uses emojis to break up content
+and is relevant to the item discussed or used in response to post to signify
+voting, opinion, acceptance, emotion, etc.  
+
+Example of reasonable image and video:  Posting a picture of a community meetup*
+or posting a recording to a presentation on cloud native security.
+
+*Note: Many events within the community may include content which is only
+acceptable depending on the context it is used in.  An example of this is
+alcohol consumption. It is important that when posting photos and videos members
+consider if the post glorifies alcohol or alcohol is the primary subject of the
+content (unacceptable) or if the alcohol is happenstance occurrence in the image
+(acceptable).  
+
+## Inspiration
+
+The above guidelines are inspired by and borrowed from other communities:
+
+* <https://bridgefoundry.org/code-of-conduct>
+* <https://www.rust-lang.org/policies/code-of-conduct>
+* <https://golang.org/conduct>
+
+[cncf-coc]: https://github.com/cncf/foundation/blob/master/code-of-conduct.md  
+[charter]: https://github.com/cncf/tag-security/blob/main/governance/charter.md
+[review-outcome]: https://github.com/cncf/tag-security/tree/main/assessments#outcome
+[cncf-toc]: https://www.cncf.io/people/technical-oversight-committee/

CODEOWNERS

@@ -0,0 +1,19 @@
+# CODEOWNERS file indicates code owners for certain files
+#
+# Code owners will automatically be added as a reviewer for PRs that touch
+# the owned files.
+#
+# The main branch will be configured to require at least 1 approval from a 
+# code owner for a PR.
+#
+# Actions by community members should follow the following guidelines:
+# https://github.com/cncf/tag-storage/blob/main/governance/github.md
+
+# Global code owners: co-chairs, tech leads
+# Note: Tech leads can perform approval and merging of PRs, with the intent
+# of delegating some responsibilities from co-chairs. 
+#
+# Tech lead, Chair Emeritus roles should exercise discretion in defering final
+# approval for a PR to a co-chair. 
+# This includes major edits or new introductions to the repository.
+*       @chira001 @sougou @quinton-hoole @erinboyd @xing-yang @saad-ali @lpabon

CONTRIB/README.md

@@ -0,0 +1,37 @@
+# Contributing
+
+We aspire to create a welcoming environment for collaboration on this project
+and ask that all contributors do the same. For more details, see our [code of
+conduct](/CODE-OF-CONDUCT.md).
+
+This document covers contributions to this git repository. Please review
+[governance](/governance) for our mission, charter, and other operations.
+
+## Open source
+
+While this repository does not contain open source code, we manage content
+contributions following open source practice, as detailed below.
+
+All contributions to this project will be released under open source license as
+described in [LICENSE.md](/LICENSE.md). By submitting a pull request (PR),
+you are agreeing to release the PR contents under this license.
+
+## Communication
+
+Anyone interested in contributing should join the mailing list and other
+[communication channels](/README.md#Communications)
+
+We strongly encourage and support all our members to participate in anyway
+they can. Not everyone can participate in the regularly scheduled live meetings,
+so we strive to make our processes friendly for people to be active contributors
+through asynchronous communication and contributions to our documentation
+in this repository.
+
+## Github pull requests and issues
+
+If you are new to the group, [reviewing pull requests](pull-request-review.md)
+and commenting on issues is a great way to get involved!
+
+When creating or reviewing pull requests, please refer to the
+[writing style guide](writing-style.md) to help maintain consistency across
+all of our documents.

CONTRIB/first-time-contributions.md

@@ -0,0 +1,63 @@
+# First time contributors
+
+We happily welcome our new contributors to this
+community. If you are contributing to the CNCF
+and/or TAG-Storage for the first time it is
+okay if you feel overwhelmed. We, as a
+community, are always there to help you
+with any problems you are facing.
+Open source is about collaboration and
+we are always there to support
+each other.
+
+## Getting involved and contributing
+
+As a new contributor, you might find
+difficulties in understanding where to start.
+Don't worry! We got you.
+
+In the interest of getting more new people
+involved, we have issues marked as
+[good-first-issues](https://github.com/cncf/tag-storage/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22).
+These are issues that have a smaller scope,
+and are great to start with.
+
+The good-first-issues should also provide
+you details on how to get things resolved or
+how to proceed. If you find it is missing or
+incomplete please tag the person who created
+the issue and let them know.
+
+## Before your first PR
+
+Before you make you first PR, we would like
+you to go through the below resources
+for your understanding:
+
+- [How to submit contributions](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution)
+- [Collaborating with pull requests](https://docs.github.com/en/github/collaborating-with-pull-requests)
+
+Our PR also follows a particular writing
+style. Checkout the [style guide](https://github.com/cncf/tag-storage/blob/main/CONTRIB/writing-style.md).
+
+## Other ways of communication
+
+If have additional questions or
+doubts about a certain issue.
+Please reach out and we will
+be happy to discuss.
+
+You can reach us via our [Mailing List](mailto:cncf-tag-storage-leads@lists.cncf.io).
+
+You can also reach out on our slack [#tag-storage-governance](https://cloud-native.slack.com/archives/C0230RW8V2T).
+
+### You can reach out to our members
+
+Our members list can be found
+[here](https://github.com/cncf/tag-storage#members).
+
+## After PR merge
+
+Once you have successfully get your
+first PR merged, you can add your name
+to our Members section in [README.md](https://github.com/cncf/tag-storage#members).

CONTRIB/pull-request-review.md

@@ -0,0 +1,88 @@
+# Pull Request (PR) reviews
+
+Except for urgent or very small grammar or spelling fixes, such as simple
+changes discussed below, we leave pull requests open for at least 24 hours, so
+that others have the chance to review/comment.
+
+### Favorable review
+
+A favorable review is determined by the contents of the PR complying with the
+contributing guide, the writing style, and agreement the contents align with the
+TAG's goals, objectives, and scope.  It is anticipated that PRs submitted, with
+the exception of spelling and grammar changes, have been discussed with members
+of the TAG via slack or issues.
+
+#### Nits
+
+Nits are minor suggestions and changes that are strongly encouraged to be
+identified and resolved to provide consistency in the repo.  Preferential
+language or language that is a matter of preferred usage are not considered
+nits.
+
+##### Example of preferential language
+
+> They use cloud technologies with clear understanding of risks and the ability
+> to validate that their storage policy decisions are reflected in deployed
+> software.
+
+"Ability" is a human oriented term, "capability" is more technical and may be
+more appropriate.
+
+Suggestion:
+> They use cloud technologies with clear understanding of risks and the
+> capability to validate their storage policy decisions are reflected in
+> deployed software.
+
+##### Example of a nit
+
+> They use cloud-native technologies with clear understanding of risks and the
+> ability to validate that their storage policy decisions are reflected in
+> deployed software.
+
+Per TOC definition of cloud native, it is not hyphenated.
+
+correction:
+> They use cloud native technologies...
+
+#### Simple changes
+
+Simple changes are defined as:
+
+* spelling, typo, grammar
+* clarifications, minor updates
+
+A person without access, other than the PR author, can and _is_ encouraged to
+review a PR and comment/+1 that they have done a review and found it favorable.
+A person with access, including the PR author, may then perform the merge.
+
+A person with access, other than the PR author, can both review **and** merge a
+PR if found favorable after review.
+
+[Code owners](/CODEOWNERS) need to be at least one concurring reviewer or the
+merging party.
+
+#### Significant changes
+
+Significant changes are defined as:
+
+* major changes to the repo
+* extensive changes to repo contents
+* other items as determined by the Technical Leads and Co-Chairs (to be updated
+  here as they occur)
+
+A person without access, other than the PR author can and _is_ encouraged to
+review a PR and comment/+1 that they have done a review and found it favorable.
+A second person with access, other than the PR Author, must also review the PR
+and provide concurrence prior to merging.
+
+Two persons with access, other than the PR author, must review the PR and
+provide concurrence, the last of which should perform the merge.
+
+[Code owners](/CODEOWNERS) need to be at least one concurring reviewer or the
+merging party.
+
+### Merging pull requests
+
+PRs may be merged after at least one review as occurred, dependent on the type
+of changes reflected in the PR.  The merging party needs to verify a review has
+occurred, the PR is in alignment with this guide, and is in scope of the TAG.

CONTRIB/writing-style.md

@@ -0,0 +1,42 @@
+# Writing style
+
+Consistency creates clarity in communication.
+
+If you find yourself correcting for consistency, please propose additional style
+guidelines via pull request to this document. Feel free to add references to
+good sources for content guidelines at the bottom of this guide.
+
+<!-- cSpell:ignore usecase --->
+## Common terms
+
+* When referring to users and use cases, ensure consistency with
+  [use cases](/usecase-personas/)
+* See [CNCF Style Guide][cncf-style] for common terms. Note that the following
+  terms are not hyphenated and all lower case, except for capitalizing the
+  first letter when at the beginning of a sentence:
+  * open source
+  * cloud native
+
+## Additional formatting
+
+* Headlines, page titles, subheads and similar content should follow sentence
+  case, and should not include a trailing colon.
+* Paragraphs do not start with leading indent.
+* Wrap lines at 80 characters, except where it would break a link. No need to
+  reformat the whole paragraph to make it perfect -- fewer diffs are easier
+  for reviewers.
+
+## File & directory naming conventions
+
+* Every directory should have a README.md with useful introductory text.
+* All other file and directory names should be all lower case with dashes to
+  separate words.
+
+## Sources
+
+<!-- cSpell:ignore Opps --->
+* [OpenOpps Contribution Guide][openopps-style]
+* [18F Content Guide](https://content-guide.18f.gov/)
+
+[cncf-style]: https://github.com/cncf/foundation/blob/master/style-guide.md
+[openopps-style]: https://github.com/openopps/openopps-platform/blob/master/CONTRIBUTING.md