Remove contents of _plugin-dev/basics.md regarding Picos core

This happens in favour of a separate CONTRIBUTING.md on GitHub, see d29e2c1. The website should stick to plugin and theme development.

_plugin-dev/basics.md

@@ -1,74 +1,12 @@
 ---
 toc:
-    basics:
+    basics: Basics
-        _title: Basics
-        versioning: Versioning
-        branches: Branches
-        build--release: Build & Release
 nav: 1
 ---
 
 # Basics
 Creating your own content for Pico is *easy*.
 
-Inside the root Pico folder, all *themes* reside in the `themes` directory, and all *plugins* in the `plugins` directory. (As a developer, you may have changed these paths and/or directory names when you initialized Pico.)
+Inside the root Pico folder, all *themes* reside in the `themes` directory, and all *plugins* in the `plugins` directory.
 
-Note that if you are submitting pull requests they should be small (i.e. one feature per request), stick to existing coding conventions and documentation should be updated if required.
+If you want to contribute to Picos core please refer to our [CONTRIBUTING.md](https://github.com/picocms/Pico/blob/master/CONTRIBUTING.md) on GitHub.
-
-# Versioning
-Pico uses Semantic Versioning. Given a version number MAJOR.MINOR.PATCH, increment the:
-
-- MAJOR version when you make incompatible API changes,
-- MINOR version when you add functionality in a backwards-compatible manner, and
-- PATCH version when you make backwards-compatible bug fixes.
-
-For more information see the [http://semver.org](http://semver.org) website.
-
-# Branches
-The `master` branch contains the current development version of Pico,
-*it is likely unstable and __not ready__ for production use*.
-
-When creating a new development branch, please follow this prefixing convention:
-
-- `feature/` for bigger features,
-- `enhancement/` for smaller improvements, and
-- `bugfix/` for bug fixes.
-
-As soon as development reaches a point where feedback is appreciated, a PR is opened. After some time (very soon for bug fixes, and other improvements should have a reasonable feedback phase) the PR is merged into `master` and the development branch can be deleted.
-
-# Build & Release
-Defined below is a specification to which the Build and Release process of Pico should follow. We use `travis-ci` to automate the process, and each commit to `master` should be releasable.
-
-### Commit phase
-- Commit changes
-- Create & Push Git tag
-- Trigger automatic build process...
-
-Example commit message:
-
-    Pico 1.0.1
-    * [New] ...
-    * [Changed] ...
-
-*Please submit pull-requests with a properly
-formatted commit message/SemVer increase to avoid the need for manual amendments.*
-
-### Analysis phase
-- Run through `scrutinizer-ci`?
-
-### Packaging phase
-- Run composer locally
-- Create a ZIP archive (so vendor/ is included)
-- Build documentation, output goes to a new folder in the `gh-pages` branch
-
-### Release phase
-- Create new Git release at tag
-- Upload ZIP archive
-- Upload documentation to the `gh-pages` branch
-- Set Symlink for latest documentation (http://picocms.org/docs/latest)
-- Update release information on GitHub with:
-    - Release title (taken from changelog)
-    - Changelog
-
-### Announcements
-- Where to announce new Pico release?