.gitignore

 ietemplates/
 _site/*
 .idea/
+*.swp

.gitlab-ci.yml

+image: ruby:2.5
+stages:
+  - build
+
+variables:
+  LANG: "C.UTF-8"
+
+before_script:
+  - gem install bundler
+
+build_site:
+  stage: build
+  only:
+    - master
+  script:
+    - bundle install
+    - bundle exec jekyll build 

.gitlab/issue_templates/Merchant.md

+#### What's the name of your business?
+
+<!-- Write here -->
+
+#### What's the URL of the website?
+
+<!-- Write here. Referral links and/or trackers are not accepted -->
+
+#### Write a brief description of your business/service (max 50 characters)
+
+<!-- Write here. This text will be displayed on the Merchant page. Keep it short -->
+
+#### Enter the URL where a Monero mention can be found
+
+<!-- Be aware of the fact that to be listed, you must specify somewhere on your website that you accept Monero. -->
+
+https://
+
+#### How do you accept Monero? *(choose only one option)*
+
+- [ ] Monero integrations *(github.com/monero-integrations)*
+- [ ] Globee
+- [ ] Native wallet
+- [ ] Other payment gateaway (Coinpayments, Morphtoken, etc. *Please specify*)
+
+#### How would you categorize your business? *(choose only one option)*
+
+- [ ] Exchange
+- [ ] Block Explorer
+- [ ] Payment Gateway
+- [ ] Library and Helper
+- [ ] Tool
+- [ ] Service
+- [ ] Goods
+- [ ] Entertainment
+
+#### Comment
+
+<!-- Write here any additional comment -->

.ruby-version

+2.4.1

404/css/ie7.css

-@charset "utf-8";
-div.not-found-text{
-	top:65px;	
-}
-
-div.planet{
-	z-index:-1;	
-}
-
-div.dog{
-	z-index:1000;	
-}
-
-div.dog-bubble{
-	filter: alpha(opacity=0); /* IE6+ */
-    filter: progid:DXImageTransform.Microsoft.Alpha(opacity=0); /* IE6+ */
-	-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(opacity=0)";
-	padding-top:35px;	
-}
-
-#dog-changer ul li a{
-	filter: alpha(opacity=30); /* IE6+ */
-    filter: progid:DXImageTransform.Microsoft.Alpha(opacity=30); /* IE6+ */
-	-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(opacity=30)";
+@charset "utf-8";
+div.not-found-text{
+	top:65px;	
+}
+
+div.planet{
+	z-index:-1;	
+}
+
+div.dog{
+	z-index:1000;	
+}
+
+div.dog-bubble{
+	filter: alpha(opacity=0); /* IE6+ */
+    filter: progid:DXImageTransform.Microsoft.Alpha(opacity=0); /* IE6+ */
+	-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(opacity=0)";
+	padding-top:35px;	
+}
+
+#dog-changer ul li a{
+	filter: alpha(opacity=30); /* IE6+ */
+    filter: progid:DXImageTransform.Microsoft.Alpha(opacity=30); /* IE6+ */
+	-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(opacity=30)";
 }
\ No newline at end of file

404/css/main.css

-@charset "utf-8";
-
-/* === General stuff === */
-
-html, body{
-	height:100%;
-	background:#186aa9 url(/404/images/sky-background.png) top repeat-x;	
-	overflow:hidden;
-	padding:0;
-	margin:0;
-	font-family:Arial, Helvetica, sans-serif;
-	margin-top: 5px;
-}
-
-.footer{
-	display: none;
-}
-
-a{
-	color:#3680b1;	
-}
-
-img, a img{
-	border:0px none;	
-	outline:none;
-}
-
-/* === Main Section === */
-
-#wrapper{	
-	width:980px;
-	margin:0px auto;
-	position:relative;
-	height:100%;
-	background:url(/404/images/sky-shine.jpg) top left no-repeat;
-}
-
-div.top-left{
-	position:absolute;
-	right:0px;
-}
-
-div.not-found-text{
-	position:absolute;
-	top:35px;
-	right:0px;
-	width:430px;
-}
-
-h1.not-found-text{
-	font-size:50px;
-	color:#fff;
-	letter-spacing:2px;
-	margin-bottom:20px;
-}
-
-div.graphic{
-	position:absolute;
-	top:80px;
-	left:0px;
-}
-
-div.planet{
-	position:absolute;
-	bottom:-720px;
-	margin:0px auto;
-	z-index:0;
-}
-
-div.planet>img{
-	width:960px;
-}
-
-div.dog-wrapper{
-	position:absolute;
-	top:45px;
-	left:440px;
-}
-
-div.dog{
-	position:absolute;
-	bottom:0px;
-	left:0px;
-	width:80px;
-	height:80px;
-	z-index:999;
-	background:url(/404/images/dog1.png) 0px 0px no-repeat;
-}
-
-div.dog-bubble{
-	font-size:18px;
-	line-height:1.5;
-	font-style:italic;
-	height:179px;
-	width:246px;
-	background:url(/404/images/bubble.png) top center no-repeat;
-	padding:20px 0px;
-	position:absolute;
-	bottom:0px;
-	left:30px;
-	z-index:999;
-	opacity:0;
-	color:#555555;
-	text-shadow:1px 1px 0 #ffffff;
-}
-
-div.dog-bubble>p{
-	text-align:center;
-	padding:0px 35px;	
-}
-
-div.bubble-options{
-	opacity:0;
-	visibility:hidden;
-	display:none;
-}
-
-/* === Responsive === */
-
-/* #Small laptop screens
-================================================== */
-
-    @media only screen and (max-width: 960px) {
-    	#wrapper{
-    		width:600px;
-    		background-image:none;
-			margin-top: 50px;
-    	}
-
-        div.planet{
-			position:absolute;
-			bottom:-300px;
-			margin:0 auto 0 -280px;
-			z-index:0;
-			left:50%;
-			
-		}
-
-		div.planet>img{
-			width:560px;
-		}
-
-		div.dog-wrapper{
-			position:absolute;
-			top:30px;
-			left:250px;
-			
-		}
-
-		div.graphic{
-			position:absolute;
-			top:50px;
-			left:40px;
-			
-		}
-
-		div.top-left {
-		    position: absolute;
-		    right: 0px;
-		    top: -40px;
-		}
-
-		div.graphic>img{
-			width:60%;
-		}
-
-		div.graphic{
-			left: 0px;
-		    position: absolute;
-		    top: 20px;
-		}
-
-		div.not-found-text{
-			right:0px;
-			top:22px;
-			width:320px;
-		}
-
-		h1.not-found-text{
-			font-size:35px;
-		}
-
-    }
-
-
-/*  #Tablets and small screens
-================================================== */
-
-    @media only screen and (max-width: 767px) {
-        
-    	#wrapper{
-    		width:400px;
-    		background-image:none;
-    	}
-
-    	div.graphic>img{
-			width:40%;
-		}
-
-        div.planet{
-			position:absolute;
-			bottom:-170px;
-			margin:0 auto 0 -180px;
-			z-index:0;
-			left:50%;
-			
-		}
-
-		div.planet>img{
-			width:360px;
-		}
-
-		div.dog-wrapper{
-			position:absolute;
-			top:30px;
-			left:150px;
-			
-		}
-
-		div.graphic{
-			position:absolute;
-			top:20px;
-			left:0px;
-			
-		}
-
-		div.top-left {
-		    position: absolute;
-		    right: 390px;
-		    top: 170px;
-		}
-
-		h1.not-found-text {
-		    font-size: 26px;
-		}
-
-		div.not-found-text {
-		    right: -60px;
-		    top: 33px;
-		    width: 270px;
-		}
-
-		div.top-left {
-		    position: absolute;
-		    right: 0;
-		    top: -38px;
-		}
-
-    }
-
-
-/* #Mobile phones
-================================================== */
-
-    @media only screen and (max-width: 479px){
-        
-    	#wrapper{
-    		width:320px;
-    		background-image:none;
-    	}
-
-		h1.not-found-text {
-		    font-size: 20px;
-		    text-align: center;
-		}
-
-		div.not-found-text {
-		    right: 20px;
-		    top: 210px;
-		}
-
-    	div.graphic>img{
-			width:100%;
-		}
-		
-
-        div.planet{
-			position:absolute;
-			bottom:-70px;
-			margin:0 auto 0 -100px;
-			z-index:0;
-			left:50%;
-			
-		}
-
-		div.planet>img{
-			width:200px;
-		}
-
-		div.dog-wrapper {
-		    left: 70px;
-		    position: absolute;
-		    top: 26px;
-		}
-
-		div.dog-bubble{
-			font-size:10px;
-			line-height:1.5;
-			font-style:italic;
-			height:107px;
-			width:147px;
-			background:url(/404/images/bubble.png) top center no-repeat;
-			background-size: contain;
-			padding:10px 0px;
-			position:absolute;
-			bottom:0px;
-			left:55px;
-			z-index:999;
-			opacity:0;
-			color:#555555;
-			text-shadow:1px 1px 0 #ffffff;
-		}
+@charset "utf-8";
+
+/* === General stuff === */
+
+html, body{
+	height:100%;
+	background:#186aa9 url(/404/images/sky-background.png) top repeat-x;	
+	overflow:hidden;
+	padding:0;
+	margin:0;
+	font-family:Arial, Helvetica, sans-serif;
+	margin-top: 5px;
+}
+
+.footer{
+	display: none;
+}
+
+a{
+	color:#3680b1;	
+}
+
+img, a img{
+	border:0px none;	
+	outline:none;
+}
+
+/* === Main Section === */
+
+#wrapper{	
+	width:980px;
+	margin:0px auto;
+	position:relative;
+	height:100%;
+	background:url(/404/images/sky-shine.jpg) top left no-repeat;
+}
+
+div.top-left{
+	position:absolute;
+	right:0px;
+}
+
+div.not-found-text{
+	position:absolute;
+	top:35px;
+	right:0px;
+	width:430px;
+}
+
+h1.not-found-text{
+	font-size:50px;
+	color:#fff;
+	letter-spacing:2px;
+	margin-bottom:20px;
+}
+
+div.graphic{
+	position:absolute;
+	top:80px;
+	left:0px;
+}
+
+div.planet{
+	position:absolute;
+	bottom:-720px;
+	margin:0px auto;
+	z-index:0;
+}
+
+div.planet>img{
+	width:960px;
+}
+
+div.dog-wrapper{
+	position:absolute;
+	top:45px;
+	left:440px;
+}
+
+div.dog{
+	position:absolute;
+	bottom:0px;
+	left:0px;
+	width:80px;
+	height:80px;
+	z-index:999;
+	background:url(/404/images/dog1.png) 0px 0px no-repeat;
+}
+
+div.dog-bubble{
+	font-size:18px;
+	line-height:1.5;
+	font-style:italic;
+	height:179px;
+	width:246px;
+	background:url(/404/images/bubble.png) top center no-repeat;
+	padding:20px 0px;
+	position:absolute;
+	bottom:0px;
+	left:30px;
+	z-index:999;
+	opacity:0;
+	color:#555555;
+	text-shadow:1px 1px 0 #ffffff;
+}
+
+div.dog-bubble>p{
+	text-align:center;
+	padding:0px 35px;	
+}
+
+div.bubble-options{
+	opacity:0;
+	visibility:hidden;
+	display:none;
+}
+
+/* === Responsive === */
+
+/* #Small laptop screens
+================================================== */
+
+    @media only screen and (max-width: 960px) {
+    	#wrapper{
+    		width:600px;
+    		background-image:none;
+			margin-top: 50px;
+    	}
+
+        div.planet{
+			position:absolute;
+			bottom:-300px;
+			margin:0 auto 0 -280px;
+			z-index:0;
+			left:50%;
+			
+		}
+
+		div.planet>img{
+			width:560px;
+		}
+
+		div.dog-wrapper{
+			position:absolute;
+			top:30px;
+			left:250px;
+			
+		}
+
+		div.graphic{
+			position:absolute;
+			top:50px;
+			left:40px;
+			
+		}
+
+		div.top-left {
+		    position: absolute;
+		    right: 0px;
+		    top: -40px;
+		}
+
+		div.graphic>img{
+			width:60%;
+		}
+
+		div.graphic{
+			left: 0px;
+		    position: absolute;
+		    top: 20px;
+		}
+
+		div.not-found-text{
+			right:0px;
+			top:22px;
+			width:320px;
+		}
+
+		h1.not-found-text{
+			font-size:35px;
+		}
+
+    }
+
+
+/*  #Tablets and small screens
+================================================== */
+
+    @media only screen and (max-width: 767px) {
+        
+    	#wrapper{
+    		width:400px;
+    		background-image:none;
+    	}
+
+    	div.graphic>img{
+			width:40%;
+		}
+
+        div.planet{
+			position:absolute;
+			bottom:-170px;
+			margin:0 auto 0 -180px;
+			z-index:0;
+			left:50%;
+			
+		}
+
+		div.planet>img{
+			width:360px;
+		}
+
+		div.dog-wrapper{
+			position:absolute;
+			top:30px;
+			left:150px;
+			
+		}
+
+		div.graphic{
+			position:absolute;
+			top:20px;
+			left:0px;
+			
+		}
+
+		div.top-left {
+		    position: absolute;
+		    right: 390px;
+		    top: 170px;
+		}
+
+		h1.not-found-text {
+		    font-size: 26px;
+		}
+
+		div.not-found-text {
+		    right: -60px;
+		    top: 33px;
+		    width: 270px;
+		}
+
+		div.top-left {
+		    position: absolute;
+		    right: 0;
+		    top: -38px;
+		}
+
+    }
+
+
+/* #Mobile phones
+================================================== */
+
+    @media only screen and (max-width: 479px){
+        
+    	#wrapper{
+    		width:320px;
+    		background-image:none;
+    	}
+
+		h1.not-found-text {
+		    font-size: 20px;
+		    text-align: center;
+		}
+
+		div.not-found-text {
+		    right: 20px;
+		    top: 210px;
+		}
+
+    	div.graphic>img{
+			width:100%;
+		}
+		
+
+        div.planet{
+			position:absolute;
+			bottom:-70px;
+			margin:0 auto 0 -100px;
+			z-index:0;
+			left:50%;
+			
+		}
+
+		div.planet>img{
+			width:200px;
+		}
+
+		div.dog-wrapper {
+		    left: 70px;
+		    position: absolute;
+		    top: 26px;
+		}
+
+		div.dog-bubble{
+			font-size:10px;
+			line-height:1.5;
+			font-style:italic;
+			height:107px;
+			width:147px;
+			background:url(/404/images/bubble.png) top center no-repeat;
+			background-size: contain;
+			padding:10px 0px;
+			position:absolute;
+			bottom:0px;
+			left:55px;
+			z-index:999;
+			opacity:0;
+			color:#555555;
+			text-shadow:1px 1px 0 #ffffff;
+		}
     }
\ No newline at end of file

404/index.md

@@ -15,7 +15,7 @@ title: "Error 404, Page Not Found"
 
 	<div class="top-left">
 			<div class="not-found-text">
-				<h1 class="not-found-text">Oh no, we couldn't find anything for that link!</h1>
+				<h1 class="not-found-text">Oh no! We couldn't find anything for that link!</h1>
 			</div>
 	</div>
 

CONTRIBUTING.md

+# General Guidelines
+
+- Commits should be [atomic](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention) and diffs should be easy to read. Please try to not mix formatting fixes with non-formatting commits
+- The body of the pull request should:
+  * contain an accurate description of what the patch does
+  * provide justification/reasoning for the patch (when appropriate)
+  * include references to any discussions such as other tickets or chats on IRC
+- If a particular commit references another issue, please add a reference. For example "See #123", or "Fixes #123". This will help us resolve tickets when we merge into `master`
+
+# [Code of Conduct (22/C4.1)](http://rfc.zeromq.org/spec:22)
+
+## License
+
+Copyright (c) 2009-2015 Pieter Hintjens.
+
+This Specification 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 3 of the License, or (at your option) any later version.
+
+This Specification 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, see <http://www.gnu.org/licenses>.
+
+## Language
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
+
+## Goals
+
+C4 is meant to provide a reusable optimal collaboration model for open source software projects. It has these specific goals:
+
+- To maximize the scale and diversity of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks;
+- To relieve dependencies on key individuals by separating different skill sets so that there is a larger pool of competence in any required domain;
+- To allow the project to develop faster and more accurately, by increasing the diversity of the decision making process;
+- To support the natural life cycle of project versions from experimental through to stable, by allowing safe experimentation, rapid failure, and isolation of stable code;
+- To reduce the internal complexity of project repositories, thus making it easier for Contributors to participate and reducing the scope for error;
+- To enforce collective ownership of the project, which increases economic incentive to Contributors and reduces the risk of hijack by hostile entities.
+
+## Design
+
+### Preliminaries
+
+- The project SHALL use the git distributed revision control system.
+- The project SHALL be hosted on github.com or equivalent, herein called the "Platform".
+- The project SHALL use the Platform issue tracker.
+- The project SHOULD have clearly documented guidelines for code style.
+- A "Contributor" is a person who wishes to provide a patch, being a set of commits that solve some clearly identified problem.
+- A "Maintainer" is a person who merges patches to the project. Maintainers are not developers; their job is to enforce process.
+- Contributors SHALL NOT have commit access to the repository unless they are also Maintainers.
+- Maintainers SHALL have commit access to the repository.
+- Everyone, without distinction or discrimination, SHALL have an equal right to become a Contributor under the terms of this contract.
+
+### Licensing and Ownership
+
+- The project SHALL use a share-alike license, such as the GPLv3 or a variant thereof (LGPL, AGPL), or the MPLv2.
+- All contributions to the project source code ("patches") SHALL use the same license as the project.
+- All patches are owned by their authors. There SHALL NOT be any copyright assignment process.
+- The copyrights in the project SHALL be owned collectively by all its Contributors.
+- Each Contributor SHALL be responsible for identifying themselves in the project Contributor list.
+
+### Patch Requirements
+
+- Maintainers and Contributors MUST have a Platform account and SHOULD use their real names or a well-known alias.
+- A patch SHOULD be a minimal and accurate answer to exactly one identified and agreed problem.
+- A patch MUST adhere to the code style guidelines of the project if these are defined.
+- A patch MUST adhere to the "Evolution of Public Contracts" guidelines defined below.
+- A patch SHALL NOT include non-trivial code from other projects unless the Contributor is the original author of that code.
+- A patch MUST compile cleanly and pass project self-tests on at least the principle target platform.
+- A patch commit message SHOULD consist of a single short (less than 50 character) line summarizing the change, optionally followed by a blank line and then a more thorough description.
+- A "Correct Patch" is one that satisfies the above requirements.
+
+### Development Process
+
+- Change on the project SHALL be governed by the pattern of accurately identifying problems and applying minimal, accurate solutions to these problems.
+- To request changes, a user SHOULD log an issue on the project Platform issue tracker.
+- The user or Contributor SHOULD write the issue by describing the problem they face or observe.
+- The user or Contributor SHOULD seek consensus on the accuracy of their observation, and the value of solving the problem.
+- Users SHALL NOT log feature requests, ideas, suggestions, or any solutions to problems that are not explicitly documented and provable.
+- Thus, the release history of the project SHALL be a list of meaningful issues logged and solved.
+- To work on an issue, a Contributor SHALL fork the project repository and then work on their forked repository.
+- To submit a patch, a Contributor SHALL create a Platform pull request back to the project.
+- A Contributor SHALL NOT commit changes directly to the project.
+- If the Platform implements pull requests as issues, a Contributor MAY directly send a pull request without logging a separate issue.
+- To discuss a patch, people MAY comment on the Platform pull request, on the commit, or elsewhere.
+- To accept or reject a patch, a Maintainer SHALL use the Platform interface.
+- Maintainers SHOULD NOT merge their own patches except in exceptional cases, such as non-responsiveness from other Maintainers for an extended period (more than 1-2 days).
+- Maintainers SHALL NOT make value judgments on correct patches.
+- Maintainers SHALL merge correct patches from other Contributors rapidly.
+- The Contributor MAY tag an issue as "Ready" after making a pull request for the issue.
+- The user who created an issue SHOULD close the issue after checking the patch is successful.
+- Maintainers SHOULD ask for improvements to incorrect patches and SHOULD reject incorrect patches if the Contributor does not respond constructively.
+- Any Contributor who has value judgments on a correct patch SHOULD express these via their own patches.
+- Maintainers MAY commit changes to non-source documentation directly to the project.
+
+### Creating Stable Releases
+
+- The project SHALL have one branch ("master") that always holds the latest in-progress version and SHOULD always build.
+- The project SHALL NOT use topic branches for any reason. Personal forks MAY use topic branches.
+- To make a stable release someone SHALL fork the repository by copying it and thus become maintainer of this repository.
+- Forking a project for stabilization MAY be done unilaterally and without agreement of project maintainers.
+- A stabilization project SHOULD be maintained by the same process as the main project.
+- A patch to a stabilization project declared "stable" SHALL be accompanied by a reproducible test case.
+
+### Evolution of Public Contracts
+
+- All Public Contracts (APIs or protocols) SHALL be documented.
+- All Public Contracts SHOULD have space for extensibility and experimentation.
+- A patch that modifies a stable Public Contract SHOULD not break existing applications unless there is overriding consensus on the value of doing this.
+- A patch that introduces new features to a Public Contract SHOULD do so using new names.
+- Old names SHOULD be deprecated in a systematic fashion by marking new names as "experimental" until they are stable, then marking the old names as "deprecated".
+- When sufficient time has passed, old deprecated names SHOULD be marked "legacy" and eventually removed.
+- Old names SHALL NOT be reused by new features.
+- When old names are removed, their implementations MUST provoke an exception (assertion) if used by applications.
+
+### Project Administration
+
+- The project founders SHALL act as Administrators to manage the set of project Maintainers.
+- The Administrators SHALL ensure their own succession over time by promoting the most effective Maintainers.
+- A new Contributor who makes a correct patch SHALL be invited to become a Maintainer.
+- Administrators MAY remove Maintainers who are inactive for an extended period of time, or who repeatedly fail to apply this process accurately.
+- Administrators SHOULD block or ban "bad actors" who cause stress and pain to others in the project. This should be done after public discussion, with a chance for all parties to speak. A bad actor is someone who repeatedly ignores the rules and culture of the project, who is needlessly argumentative or hostile, or who is offensive, and who is unable to self-correct their behavior when asked to do so by others.
+
+# Addendum to [Code of Conduct (22/C4.1)](http://rfc.zeromq.org/spec:22)
+
+## License
+
+Copyright (c) 2017 The Monero Project
+
+## Language
+
+The "Monero Site Maintainer Team" is defined in this document as the following users:
+- fluffypony
+- anonimal
+
+### Development Process
+
+- Maintainers MUST NOT merge pull requests in less than 168 hours (1 week) unless deemed urgent by the Monero Site Maintainer Team

Gemfile

+source 'https://rubygems.org'
+
+gem 'jekyll'
+gem 'jekyll-paginate'
+gem 'builder'
+gem 'rubysl-rexml'
+gem 'wdm', '>= 0.1.0' if Gem.win_platform?
+gem 'jekyll-multiple-languages-plugin'

Gemfile.lock

+GEM
+  remote: https://rubygems.org/
+  specs:
+    addressable (2.7.0)
+      public_suffix (>= 2.0.2, < 5.0)
+    builder (3.2.3)
+    colorator (1.1.0)
+    concurrent-ruby (1.1.5)
+    em-websocket (0.5.1)
+      eventmachine (>= 0.12.9)
+      http_parser.rb (~> 0.6.0)
+    eventmachine (1.2.7)
+    ffi (1.11.3)
+    forwardable-extended (2.6.0)
+    http_parser.rb (0.6.0)
+    i18n (0.9.5)
+      concurrent-ruby (~> 1.0)
+    jekyll (3.8.6)
+      addressable (~> 2.4)
+      colorator (~> 1.0)
+      em-websocket (~> 0.5)
+      i18n (~> 0.7)
+      jekyll-sass-converter (~> 1.0)
+      jekyll-watch (~> 2.0)
+      kramdown (~> 1.14)
+      liquid (~> 4.0)
+      mercenary (~> 0.3.3)
+      pathutil (~> 0.9)
+      rouge (>= 1.7, < 4)
+      safe_yaml (~> 1.0)
+    jekyll-multiple-languages-plugin (1.5.1)
+      jekyll (>= 2.0, < 4.0)
+    jekyll-paginate (1.1.0)
+    jekyll-sass-converter (1.5.2)
+      sass (~> 3.4)
+    jekyll-watch (2.2.1)
+      listen (~> 3.0)
+    kramdown (1.17.0)
+    liquid (4.0.3)
+    listen (3.2.1)
+      rb-fsevent (~> 0.10, >= 0.10.3)
+      rb-inotify (~> 0.9, >= 0.9.10)
+    mercenary (0.3.6)
+    pathutil (0.16.2)
+      forwardable-extended (~> 2.6)
+    public_suffix (4.0.1)
+    rb-fsevent (0.10.3)
+    rb-inotify (0.10.0)
+      ffi (~> 1.0)
+    rouge (3.14.0)
+    rubysl-rexml (2.0.4)
+    safe_yaml (1.0.5)
+    sass (3.7.4)
+      sass-listen (~> 4.0.0)
+    sass-listen (4.0.0)
+      rb-fsevent (~> 0.9, >= 0.9.4)
+      rb-inotify (~> 0.9, >= 0.9.7)
+
+PLATFORMS
+  ruby
+
+DEPENDENCIES
+  builder
+  jekyll
+  jekyll-multiple-languages-plugin
+  jekyll-paginate
+  rubysl-rexml
+
+BUNDLED WITH
+   1.17.3

LICENSE

+Copyright (c) 2014-2020, The Monero Project
+
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
+
+1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
+
+3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

README.md

-# Monero
+## Table of Contents
 
-Copyright (c) 2014-2016, The Monero Project
+- [Introduction](#introduction)
+- [What you'll need](#what-youll-need)
+- [General change recommendations](#general-change-recommendations)
+- [Translation](#translation)
+- [housekeeping](#housekeeping)
+- [How to make a blog post](#how-to-make-a-blog-post)
+- [Updates on User Guides](#updates-on-user-guides)
+- [How to make a blog post](#how-to-make-a-blog-post)
+- [How to make a User Guide](#how-to-make-a-user-guide)
+- [How to make a Moneropedia Entry](#how-to-make-a-moneropedia-entry)
+- [How to update the Team page](#how-to-update-the-team-page)
+- [How to update the Roadmap](#how-to-update-the-roadmap)
+- [How to add a new Merchant](#how-to-add-a-new-merchant)
+- [How to add a question to the FAQ](#how-to-add-a-question-to-the-faq)
+- [How to add a publication to the Library](#how-to-add-a-publication-to-the-library)
 
-## Development Resources
+## Introduction
+This README here to walk you through everything you need to know to make changes, edits, or even completely new pages for the new [getmonero.org website](https://getmonero.org/). It'll definitely be a bit of a ride, so strap yourself in.
+Feel free to skip down to a relevant section if you already know what you need.
 
-Web: [getmonero.org](http://getmonero.org)  
-Mail: [dev@getmonero.org](mailto:dev@getmonero.org)  
-IRC: [#monero-dev on Freenode](irc://chat.freenode.net/#monero-dev)
+If you need support about something related to the website, plese join `#monero-site` [Freenode/IRC](irc://chat.freenode.net/#monero-site), [Matrix](https://matrix.to/#/!txpwSzQzkuUaVbtsIx:matrix.org) and MatterMost. For general info about Monero join `#monero`. We'll do whatever we can to help you.
 
-## About this Project
+## What you'll need
 
-This is the Monero website. Instead of using MediaWiki or similar, we are using Jekyll and hosting the source on github. All site content is in the easy-to-use Markdown format (Kramdown, specifically), so contributors don't need to have any knowledge of HTML or anything else.
+* Jekyll: [getmonero.org](https://getmonero.org/) is made using a simple, static website generator called [Jekyll](https://jekyllrb.com/). You will need it installed on your system to test any changes that you made. Follow the instructions on the website to get up and going:
+  * Install Ruby dependencies as suggested [in the Jekyll documentation](https://jekyllrb.com/docs/installation/)
+  * Install Bundler: `gem install bundler`
+  * Install Jekyll with all dependencies (run from the project directory): `bundle`
 
-## Pages, Formats, and Rules
+* GitHub/GitLab: Pretty much everything in Monero is hosted on [GitHub](https://github.com/monero-project) or [getmonero GitLab](https://repo.getmonero.org/users/monero-project/projects) and uses Git as the primary version control system. If you're not familiar with how to use Git, you can check out [this tutorial](https://guides.github.com/activities/hello-world/) for a good overview. It will take you through pretty much everything you'll need to know to edit the website. If you haven't already, register on GitLab and fork the [Monero Website repository](https://repo.getmonero.org/monero-project/monero-site). Please note that GitLab accounts logged in using the "Log in with GitHub" option require manual intervention in order to be able to fork repositories. Either register your account using email/password or contact the Website Workgroup via GitLab or `#monero-site` to have your GitHub OAuth profile unlocked.
 
-If you would like to suggest changes you can do so by forking the repository, making changes directly on your fork, and then submitting them as pull requests. If you need help doing so feel free to ask for assistance in #monero-dev on Freenode.
+*Note: If you're confused, feel free to click other files in the same directory (folder) that you are in for the step that you are on to see some working examples. Compare them to the instructions and you should understand better.*
 
-Pages and formats should be based off existing pages to maintain a consistent look-and-feel. The following notes apply to various parts of the site:
+Once you have the above list of things, it's typically a good idea to build the website from your local computer to make sure it works before you make any changes. To do this, complete the following steps:
 
-- changes made to _layouts, _includes, and home.php will need to use {% t x.x %} translation tags to pull in the YAML tag from _strings_en.yml, as this is required for multi-language support later on
-- with the exception of something like blog/index.html (that is required to be a .html file for Jekyll's pagination to work) all pages should be .md files
-- since all static content (CSS/JS/images) is hosted in a separate, non-public repository, changes can be suggested via Github issues and we will cross-apply them to that repo, crediting you in the commit message
-- SVG should be used in header icons and diagrams, and FontAwesome icons can be used in text
-- Moneropedia entries require nothing more than creating the .md file in knowledge-base/moneropedia/, please use the 00-base-00 file as a boilerplate
-- To create a CLI screen shot, prefix the text block with {:.cli-code}, and use span elements for the colours; see getting-started/running.md, getting-started/accepting.md, and the account.md Moneropedia entry
+1. Navigate to your local `monero-site` repository.
+2. Serve the website: `bundle exec jekyll serve --baseurl ''`. If you want, you can speedup thi process by loading only the last blog post instead of all of them. Simply add `--limit_posts 1` to the command above. The resulting command will be `bundle exec jekyll serve --limit_posts 1 --baseurl ''`.
+3. Open a browser and go to [http://127.0.0.1:4000](http://127.0.0.1:4000).
+4. If all went well, you should see the Monero website and you're ready to make changes.
 
-## Deployment
+## General change recommendations
+The average Monero user that will want to contribute to the website should probably start looking for issues labelled [⛑️ help needed](https://repo.getmonero.org/monero-project/monero-site/issues?label_name%5B%5D=%E2%9B%91%EF%B8%8F++help+needed) or making blog posts, user guides or Moneropedia entries; all of which are covered in this document. If this is all you want to do, don't worry, it's actually not a daunting task at all.
 
-Deploying this website requires Jekyll (3.0+) and the following ruby gems: builder, rubysl-rexml, jekyll-paginate
+If you are a web developer and would like to make large macro-level changes, it would be best to open an issue first or to get in contact with the developers on `#monero-site` (IRC/Freenode, MatterMost, Matrix).
 
-Multiple language support will be added soon.
+This website is completely open-source however and anything and everything is available for changing should the community deem it necessary.
 
-To test changes locally before pushing to git, make sure you have ruby installed on your system, then:
+Every section from here on out will talk about how to make a specific type of web page. It will start with a bullet point list of what to do for the advanced among you that just want a quick overview. For those who are still learning this list is followed by a detailed explanation, starting with example front matter. Any variable in the front matter written in all caps you are expected to change (make sure your changes are not all caps though). It will then lead you through the rest of the process until it's time to type your content.
 
-1. Make sure you have the necessary ruby gems: `gem install builder rubysl-rexml jekyll-paginate jekyll`
-2. Navigate to the your local `monero-site` repository.
-3. Serve the website: `jekyll serve`
-4. Open a browser and go to [http://127.0.0.1:4000](http://127.0.0.1:4000).
-5. A basic page list will appear. Click on the part of the site you are working on (ex: `design_goals`) and see your work!
+A few random points of note:
 
-## License
+- After [a discussion](https://repo.getmonero.org/monero-project/monero-site/issues/982), the community decided to include only open source wallets in the 'Downloads' section of the website. Requests to add closed source wallets to that page will be rejected.
+- All external links must have `https://` in front of them or they will not redirect properly.
+- If you want to add a new page to the navigation, you should go to ALL LANGUAGES in the `_data/lang` folder and add the page.
+- It is strongly strongly STRONGLY encouraged that if you make a change, you - at the minimum - test it on your local machine before submitting a PR. Sometimes unexpected things may happen due to a change. If you change a page, check the whole page on multiple screen sizes and browsers to make sure there wasn't any collateral damage.
 
-Copyright (c) 2014-2016, The Monero Project
+## Translation
+In this section you'll find the info you need to translate a page and add a new translation, but keep in mind that Monero has a [Localization Workgroup](https://github.com/monero-ecosystem/monero-translations) who coordinate and give support to translators-volunteers. For live support/request of infos, come chat on `#monero-translations` (Freenode/IRC, riot/matrix, MatterMost).
 
-All rights reserved.
+The bulk of the website and the roadmap are translatable on Weblate, an easy to use localization platform that provide contributors with a user friendly interface: [translate.getmonero.org](https://translate.getmonero.org). Before translating, please read [the guide for translators](https://github.com/monero-ecosystem/monero-translations/blob/master/weblate.md), which contains all the info and workflows you need to know before starting.
 
-Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
+We are trying to move most of the localization work on Weblate, but some parts of the website still need to be manually translated on the repository. The following instructions will tell you which files to translate and how to proceed.
 
-1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
+### 1. Quickstart
+* Navigate to the correct language in the /i18n folder and find the page you wish to translate
+* Do not translate any of the `*.yml` files in the /_18n folder
+* Click the file and translate the page, not touching any HTML or markdown
+* Remove `{% include untranslated.html %}` from the page
+* Test/Build
+* Submit PR
 
-2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
+### 2. Navigate to correct file
+Go to the /i18n folder and find the two letter code for the language you wish to translate for. Enter that folder and find the file you wish to translate. The filenames are all in English and MUST NOT BE CHANGED.
 
-3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
+### 3. Translate the file
+Here you can do your translation. Depending on the page, you may have to maneuver around some HTML or markdown. In general, anything between two tags (such as `<p>TRANSLATE THIS</p>`) should be fine. Testing is VERY important, so do NOT skip it. If during testing, the page appears different from the original English page (besides the translated text, of course), you did something wrong and may have to start again.
 
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+#### 3.1. Notes for Moneropedia Entries
+Moneropedia entries have two specificities:
+
+* The Front Matter:  
+Moneropedia Fron should be translated for both *entry:* and *summary:* elements. However, *terms:* should be extanded with their translation, leaving the English words **untouched**.
+This is really important for compatibility purposes. With this, if a new guide is added to the site, an English term on the untranslated version of the guide in another language could be linked to the moneropedia article (of the same language).
+
+* The old *untranslated* snippet must be removed, therefore the next section is irrelevant here.
+
+Finally, your entry should go from:
+```
+---
+entry: "Entry name in English"
+terms: ["English", "terms"]
+summary: "English summary."
+---
+
+{% include untranslated.html %}
+```
+To:
+```
+---
+entry: "Translated entry name"
+terms: ["English", "terms", "translated", "terms"]
+summary: "Translated summary."
+---
+```
+
+### 4. set the 'translated' snippet to true
+Somewhere on the page (usually the top) should be a snippet that says `{% include disclaimer.html translated="false" version=page.version %}`. Simply change this to `{% include disclaimer.html translated="true" version=page.version %}`. This will remove the orange bar from the bottom saying the page is untranslated.
+
+## How to add a new language
+Adding a new language can be complicated. If you feel unsure about the steps necessary, contact the Website workgroup and somebody will add the new language for you.
+
+### 1. \_config.yml file
+Navigate to the root folder of the whole website and find the file labeled `_config.yml`. Open it and find the line that says `languages:`. Add your two letter language code (Google it if you don't know it) in between the brackets after the others already present. You will need to put a comma after the previous last one.
+
+Example:
+```
+languages: ["en", "es", "NEW LANG HERE"]
+```
+Save and exit the file.
+
+### 2. \_data folder
+Navigate to the `_data/lang` folder and copy the `en` folder. Paste it into the same folder and the copy renamed to the two letter language code of the language you will be translated to.
+**The 'en' folder itself should still be there. It should not be renamed. There should be a new folder in addition to the ones that were already there.**
+
+Translate the content of the files. Do not touch anything labeled `url`.
+
+### 3. \_i18n folder
+Navigate to the \_i18n folder and duplicate the en.yml file. Rename the duplicate to the two letter language code of your language with a `.yml`. Now duplicate the `en` folder and rename it with the correct language code.
+**The original folder and yml file themselves should still be there. They should not be renamed. There should be a new folder and yml file in addition to the ones that were already there.**
+
+### 4. Open an issue on the repo where the website is hosted
+After you've done all the above, you'll need to [open an issue on the repository](https://repo.getmonero.org/monero-project/monero-site/issues/new?issue%5Bassignee_id%5D=&issue%5Bmilestone_id%5D=) asking to add the language you are working on to Weblate, where the core of the website is translated.
+
+## Housekeeping
+
+### GitLab Issues
+We ask that if you open an issue on the site that you remain available for clarifying questions or corrections. We do our best to close issues that are resolved when we make changes to the site, but If your issue is resolved by a contributor and the issue is not closed we ask that you close it in a timely manner. A contributor may ask you to close an issue after it's confirmed fixed. Please review the changes to the site and close your issue if you can verify that it's fixed.
+
+## Updates on User Guides
+User guides and developer guides may need regular updates, either to fix typos, to add explanations regarding new features, to update screenshots, and so on.
+As those guides are translated in several languages, it could be hard to keep all languages version up to date with the English version.
+To keep track of those changes, guides are versioned using a snippet at the top of each localized (\_i18n/en/resources/\*-guides) file:
+```
+{% assign version = '1.1.0' | split: '.' %}
+```
+This snippet is responsible for keeping track of the language version.
+
+The based version (English version) is however also tracked in the `Front Matter` from the /resources/user-guides/ or /resources/developer-guides/ directory file:
+```
+mainVersion:
+  - "1"
+  - "1"
+  - "0"
+```
+
+- First number is the Major version number
+- Second number is the Minor version number
+- Third number is the build number.
+
+When you update a guide, you are responsible for updating this version tracking in every file involved in your update:
+
+- For an update on English files, you will update the version tracking number in the `Front Matter` of /resources/\*-guides/ and in \_i18n/en/resources/\*-guides
+- For an update on localized files, you will update the version tracking number in the \_i18n/<local>/resources/\*-guides only, and
+  - You will not update to a higher Major or Minor version number than the reference English guide
+  - If you want to update to a higher Major or Minor version number, you should update the English version accordingly so that English is always the highest Major.Minor version.
+
+And you will increment the version number in the following way:
+
+- Cosmetic change only (typo, rephrasing, screenshot update with exact same field names and positions): Increment the third number (build number). We do not want to even warn the user about this update in another language.
+- Changes that add instructions or explanations (or screenshot updates with different field names and positions), without making the old version misleading for users: Increment the second number (Minor version number) and reset the third to 0. We want to let the user know the English version could be more accurate and helpful to read.
+- Changes that makes the old version false, or misleading to users: Increment the first number (Major version number) and reset the second and third to 1.0. We want to discourage users from reading this too outdated version that could lead them to do wrong things (for instance, buy the wrong algo of mining power on nicehash, after a pow change).
+
+## How to make a blog post
+
+### 1. Make a file
+Navigate to the \_posts folder of the website and make a new file. Be sure the file name has no spaces and the ending is .md. Take a look at the other posts to get an idea of how to name yours
+
+### 2. Front Matter
+```
+---
+layout: post
+title: CHANGE TO YOUR TITLE
+summary: A BRIEF ONE OR TWO SENTENCE SUMMARY
+tags:  [CHOOSE, RELEVANT, TAGS, AND, SEPARATE, THEM, BY, COMMAS, KEEP, THE, BRACKETS]
+author: YOUR NAME OR HANDLE HERE
+---
+```
+
+### 3. Write
+After the front matter is finished you are free to write the remainder of your blog post in markdown.
+
+## How to make a User Guide
+
+### 1. Quick Start
+
+* Create file in /resources/user-guides with an .md ending and no spaces in filename.
+* Create file in /\_i18n/en/resources/user-guides with the exact same filename as above ending in .md
+* Write User Guide
+* Add versioning snippet
+* Copy User Guide file to ALL LANGUAGES in /\_i18n/[ALL LANGUAGES]/resources/user-guides
+* set translation to false in the snippet the top of each language version of your User Guide, except the original language
+* Add guide using markdown in the correct category, and in alphabetic order, in ALL LANGUAGES to /\_i18n/[ALL LANGUAGES]/resources/user-guides/index.md being careful not to mess with any indentation
+* Test/Build
+* Submit PR
+
+### 2. Make a file
+Navigate to the /resources/user-guides folder and make a new file. Be sure the file name has no spaces and the ending is .md
+
+### 3. Content of file
+```
+---
+layout: user-guide
+title: TITLE OF YOUR USER GUIDE
+permalink: /resources/user-guides/NAME-OF-FILE-GOES-HERE.html
+mainVersion:
+  - "1"
+  - "1"
+  - "0"
+---
+
+{% tf resources/user-guides/NAME-OF-FILE-GOES-HERE.md %}
+```
+
+Copy this exactly and merely change the files names where indicated.
+
+### 4. Create file in localization folders
+Navigate to the /i18n/ folder and choose the correct folder for your language. Navigate further into the `resources/user-guides` folders and make a .md file with the EXACT SAME filename as the you made before.
+
+### 5. Write
+Write your user guide. Be succinct but thorough. Remember, people will be using your guides when they need help. Make sure all the information is there. Feel free to use images or screenshots if necessary to help get your point across.
+
+The title should be at the top of the User Guide using a single `#` for an H1 tag. Titles will not be automatically put on these pages as with other pages. There should be NO front matter on this file.
+
+Add the version snippet at the top of your guide (before your title):
+```
+{% assign version = '1.1.0' | split: '.' %}
+{% include disclaimer.html translated="true" version=page.version %}
+```
+Your version should start at `1.1.0` as it is the first Major, first Minor, and no cosmetic changes have occurred.
+
+### 6. Copy User Guide file into all languages
+Copy your file and navigate to each language file in the /i18n folder. In each language folder go to the resources/user-guides folder and paste your user guide (don't worry, you don't have to translate it) there. This is very important, and the site will not build if the file with the same name is not in each language folder.
+
+As you paste into each folder, open up the file and edit the snippet at the top of the file (before your title) to mark it untranslated:
+`{% include disclaimer.html translated="false" version=page.version %}`. This does not need to be done in the original language that the User Guide was written in.
+
+### 7. Add Guide to the 'User Guide' landing page of EACH LANGUAGE
+In the /\_i18n/[ORIGINAL LANGUAGE OF USER GUIDE]/resources/user-guides folder, find the file labeled index.md and open it.
+
+DO NOT CHANGE ANYTHING IN THIS DOCUMENT BESIDES WHAT YOU ARE INSTRUCTED TO.
+
+This file will look quite different because it's HTML. Don't panic. Simply Ctrl + F (i.e. the find feature) and search for the category that you want to put your User Guide in. You will see there are some sections that are not indented like the others. They are flush with the left side of the screen. **Do not change the indentation.** You can put markdown in these areas.
+
+Once you've identified the non-indented area under the category you would like your User Guide to be under, you can use markdown to insert your link with the others in alphabetic order. `[TITLE OF USER GUIDE]({{site.baseurl}}/LINK-TO-USER-GUIDE.html)`. Please note that the file name in between the parentheses must be EXACTLY the same name as the permalink you made in step 5.3, but with a `.html` at the end instead of `.md` and the snippet `{{site.baseurl}}/` before the link.
+
+In the event that you think your User Guide should be in a new Category that doesn't exist yet, contact the Website workgroup.
+
+Repeat the above process for each language version of this index page.
+
+## How to make a Moneropedia Entry
+
+### 1. Make a Global file
+Navigate to the /resources/moneropedia folder and make a new file. Be sure the file name has no spaces and the ending is .md
+Fil this file with this exact content:
+```
+---
+layout: moneropedia
+---
+
+@moneropedia_article
+
+{% t global.lang_tag %}
+{% tf resources/moneropedia/account.md %}
+
+```
+
+### 2. Make the localized File
+Navigate to the /\_i18n/en/resources/moneropedia folder and make a new file. give it the same <name>.md than in previous step.
+Start the file with the front Matter:
+```
+---
+entry: "PUT THE NAME OF THE TERM HERE IN QUOTE, THIS IS HOW IT WILL SHOW UP ON THE LANDING PAGE"
+terms: ["PUT", "TERMS", "HERE", "EXPLAINED", "BELOW"]
+summary: "PUT SUMMARY OF YOUR ENTRY HERE IN QUOTES"
+---
+```
+
+There are two things to highlight:  
+The `terms:` section of the front matter can be filled with as many terms as you would like. This is how other Moneropedia entries will link to this page. You can link to other Moneropedia entries as well in your page by putting an ampersand before the term used, i.e. `@THE-TERM-USED`. This will make an automatic link in the Moneropedia entry to the referred term, replace the @term with the word used in that terms `entry:` area of the front matter, and on hover it will show the summary. How cool is that?  
+The lines must not contain trailing whitespace, and it must be no blank lines added, otherwise the site with not build correctly.
+
+### 3. Write
+Write your Moneropedia entry. Remember that you can link to other Moneropedia entries using `@term-used-in-entry` as described above. Just go to the .md file of the Moneropedia entry you want to link to and use any of the terms in the `terms:` field of the front matter. Be sure to write whichever one you choose EXACTLY as shown and preceded by an ampersand.
+
+### 4. Copy to other languages
+Copy the file from the /\_i18n/en/resources/moneropedia folder to the other /\_i18n/<language>/resources/moneropedia folders and add the untranslated snippet at the same time just after the front matter, so it looks like:
+```
+---
+entry: "PUT THE NAME OF THE TERM HERE IN QUOTE, THIS IS HOW IT WILL SHOW UP ON THE LANDING PAGE"
+terms: ["PUT", "TERMS", "HERE", "EXPLAINED", "BELOW"]
+summary: "PUT SUMMARY OF YOUR ENTRY HERE IN QUOTES"
+---
+
+{% include untranslated.html %}
+```
+
+## How to update the Team page
+
+If you are acting on behalf of another individual, please make sure you get their permission first before adding them onto the Team page.
+
+### 1. Change the .yml file
+Navigate to the `/_data/` folder and open `team.yml`. You will notice a long list separated by main `-area:` tags.
+
+**DO NOT MESS WITH THE FORMATTING OR INDENTATION OF ANYTHING OR JEKYLL WILL NOT BUILD PROPERLY!**
+
+Find the area that you want to update and copy the code below:
+```
+- name:
+  url:
+```
+Put the name or handle of the person in the `name` section and in the  `url:` section put the link to their GitHub or GitLab URL (it must have https:// at the beginning). If they have no GitHub, then you may leave it blank, it won't mess anything up.
+
+**Make sure the indentation is EXACTLY the same as the other proposals in the area. If it's not the jekyll build WILL fail.**
+
+Save the file.
+
+## How to update the Roadmap
+
+### 1. Edit the .yml file
+Navigate to the `/_data/` folder and open `lang/en/roadmap.yml`. You will notice this structure:
+
+```
+year_2014:
+- month:
+  STATUS:
+    - name:
+```
+Where STATUS can be either `completed`, `ongoing` or `upcoming`.
+
+Look for the year and month related to the entry you want to add, if the month and status are already present, simply add `- name: NAME OF YOUR ENTRY` in the correct position.
+
+For example, there was a new release on March 2020 and you would like to add it to the roadmap as "completed":
+
+- Scroll the `roadmap.yml` file until you arrive to `year_2020`
+- The milestone happened in March so you need to look for that month (`- month: March`)
+- Since the milestione has been already achieved, look for the `completed:` status.
+- Under it add `-name: NAME OF YOUR ACHIEVED MULESTONE`. Which in our case would be `-name: release wallet WHATEVER`
+
+If a year, month or status is missing, simpluy adding by following the structure you see in the page.
+
+**Make sure the indentation is EXACTLY the same as the other proposals in the area. If it's not the jekyll build WILL fail.**
+
+The translation of the roadmap happens [on Weblate](https://translate.getmonero.org/projects/getmonero/roadmap/).
+
+## How to add a new Merchant
+
+### 1. Edit the .yml file
+Navigate to the `/_data/` folder and open `merchants.yml`. You will notice a list separated by hyphenated `-category` tags.
+
+Find the category that best describes your business/service and copy the code below, making sure you are keeping the alphabetic order consistent:
+```
+- name:
+  url:
+```
+and paste it in the correct category under the `merchants:` section.
+
+Fill in the data as follows:
+* `name:` The name of the business/service.
+* `url:` The external url of the business/service. This link must have http:// (or https://) at the beginning if it is an external link.
+
+**Make sure the indentation is EXACTLY the same as the other proposals in the area. If it's not the jekyll build WILL fail.**
+
+Save the file.
+
+## How to add a question to the FAQ
+The structure of the FAQ is a bit more complex than it used to be and contains anchors, variables and a TOC. A step by step guide would be too complex to follow. A basic knowledge of HTML is necessary to edit the page. If you wish to add a new FAQ please open an issue in the repository or/and contact the Website workgroup.
+
+## How to add a publication to the Library
+
+### 1. Add your file
+Navigate to the `/library/` folder and drop your publication file here.
+
+Please remind to minimize the size of your publication. For PDF, you'll find a large amount of service to compress your file with a minimal loss in quality.
+
+### 2. Edit the .yml files
+Navigate to the `/_i18n/` folder and open `en.yml`.
+
+Go down until you find the `library` section. You will notice a list separated by hyphenated `-category` tags in a `books:` section.
+
+Find the category that best corresponds your publication and copy the code below:
+```
+- name: "<name>"
+  file: "<filename>"
+  abstract: >
+    <abstract><br>
+    <on multiple lines>
+```
+and paste it in the correct category under the `publications:` section.
+
+For books, paste it in alphabetical order. For magazines, past it at the top.
+
+Fill in the placeholders as follows:
+* `<name>` The name of the publication, as it should be displayed.
+* `<file>` The filename you have dropped in `/library/` folder, including extension.
+* `<abstract>`,`<on multiple lines>` An abstract for your publication, formatted with html newlines `<br>`
+
+**Make sure the indentation is EXACTLY the same as the other proposals in the area. If it's not the jekyll build WILL fail.**
+
+Save the file.
\ No newline at end of file