update contribution guidelines, remove redundant files

docs/CODE_OF_CONDUCT.md

@@ -0,0 +1,76 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers
+pledge to making participation in our project and our community a harassment-free experience for
+everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level
+of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic address, without explicit
+  permission
+* Other conduct which could reasonably be considered inappropriate in a professional setting
+
+### Facilitation, Not Strongarming
+
+We recognize that this software is merely a tool for users to create and maintain their blockchain
+of preference. We see that blockchains are naturally community platforms with users being the
+ultimate decision makers. We assert that good software will maximize user agency by facilitating
+user-expression on the network. As such:
+
+* This project will strive to give users as much choice as is both reasonable and possible over what
+  protocol they adhere to; but
+* Use of the project's technical forums, commenting systems, pull requests and issue trackers as a
+  means to express individual protocol preferences is forbidden.
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable behavior and are
+expected to take appropriate and fair corrective action in response to any instances of unacceptable
+behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits,
+code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to
+ban temporarily or permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces when an individual is
+representing the project or its community. Examples of representing a project or community include
+using an official project e-mail address, posting via an official social media account, or acting as
+an appointed representative at an online or offline event. Representation of a project may be further
+defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting
+the project team at <[email protected]>. The project team will review and investigate all complaints,
+and will respond in a way that it deems appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident. Further details of
+specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary
+or permanent repercussions as determined by other members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at
+https://contributor-covenant.org/version/1/4
+
+[homepage]: https://contributor-covenant.org

docs/CONTRIBUTING.md

@@ -0,0 +1,128 @@
+# Contributing
+
+The `Polkadot SDK` project is an **OPENISH Open Source Project**
+
+## What?
+
+Individuals making significant and valuable contributions are given commit-access to the project.
+Contributions are done via pull-requests and need to be approved by the maintainers.
+
+## Rules
+
+There are a few basic ground-rules for contributors (including the maintainer(s) of the project):
+
+1. **No `--force` pushes** or modifying the master branch history in any way.
+   If you need to rebase, ensure you do it in your own repo. No rewriting of the history
+   after the code has been shared (e.g. through a Pull-Request).
+2. **Non-master branches**, prefixed with a short name moniker (e.g. `gav-my-feature`) must be
+   used for ongoing work.
+3. **All modifications** must be made in a **pull-request** to solicit feedback from other contributors.
+4. A pull-request **must not be merged until CI** has finished successfully.
+5. Contributors should adhere to the [house coding style](./STYLE_GUIDE.md).
+6. Contributors should adhere to the [house documenting style](./DOCUMENTATION_GUIDELINES.md), when applicable.
+
+## Merge Process
+
+### In General
+
+A Pull Request (PR) needs to be reviewed and approved by project maintainers.
+If a change does not alter any logic (e.g. comments, dependencies, docs), then it may be tagged
+`A1-insubstantial` and merged faster.
+If it is an urgent fix with no large change to logic, then it may be merged after a non-author
+contributor has reviewed it well and approved the review once CI is complete.
+No PR should be merged until all reviews' comments are addressed.
+
+### Labels:
+
+The set of labels and their description can be found [here](linktobeinserted)
+
+### Process:
+
+1. Please use our [Pull Request Template](./PULL_REQUEST_TEMPLATE.md) and make sure all relevant
+   information is reflected in your PR.
+2. Please tag each PR with minimum one `T*` label. The respective `T*` labels should signal the
+   component that was changed, they are also used by downstream users to track changes and to
+   include these changes properly into their own releases.
+3. If your’re still working on your PR, please submit as “Draft”. Once a PR is ready for review change
+   the status to “Open”, so that the maintainers get to review your PR. Generally PRs should sit for
+   48 hours in order to garner feedback. It may be merged before if all relevant parties had a look at it.
+4. If you’re introducing a major change, that might impact the documentation please add the label
+   `T13-documentation`. The docs team will get in touch.
+5. If your PR changes files in these paths:
+
+   `polkadot` : '^runtime/polkadot'
+   `polkadot` : '^runtime/kusama'
+   `polkadot` : '^primitives/src/'
+   `polkadot` : '^runtime/common'
+   `substrate` : '^frame/'
+   `substrate` : '^primitives/'
+
+   It should be added to the [security audit board](https://github.com/orgs/paritytech/projects/103)
+   and will need to undergo an audit before merge.
+6. PRs will be able to be merged once all reviewers' comments are addressed and CI is successful.
+
+**Noting breaking changes:**
+When breaking APIs, the PR description should mention what was changed alongside some examples on how
+to change the code to make it work/compile.
+It should also mention potential storage migrations and if they require some special setup aside adding
+it to the list of migrations in the runtime.
+
+## Reviewing pull requests:
+
+When reviewing a pull request, the end-goal is to suggest useful changes to the author.
+Reviews should finish with approval unless there are issues that would result in:
+1. Buggy behavior.
+2. Undue maintenance burden.
+3. Breaking with house coding style.
+4. Pessimization (i.e. reduction of speed as measured in the projects benchmarks).
+5. Feature reduction (i.e. it removes some aspect of functionality that a significant minority of users rely on).
+6. Uselessness (i.e. it does not strictly add a feature or fix a known issue).
+
+The reviewers are also responsible to check:
+
+a) if a changelog is necessary and attached
+
+b) the quality of information in the changelog file
+
+c) the PR has an impact on docs
+
+d) that the docs team was included in the review process of a docs update
+
+**Reviews may not be used as an effective veto for a PR because**:
+1. There exists a somewhat cleaner/better/faster way of accomplishing the same feature/fix.
+2. It does not fit well with some other contributors' longer-term vision for the project.
+
+## Helping out
+
+We use [labels](https://github.com/paritytech/polkadot-sdk/labels) to manage PRs and issues and communicate
+state of a PR. Please familiarise yourself with them. Best way to get started is to a pick a ticket tagged
+`[easy](https://github.com/paritytech/polkadot-sdk/issues?q=is%3Aopen+is%3Aissue+label%3AD0-easy)`
+or `[medium](https://github.com/paritytech/polkadot-sdk/issues?q=is%3Aopen+is%3Aissue+label%3AD1-medium)`
+and get going or `[mentor](https://github.com/paritytech/polkadot-sdk/issues?q=is%3Aopen+is%3Aissue+label%3AC1-mentor)`
+and get in contact with the mentor offering their support on that larger task.
+
+****
+
+### Issues
+
+If what you are looking for is an answer rather than proposing a new feature or fix, search
+[https://substrate.stackexchange.com](https://substrate.stackexchange.com/) to see if an post already
+exists, and ask if not. Please do not file support issues here.
+Before opening a new issue search to see if a similar one already exists and leave a comment that you
+also experienced this issue or add your specifics that are related to an existing issue.
+Please label issues with the following labels:
+1. `I*`  issue severity and type. EXACTLY ONE REQUIRED.
+2. `D*`  issue difficulty, suggesting the level of complexity this issue has. AT MOST ONE ALLOWED.
+3. `T*`  Issue topic. MULTIPLE ALLOWED.
+
+## Releases
+
+Declaring formal releases remains the prerogative of the project maintainer(s).
+
+## UI tests
+
+UI tests are used for macros to ensure that the output of a macro doesn’t change and is in the expected format.
+These UI tests are sensible to any changes in the macro generated code or to switching the rust stable version.
+The tests are only run when the `RUN_UI_TESTS` environment variable is set. So, when the CI is for example complaining
+about failing UI tests and it is expected that they fail these tests need to be executed locally.
+To simplify the updating of the UI test ouput there is the `.maintain/update-rust-stable