fix: move to pristine

BUILDING.md

@@ -1,4 +1,4 @@
-# Jade Project Building
+# Project Building
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://tools.ietf.org/html/bcp14) [RFC2119](https://tools.ietf.org/html/rfc2119) [RFC8174](https://tools.ietf.org/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
 
@@ -8,7 +8,7 @@ When using the name 'version' we mean the versioning scheme described in [VERSIO
 
 ## Introduction
 
-This document is to describe the functionality a jade project MUST provide in terms of creating build artifacts. It also describes the structure in which jade project's MUST write build artifacts in.
+This document is to describe the functionality a project MUST provide in terms of creating build artifacts. It also describes the structure in which project's MUST write build artifacts in.
 
 We propose:
  - a folder name convention for build artifacts
@@ -43,7 +43,7 @@ Below is an example:
 .
 └── build
     └── windows
-        └── jade-signer.{ext}
+        └── my-build.exe
 ```
 
 ## Build Platform Targets
@@ -58,7 +58,7 @@ The result of this is that every project MUST produce a build for each target pl
  - `docker-compose up -f ./docker-compose.build.yml`
 
 The docker-compose.build.yml file MUST be placed in the project's root directory.
-Any dockerfiles used by the docker-compose may be placed at the discretion of the developer of the jade project.
+Any dockerfiles used by the docker-compose may be placed at the discretion of the developer of the project.
 
 ## Build Pipeline
 Starting from clean master branch with latest HEAD

README.md

@@ -1,4 +1,21 @@
-# jade
+# Pristine
 
-![](https://www.etclabs.org/dist/resources/images/v2/logo-top.png)
-Supported by [ETC Labs](https://www.etclabs.org/)
+Pristine is an open source repository in its original condition. It is meant to be a starting point and a place to find resources to augment your own open source repositories.
+
+### Conventions and Specifications 
+
+Using conventions and specifications make it easier to:
+- build and use composable tools
+- ease onboarding
+- promote issue and feature discussion
+
+### How to Contribute
+
+How to create tickets and contribute outlined in [CONTRIBUTING.md](CONTRIBUTING.md)
+
+### Docker:
+
+Docker is used as a building block. Here are the resources you need to get started and install docker:
+
+- [Install Docker Desktop for Mac](https://docs.docker.com/docker-for-mac/install/)
+- [Install Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/install/)

RELEASING.md

@@ -1,4 +1,4 @@
-# Jade Project Releasing
+# Project Releasing
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://tools.ietf.org/html/bcp14) [RFC2119](https://tools.ietf.org/html/rfc2119) [RFC8174](https://tools.ietf.org/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
 
@@ -14,7 +14,7 @@ We propose:
  - a set of release targets that are allowable
  - a pipeline for handling the release folder's artifacts
 
-It is NOT the purpose of this document to describe how a project might create a build, NOR is it describing a strcture in which jade projects MUST write build artifacts to. It is describing the structure of the releases themselves, however.
+It is NOT the purpose of this document to describe how a project might create a build, NOR is it describing a strcture in which projects MUST write build artifacts to. It is describing the structure of the releases themselves, however.
 
 ## Release Targets
 1. github

VERSIONING.md

@@ -1,16 +1,16 @@
-# Jade Project Versioning
+# Versioning
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://tools.ietf.org/html/bcp14) [RFC2119](https://tools.ietf.org/html/rfc2119) [RFC8174](https://tools.ietf.org/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
 
 This document is licensed under [The Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0.html).
 
 ## Introduction
-This document is to describe how a jade project is to version its releases
+This document is to describe how a project is to version its releases
 
 It also describes standardized tooling around manipulating the version
 
 ## Semver
-A Jade project MUST use Semantic Versioning [semver](https://semver.org). Build metadata MAY NOT be used in a jade project. Build metadata SHOULD be ignored.
+A project MUST use Semantic Versioning [semver](https://semver.org). Build metadata MAY NOT be used in a project. Build metadata SHOULD be ignored.
 
 A Basic summary of Semantic Versioning taken from: [semver.org(https://semver.org)