diff --git a/docs/ESLintConvention.md b/docs/ESLintConvention.md
deleted file mode 100644
index 001dba56ac6f0f96234f03d0278f618826728495..0000000000000000000000000000000000000000
--- a/docs/ESLintConvention.md
+++ /dev/null
@@ -1,45 +0,0 @@
-## ESLint Convention
-
-Make the changes to the code and tests and then commit to your branch. Be sure to follow the commit message conventions.
-
-Commit message summaries must follow this basic format:
-
-```
-Tag: Message (fixes #1234)
-```
-
-`Tag` should not be confused with git tag.
-`Message` should not be confused with git commit message.
-
-The `Tag` is one of the following:
-
-* `Fix` - for a bug fix.
-* `Update` - for a backwards-compatible enhancement.
-* `Breaking` - for a backwards-incompatible enhancement.
-* `Docs` - changes to documentation only.
-* `Build` - changes to build process only.
-* `New` - implemented a new feature.
-* `Upgrade` - for a dependency upgrade.
-
-The message summary should be a one-sentence description of the change. The issue number should be mentioned at the end. * The commit message should say "(fixes #1234)" at the end of the description if it closes out an existing issue (replace 1234 with the issue number). If the commit doesn't completely fix the issue, then use `(refs #1234)` instead of `(fixes #1234)`.
-
-Here are some good commit message summary examples:
-
-```
-Build: Update Travis to only test Node 0.10 (refs #734)
-Fix: Semi rule incorrectly flagging extra semicolon (fixes #840)
-Upgrade: Esprima to 1.2, switch to using Esprima comment attachment (fixes #730)
-```
-
-The commit message format is important because these messages are used to create a changelog for each release. The tag and issue number help to create more consistent and useful changelogs.
-
-Based on https://github.com/eslint/eslint.github.io/blob/master/docs/developer-guide/contributing.md#step-2-make-your-changes
-
-[npm-image]: https://badge.fury.io/js/conventional-changelog-eslint.svg
-[npm-url]: https://npmjs.org/package/conventional-changelog-eslint
-[travis-image]: https://travis-ci.org/stevemao/conventional-changelog-eslint.svg?branch=master
-[travis-url]: https://travis-ci.org/stevemao/conventional-changelog-eslint
-[daviddm-image]: https://david-dm.org/stevemao/conventional-changelog-eslint.svg?theme=shields.io
-[daviddm-url]: https://david-dm.org/stevemao/conventional-changelog-eslint
-[coveralls-image]: https://coveralls.io/repos/stevemao/conventional-changelog-eslint/badge.svg
-[coveralls-url]: https://coveralls.io/r/stevemao/conventional-changelog-eslint
\ No newline at end of file
diff --git a/docs/home.md b/docs/home.md
deleted file mode 100644
index e4f2d6d76156e188088040e8211e300f39e8bd71..0000000000000000000000000000000000000000
--- a/docs/home.md
+++ /dev/null
@@ -1,47 +0,0 @@
-## C# Database ORM and FluentMigrator
-
-We provide a data model generated using linq2DB, allowing us to access our database via linq.
-A migration tool based on fluent migrator is used for stable and reversible database migrations.
-
-
-## Data Model
-linq2db generates the code that eventually creates the data model by compiling a design time text template.
-The main file for the text compilation is the /DataModel/CsDatabase.tt file. In that file, the database connection information should be provided. Follow the instructions in that file for working with the datamodel.
-
-The data model will be generated on every build process for the project guaranteering an up-to-date state of the data model with respect to migrations. The builer in this case is MSBuild, which does not know relative paths used by linqToDB. That means, if, for instance, some library changes require changes to the text compilation process from the text templates, you need to register the path variables used by linqToDB by unloading and editing the CsDatabase.proj!
-
-### Using the data model in your project
-Other than including this project, you need to set the configuration string for linqToDb to establish a connection to your database.
-You must call the constructor for the data model object with the server provider name and the connection string.
-The connection string has the format: "Data Source={dbDataSource}; Database={dbDatabase}; User Id={dbUserId}; Password={dbPassword};".
-The provider name is "SqlServer.2008" for our projects. A list of valid alternative names can be found here: https://linq2db.github.io/api/LinqToDB.ProviderName.html
-For an example look at the unit test in CsDatabase.Tests/ModelTest.cs
-
-### Changing the target of the data model
-If you want to change the database for which the data model should be created, you need to make a few adjustments:
- - The namespace should be adjusted in
- - cs-database/DataModel/CsDatabase.tt
- - cs-database/DataModelConstructor.ttinclude
- - The name of the partial class in cs-database/DataModelConstructor.ttinclude
- - The configuration string for the database connection will, by default, be fetched from consul. If needed, change the consul query keys in:
- - cs-database/DatabaseConnection.ttinclude
- - Migrator/Migrator.cs
- - If you are connecting a database other than msserver, you also must swap the
- It is recommended to include the cs-database/DataModelConstructor.ttinclude so that the database connection can be established with a programmatically obtained connection string (e.g. using consul) rather than having to include a App.config file to your projects.
- - Furhtermore you need to adapt the right _providerName in:
- - CsDatabase.Tests/ModelTest.cs
- - your projects
-
-## Fluent Migrator
-The fluent migrator provides a command line tool for handling database migrations.
-Currently, it provides an intermediary interface for utilizing the fluentMigrator up migration (down migration is currently not supported by us) as well as its rollback function, using the command line arguments:
-```
--migrate_up
--roll_back <number of roll back steps>
-```
-FluentMigrator will look for migrations in the Migrations directory. While it is, in principle, possible to call the our migrator from other projects as well, it is recommended to have all migrations in this project for greater cohesion and in order to make sure that the data model stays up-to-date.
-Migrations should be identified by a unique id which corresponds, roughly, to the date and time of its implementation. The format is:
-```
-YYYYMMDDhhmm
-```
-FluentMigrator uses this identifier to manage its migration versioning. For an example migration, check out the migrations in the test project for the database.
\ No newline at end of file
diff --git a/docs/images/add_a_package.png b/docs/images/add_a_package.png
deleted file mode 100644
index e8e8ed2121edfc81d8fb2e4f3e03ed4807c66eea..0000000000000000000000000000000000000000
Binary files a/docs/images/add_a_package.png and /dev/null differ
diff --git a/docs/images/add_a_reference.png b/docs/images/add_a_reference.png
deleted file mode 100644
index 4ee38c9951bc5739297b78abb2c82113286f6e71..0000000000000000000000000000000000000000
Binary files a/docs/images/add_a_reference.png and /dev/null differ
diff --git a/docs/images/create_class_library.png b/docs/images/create_class_library.png
deleted file mode 100644
index 89a252c6e358c73fb9b7299464f851e69127285a..0000000000000000000000000000000000000000
Binary files a/docs/images/create_class_library.png and /dev/null differ
diff --git a/docs/images/create_project.png b/docs/images/create_project.png
deleted file mode 100644
index f7ae1a1701c9287d5f7a959bf856f55966293081..0000000000000000000000000000000000000000
Binary files a/docs/images/create_project.png and /dev/null differ
diff --git a/docs/images/select_framework.png b/docs/images/select_framework.png
deleted file mode 100644
index bba5b07168b73cb1005150aad92d6d925bada649..0000000000000000000000000000000000000000
Binary files a/docs/images/select_framework.png and /dev/null differ
diff --git a/docs/images/select_project.png b/docs/images/select_project.png
deleted file mode 100644
index 6f42cc3a18e89d6e2a26cd76de9730f39feb51bf..0000000000000000000000000000000000000000
Binary files a/docs/images/select_project.png and /dev/null differ
diff --git a/docs/images/test_code.png b/docs/images/test_code.png
deleted file mode 100644
index e9d9b5f88107c03fb19d4d2c6567981d25658154..0000000000000000000000000000000000000000
Binary files a/docs/images/test_code.png and /dev/null differ
diff --git a/docs/markup.md b/docs/markup.md
deleted file mode 100644
index 938b6eb3d01ae251f10a000bda25fd4538d87d7a..0000000000000000000000000000000000000000
--- a/docs/markup.md
+++ /dev/null
@@ -1,78 +0,0 @@
-It's very easy to make some words **bold** and other words *italic* with Markdown. You can even [link to Google!](http://google.com)
-
-Sometimes you want numbered lists:
-
-1. One
-2. Two
-3. Three
-
-Sometimes you want bullet points:
-
-* Start a line with a star
-* Profit!
-
-Alternatively,
-
-- Dashes work just as well
-- And if you have sub points, put two spaces before the dash or star:
- - Like this
- - And this
-
-If you want to embed images, this is how you do it:
-
-
-
-# Structured documents
-
-Sometimes it's useful to have different levels of headings to structure your documents. Start lines with a `#` to create headings. Multiple `##` in a row denote smaller heading sizes.
-
-### This is a third-tier heading
-
-You can use one `#` all the way up to `######` six for different heading sizes.
-
-If you'd like to quote someone, use the > character before the line:
-
-> Coffee. The finest organic suspension ever devised... I beat the Borg with it.
-> - Captain Janeway
-
-[200~There are many different ways to style code with GitHub's markdown. If you have inline code blocks, wrap them in backticks: `var example = true`. If you've got a longer block of code, you can indent with four spaces:
-
- if (isAwesome){
- return true
- }
-
-GitHub also supports something called code fencing, which allows for multiple lines without indentation:
-
-```
-if (isAwesome){
- return true
-}
-```
-
-And if you'd like to use syntax highlighting, include the language:
-
-```javascript
-if (isAwesome){
- return true
-}
-```
-
-GitHub supports many extras in Markdown that help you reference and link to people. If you ever want to direct a comment at someone, you can prefix their name with an @ symbol: Hey @kneath — love your sweater!
-
-But I have to admit, tasks lists are my favorite:
-
-- [x] This is a complete item
-- [ ] This is an incomplete item
-
-When you include a task list in the first comment of an Issue, you will see a helpful progress bar in your list of issues. It works in Pull Requests, too!
-
-And, of course emoji!
-GitHub supports many extras in Markdown that help you reference and link to people. If you ever want to direct a comment at someone, you can prefix their name with an @ symbol: Hey @kneath — love your sweater!
-
-But I have to admit, tasks lists are my favorite:
-
- This is a complete item
- This is an incomplete item
-When you include a task list in the first comment of an Issue, you will see a helpful progress bar in your list of issues. It works in Pull Requests, too!
-
-And, of course emoji!
diff --git a/docs/nunit.md b/docs/nunit.md
deleted file mode 100644
index 020e56f85510b1319edbe89e76cdd0891b5abe43..0000000000000000000000000000000000000000
--- a/docs/nunit.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## Add NUnit Tests
-
-### Add Nunit test adapter
-1. Choose **Tools > Extensions and Updates**
-2. In the **Extensions and Updates** dialog box, expand the **Online** category and then **Visual Studio Marketplace**. Then, choose **Tools > Testing**.
-2. Select the **NUnit test adapter** and then choose **Download.**
-### Add Tests
-
-1. Create a class library project and add it to your solution.
-
- For convinience name it like your main project and add **.Tests** as a suffix.
- 
-
-2. Install the plug-in. In **Solution Explorer**, select the class library project, and then choose **Manage NuGet Packages** from its right-click or context menu.
-
- 
-
-3. In the **NuGet Package Manager** window, search for and select the plug-in (NUnit), and then choose **Install**.
- 
-
- The framework is now referenced in your project under **References**.
-
-4. From the class library project's **References** node, select **Add Reference**.
-
- 
-
-5. In the **Reference Manager** dialog box, select the project that contains the code you'll test.
-
- 
-
-6. Code your unit test.
-
- 
diff --git a/src/Database/Models/ProjectModel.cs b/src/Database/Models/ProjectModel.cs
index ddb3205793856ae95bc0f2e2ddfac87b0ae222f6..9429b31b821f8121d7985e57694e923d6580694d 100644
--- a/src/Database/Models/ProjectModel.cs
+++ b/src/Database/Models/ProjectModel.cs
@@ -248,7 +248,8 @@ namespace Coscine.Database.Models
projectQuotaModel.Insert(new ProjectQuota
{
ProjectId = project.Id,
- ResourceTypeId = resourceType.Id
+ ResourceTypeId = resourceType.Id,
+ Quota = 25
});
}
}