outdated stuff

docs/CONTRIBUTING.md

@@ -1,24 +0,0 @@
-[WIP]
-
-## What are nillware's plans for the project?
-
-- We want **reicast** to be the best dreamcast emulator, available _on every possible platform_, with the source **public**, and at _no cost of the end users_. 
-- We are not really interested in making any money off of it, apart from guaranteeing its developers' sustainability.
-- We'd really like that every regular/"important" contributor to get paid a reasonable amount of money for their work. 
-
-## CLA Stuff
-**reicast** has a CLA, which typically requires the commit author's signature. This means that **any commit returned upstream from a fork of reicast** also requires a CLA signature.
-- This leaves two options for handling the commit. 
-	1. Either attempt to get the original author to put in the extra work of modifying and resubmitting it to reicast or
-	2. alter the commit's recognized author by resubmitting it with a reference to the original commit.
-
-### Here's the current copyright structure of reicast
-- Parts written independently (this covers over 95% of the source) are owned by nillware.
-- Parts that were developed by skmp under contract, for which he doesn't have the copyright, but are licensed as GPL.
-- Parts developed by the rest of the **nulldc team (ZeZu, PsyMan)**. This code is under GPL, but the copyright belongs to them.
-- 3rd party contributions to nulldc, before 2008-2009. We use them under GPL. 
-- Contributions to the reicast project. Copyright belongs to the contributors, we use them via GPL.
-- 3rd party libraries. 
-
-We'll have to rewrite the parts that we can't get permission for though. 
-And be advised, we are really good at "refactoring" code!

docs/Release schedule and structure.md

@@ -1,26 +0,0 @@
-Release Naming
----
-Our release names are time-based and follow a `yy.mm(.respin)` notation. 
-Eg `Release 18.10` should happen in October of 2018.
-Hotfix/respins are denoted by an increasing trailing number if needed. Eg `Release 18.10.1`, `Release 18.10.2` and so on.
-
-Release Schedule
----
-We aim for a release on the first Monday of each month. This is manual right now, but ideally, it will be automated.
-Monday was selected because emulator use peaks on the weekends, so we have 5 days to fix things up/rollback if a bad release happens.
-
-Release Planning
----
-We have milestones for 3 releases ahead, then [Mid Term Goals](https://github.com/reicast/reicast-emulator/milestone/4) for 3-9 months ahead, and [Long Term Goals](https://github.com/reicast/reicast-emulator/milestone/2) for 9+ months ahead.
-
-Tickets are assigned to milestones based on a combination of feature planning and developer availability.
-
-Feature "Freeze" Windows
----
-We do a soft "feature freeze" on the week before release, to allow for the beta builds to be tested.
-During this window, experimental/untested changes should not be merged.
-
-Release Testing / QA
----
-We depend on the public beta and people complaining right now. 
-If you're interested to do QA testing around releases, please let us know in #1225, and/or join our [discord](http://chat.reicast.com)