new maintainers tutorial

opsec/index.html

@@ -405,7 +405,7 @@
                 <li><a href="http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/blog-contributions/issues/250">❌ How to become a Moderator </a></li>
                 <li><a href="contribute/index.html">✅ How to become a Contributor</a></li>
                 <li><a href="qualitystandard/index.html">✅ The Quality Standard</a></li>
-                <li><a href="http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/blog-contributions/issues/203">❌ How to become a Maintainer</a></li>
+                <li><a href="maintainers/index.html">✅ How to become a Maintainer</a></li>
                 <li><a href="http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/blog-contributions/issues/249">❌ How to become an Administrator</a></li>
                 <li><a href="runtheblog/index.html">✅ How to run the blog yourself</a></li>
 </ol></br>
@@ -424,7 +424,7 @@
 <h2><b> Inspirations</b></h2>
 
 <ol>
-	<li><a href="https://anonymousplanet.org/guide.html">The Hitchhiker's guide to Anonymity</a> (the entire opsec category was inspired from this awesome guide, check them out!)</li>
+	<li><a href="http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/The-Hitchhikers-guide-to-Anonymity/src/branch/main/guide.md">The Hitchhiker's guide to Anonymity</a> (the entire opsec category was inspired from this awesome guide, check them out!)</li>
 	<li><a href="https://git.hackliberty.org/hackliberty.org/Hack-Liberty-Resources">Hack Liberty Resources</a></li>
 	</ol></br>
           <h2><b>Non-KYC VPS providers</b></h2> </br> </br>

opsec/maintainers/index.html

@@ -56,14 +56,14 @@
 
 	<!-- +++++ Posts Lists +++++ -->
 	<!-- +++++ First Post +++++ -->
-	<div id="anon2">
+	<div id="anon3">
 	    <div class="container">
 			<div class="row">
 				<div class="col-lg-8 col-lg-offset-2">
-  					<a href="../index.html">Previous Page</a></br></br><p><img src="../../assets/img/user.png" width="50px" height="50px"> <ba>nihilist@Mainpc-PrivateVM-Debian12 - 2025-03-21</ba></p>
+  					<a href="../index.html">Previous Page</a></br></br><p><img src="../../assets/img/user.png" width="50px" height="50px"> <ba>nihilist@mainpc - 2025-03-21</ba></p>
 <h1>How to become a Maintainer </h1>
 <img src="0.png" class="imgRz">
-<p>Becoming a Maintainer is the next step to contribute to the Opsec blog and Darknet Lantern projects, where you get to assist the other contributors contribute just like you did. The requirement is simple: <b>You should have contributed at least 3 times, having submitted contributions that were already nearly finished (95%) in one go.</b> If you are still submitting contributions that are 75% finished in one go, you are not ready to become a maintainer yet, maintainers are supposed to know the quality standard perfectly, therefore i expect that they show that they understand it.</p>
+<p>Becoming a Maintainer is the next step to contribute to the Opsec blog and Darknet Lantern projects, where you get to assist the other contributors contribute just like you did. The requirement is simple: <b>You should have contributed at least 3 times, having submitted contributions that were already nearly finished (95%) in one go.</b> If you are still submitting contributions that are 75% finished in one go, you are not ready to become a maintainer yet, maintainers are supposed to know the quality standard perfectly, to be able to enforce it <a href="https://www.youtube.com/watch?v=jJuNQeG9Irc&t=4m14s">when doing reviewing contributions</a>, therefore i expect that they show that they understand it.</p>
           
 	       </div>
 			</div><!-- /row -->
@@ -71,7 +71,7 @@
 	</div><!-- /grey -->
 
 	<!-- +++++ Second Post +++++ -->
-	<div id="anon3">
+	<div id="anon2">
 	    <div class="container">
 			<div class="row">
 				<div class="col-lg-8 col-lg-offset-2">
@@ -82,13 +82,44 @@
 <img src="1.png" class="imgRz">
 <p>In the Contributors chatroom, the contributors will be able to communicate with maintainers directly:</p>
 <img src="2.png" class="imgRz">
-<p>For example, to brainstorm with the contributors and adjust todolists:</p>
-<img src="3.png" class="imgRz">
-<p>As a maintainer, you are getting rewarded 2 euros per todolist that you correctly write for each git issue, so if you edit one, please make sure that you save the link to the todolists you wrote so that you get to recieve payment at the end of the month for them.</p>
-<img src="7.png" class="imgRz">
-<p>If there are any valid criticisms to tutorials that are supposed to be finished, write the todolist on the issue (in the completed column), and move it back to the "to be assigned" column</p>
+	       </div>
+			</div><!-- /row -->
+	    </div> <!-- /container -->
+	</div><!-- /grey -->
 
-<p>Make sure that you also take part in the criticisms and debates in <a href="https://simplex.chat/contact#/?v=2-7&smp=smp%3A%2F%2FBD4qkVq8lJUgjHt0kUaxeQBYsKaxDejeecxm6-2vOwI%3D%40b6geeakpwskovltbesvy3b6ah3ewxfmnhnshojndmpp7wcv2df7bnead.onion%2FdXQ3FLM5ufTNQxgXU6jm07fRXSq9Ujkt%23%2F%3Fv%3D1-3%26dh%3DMCowBQYDK2VuAyEAzABUDXe4g0bjXyPcNOU0QzWxMYMMGgR3kcOQacoEaQ0%253D&data=%7B%22groupLinkId%22%3A%22G3yklv9753AcNA7lGV3FBw%3D%3D%22%7D">the public OPSEC chatroom</a>, as this is the place where you'll see the most criticism coming from, so if there are any valid criticisms coming from there, make sure that the criticism is at least saved somewhere (ideally on the targeted git issue, or on a new one that you created yourself.)</p>
+	<!-- +++++ Second Post +++++ -->
+	<div id="anon3">
+	    <div class="container">
+			<div class="row">
+				<div class="col-lg-8 col-lg-offset-2">
+          <h2><b>Converting Criticism into todolists</b></h2>
+<p>As a maintainer, <b>you get to also be paid for writing valid (and actionnable) todolists</b>, since you get to have authority on what they contain, and you get to decide if they are valid or not. This is why it is important for you to take part in the debates that are happening in <a href="https://simplex.chat/contact#/?v=2-7&smp=smp%3A%2F%2FBD4qkVq8lJUgjHt0kUaxeQBYsKaxDejeecxm6-2vOwI%3D%40b6geeakpwskovltbesvy3b6ah3ewxfmnhnshojndmpp7wcv2df7bnead.onion%2FdXQ3FLM5ufTNQxgXU6jm07fRXSq9Ujkt%23%2F%3Fv%3D1-3%26dh%3DMCowBQYDK2VuAyEAzABUDXe4g0bjXyPcNOU0QzWxMYMMGgR3kcOQacoEaQ0%253D&data=%7B%22groupLinkId%22%3A%22G3yklv9753AcNA7lGV3FBw%3D%3D%22%7D">the public OPSEC chatroom</a>. </p>
+<img src="3.png" class="imgRz">
+<p>As a maintainer, <b>you are getting rewarded 2 euros per valid todolist</b>, all you need to do is write them (coming from criticisms that you either make, or that the other community members make), then you need to put them on each git issue that they are related to. <b>So if you write a new todolist, please make sure that you save the link to the todolists that you wrote</b> so that you can ask to recieve payment at the end of the month for all of the todolists you wrote, in one go.</p>
+<img src="16.png" class="imgRz">
+<p>The financial incentive lies is in tracking all the valid criticisms that are being thrown at us in the public chatrooms (which are all opportunities to improve, that's why we welcome it) <b>to then write alot of todolists</b>, for example if you write 10 valid todolists in 1 month time, you'll recieve 20 euros in monero for correctly writing them (as the payment is 2 euros PER todolist correctly written). </p>
+<img src="7.png" class="imgRz">
+<p>If there are any valid criticisms to tutorials that are supposed to be finished (meaning there are tutorials that need to be improved), write the todolist on the issue (in the completed column), and move it back to the "to be assigned" column</p>
+
+<p>Therefore make sure that you take part in the criticisms and debates in in the opsec chatroom, as this is the place where you'll see the most criticism coming from, so if there are any valid criticisms coming from there, make sure that the criticism is at least saved somewhere (ideally on the targeted git issue, or on a new one that you created yourself.)</p>
+<p>If you want to save the criticism somewhere on the git repo for later, go into the <a href="http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/blog-contributions/projects/6">maintainers project board</a> and create a git issue there, with the title starting with <b>"Criticism - For the tutorials XYZ", and make sure you add the label "criticism to convert into todolists"</b>, that'll help us make sure that criticisms aren't lost forever, but rather are stored somewhere, to be treated at a later time: </p>
+<img src="17.png" class="imgRz">
+<p>See this <a href="http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/blog-contributions/issues/246">git issue</a> for instance, that i created to contain the valid criticism i recieved for the <a href="../sensitivevm/index.html">Sensitive VMS tutorial</a>, that i saved here to treat (or let another maintainer) treat at a later time.</p>
+<img src="18.png" class="imgRz">
+<p>When you decide to turn criticisms into todolists, follow the usual format as detailed in the previous <a href="../contribute/index.html">"how to become a contributor"</a> tutorial:</p>
+<pre><code class="nim">
+to be explained: (why + what)
+-
+-
+-
+
+to be showcased: (How)
+-
+-
+-
+
+</pre></code>
+<p>If you are not sure about if a particular todolist/criticism is valid or not, you can ask an administrator their opinion to know if it's OK or not aswell, to double check. But by default, as a maintainer your judgement is going to be trusted to write correct todolists. (</p>
 
 	       </div>
 			</div><!-- /row -->
@@ -120,7 +151,8 @@
           <h2><b>Reviewing Contributions</b></h2>
 <p>And lastly, the maintainer's role is to review contributions whenever a contributor submits one, That's probably the most time consumming part. For example, we have the following contributor that's assigned on <a href="http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/blog-contributions/issues/233">this issue</a>:</p>
 <img src="8.png" class="imgRz">
-<p>As you are most likely already aware since you are supposed to already be a contributor, whenever someone submits a contribution, they need to follow <a href="../qualitystandard/index.html">the quality standard</a>, <b>as a maintainer, you are supposed to make sure that they follow it whenever they try to contribute new content.</b></p>
+<p>As you are most likely already aware since you are supposed to already be a contributor, whenever someone submits a contribution, they need to follow <a href="../qualitystandard/index.html">the quality standard</a>, <b>as a maintainer, you are supposed to make sure that they follow that standard whenever they try to contribute new content.</b> </p>
+
 
 <p>Here for example, the contributor "optimist" submits a contribution after having followed the <a href="../contribute/index.html">"how to contribute"</a> guide, and lets you know in the contributors chatroom:</p>
 <img src="9.png" class="imgRz">
@@ -146,13 +178,12 @@ Resolving deltas: 100% (3302/3302), done.
 
 <p>If they wrote their changes in a separate git branch, switch to the correct branch like so:</p>
 <pre><code class="nim">
-
-</pre></code>
 [ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [blog-contributions.optimist/opsec/nextcloud]
 → git switch branchname
 
+</pre></code>
+<p>Then in the cloned repository, navigate to the new tutorial folder to get the path:</p>
 <pre><code class="nim">
-
 [ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [~/Documents/blog-contributions.optimist]
 → cd opsec/nextcloud
 
@@ -163,8 +194,23 @@ Resolving deltas: 100% (3302/3302), done.
 </pre></code>
 <p>And in there from your local browser you can assess if the contribution is completed, and if it follows the quality standard: </p>
 <img src="11.png" class="imgRz">
-<p>Here as you can see, this is clearly garbage, so you can make the following assessment:</p>
-<p>Then they push some more commits to fix their mistakes and ask for a second review, so since you already git cloned their repository you just need to do a git clone to pull their new commits:</p>
+<p>Here as you can see, this is clearly garbage. It does not follow the quality standard at all, and it even deviates from the todolist that the contributor agreed to work on. So you can either spend 10x more time reviewing what they took to write by making <a href="http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/blog-contributions/pulls/253#issuecomment-1997">the following assessment</a>, or since this was a low effort you could simply post a low effort review like so:</p>
+<img src="23.png" class="imgRz">
+<pre><code class="nim">
+1) re-read the quality standard
+2) re-read the methodology on how to contribute
+3) re-read the todolist again and follow it this time 
+
+this is 30% completed.
+
+</pre></code>
+
+<p>On the contrary, if the user actually tried his best to write the contribution, (meaning it has to be above 30% completed FOR SURE, ideally 95% completed) then yes give them a lengthy review to help them better their contribution like the one that oxeo wrote:</p>
+<img src="12.png" class="imgRz">
+<p>Then the contributor pushes some more commits to fix their mistakes and ask for a second review, so since we already git cloned their repository we just need to do a git clone to pull their new commits:</p>
+<img src="13.png" class="imgRz">
+<img src="14.png" class="imgRz">
+<p>Then, locally you can do a git pull to review their updates, in order to review their contribution locally again: </p>
 <pre><code class="nim">
 [ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [blog-contributions.optimist/opsec/nextcloud]
 → cd ../..
@@ -174,11 +220,39 @@ Resolving deltas: 100% (3302/3302), done.
 
 </pre></code>
 
-<p>Then, locally you can do a git pull to review their updates: </p>
-<p>From there, there are still a few minor mistakes that they can improve on:</p>
-<p>And lastly they fixed the remaining issues and now upon reviewing that's now an OK contribution:</p>
-<p>So on the issue you mark it as good to go, and you add the label "good to merge" so that the administrators knows that it's good to be merged.</p>
-<p>Then the administrator issues payment for both the contributor and to you the maintainer, for correctly reviewing a contribution.</p>
+<img src="15.png" class="imgRz">
+<p>And from there, if there are still mistakes that they can improve on, tell them that the contribution is (depending your assessment) for example 80% completed, stating what's missing still. <b>Otherwise confirm that the contribution is OK and ready to be merged (using the good to merge git label)</b> </p>
+<img src="19.png" class="imgRz">
+<img src="22.png" class="imgRz">
+<p>Then the administrator issues payment for both the contributor and to you the maintainer, for correctly reviewing a contribution. For maintainers specifically, the payment for the reviews will depend on how tedious the reviewing was.</p>
+<pre><code class="nim">
+- 1 back and forth: (easy review) 3 euros
+- 2 backs and forth: (average review) 5 euros
+- 3+ backs and forth: (tedious review) 8 euros
+
+</pre></code>
+<p>Obviously, no need to be an ultra-perfectionnist for every detail that doesnt truly matter, however <b> The top priority here is that the blogpost needs to be CRYSTAL CLEAR</b> It needs to be easy to understand, from start to finish, while containing all the information one needs to understand what we are talking about, and how to achieve the targeted setup. <b>If the noobs out there don't understand what the hell we're talking about, then we are doing them a disservice by writing those blogposts.</b></p>
+
+				</div>
+			</div><!-- /row -->
+	    </div> <!-- /container -->
+	</div><!-- /white -->
+	<div id="anon2">
+	    <div class="container">
+			<div class="row">
+				<div class="col-lg-8 col-lg-offset-2">
+          <h2><b>Dealing with Lazy and Incompetent Contributors</b></h2></br>
+<p>Just warning you, this is the most annoying part of being a maintainer, so <b>if the reviewing is extra-tedious becuase you are facing an incompetent or lazy contributor, don't worry i'll send you extra monero your way for your trouble.</b> </p>
+
+<p>I don't want this blog to contain ANY half-assed content, <b>the only acceptable content is VALID, FINISHED, QUALITY content.</b> It takes time to have quality, that's why we give a 1 month default deadline (which is more than enough 99% of the time, even for complex contributions). <b>if contributor A is not going to write a tutorial correctly before the deadline, REJECT THEIR CONTRIBUTION</b>,  contributor B will write it correctly later on (<a href="../../productivity/sum-nihil/index.html">Sum Nihil</a>, don't care who does what, only care about what they do). </p>
+
+<p>With a 1 month deadline, there's no rush. Do not tolerate laziness or incompetence coming from contributors. Whoever wants to contribute to the blog is expected to follow the todolist, and follow the quality standard. If that contributor does not contribute quality, it means that they do not WANT to contribute quality. And if that's the case, do not waste your time on them.</p>
+<img src="21.png" class="imgRz">
+<p> <b>I repeat, If a contributor doesn't contribute quality after being told to do so, DO. NOT. CARE. REJECT THEIR CONTRIBUTION.</b> It's not for you to do it for them, <u>it is for them to step up to do it themselves,</u> do not treat them like a baby, if something needs to be fixed, tell them to fix it, and wait for them to fix it. From my own experience, if the contributor is not competent, it is not worthwhile to keep recieving contributions coming from them, as they are simply wasting the reviewers' time. </p>
+<p>The contributor is expected to know what they are talking about, and they must be willing to write it in the correct way, so that their knowledge is correctly transmitted to the readers out there.</p>
+
+
+
 				</div>
 			</div><!-- /row -->
 	    </div> <!-- /container -->