[BUGFIX] CI: Fix YAML indentations

[jirafeau_project.git] / CONTRIBUTING.md

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 641fb44c18403ace6de893be36eee2206847ecec..e7ee9c3d4d01ade18824b4318acf56a9625b7ac5 100644 (file)
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -4,6 +4,8 @@ Hi,
 
 this document is made for newcomers in Jirafeau who are digging into the code.
 
 
 this document is made for newcomers in Jirafeau who are digging into the code.
 

+If you have further questions, then just ask for help 🤓.
+

 ## General principle
 
 Jirafeau is made in the [KISS](http://en.wikipedia.org/wiki/KISS_principle) way (Keep It Simple, Stupid).
 ## General principle
 
 Jirafeau is made in the [KISS](http://en.wikipedia.org/wiki/KISS_principle) way (Keep It Simple, Stupid).


@@ -22,6 +24,7 @@ view only to show the most importants files and their role.
 ```
 .
 ├── admin.php : administration interface to manage links and files
 ```
 .
 ├── admin.php : administration interface to manage links and files

+├── docker : folder containing some configuration files to run Jirafeau in docker

 ├── f.php : permits to download files or show the download page
 ├── index.php : provides a web interface to interact with API
 ├── script.php : API interface (all file actions happen here - upload, deletion, etc)
 ├── f.php : permits to download files or show the download page
 ├── index.php : provides a web interface to interact with API
 ├── script.php : API interface (all file actions happen here - upload, deletion, etc)


@@ -43,10 +46,10 @@ view only to show the most importants files and their role.
 └── var-xxxxxxx : the users folder containing all data (auto generated, not versionized)
     ├── async : chunks of uploaded files (not succressfull yet) 
     ├── files : all files that have been uploaded successfully
 └── var-xxxxxxx : the users folder containing all data (auto generated, not versionized)
     ├── async : chunks of uploaded files (not succressfull yet) 
     ├── files : all files that have been uploaded successfully

-        ├── [hashed file name] : the original file
-        ├── [hashed file name]_count : count many links to this file exist
+    │   ├── [hashed file name] : the original file
+    │   └── [hashed file name]_count : count many links to this file exist

     └── links : all links, including meta-informations, pointing to files
     └── links : all links, including meta-informations, pointing to files

-        â\94\9c── [link] : the link file, includes which original file should be used and some meta data like creation date, expiration time
+        â\94\94── [link] : the link file, includes which original file should be used and some meta data like creation date, expiration time

 ```
 
 ## Translations
 ```
 
 ## Translations


@@ -55,12 +58,9 @@ Translation may be add via [Jirafeau's Weblate](https://hosted.weblate.org/proje
 
 ## Coding style
 
 
 ## Coding style
 

-- PHP function keywords are alone on a line
-- Braces "{" must be put in a new line
+- This project follows the [PSR-2](http://www.php-fig.org/psr/psr-2/) Coding Style

 - Files must be in UTF-8 without BOM and use Unix Line Endings (LF)
 
 - Files must be in UTF-8 without BOM and use Unix Line Endings (LF)
 

-The whole project is not clean about that yet, feel free to fix :)
-

 ## Branches
 
 * ```master``` = latest release, e.g. 2.0.1
 ## Branches
 
 * ```master``` = latest release, e.g. 2.0.1


@@ -74,3 +74,31 @@ Please create one branch for each feature and send one merge request for each br
 Dont squash several changes or commits into one merge request as this is hard to review.
 
 Please use ```next-release``` as base branch and send your merge request to this branch (not ```master```).
 Dont squash several changes or commits into one merge request as this is hard to review.
 
 Please use ```next-release``` as base branch and send your merge request to this branch (not ```master```).

+
+Quick walktrough:
+
+* Create ticket for new feature
+* Fork the original repository, clone the own repository, add the original repository as upstream
+* Checkout »next-release« branch ```git checkout next-release```
+* Create a new branch on top of that one, e.g. »some-feature« ```git checkout -b some-feature```
+* Make your change
+* You may check if the project is still [REUSE Compliant](https://reuse.software/) by running `docker run -v $(pwd):/code --rm fsfe/reuse /bin/sh -c "cd /code && reuse lint"`
+* Commit changes → push → send merge request ```git add -A; git commit; git push``` MR via GitLab (link shown in console)
+* Feature is reviewed
+  * MR accepted: Reviewer checks out »next-release« branch and cherry-picks the commit ```git checkout next-release; git cherry-pick be4369641; git push```
+  * MR declined: Reviewer add some notes, Developer rebases his branch, adds neccessary changes, force pushes the branch, ask a reviewer to review the changes in the merge request ticket (as Gitlab recognizes them automatically) ```git checkout some-feature; git rebase upstream/next-release``` …[add changes]… ```git add -A, git commit --amend; git push -f```
+
+## New Releases
+
+* If the release is not done for security purposes: create a new issue and freeze next-release branch for at least week.
+* Compare the [»next-release« branch to »master«](https://gitlab.com/mojo42/Jirafeau/compare/master...next-release)
+* Add a list of noteworthy features and bugfixes to `CHANGELOG.md`
+* Add eventual upgrade procedure to `CHANGELOG.md`
+* Build and test docker image
+* Change the version, using [semantic versioning](http://semver.org/), in ```settings.php```
+* Merge »next-release« branch to »master«
+* Tag the »master« with the new version
+* Push branch and tag
+* Push new docker image
+* Update the demo page
+* Dance a little