Move help into docs

docs/README.md

@@ -1,9 +1,22 @@
-# OpenProject Community Guides
-
+---
+sidebar_navigation:
+  title: OpenProject Documentation
+  priority: 999
+description: Help and documentation for OpenProject Community, Enterprise Edition and Cloud Edition.
+robots: index, follow
+keywords: help, documentation
+---
+# OpenProject Documentation
+
+<div class="alert alert-info" role="alert">
+**Note**: To better read our OpenProject Documentation, please go to [docs.openproject.org](https://docs.openproject.org).
+</div>
+
+ToDo: check all links.
 
 ## Installation
 
-Get started with installing and upgrading OpenProject using [our Installation Guide starting point](https://www.openproject.org/open-source/download/).
+Get started with installing and upgrading OpenProject using [our Installation Guide starting point](https://docs.openproject.org/installation-and-operations/).
 
 The guides for [manual](./installation/manual/README.md), [packaged](./installation/packaged/) and [Docker-based](./installation/docker/README.md) installations are provided.
 

docs/development/README.md

@@ -1,11 +1,121 @@
-# Resources for developers
+# Develop OpenProject
 
+We are pleased that you are thinking about contributing to OpenProject! This guide details how to contribute to OpenProject.
 
-* [Quick Start for Developers](./quick-start.md)
-* [Development environment for Ubuntu 16.04.](./development-environment-ubuntu.md)
-* [Development environment for Mac OS X](./development-environment-osx.md)
+## Get in touch
 
-* [Developing Plugins](development/create-openproject-plugin.md)
-* [Running Tests](RUNNING_TESTS.md)
-* [API Documentation](./api/README.md)
-* [Report a Bug](report-a-bug.md)
+Please get in touch with us using our [develompment forum](https://community.openproject.com/projects/openproject/forums/7) or send us an email to info@openproject.org.
+
+## Issue tracking and coordination
+
+We eat our own ice cream so we use OpenProject for roadmap planning and team collaboration. Please have a look at the following pages:
+
+- [Development roadmap](https://community.openproject.com/projects/openproject/work_packages?query_id=1993)
+- [Wish list](https://community.openproject.com/versions/26)
+- [Bug backlog](https://community.openproject.com/versions/136)
+- [Reporting a bug](https://www.openproject.org/development/report-a-bug/)
+- [Submit a feature idea](https://www.openproject.org/development/submit-feature-idea/)
+
+## Branching model
+
+The main development branch for upcoming releases is `dev`. If in doubt, create your pull request against `dev`. All new features, gem updates and bugfixes for the upcoming release should go into the `dev` branch.
+
+## Development flow
+
+For contributing source code, please follow the git workflow below:
+
+- **Fork** OpenProject on GitHub
+- Clone your fork to your development machine:
+
+```
+git clone git@github.com/<username>/openproject
+```
+
+- Optional: Add the original OpenProject repository as a remote, so you can fetch changes:
+
+```
+git remote add upstream git@github.com:opf/openproject
+```
+
+- Make sure you're on the right branch. The main development branch is `dev`:
+
+```
+git checkout dev
+```
+
+- Create a feature branch:
+
+```
+git checkout -b feature/<short description of your feature>
+```
+
+- Make your changes, then push the branch into your **own** repository:
+
+```
+git push origin <your feature branch>
+```
+
+- Create a pull request against a branch of of the <opf/openproject> repository, containing a **clear description** of what the pull request attempts to change and/or fix.
+
+If your pull request **does not contain a description** for what it does and what it's intentions are, we will reject it. If you are working on a specific work package from the [list](https://community.openproject.com/projects/openproject/work_packages), please include a link to that work package in the description, so we can track your work.
+
+The core contributor team will then review your pull request according to our [code review guideline](https://www.openproject.org/open-source/development-free-project-management-software/code-review-guideliness/). Please note that you can add commits after the pull request has been created by pushing to the branch in your fork.
+
+## Translations
+
+If you want to contribute to the localization of OpenProject and its plugins you can do so on the [Crowdin OpenProject page](https://crowdin.com/project/openproject). Once a day we fetch those locales and automatically them to GitHub. Contributing there will ensure your language will be up to date for the next release!
+
+More on this topic can be found in our [blog post](https://www.openproject.org/help-translate-openproject-into-your-language/).
+
+## Testing
+
+Please add tests to your code to verify functionality, especially if it is a new feature.
+
+Pull requests will be verified by TravisCI as well, but please run them locally as well and make sure they are green before creating your pull request. We have a lot of pull requests coming in and it takes some time to run the complete suite for each one.
+
+If you push to your branch in quick succession, please consider stopping the associated Travis builds, as Travis will run for each commit. This is especially true if you force push to the branch.
+
+Please also use `[ci skip]` in your commit message to suppress builds which are not necessary (e.g. after fixing a typo in the `README`).
+
+## Bugs and hotfixes
+
+Bugfixes for one of the actively supported versions of OpenProject should be issued against the respective branch. A fix for the current version (called "Hotfix" and the branch ideally being named `hotfix/XYZ`) should target `release/*` and a fix for the former version (called "Backport" and the branch ideally being named `backport/XYZ`) should target `backport/*`. We will try to merge hotfixes into dev branch but if that is no trivial task, we might ask you to create another PR for that.
+
+## Inactive pull requests
+
+We want to keep the Pull request list as cleaned up as possible - we will aim close pull requests after an **inactivity period of 30 days** (no comments, no further pushes) which are not labelled as `work in progress` by us.
+
+## Security
+
+If you notice a security issue in OpenProject, please send us a gpg encrypted email to security@openproject.com and describe the issue you found. Download our public gpg key [here](https://pgp.mit.edu/pks/lookup?op=get&search=0x7D669C6D47533958).
+
+Please include a description on how to reproduce the issue if possible. Our security team will get your email and will attempt to reproduce and fix the issue as soon as possible.
+
+## Contributor code of conduct
+
+As contributors and maintainers of this project, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
+
+We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, age, or religion.
+
+Examples of unacceptable behavior by participants include the use of sexual language or imagery, derogatory comments or personal attacks, trolling, public or private harassment, insults, or other unprofessional conduct.
+
+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. Project maintainers who do not follow the Code of Conduct may be removed from the project team.
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or contacting one or more of the project maintainers.
+
+This code of conduct is adapted from the [Contributor Covenant](http://contributor-covenant.org/), version 1.0.0, available at http://contributor-covenant.org/version/1/0/0/
+
+
+
+
+
+# Additional resources
+
+
+* [Development environment for Ubuntu 16.04.](development-environment-ubuntu)
+* [Development environment for Mac OS X](development-environment-osx)
+
+* [Developing Plugins](create-openproject-plugin)
+* [Running Tests](running-tests)
+* [API Documentation](/api/)
+* [Report a Bug](report-a-bug)

docs/development/accessibility-checklist.md

@@ -1,79 +0,0 @@
-# Accessibility Checklist
-
-Web sites should be:
-
-* Perceivable
-* Operable
-* Understandable
-* Robust
-
-## 1. Perceivable - Using senses for web content (sight, hearing and/or touch)
-
-### 1.1. Graphics
-* All images, form image buttons, and image map hot spots have appropriate, equivalent alternative text.
-  * Every image must have an alt attribute.
-* Images that do not convey content, are decorative, or contain content that is already conveyed in text are given null alt text (alt="") or implemented as CSS backgrounds. All linked images have descriptive alternative text.
-* Background images do not contain information (e.g. text displayed in image (without label))
-* Form buttons have a descriptive value.
-* Form inputs have associated text labels.
-* When audio information is used, a text alternative is supplied
-* When video information is used, an audio description / alternative text is supplied
-
-### 1.2. Relations / Context
-* The reading and navigation order (determined by code order) is logical and intuitive.
-* Instructions do not rely upon shape, size, or visual location (e.g., "Click the square icon to continue" or "Instructions are in the right-hand column").
-* Color is not used as the sole method of conveying content or distinguishing visual elements.
-* The contrast is sufficient
-  * Text and images of text have a contrast ratio of at least 7:1.
-  * Large text (over 18 point or 14 point bold) has a contrast ratio of at least 4.5:1
-* The page is readable and functional when the text size is doubled.
-* If the same visual presentation can be made using text alone, an image is not used to present that text.
-
-## 2. Operable - Interface forms, controls, and navigation are operable
-
-### 2.1. Keyboard usability
-* All page functionality is available using the keyboard, unless the functionality cannot be accomplished in any known way using a keyboard (e.g., free hand drawing).
-* Page-specified shortcut keys and accesskeys (accesskey should typically be avoided) do not conflict with existing browser and screen reader shortcuts.
-* Keyboard focus is never locked or trapped at one particular page element. The user can navigate to and from all navigable page elements using only a keyboard.
-* All page functionality is available using the keyboard.
-
-### 2.2. Enough time
-* If a page or application has a time limit, the user is given options to turn off, adjust, or extend that time limit.
-* The content and functionality has no time limits or constraints.
-* If an authentication session expires, the user can re-authenticate and continue the activity without losing any data from the current page.
-
-### 2.3. Navigation
-* The web page has a descriptive and informative page title.
-* The navigation order of links, form elements, etc. is logical and intuitive.
-* Page headings and labels for form and interactive controls are informative.
-* Text fields and labels are connected.
-* It is visually apparent which page element has the current keyboard focus (i.e., as you tab through the page, you can see where you are).
-* Layout tables do not contain any table markup.
-* If a web page is part of a sequence of pages or within a complex site structure, an indication of the current page location is provided, for example, through breadcrumbs or specifying the current step in a sequence (e.g., "Step 2 of 5 - Shipping Address").
-* The purpose of each link (or form image button or image map hotspot) can be determined from the link text alone, or from the link text and its context (e.g., surrounding paragraph, list item, table cell, or table headers).
-
-## 3. Understandable - Content and interface are understandable
-
-### 3.1. Texts
-* The language of the page is identified using the HTML lang attribute (`<html lang="en">`, for example).
-* Words that may be ambiguous, unknown, or used in a very specific way are defined through adjacent text, a definition list, a glossary, or other suitable method.
-
-### 3.2. Predictable
-* When a page element receives focus, it does not result in a substantial change to the page, the spawning of a pop-up window, an additional change of keyboard focus, or any other change that could confuse or disorient the user.
-* Navigation links that are repeated on web pages do not change order when navigating through the site.
-
-### 3.3. Errors and help
-* Required form elements or form elements that require a specific format, value, or length provide this information within the element's label.
-* Required fields are clearly marked.
-* Help and documents are available.
-
-## 4. Robust - Content can be used reliably by a wide variety of user agents, including assistive technologies
-* Markup is used in a way that facilitates accessibility. This includes following the HTML/XHTML specifications and using forms, form labels, frame titles, etc. appropriately.
-
-## 5. Additional information
-* [WCAG checklist](http://webaim.org/standards/wcag/checklist) (English)
-* [BITV checklist](http://www.wob11.de/checklisten.html) (German)
-
-Screen reader used for accessibility tests (DTAG):
-
-* JAWS 18 (with Chrome (latest version), German language settings, activated accessibility mode)

docs/development/code-review-guidelines.md

@@ -1,69 +0,0 @@
-# Code review guidelines
-
-## Correctness
-
-*As a reviewer, your job is not to make sure that the code is what you would have written – because it will not be. Your job as a reviewer of a piece of code is to make sure that the code as written by its author is correct.*
-
-## Coding style
-
-We try to adhere to the [Ruby community styleguide](https://github.com/bbatsov/ruby-style-guide). At some point we will have to make decisions about some rules that are not clear or defined within that styleguide. In that case, we should either fork it or note all decisions here.
-
-Most of our code does not yet adhere to this styleguide, but we want all new code to adhere to it. You do not have to improve existing code when making changes, but we encourage it. If you do, please do all improvements in a separate commit from the actual change, so the improvements do not hide your actual code changes in a diff.
-
-Before committing, please run your new code through [Rubocop](https://github.com/bbatsov/rubocop). It detects deviations from a lot of things in the style guide and things that are bad practice in general. You obviously do not have to fix issues with existing code. There is a [list of editor plugins](https://github.com/bbatsov/rubocop#editor-integration) in the Rubocop readme.
-
-When reviewing code and you think the author has not run the code through Rubocop, please ask them to.
-
-## Commit messages
-
-- First line: less than 72 characters, this is when GitHub shows ‘…’
-- Blank line
-- Detailed description of the change, wrapped to 72 characters so the text is readable in git log
-
-See the [Git Book](http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines).
-
-## Testing
-
-- All tests must be green on continuous integration
-- Appropriate unit and integration tests, e.g. test application logic via rspec tests and its integration with the user interface via Cucumber tests
-- Test JavaScript code, e.g. via Jasmine or Selenium/Cucumber, but: Cucumber tests that do not test JavaScript must not have the @javascript tag, otherwise they run slower
-- Look for sufficient coverage of both Ruby and JavaScript code. CI will provide at least Ruby line coverage information at some point in the future
-- Forms: besides testing for success response, also test whether values are actually saved, e.g. read form or look into database
-- Bugfixes: must contain a test which detects the bug they fix to prevent regressions
-- Translations: Never use a specific translation string in a test. We might want to change them in the future and do not want to fix tests when we do.
-
-## Security
-
-Every developer and reviewer should read the Rails Security Guide.
-
-[Rails Security Guide](http://guides.rubyonrails.org/security.html)
-
-## Changelog
-
-- All changes made to the OpenProject software are managed and documented via work packages in the [OpenProject project](https://community.openproject.org/projects/openproject/).
-- The [Roadmap view](https://www.openproject.org/projects/openproject/roadmap) gives a corresponding overview.
-- To prevent inconsistencies and avoid redundant work there is no additional change log in the source code.
-
-## Other
-
-- For external contributions: Check whether the author has signed a Contributor License Agreement and kindly ask for it if not
-- Copyright notice: When new files are added, make sure they contain the OpenProject copyright notice (copy from any file in OpenProject)
-- Adding Gems: When adding gems, make sure not only the Gemfile is updated, but also the Gemfile.lock
-- No trailing whitespace
-- [Single newline at the end of a file](http://stackoverflow.com/questions/729692/why-should-files-end-with-a-newline).
-
-## Readability
-
-The reviewer should understand the code without explanations outside the code.
-
-*There is never anything wrong with just saying “Yup, looks good”. If you constantly go hunting to try to find something to criticize, then all that you accomplish is to wreck your own credibility.*
-
-*You should not rush through a code review – but also, you need to do it promptly. Your coworkers are waiting for you.*
-
-## Citations
-
-http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/
-
-http://beust.com/weblog/2006/06/22/why-code-reviews-are-good-for-you/
-
-https://developer.mozilla.org/en/Code_Review_FAQ

docs/development/create-omniauth-plugin.md

@@ -1,122 +0,0 @@
-# Create an OmniAuth plugin
-
-The OpenProject core integrates OmniAuth. This means that OmniAuth providers can be used to authenticate OpenProject users. For the time being this is not possible for existing users but only for new users who register using that particular provider.
-
-This page describes how to create an OpenProject plugin to authenticate users via an Omniauth strategy.
-
-## Warning
-
-This howto is in a preliminary state and explains a low-level way to create an OmniAuth authentication plugin for OpenProject. We will provide a more high-level API and update this howto soon.
-
-## OpenID Connect
-
-There is a bare minimum [plugin](https://github.com/machisuji/openproject-mock_auth) implementing a mock strategy for OpenProject using the provided OmniAuth infrastructure. You can refer to this plugin and compare to see how things can be done.
-
-## Terminology
-
-### Strategy
-
-An OmniAuth strategy implements a certain way of authentication. Examples for this are LDAP, OAuth and OpenID Connect strategies.
-
-### Provider
-
-An OmniAuth provider uses an OmniAuth strategy in order to authenticate a user against a certain service.
-For instance there can be two providers that both use the OpenID Connect strategy but for different services.
-
-## To do
-
-Any authentication plugin has to do at least the following things:
-
-1. Create plugin settings (e.g. for server-side secrets) if necessary
-2. Register its authentication provider(s) with OmniAuth
-3. Render a sign-in link for each provider on the login page and the login drop down menu
-
-## Authentication Plugin How-to
-
-In the following section we will go through the basic steps required to create an authentication plugin for OpenProject.
-
-### Generate a plugin
-
-First off you can use the [plugin generator](https://github.com/opf/openproject-plugins) to create a basic plugin to base yours on.
-How to do that is described [here](https://www.openproject.org/development/create-openproject-plugin/). In short it’s the following command:
-
-```bash
-# in OpenProject directory
-rails generate open_project:plugin my_auth_plugin path/to/where/you/want/to/have/it
-```
-
-Let’s assume that the plugin you generated is called `openproject-my_auth_plugin`.
-
-### Implement the strategy
-
-This is specific to your plugin. There may already be a gem implementing a strategy for the service you want to use.
-In that case you can skip this step and use an existing gem. Just google ‘omniauth <service>’ and chances are that you will find one.
-E.g. for twitter ‘omniauth twitter’ will lead you to [this](https://github.com/arunagw/omniauth-twitter) quickly.
-
-### Register required settings
-
-If you want to use settings for your plugin in order to configure your authentication provider you will have to register them in `lib/open_project/my_auth_plugin/engine.rb` by adding them to the already generated plugin registration call like this:
-
-```
-register 'openproject-my_auth_plugin',
-  :author_url => 'Hans Wurst',
-  :requires_openproject => '>= 3.1.0',
-  :settings => { 'default' => { 'auth_server_address' => {'192.168.178.42'} } }
-```
-
-You can access your plugin’s settings like this:
-
-```
-server_addr = Setting.plugin_openproject_my_auth_plugin["auth_server_address"]
-```
-
-### Register the provider(s)
-
-For this you can use the [openproject-auth_plugins](https://github.com/opf/openproject-auth_plugins) plugin, which provides you with an easy way to integrate a new authentication plugin into OpenProject.
-As described in the plugin’s readme file you just add the following bit to the class body of Engine:
-
-```ruby
-register_auth_providers do
-  strategy :my_auth_plugin_strategy do
-    [
-      {
-        name: 'my_provider',
-        display_name: 'Optional Label', # (optional) provider's name as shown in OpenProject
-        icon: 'my_auth_plugin/optional_provider_icon.png', # (optional) provider icon
-        # example options depending on your strategy:
-        host: Setting.plugin_openproject_my_auth_plugin["auth_server_address"]
-      }
-    ]
-  end
-end
-```
-
-OmniAuth will try to look up a strategy based on the passed symbol `:my_auth_plugin_strategy`, meaning that in this case it would expect a strategy class to be defined as follows:
-
-```ruby
-module OmniAuth
-  module Strategies
-    class MyAuthPluginStrategy
-      # ...
-```
-
-You can register any number of providers using different strategies (or the same) with different options.
-For instance you could configure two OpenID Connect providers using the same strategy (OpenIDConnect) but with different options according to the service to be used (e.g. Google vs Microsoft).
-
-### Add your plugin to Gemfile.plugins
-
-All that’s that left to do is declaring your plugin in the file `Gemfile.plugins` in your OpenProject application’s root directory.
-If you haven’t published it as a gem yet you can also use a local copy:
-
-```
-  gem "openproject-auth_plugins", :git => 'https://github.com/opf/openproject-auth_plugins.git', :branch => 'dev'
-  gem 'openproject-my_auth_plugin', :path => 'plugins/openproject-my_auth_plugin'
-```
-
-Also don’t forget to include the `openproject-auth_plugins` as a dependency in your plugin’s gem specification (`openproject-my_auth_plugin.gemspec`).
-The first line in the snippet shown above is only necessary because the `openproject-auth_plugins` plugin itself has not been published as a gem yet.
-
-### Profit
-
-That’s it. Now users can authenticate using your own provider.
-

docs/development/create-openproject-plugin.md

@@ -1,166 +0,0 @@
-# Create an OpenProject plugin
-
-OpenProject plugins are special ruby gems. You may include them in your `Gemfile.plugins` file like you would do for any other gem. Fortunately, this gives us plugin version management and dependency resolution for free.
-
-## Generate the plugin
-
-You can generate a new plugin directly from OpenProject. Think of a good name and a place (in your filesystem) where the plugin should go. In this example, we have a `plugins` directory right next to the `openproject` directory. Then do
-
-```bash
-bundle exec rails generate open_project:plugin my_plugin ../plugins/
-```
-
-This generates the plugins `openproject-my_plugin` into the directory `../plugins/openproject-my_plugin`. The new plugin is a rails engine, which can be published as a gem.
-
-You may want to update the generated plugin's gemspec (`openproject-my_plugin.gemspec`).
-
-**Example Plugin**
-
-There is an [example plugin](https://github.com/opf/openproject-proto_plugin) which does some of the basic things (adding menu items, hooking into views, defining a project menu, etc.) and provides further info in its README.
-
-Instead of generating a new plugin you can also just clone the example plugin and adapt it.
-
-## Hook the new plugin into OpenProject
-
-To include the new plugin into OpenProject, we have to add it into `Gemfile.plugins` like any other OpenProject plugin. Add the following lines to `Gemfile.plugins`:
-
-```
-group :opf_plugins do
-  gem "openproject-my_plugin", :path => '../plugins/openproject-my_plugin'
-end
-```
-
-If there already is an `opf_plugins` group, just add the `gem` line to it.
-
-Once you've done that install it via
-
-```bash
-bundle install
-```
-
-## Start coding
-
-You may have a look at some existing OpenProject plugins to get inspiration. It is possible to add new routes, views, models, … and/or overwrite existing ones.
-
-Feel free to ask for help in our [Development Forum](https://community.openproject.org/projects/openproject/boards/7).
-
-## Steps to release a plugin
-
-The following steps are necessary to release a new plugin:
-
-### Code Review
-A code review should check the whole code and remove glitches like:
-
-- Inappropriate comments
-- Deactivated code
-- Minor cases of code smell
-
-### Resolve licensing and copyright issues
-
-1. Check the license and the copyright of the plugin to be released
-
- Usually, this should be GPLv3 and we are the copyright owner. However, some plugins might have additional authors or might originate from code with a different license. These issues have to be resolved first. Also check the years in the copyright. If you need to find all contributors of a repository including their contribution period use the following rake task:
- ```bash
-rake copyright:authors:show['../Path/to/repository/']
-```
-
-2. Add a copyright notice to all the source files
-
- There is a rake task in the core to perform this job. Use `rake copyright:update['path_to_plugin']` (e.g. `rake copyright:update['../plugins/openproject-global_roles']`) to add the copyright header in `doc/COPYRIGHT_short.md` to all relevant plugin files.
- If no such file exists, `doc/COPYRIGHT_short.md` from the core is used.
-
-3. Check for existence of `doc/COPYRIGHT.md` and `doc/GPL.txt` if referenced by the copyright notice.
-
-### Complete the readme file or add one if not existing
-
-There should be a file README.md containing:
-
-1. A description about what the plugin is actually doing
-2. Requirements to use the plugin
-3. Instructions how to install and uninstall a plugin
-4. Notes where to report bugs
-5. Notes where to contribute
-6. Credits
-
-If you’re unsure about if/who to give credit, you should take a look into the changelog:
-
-```bash
-git log --pretty=format:%aN | sort | uniq -c | sort -rn
-```
-
-For your convenience you may use the following rake task, that extracts all authors from a repository
-
-```bash
-rake copyright:authors:show['../Path/to/repository/']
-```
-
-7. Licensing information.
-It is probably best to use READMEs of already released plugins as a template.
-
-### Complete the gemspec
-
-1. Add the license to the gemspec of the plugin if not already there.
-2. Add any files that should be included to the gemspec (e.g. the `doc` folder, the `db` folder if there are any migrations, the `CHANGELOG.md`, and the `README.md`).
-3. Check authors and email point to the right authors.
-4. The homepage should be the homepage of the plugin.
-5. Check if summary and description are there.
-6. Check if all dependencies are listed (this might be difficult, I know): There should be a sentence in the README, that this is an OpenProject-Plugin and requires the core to run. Apart from that, state only dependencies that are not already present in core.
-7. While you are at it, also check if there is any wiring to core versions necessary in engine.rb; also check, that the url of the plugin is wired correctly.
-8. Push the version of the plugin, mostly by just removing any .preX specials at the end.
-9. Don’t forget to add a changelog entry.
-10. Commit everything.
-11. Also create a release tag (named ‘release/<version>’ for example ‘release/1.0.2′) to name the new version.
-12. Push the tag with `git push --tags`.
-
-### Publish the gem at Rubygems
-
-- `gem update --system`
-- Ensure gemspec fields are complete and version number is correct
-- `gem build <name>.gemspec`
-- `gem push <name>-<version>.gem`. This asks for your user/password
-- Go to https://rubygems.org, log in, go to the dashboard, click on the uploaded gem, click edit.  Set URLs, at least source code URL and Bug Tracker URL
-- You are done .
-- *Be careful when publishing a gem.Once it is published, it cannot be replaced in the same version*. It is only possible to take a version out of the index and publish a new version.
-
-### Create public visibility
-
-1. Make the github repository public.
-2. Make the plugin project public.
-  Do a little cleanup work first by removing modules not needed. Currently,
-  Activity, Issue Tracking, Time Tracking, Forums, and Backlogs are default.
-  Also, the My Project Page should only show Project Description and Tickets blocks.
-3. Create a news article about the newly released plugin and its features.
-4. Twitter with a link to the news article.
-5. If the plugin is referenced in our feature tour, add a download link to the plugin in the feature tour
-6. Add the newly released plugin to the list of [released plugins](https://www.openproject.org/download/install-plugins/openproject-plugins/).
-
-
-# Frontend plugins [WIP]
-
-Plugins that extend the frontend application may be packaged as **npm modules**.
-These plugins must contain a `package.json` in the root directory of the plugin.
-
-Plugins are responsible for loading their own assets, including additional
-images, styles and I18n translations.
-
-Translations are processed by I18n.js through Rails and will be picked up from `config/locales/js-<locale>.js`.
-
-Pure frontend plugins are currently not possible without modifications to the OpenProject core `package.json`.
-We instead recommend to create a hybrid gem plugin instead (see below).
-
-## Hybrid plugins
-
-Plugins that extend both the Rails and frontend applications are possible. They
-must contain both a `Gem::Specification` and `package.json`.
-
-_CAVEAT: npm dependencies for hybrid plugins are not yet resolved._
-
-**To use a hybrid plugin:**
-
-  * declare the dependency in `Gemfile.plugins` within the `:opf_plugins` group
-    using the Bundler DSL.
-
-  * then run `bundle install`.
-
-Provided Ruby Bundler is aware of these plugins, Webpack (our node-based build pipeline)
-will bundle their assets.

docs/development/development-environment-osx.md

@@ -1,242 +0,0 @@
-# OpenProject development Setup on Mac OS X
-
-To develop OpenProject a setup similar to that for using OpenProject in production is needed.
-
-This guide assumes that you have a Mac OS Xinstallation installation with administrative rights. 
-
-**Please note**: This guide is NOT suitable for a production setup, but only for developing with it!
-
-If you find any bugs or you have any recommendations for improving this tutorial, please, feel free to send a pull request or comment in the [OpenProject forums](https://community.openproject.org/projects/openproject/boards).
-
-# Prepare your environment
-
-We'll use [homebrew](https://brew.sh/) to install most of our requirements. Please install that first using the guide on their homepage.
-
-## Install Ruby 2.6.
-
-Use [rbenv](https://github.com/rbenv/rbenv) and [ruby-build](https://github.com/rbenv/ruby-build#readme) to install Ruby 2.6.1.
-**Install rbenv and ruby-build**
-
-rbenv is a ruby version manager that lets you quickly switch between ruby versions.
-ruby-build is an addon to rbenv that installs ruby versions.
-
-```bash
-# Install 
-$ brew install rbenv ruby-build
-# Initialize rbenv
-$ rbenv init
-```
-
-**Installing ruby-2.6**
-
-With both installed, we can now install the actual ruby version 2.6. You can check available ruby versions with `rbenv install --list`.
-At the time of this writing, the latest stable version is `2.6.1`, which we also require.
-
-We suggest you install the version we require in the [Gemfile](https://github.com/opf/openproject/blob/dev/Gemfile). Search for the `ruby '~> X.Y.Z'` line
-and install that version.
-
-```bash
-# Install the required version as read from the Gemfile
-[dev@ubuntu]# rbenv install 2.6.1
-```
-
-This might take a while depending on whether ruby is built from source. After it is complete, you need to tell rbenv to globally activate this version
-
-```bash
-[dev@ubuntu]# rbenv global 2.6.1
-```
-
-You also need to install [bundler](https://github.com/bundler/bundler/), the ruby gem bundler.
-
-```bash
-[dev@ubuntu]# gem install bundler
-```
-
-## Setup PostgreSQL database
-
-Next, install a PostgreSQL database.
-
-```bash
-# Install postgres database
-$ brew install postgres
-
-# Create the database instance
-$ postgres -D /usr/local/var/postgres
-```
-
-Then, create the OpenProject database user and accompanied database.
-
-```bash
-$ createuser -d -P openproject
-```
-You will be prompted for a password, for the remainder of these instructions, we assume its `openproject-dev-password`.
-
-Now, create the database `openproject_dev` and `openproject_test` owned by the previously created user.
-
-```bash
-$ createdb -O openproject openproject_dev
-$ createdb -O openproject openproject_test
-```
-
-## Install Node.js
-
-We will install the latest LTS version of Node.js via [nodenv](https://github.com/nodenv/nodenv). This is basically the same steps as for rbenv:
-
-**Install nodenv and node-build**
-
-```bash
-# Install
-$ brew install nodenv node-build
-# Initialize nodenv
-$ nodenv init
-```
-
-**Install latest LTS node version**
-
-You can find the latest LTS version here: https://nodejs.org/en/download/
-Currently, this is v10.15.3. Install and activate it with:
-
-```bash
-[dev@ubuntu]# nodenv install 10.15.3
-[dev@ubuntu]# nodenv global 10.15.3
-```
-
-## Verify your installation
-
-You should now have an active ruby and node installation. Verify that it works with these commands.
-
-```bash
-$ ruby --version
-ruby 2.6.1p33 (2019-01-30 revision 66950) [x86_64-darwin16]
-
-$ bundler --version
-Bundler version 2.0.1
-
-$ npm --version
-6.7.0
-```
-
-# Install OpenProject
-
-```bash
-# Download the repository
-[dev@ubuntu]# git clone https://github.com/opf/openproject.git
-[dev@ubuntu]# cd openproject
-
-# Install gem dependencies
-# If you get errors here, you're likely missing a development dependency for your distribution
-[dev@ubuntu]# bundle install
-
-# Install node_modules
-[dev@ubuntu]# npm install
-```
-
-Note that we have checked out the `dev` branch of the OpenProject repository. Development in OpenProject happens in the `dev` branch (there is no `master` branch).
-So, if you want to develop a feature, create a feature branch from a current `dev` branch.
-
-## Configure OpenProject
-
-Create and configure the database configuration file in `config/database.yml` (relative to the openproject-directory.
-
-```bash
-[dev@debian]# vim config/database.yml
-```
-
-Now edit the `config/database.yml` file and insert your database credentials.
-It should look like this (just with your database name, username, and password):
-
-```
-default: &default
-  adapter: postgresql
-  encoding: unicode
-  host: localhost
-  username: openproject
-  password: openproject-dev-password
-
-development:
-  <<: *default
-  database: openproject_dev
-
-test:
-  <<: *default
-  database: openproject_test
-```
-
-## Finish the Installation of OpenProject
-
-Now, run the following tasks to migrate and seed the dev database, and prepare the test setup for running tests locally.
-
-```bash
-[dev@ubuntu]# export RAILS_ENV=development
-[dev@ubuntu]# ./bin/rake db:migrate db:seed db:test:prepare
-```
-
-
-## Run OpenProject through foreman
-
-You can run all required workers of OpenProject through `foreman`, which combines them in a single tab. This is useful for starting out,
-however most developers end up running the tasks in separate shells for better understanding of the log output, since foreman will combine all of them.
-
-```bash
-[dev@ubuntu]# gem install foreman
-[dev@ubuntu]# foreman start -f Procfile.dev
-```
-The application will be available at `http://127.0.0.1:5000`. To customize bind address and port copy the `.env.sample` provided in the root of this
-project as `.env` and [configure values][foreman-env] as required.
-
-By default a worker process will also be started. In development asynchronous execution of long-running background tasks (sending emails, copying projects,
-etc.) may be of limited use. To disable the worker process:
-
-echo "concurrency: web=1,assets=1,worker=0" >> .foreman
-
-For more information refer to Foreman documentation section on [default options][foreman-defaults].
-
-You can access the application with the admin-account having the following credentials:
-
-    Username: admin
-    Password: admin
-
-## Run OpenProject manually
-
-To run OpenProject manually, you need to run the rails server and the webpack frontend bundler to:
-
-**Rails web server**
-
-```bash
-[dev@ubuntu]# RAILS_ENV=development ./bin/rails server
-```
-
-This will start the development server on port `3000` by default.
-
-**Webpack bundling**
-
-```bash
-[dev@ubuntu]# RAILS_ENV=development npm run webpack-watch
-```
-
-This will watch for any changes within the `frontend/` and compile the application javascript bundle on demand. You will need to watch this tab for the compilation output,
-should you be working on the TypeScript / angular.js frontend part.
-
-
-## Start Coding
-
-Please have a look at [our development guidelines](https://www.openproject.org/open-source/code-contributions/) for tips and guides on how to start coding. We have advice on how to get your changes back into the OpenProject core as smooth as possible.
-Also, take a look at the `doc` directory in our sources, especially the [how to run tests](https://github.com/opf/openproject/blob/dev/docs/development/running-tests.md) documentation (we like to have automated tests for every new developed feature).
-
-## Troubleshooting
-
-The OpenProject logfile can be found here:
-
-```
-/home/openproject/openproject/log/development.log
-```
-
-If an error occurs, it should be logged there (as well as in the output to STDOUT/STDERR of the rails server process).
-
-## Questions, Comments, and Feedback
-
-If you have any further questions, comments, feedback, or an idea to enhance this guide, please tell us at the appropriate community.openproject.org [forum](https://community.openproject.org/projects/openproject/boards/9).
-[Follow OpenProject on twitter](https://twitter.com/openproject), and follow [the news](https://www.openproject.org/blog) to stay up to date.
-
-[foreman-defaults]:http://ddollar.github.io/foreman/#DEFAULT-OPTIONS
-[foreman-env]:http://ddollar.github.io/foreman/#ENVIRONMENT

docs/development/development-environment-ubuntu.md

@@ -1,280 +0,0 @@
-# OpenProject development Setup on Debian / Ubuntu
-
-To develop OpenProject a setup similar to that for using OpenProject in production is needed.
-
-This guide assumes that you have a Ubuntu 18.04 installation with administrative rights. This guide will work
-analogous with all other distributions, but may require slight changes in the required packages. _Please, help us to extend this guide with information on other distributions should there be required changes._
-
-OpenProject will be installed with a PostgreSQL database. Support for MySQL was removed from `dev` branch before release of version 10.
-
-**Please note**: This guide is NOT suitable for a production setup, but only for developing with it!
-
-If you find any bugs or you have any recommendations for improving this tutorial, please, feel free to send a pull request or comment in the [OpenProject forums](https://community.openproject.org/projects/openproject/boards).
-
-# Prepare your environment
-
-We need an active Ruby and Node JS environment to run OpenProject. To this end, we need some packages installed on the system.o
-
-```bash
-[dev@ubuntu]# sudo apt-get update
-[dev@ubuntu]# sudo apt-get install git curl build-essential zlib1g-dev libyaml-dev libssl-dev libmysqlclient-dev libpq-dev  libreadline-dev libffi6
-```
-
-## Install Ruby 2.6.
-
-Use [rbenv](https://github.com/rbenv/rbenv) and [ruby-build](https://github.com/rbenv/ruby-build#readme) to install Ruby 2.6.
-
-
-**Install rbenv**
-
-rbenv is a ruby version manager that lets you quickly switch between ruby versions.
-
-```bash
-# Install rbenv locally for the dev user
-[dev@ubuntu]# git clone https://github.com/rbenv/rbenv.git ~/.rbenv
-# Optional: Compile bash extensions 
-[dev@ubuntu]# cd ~/.rbenv && src/configure && make -C src
-# Add rbenv to the shell's $PATH.
-[dev@ubuntu]# echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
-
-# Run rbenv-init and follow the instructions to initialize rbenv on any shell
-[dev@ubuntu]# ~/.rbenv/bin/rbenv init
-# Source bashrc
-[dev@ubuntu]# source ~/.bashrc
-```
-
-**Installing ruby-build**
-
-ruby-build is an addon to rbenv that installs ruby versions
-
-```bash
-[dev@ubuntu]# git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build
-```
-
-**Installing ruby-2.6**
-
-With both installed, we can now install the actual ruby version 2.6. You can check available ruby versions with `rbenv install --list`.
-At the time of this writing, the latest stable version is `2.6.5`, which we also require.
-
-We suggest you install the version we require in the [Gemfile](https://github.com/opf/openproject/blob/dev/Gemfile). Search for the `ruby '~> X.Y.Z'` line
-and install that version.
-
-```bash
-# Install the required version as read from the Gemfile
-[dev@ubuntu]# rbenv install 2.6.5
-```
-
-This might take a while depending on whether ruby is built from source. After it is complete, you need to tell rbenv to globally activate this version
-
-```bash
-[dev@ubuntu]# rbenv global 2.6.5
-```
-
-You also need to install [bundler](https://github.com/bundler/bundler/), the ruby gem bundler.
-
-```bash
-[dev@ubuntu]# gem install bundler
-```
-
-## Setup PostgreSQL database
-
-Next, install a PostgreSQL database.
-
-(Looks counter-intuitive but for the time being we also need the `mysql-client`. It is required for migration from MySQL to PostgreSQL code.)
-
-```bash
-[dev@debian]# sudo apt-get install postgresql postgresql-client mysql-client
-```
-
-Create the OpenProject database user and accompanied database.
-
-```bash
-[dev@ubuntu]# sudo su postgres
-[postgres@ubuntu]# createuser -d -P openproject
-```
-You will be prompted for a password, for the remainder of these instructions, we assume its `openproject-dev-password`.
-
-Now, create the database `openproject_dev` and `openproject_test` owned by the previously created user.
-
-```bash
-[postgres@ubuntu]# createdb -O openproject openproject_dev
-[postgres@ubuntu]# createdb -O openproject openproject_test
-
-# Exit the shell as postgres
-[postgres@ubuntu]# exit
-```
-
-## Install Node.js
-
-We will install the latest LTS version of Node.js via [nodenv](https://github.com/nodenv/nodenv). This is basically the same steps as for rbenv:
-
-**Install nodenv**
-
-```bash
-# Install nodenv
-[dev@ubuntu]# git clone https://github.com/nodenv/nodenv.git ~/.nodenv
-# Optional: Install bash extensions
-[dev@ubuntu]# cd ~/.nodenv && src/configure && make -C src
-# Add nodenv to the shell's $PATH.
-[dev@ubuntu]# echo 'export PATH="$HOME/.nodenv/bin:$PATH"' >> ~/.bashrc
-
-# Run nodenv init and follow the instructions to initialize nodenv on any shell
-[dev@ubuntu]# ~/.nodenv/bin/nodenv init
-# Source bashrc
-[dev@ubuntu]# source ~/.bashrc
-```
-
-**Install node-build**
-
-```bash
-[dev@ubuntu]# git clone https://github.com/nodenv/node-build.git $(nodenv root)/plugins/node-build
-```
-
-**Install latest LTS node version**
-
-You can find the latest LTS version here: https://nodejs.org/en/download/
-Currently, this is v10.15.3 Install and activate it with:
-
-```bash
-[dev@ubuntu]# nodenv install 10.15.3
-[dev@ubuntu]# nodenv global 10.15.3
-```
-
-## Verify your installation
-
-You should now have an active ruby and node installation. Verify that it works with these commands.
-
-```bash
-[dev@ubuntu]# ruby --version
-ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-linux]
-
-[dev@ubuntu]# bundler --version
-Bundler version 2.0.1
-
-[dev@ubuntu]# npm --version
-6.7.0
-```
-
-# Install OpenProject
-
-```bash
-# Download the repository
-[dev@ubuntu]# git clone https://github.com/opf/openproject.git
-[dev@ubuntu]# cd openproject
-
-# Install gem dependencies
-# If you get errors here, you're likely missing a development dependency for your distribution
-[dev@ubuntu]# bundle install
-
-# Install node_modules
-[dev@ubuntu]# npm install
-```
-
-Note that we have checked out the `dev` branch of the OpenProject repository. Development in OpenProject happens in the `dev` branch (there is no `master` branch).
-So, if you want to develop a feature, create a feature branch from a current `dev` branch.
-
-## Configure OpenProject
-
-Create and configure the database configuration file in `config/database.yml` (relative to the openproject-directory.
-
-```bash
-[dev@debian]# vim config/database.yml
-```
-
-Now edit the `config/database.yml` file and insert your database credentials.
-It should look like this (just with your database name, username, and password):
-
-```
-default: &default
-  adapter: postgresql
-  encoding: unicode
-  host: localhost
-  username: openproject
-  password: openproject-dev-password
-
-development:
-  <<: *default
-  database: openproject_dev
-
-test:
-  <<: *default
-  database: openproject_test
-```
-
-## Finish the Installation of OpenProject
-
-Now, run the following tasks to migrate and seed the dev database, and prepare the test setup for running tests locally.
-
-```bash
-[dev@ubuntu]# export RAILS_ENV=development
-[dev@ubuntu]# ./bin/rake db:migrate db:seed db:test:prepare
-```
-
-
-## Run OpenProject through foreman
-
-You can run all required workers of OpenProject through `foreman`, which combines them in a single tab. This is useful for starting out,
-however most developers end up running the tasks in separate shells for better understanding of the log output, since foreman will combine all of them.
-
-```bash
-[dev@ubuntu]# gem install foreman
-[dev@ubuntu]# foreman start -f Procfile.dev
-```
-The application will be available at `http://127.0.0.1:5000`. To customize bind address and port copy the `.env.sample` provided in the root of this
-project as `.env` and [configure values][foreman-env] as required.
-
-By default a worker process will also be started. In development asynchronous execution of long-running background tasks (sending emails, copying projects,
-etc.) may be of limited use. To disable the worker process:
-
-echo "concurrency: web=1,assets=1,worker=0" >> .foreman
-
-For more information refer to Foreman documentation section on [default options][foreman-defaults].
-
-You can access the application with the admin-account having the following credentials:
-
-    Username: admin
-    Password: admin
-
-## Run OpenProject manually
-
-To run OpenProject manually, you need to run the rails server and the webpack frontend bundler to:
-
-**Rails web server**
-
-```bash
-[dev@ubuntu]# RAILS_ENV=development ./bin/rails server
-```
-
-This will start the development server on port `3000` by default.
-
-**Angular frontend**
-
-To run the frontend server, please run
-
-```bash
-[dev@ubuntu]# RAILS_ENV=development npm run serve
-```
-
-This will watch for any changes within the `frontend/` and compile the application javascript bundle on demand. You will need to watch this tab for the compilation output,
-should you be working on the TypeScript / Angular frontend part.
-
-You can then access the application either through `localhost:3000` (Rails server) or through the frontend proxied `http://localhost:4200`, which will provide hot reloading for changed frontend code.
-
-## Start Coding
-
-Please have a look at [our development guidelines](https://www.openproject.org/open-source/code-contributions/) for tips and guides on how to start coding. We have advice on how to get your changes back into the OpenProject core as smooth as possible.
-Also, take a look at the `doc` directory in our sources, especially the [how to run tests](https://github.com/opf/openproject/blob/dev/docs/development/running-tests.md) documentation (we like to have automated tests for every new developed feature).
-
-## Troubleshooting
-
-The OpenProject logfile can be found in `log/development.log`.
-
-If an error occurs, it should be logged there (as well as in the output to STDOUT/STDERR of the rails server process).
-
-## Questions, Comments, and Feedback
-
-If you have any further questions, comments, feedback, or an idea to enhance this guide, please tell us at the appropriate community.openproject.org [forum](https://community.openproject.org/projects/openproject/boards/9).
-[Follow OpenProject on twitter](https://twitter.com/openproject), and follow [the news](https://www.openproject.org/blog) to stay up to date.
-
-[foreman-defaults]:http://ddollar.github.io/foreman/#DEFAULT-OPTIONS
-[foreman-env]:http://ddollar.github.io/foreman/#ENVIRONMENT

docs/development/quick-start.md

@@ -1,47 +0,0 @@
-# Quick start for developers
-
-
-Detailed installation instructions for different platforms are located on the [OpenProject website](https://www.openproject.org/download/).
-
-You can find information on configuring OpenProject in [`config/CONFIGURATION.md`](CONFIGURATION.md).
-
-## Fast install (Docker version)
-
-### Prerequisites
-
-* Git
-* [Docker Engine](https://docs.docker.com/engine/installation/)
-* [Docker Compose](https://docs.docker.com/compose/)
-
-### Building and running
-
-1. Build the image (this will take some time)
-
-        docker-compose build
-
-2. Start and setup the database
-
-        docker-compose up -d db
-        cp config/database.docker.yml config/database.yml
-        docker-compose run web rake db:create db:migrate db:seed
-
-3. Start the other processes
-
-        docker-compose up
-
-Assets should be automatically recompiled anytime you make a change, and your
-ruby code should also be reloaded when you change a file locally.
-
-You can run arbitrary commands in the context of the application by using
-`docker-compose run`. For instance:
-
-    docker-compose run web rake db:migrate
-    docker-compose run web rails c
-    ...
-
-## Manual development environment
-
-Please see the following guides for detailed instructions on how to get started developing for OpenProject.
-
-- [Development environment for Ubuntu 16.04.](./development-environment-ubuntu.md)
-- [Development environment for Mac OS X](./development-environment-osx.md)

docs/development/release-process.md

@@ -1,71 +0,0 @@
-# Release process
-
-This page summarizes all relevant information about the release process.
-
-## Distribution
-
-* The OpenProject software and plugins developed by the OpenProject Foundation itself are maintained on [Github](https://github.com/opf).
-* Releases exist as snapshots (tags) of different development trees (branches) at a specific point in time.
-
-**Explanatory note:**
-
-Due to the fact that the OpenProject Foundation provides releases in the form of the source code itself all release types are fully self-contained. This means that a hotfix release for example does not only include parts of the software which are going to be fixed by the hotfix release itself. Instead it includes the latest stable release and the fixes it was built for (i.e. we don't release patches separately).
-
-## Release notes
-
-You can find the release notes for major stable releases [here](https://www.openproject.org/release-notes/).
-
-## Release cycles
-
-### Stable release
-
-* The OpenProject Foundation releases four Stable Releases per year.
-* The Release plan is tracked via the [project timeline](https://community.openproject.com/projects/openproject/timelines/36).
-
-### Hotfix release
-
-* Hotfix releases follow no predefined release plan in the release process.
-* As soon as a bug is declared to be critical and there has to be an emergency update to currently supported stable releases a hotfix release will be prepared. However, the criteria which define a bug to be critical depend on several conditions which make it almost impossible to give a clear definition of what constitutes a critical bug.
-
-## Versioning and tags
-
-### General considerations
-
-* See the [Roadmap](https://community.openproject.com/projects/openproject/roadmap) for the overview of the current stable release version and  upcoming stable releases
-* Releases are defined by a version (number) which exists as tags on predefined development trees (see the branches on [github](https://github.com/opf/openproject/releases)).
-* All plugins maintained by the OpenProject Foundation have the same release cycle and the same version as the OpenProject software itself (typically called OpenProject core or just core).
-* The version of plugins indicate the compatibility with the core.
-* The OpenProject Foundation will ensure this via continuous integration testing.
-
-### Semantic versioning
-
-* OpenProject follows the idea of [Semantic Versioning](http://semver.org/).
-* Therefore the version is a composition of three digits in the format of e.g. 0.1.1 and can be summarised as followed:
-  * 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.
-
-Since the Stable Release 3.0.8 this idea only applies by considering the OpenProject core and all plugins maintained by the OpenProject Foundation as one piece of software.
-
-### Side Note: Keeping core and plugin versions in lockstep
-
-* Due to the fact that plugins inherit their version from the core of the OpenProject software and vice versa there are some implications to mention.
-* Since this only applies to the versions starting at version 3.0.8 (core) there are plugins which have surpassed this version in the past. The most noticeable is the costs plugin which version was set back from version 5.0.4 to 3.0.8.
-* Furthermore it is likely that the version may change for a lot of plugins or the core itself, although the source code of these software parts did not change at all. The reason for that is the described inheritance of versions.
-
-### Branches and tags on Github
-
-* There are two important branches in regard to the release process:
-  * dev: development of future stable releases
-  * release/X.Y: currently supported stable release
-* Tags on these two branches refer either to sprint releases (dev) or stable respectively hotfix releases (release/X.Y).
-
-## Change history
-
-* All changes made to the OpenProject software are documented via work packages. The [Roadmap view](https://community.openproject.com/projects/openproject/roadmap) gives a corresponding overview.
-* To prevent inconsistencies and avoid redundant work there is there is no additional change log in the source code.
-
-## Support of releases
-
-* For the community edition only the current stable releases are maintained. The [Enterprise Edition](https://www.openproject.org/enterprise-edition) provides extended maintenance.
-* We recommended to update to a new stable release as soon as possible to have a supported version installed.

docs/development/report-a-bug.md

@@ -1,68 +0,0 @@
-# Report a bug
-
-If you find a bug please create a bug report.
-
-1. Login to the [OpenProject developer platform](https://community.openproject.com/login).
-2. Open the [bug form](https://community.openproject.com/projects/openproject/work_packages/new?type=1).
-3. Add a precise subject.
-3. Add a detailed description.
-4. Attach a file (optional).
-5. Press Create.
-
-
-# Information you should add to the bug description
-
-## Preconditions to reproduce the bug
-
-Prior to detailing which steps to take to reproduce the error, the necessary preconditions which have to be met should be stated.
-* Which browser did you use when you experienced the error?
-* Do you receive any error messages in the rails console or browser console when the error occurs? Please include the error message if applicable.
-
-Example:
-
-```
-* Forum exists
-* Forum messages exist with many replies
-```
-
-## Steps to reproduce the bug
-
-* The steps that led to the bug should be listed in the description in order to replicate the bug and determine the underlying problem.
-
-Example:
-
-```
-1. Go to forum
-2. Scroll to bottom of messages
-```
-
-## Actual behavior
-
-* The actual, erroneous behavior should be stated briefly and concisely.
-
-Example:
-
-```
-* Not possible to switch to next entry in pagination
-```
-
-## Expected behavior
-
-* If known, the expected behavior of the application should be described concisely.
-
-Example:
-
-```
-* Possible to switch to next pagination page
-```
-
-## Screenshots
-
-* If applicable, a screenshot should be added to the bug report in order to explain the bug visually.
-  * The unintended behavior should be marked in the screenshot (e.g. by using red color).
-* The screenshot can be attached as a file and can be integrated in the description with the following syntax: "!Name_of_screenshot.png!" (without quotation marks)
-(Notice: *Name_of_screenshot* should be replaced with the respective name of the file. The file ending (here: *.png*) has to be adjusted to the appropriate file type of the screenshot.)
-
-## Example of bug reporting
-
-![Report a bug: Bug example](https://www.openproject.org/wp-content/uploads/2019/10/Bug-report.png "Report a bug: Bug example")

docs/development/running-tests.md

@@ -1,286 +0,0 @@
-<!---- copyright
-OpenProject is an open source project management software.
-Copyright (C) 2012-2020 the OpenProject GmbH
-
-This program is free software; you can redistribute it and/or
-modify it under the terms of the GNU General Public License version 3.
-
-OpenProject is a fork of ChiliProject, which is a fork of Redmine. The copyright follows:
-Copyright (C) 2006-2013 Jean-Philippe Lang
-Copyright (C) 2010-2013 the ChiliProject Team
-
-This program is free software; you can redistribute it and/or
-modify it under the terms of the GNU General Public License
-as published by the Free Software Foundation; either version 2
-of the License, or (at your option) any later version.
-
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with this program; if not, write to the Free Software
-Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
-
-See docs/COPYRIGHT.rdoc for more details.
-
-++-->
-
-# Testing OpenProject
-
-OpenProject uses automated tests throughout the stack. Tests that are executed in the browser (npm frontend, rspec integration and cucumber tests) require to have Chrome installed.
-
-## Frontend tests
-
-To run JavaScript frontend tests, first ensure you have all necessary
-dependencies installed via npm (i.e. `npm install`).
-
-You can run all frontend tests with the standard npm command:
-
-    npm test
-    
-
-[For more information, check out the frontend guides](https://github.com/opf/openproject/blob/dev/frontend/doc/README.md).
-
-## Rails backend and integration tests
-
-### RSpec
-
-You can run the specs with the following commands:
-
-* `bundle exec rake spec:core` Run all core specs with a random seed
-* `bundle exec rake spec:legacy` Run all legacy specs with a random seed
-* `bundle exec rake spec:plugins` Run plugin specs with a random seed
-* `bundle exec rake spec:all` Run core and plugin specs with a random seed
-* `SPEC_OPTS="--seed 12935" bundle exec rake spec` Run the core specs with the seed 12935
-
-### Integration tests with Capybara
-
-We use Capybara for integration tests as rspec feature specs. They are automatically executed with Capybara when `js: true` is set.
-
-#### Selenium, Chrome
-
-For the javascript dependent integration tests, you have to install Chrome, to run them locally.
-
-Capybara uses Selenium to drive the browser and perform the actions we describe in each spec. Previously, we have used Firefox as the browser driven by Selenium.
-
-Due to flaky test results on Travis (`No output has been received in the last 10m0s`), we switched to using Chrome for the time being. Because most developers already employ Chrome while developing and Firefox ESR being another supported browser, we would have preferred to stick to Firefox for the tests and will try to do so as soon as test results become reproducible again.
-
-
-**Headless mode**
-
-Firefox tests through Selenium are run with Chrome as `--headless` by default. To override this and watch the Chrome instance set the ENV variable `OPENPROJECT_TESTING_NO_HEADLESS=1`.
-
-### Cucumber
-
-**Note:** *We do not write new cucumber features. The current plan is to move away from
-cucumber towards regular specs using Capybara. For the time being however, please keep the existing
-cucumber features green but write feature specs in Capybara for any code that is not already
-covered by cucumber.*
-
-The cucumber features can be run using rake. You can run the following
-rake tasks using the command `bundle exec rake <task>`.
-
-* `cucumber` Run core features
-* `cucumber:plugins` Run plugin features
-* `cucumber:all` Run core and plugin features
-* `cucumber:custom[features]`: Run single features or folders of features
-
-    Example: `cucumber:custom[features/issues/issue.feature]`
-    * When providing multiple features, the task name and arguments must
-      be enclosed in quotation marks.
-
-      Example: `bundle exec rake "cucumber:custom[features/issues features/projects]"`
-      
-    In some development environments you might need to run single features differently as the former example results in weird error messages.
-    
-    `RAILS_ENV=test bundle exec cucumber -r features <path-to-feature-file> `
-
-
-`cucumber:plugins` and `cucumber:all` accept an optional parameter which
-allows specifying custom options to cucumber. This can be used for
-executing scenarios by name, e.g. `"cucumber:all[-n 'Adding an issue link']"`.
-Like with spaces in `cucumber:custom` arguments, task name and arguments
-have to be enclosed in quotation marks.
-
-#### Running cucumber features without rake
-
-Running cucumber features without going through `rake` is possible by using
-the following command
-
-`cucumber -r features features/my/path/to/cucumber.feature`
-
-It is also possible to run a certain cuke by passing a line number:
-
-`cucumber -r features features/my/path/to/cucumber.feature:123`
-
-You may also run cukes within a certain folder:
-
-`cucumber -r features features/my/path`
-
-**Note: `-r features` is required otherwise the step definitions cannot be found.**
-
-You can run cucumber without rake, and with all core and plugin features included
-through:
-
-```
-./bin/cucumber features/my/path/to/cucumber.feature:123
-```
-
-
-#### Shortcuts
-
-Here are two bash functions which allow using shorter commands for running
-cucumber features:
-
-    # Run OpenProject cucumber features (like arguments to the cucumber command)
-    # Example: cuke features/issues/issue.feature
-    cuke() { RAILS_ENV=test bundle exec rake "cucumber:custom[$*]"; }
-
-    # Run OpenProject cucumber scenarios by name
-    # Example: cuken Adding an issue link
-    cuken() { RAILS_ENV=test bundle exec rake "cucumber:all[-n '$*']"; }
-
-Setting `RAILS_ENV=test` allows the cucumber rake tasks to run the features
-directly in the same process, so this reduces the time until the features are
-running a bit (5-10 seconds) due to the Rails environment only being loaded
-once.
-
-#### Selenium
-
-To activate selenium as test driver to test javascript on web pages, you can add
-`@javascript above the scenario like the following example shows:
-
-    @javascript
-    Scenario: Testing something with Javascript
-      When I ...
-
-#### Debugging
-
-You can always start a debugger using the step "And I start debugging".
-
-### Parallel testing
-
-Running tests in parallel makes usage of all available cores of the machine.
-Functionality is being provided by [parallel_tests](https://github.com/grosser/parallel_tests) gem.
-See the github page for any options like number of cpus used.
-
-#### Prepare
-
-Adjust `database.yml` to use different databases:
-
-```yml
-test: &test
-  database: openproject_test<%= ENV['TEST_ENV_NUMBER'] %>
-  # ...
-```
-
-Create all databases: `rake parallel:create`
-
-Prepare all databases:
-
-`RAILS_ENV=test parallel_test -e "rake db:drop db:create db:migrate"`
-
-**Note: Until `rake db:schema:load` works we have to use the command above. Then we
-can use `rake parallel:prepare`**
-
-You may also just dump your current schema with `rake db:schema:dump` (db/schema.rb)
-is not part of the repository. Then you can just use `rake parallel:prepare` to prepare
-test databases.
-
-#### RSpec legacy specs
-
-Run all legacy specs in parallel with `rake parallel:spec_legacy`
-
-Or run them manually with `parallel_test -t rspec -o '-I spec_legacy' spec_legacy`
-
-#### RSpec specs
-
-Run all specs in parallel with `rake parallel:spec`
-
-Or run them manually with `parallel_test -t rspec spec`.
-
-#### Cucumber
-
-Run all cucumber features in parallel with `rake parallel:cucumber`.
-
-Or run them manually with `parallel_test -t cucumber -o '-r features' features`.
-
-**Note:** there is also a official rake task to run cucumber features but the OpenProject cucumber
-test suite requires `-r features` to run correctly. This needs to be passed to the command
-thus it looks not very handy `rake parallel:features\[,,"-r features"\]`
-(this is zsh compatible, command takes three arguments but we just want to pass the last one here.)
-
-#### Plugins
-
-Run specs for all activated plugins with `rake parallel:plugins:spec`.
-
-Run cucumber features for all activated plugins with `rake parallel:plugins:cucumber`.
-
-#### Full test suite
-
-You may run all existing parts of OpenProject test suite in parallel with
-`rake parallel:all`
-
-**Note:** This will run core specs, core cucumber features, core legacy specs,
-plugin specs and plugin cucumber features. This task will take around 40 minutes
-on a machine with 8 parallel instances.
-
-## For the fancy programmer
-
-* We are testing on travis-ci. Look there for your pull requests.<br />
-  https://travis-ci.org/opf/openproject
-* If you have enabled the terminal bell, add `; echo -e "\a"` to the end of your test command. The terminal bell will then tell you when your tests finished.
-
-
-## Manual acceptance tests
-
-* Sometimes you want to test things manually. Always remember: If you test something more than once, write an automated test for it.
-* Assuming you do not have a version of Edge already installed on your computer, you can grab a VM with preinstalled IE's directly from Microsoft: http://www.modern.ie/en-us/virtualization-tools#downloads
-
-If you want to access the development server of OpenProject from a VM,
-you need to work around the CSP `localhost` restrictions.
-
-
-### Old way, fixed compilation
-
-One way is to disable the Angular CLI that serves some of the assets when developing. To do that, run
-
-```bash
-
-# Precompile the application
-./bin/rails assets:precompile
-
-# Start the application server while disabling the CLI asset host 
-OPENPROJECT_CLI_PROXY='' ./bin/rails s -b 0.0.0.0 -p 3000
-```
-
-Now assuming networking is set up in your VM, you can access your app server on `<your local ip>:3000` from it.
-
-### New way, with ng serve
-
-**The better way** when you want to develop against Edge is to set up your server to allow the CSP to the remote host.
-Assuming your openproject is served at `<your local ip>:3000` and your ng serve middleware is running at `<your local ip>:4200`,
-you can access both from inside a VM with nat/bridged networking as follows:
-
-```bash
-# Start ng serve middleware binding to all interfaces
-npm run serve-public
-
-# Start your openproject server with the CLI proxy configuration set
-OPENPROJECT_CLI_PROXY='http://<your local ip>:4200' ./bin/rails s -b 0.0.0.0 -p 3000
-
-# Now access your server from http://<your local ip>:3000 with code reloading
-```
-
-## Legacy LDAP tests
-
-OpenProject supports using LDAP for user authentications.  To test LDAP
-with OpenProject, load the LDAP export from test/fixtures/ldap/test-ldap.ldif
-into a testing LDAP server.  Test that the ldap server can be accessed
-at 127.0.0.1 on port 389.
-
-Setting up the test ldap server is beyond the scope of this documentation.
-The OpenLDAP project provides a simple LDAP implementation that should work
-good as a test server.

docs/development/security/README.md

@@ -22,7 +22,7 @@ If you can, please send us a PGP-encrypted email using the following key:
 
 - Key ID: [0x7D669C6D47533958](https://pgp.mit.edu/pks/lookup?op=get&search=0x7D669C6D47533958) , 
 - Fingerprint BDCF E01E DE84 EA19 9AE1 72CE 7D66 9C6D 4753 3958
-- You may also find the key [attached in our OpenProject repository.](https://github.com/opf/openproject/blob/dev/docs/security/security-at-openproject.com.asc)
+- You may also find the key [attached in our OpenProject repository.](https://github.com/opf/openproject/blob/dev/docs/development/security/security-at-openproject.com.asc)
 
 Please include a description on how to reproduce the issue if possible. Our security team will get your email and will attempt to reproduce and fix the issue as soon as possible.
 

docs/development/submit-feature-idea.md

@@ -1,61 +0,0 @@
-# Submit a feature idea
-
-## How to submit a feature idea?
-
-1. Login to the [OpenProject community platform](https://community.openproject.com/login).
-2. Open the [feature create form](https://community.openproject.com/projects/openproject/work_packages/create_new?type=6).
-3. Add a subject and detailed description.
-4. Attach a file (optional).
-5. Set version to "Wish List".
-6. Press Create.
-
-## Feature idea guideline
-
-### Subject
-
-* The subject of the feature request should be as concise and crisp as possible.
-
-**Example:**
-
-> [Backlogs] Grey out status fields in task board which cannot be used by role
-
-### Description
-
-* The feature description should be concise and expressive.
-* Mention the reason why the change is relevant. Describe the associated use case.
-* Add acceptance criteria for clarification.
-* Describe the current behavior if it is to be changed by the request.
-* Using the following (user story) format, describe the intent behind a new feature request:
-
-**Example:**
-
->     AS an OpenProject user
->     I WANT to only show the allowed status fields as active for which a status transition is allowed based on the workflow
->     SO THAT I am clearly aware which status transitions are allowed before doing them.
-
-### Acceptance criteria
-
-* State and detail the requirements in the acceptance criteria.
-
-**Example:**
-
-> * In the task board only show the status allowed for the role the user has in the project as active.
->   * The status fields which are inactive should have e.g. a grey background to make clear that a user cannot use them.
-
-### Current behavior
-
-* If the feature request is changing existing behavior, briefly explain the current behavior.
-
-**Example:**
-
-> Currently, all status transitions set for a type are displayed as active (independent of the allowed status transitions defined by the workflow).
-
-### Wireframes / Screenshots
-
-* If the request is visual, it is helpful to add a short wireframe or a screenshot in which changes are highlighted.
-* The wireframe or screenshot can be attached as a file and can be integrated in the description with the following syntax: "!Name_of_screenshot.png!" (without quotation marks)
-(Notice: Name_of_screenshot should be replaced with the respective name of the file. The file ending (here: .png) has to be adjusted to the appropriate file type of the screenshot.)
-
-## Example of a feature request
-
-![Feature Request](https://www.openproject.org/wp-content/uploads/2019/10/Feature-request.png "Feature Request")

docs/development/translate-openproject.md

@@ -1,55 +0,0 @@
-# Help translate OpenProject to your language
-
-## OpenProject translations with CrowdIn
-
-OpenProject is available in more than 30 languages.
-Get an overview of the translation process and join us in translating OpenProject to your language.
-
-In order to translate OpenProject, we use [CrowdIn](https://crowdin.com/projects/opf) as a platform where contributors can provide translations for a large number of languages.
-We highly appreciate the help of anyone who wants to translate OpenProject to additional languages.
-In order to provide translations not only for the OpenProject core but also for the plugins, we created several translation projects on CrowdIn:
-* [OpenProject (core)](https://crowdin.com/project/openproject)
-* [OpenProject-Meetings](https://crowdin.com/project/openproject-meeting)
-* [OpenProject-PDF_Export](https://crowdin.com/project/openproject-pdfexport)
-* [OpenProject-Costs](https://crowdin.com/project/openproject-costs)
-* [OpenProject-My_Project_Page](https://crowdin.com/project/openproject-myprojectpage)
-* [OpenProject-Documents](https://crowdin.com/project/openproject-documents)
-* [OpenProject-Reporting](https://crowdin.com/project/openproject-reporting)
-* [OpenProject-Global_Roles](https://crowdin.com/project/openproject-globalroles)
-* [OpenProject-Backlogs](https://crowdin.com/project/openproject-backlogs)
-* [Reporting_Engine](https://crowdin.com/project/reportingengine)
-
-To help us translate OpenProject, please follow the links above and follow the instructions below (see [“How to translate OpenProject via CrowdIn”](https://github.com/opf/openproject/new/release/6.1/doc/development#how-to-translate-openproject-via-crowdin)).
-You can find this project list on https://crowdin.com/projects/opf.
-
-## How the translation process works
-
-Each of the projects listed above corresponds to a GitHub repository which contains the code for the OpenProject core and plugins.
-When a new OpenProject version is developed it typically contains new English text (strings). 
-CrowdIn facilitates the translation of those strings to different languages.
-Here is how the translation process works in detail:
-
-![Translation process via GitHub and CrowdIn in detail](https://1t1rycb9er64f1pgy2iuseow-wpengine.netdna-ssl.com/wp-content/uploads/2015/07/GitHub-CrowdIn-OP.png "Translation process via GitHub and CrowdIn in detail")
-
-1. When a new OpenProject version is developed which contains new English words (strings) (on GitHub) the new strings are copied to the CrowdIn projects for the core and the plugins via the OpenProject CI.
-2. Once the strings have been copied, they can be translated, voted on and approved via CrowdIn. Afterwards, these translations are copied to GitHub via the OpenProject CI and included in the release branch.
-3. When the new OpenProject version is released users can use the translations in their own instances with the next OpenProject version.
-
-## How to translate OpenProject via CrowdIn
-You can easily help translate OpenProject by creating a (free) CrowdIn account and by joining the [OpenProject CrowdIn projects](https://crowdin.com/projects/opf).
-Once you joined one or all of the projects, you can provide translations by following these steps:
-1. Select the language for which you want to contribute (or vote for) a translation (below the language you can see the progress of the translation).
-![Language overview in OpenProject CrowdIn project](https://1t1rycb9er64f1pgy2iuseow-wpengine.netdna-ssl.com/wp-content/uploads/2015/07/CrowdIn1.png "Language overview in OpenProject CrowdIn project")
-2. From the list of OpenProject versions, select the current version or a version which has not been completely translated yet. The blue bar shows the translation progress, the green bar the approving progress (can only be done by proof readers).
-For some OpenProject projects (such as the OpenProject core) two files exist for one version: One file contains the basic translations (Ruby on Rails), the other file contains the strings associated with the Javascript part (AngularJS). Both files need to be translated to completely translate OpenProject. 
-To provide a translation select a file from a version which has not been completely translated: 
-![Select OpenProject version to translate in CrowdIn](https://1t1rycb9er64f1pgy2iuseow-wpengine.netdna-ssl.com/wp-content/uploads/2015/07/CrowdIn2.png "Select OpenProject version to translate in CrowdIn")
-3. Once a file is selected, all the strings associated with the version are displayed on the left side. To display the untranslated strings first, select the filter icon next to the search bar and select “All, Untranslated First”.
-The red square next to an English string shows that a string has not been translated yet. To provide a translation, select a string on the left side, provide a translation in the target language in the text box in the right side (singular and plural) and press the save button.
-As soon as a translation has been provided by another user (green square next to string), you can also vote on a translation provided by another user. The translation with the most votes is used unless a different translation has been approved by a proof reader.
-![Translate strings via CrowdIn](https://1t1rycb9er64f1pgy2iuseow-wpengine.netdna-ssl.com/wp-content/uploads/2015/07/CrowdIn3.png "Translate strings via CrowdIn")
-Once a translation has been provided, a proof reader can approve the translation and mark it for use in OpenProject.
-
-If you are interested in becoming a proof reader, please contact one of the project managers in the Openproject CrowdIn project or send us an email at support@openproject.org.
-
-If your language is not listed in the list of CrowdIn languages, please contact our project managers or send us an email so we can add your language.