diff --git a/tutorials/Reporting-bugs.md b/tutorials/Reporting-bugs.md
deleted file mode 100644
index 4db0feb4..00000000
--- a/tutorials/Reporting-bugs.md
+++ /dev/null
@@ -1,79 +0,0 @@
-**Note: We are currently a few devs active on the project. We can't answer and tags each issues opened, but we read it. A good issue provide an important feedback and thank you for that, any feedback is appreciated.**
-
-When you open a new issue on a GitLab repository, you have to complete the **Summary** and the **Original Submission**:
-
-Summary is an explicit title of the bug (e.g.: GNOME - header bar is too big due to icon size)
-
-Original Submission is a precise description of the bug. Preferably it covers the following elements:
-
-+ Overview
-+ Steps to reproduce the bug
-+ Result (vs. expected result)
-+ Frequency
-+ Logs
-
-# Overview of the Issue
-
-Please include:
-
-+ Your operating system version.
-+ The exact dring version (LibRing or Daemon) and client version, including the Git commit.
-+ You can obtained it with `dring -v` and `gnome-ring -v`. But note that our packages are updated quite often.
-+ Network conditions: Are both devices on the same local network? Different networks? Is one or both behind NAT?
-+ Other elements if needed: SIP provider, hardware, etc.
-
-## Obtained Result
-
-Please include:
-
-+ The daemon (or LibRing) and client debug logs.
-+ The core dump if one was produced.
-
-## Expected Result
-
-It's a description of expected or desired behaviour.
-
-
-
-# Steps to Reproduce
-
-It is a description of steps/setup to reproduce the issue. This is one of the most **important** section. Having scenario to reproduce the bug will save a lot of time for everybody.
-
-# Result
-
-# Frequency
-
-Does it happen every time or not? It's a description of reproducibility of the bug.
-
-For crasher bugs, stack traces can be helpful.
-
-Please refer to this guide for information on how to obtain a trace: http://live.gnome.org/GettingTraces/Details
-
-Otherwise, screenshots, wireshark captures, audio recordings or any other artefacts that illustrate the bug can be very helpful.
-
-
-
-# Logs
-
-## On GNU/Linux
-Since the Ring GUI and daemon are separated processes, the easiest way to get logs from both is to start them one at a time, manually.
-
-1. Ensure that no ring client or daemon instances are running with `ps aux | grep ring`
-    + Ring may still be running even if no windows are open depending on your preferences.
-    + If either client or daemon are running, kill them with `kill PID`
-2. On one terminal, start the daemon with `dring -d -c`
-    + This executable is normally not in the PATH, and on the Ubuntu packages, it is located at `/usr/lib/x86_64-linux-gnu/dring -d -c`
-3. In another terminal, start the client with (here is a Gnome example) `gnome-ring -d`
-
-## On Mac OS
-
-Open the Terminal app and launch Ring with `/Applications/Ring.app/Contents/MacOS/Ring`
-
-## On Android
-
-+ You need to have adb setup on your laptop.
-+ Launch Ring on your smartphone and then execute
-+ `adb logcat *:D | grep \`adb shell ps | egrep 'cx.ring' | cut -c10-15\` > logring.txt`
-+ You now have a file containing the log of the client
-
-