fix alot of shit, post-mkdocs contribute guides fixed

This commit is contained in:
nihilist 2025-05-08 21:51:34 +02:00
parent abc95a5139
commit d43e7a15b1
41 changed files with 452 additions and 553 deletions

Binary file not shown.

Before

Width:  |  Height:  |  Size: 53 KiB

After

Width:  |  Height:  |  Size: 246 KiB

Before After
Before After

View file

@ -16,36 +16,36 @@ In order to make sure the content isn't rushed and the quality of the blog overa
![](50.png)
Rather than writing a gigantic wall of text and loose you halfway, as you can see i made a graph. This is the most effective way of conveying your ideas to your audience, so don't hesitate to make graphs using drawio (with colors preferably) instead of writing walls of text that nobody will read.
Rather than writing a gigantic wall of text and loose you halfway, as you can see i made a graph. DO IT. **Making a Graph is the most effective way of conveying your ideas to your audience**, so don't hesitate to make colorful graphs using drawio (with colors preferably) instead of writing walls of text that nobody will read.
First of all, the general structure of the content is with the **Why / What / How methodology** This following the minimalistic style where everything that is used and mentionned must be justified. (Everything that has no justification to be there, is to simply be removed.)
1. **Why should I care ?
1. **Why should I care ? In which context ?**
**
2. **What are my options ?
**
3. **How can i implement it ?
2. **What is the solution ?**
**
3. **How can i implement it ?**
Nobody cares about your message until you tell them **why they should care.** Usually that goes by telling them a short story that they can relate to, in our case it's an opsec scenario that explains what an adversary can do against you.
Nobody cares about your message until you tell them **why they should care.** Usually that goes by giving the context and telling them a short story that they can relate to, in our case it's an opsec scenario that explains what an adversary can do against you.
**The blog is structured around 3 core scenarios:**
1. _Privacy:_ The adversary can see you do something, how can you prevent it ?
1. Privacy: The adversary can see you do something, how can you prevent it ?
2. _Anonymity:_ The adversary knows that it's you who did it, how can you prevent it ?
2. Anonymity: The adversary knows that it's you who did it, how can you prevent it ?
3. _Deniability:_ The adversary busts down your door, and forces you to open your devices, how can you make sure he doesn't find anything in there ?
3. Deniability: The adversary busts down your door, and forces you to open your devices, how can you make sure he doesn't find anything in there ?
**If the scenario of your contribution doesn't fit into (or serve a purpose for) one of those 3, it's most likely off-topic.**
**WARNING: If the scenario of your contribution doesn't fit into (or serve a purpose for) one of those 3, it's most likely [off-topic](../offtopic/index.md).**
Context: In your house, in your bedroom, if there are windows to look outside
@ -104,7 +104,6 @@ Let's take a small todolist that is as follows:
` ![](51.png)
Here we have a combination of the 3 possible types of steps you may be expected to showcase, a physical step, a GUI digital step, and a CLI digital step.
@ -119,19 +118,17 @@ In the case of the physical step, you need to take a picture, and add arrows in
While editing the html file it will look like that (as you need to put the picture in the same folder as the tutorial you're editing):
<__img src="1.png">
![](1.png)
If you want to reuse an image from another tutorial like i just did above (it's totally fine), but rather than copying the image from another tutorial and waste diskspace, you can simply reuse the image of another tutorial by adding ../tutorialfolder/ before the path of the image like so:
<__img src="../graphene/10.png">
![](../graphene/10.png)
and lastly if you have a CLI step to show, you need to simply copy paste the terminal output in the pre code blocks while still highlighting what's important like so:
<__pre> <__code class="nim">
nowhere#**./flash-all.sh**
nowhere#./flash-all.sh
Warning: skip copying bootloader_a image avb footer (bootloader_a partition size: 0, bootloader_a image size: 14125140).
Sending 'bootloader_a' (13794 KB) OKAY [ 0.364s]
Writing 'bootloader_a' (bootloader) Flashing pack version slider-14.5-11677881
@ -167,7 +164,6 @@ and lastly if you have a CLI step to show, you need to simply copy paste the ter
**Finished. Total time: 0.150s**
nowhere#
<__/pre> <__/code>
If there are parts of the commandline output that don't matter, just replace them with [...] in order to stick to what the user needs to see.
@ -185,11 +181,29 @@ And lastly, if you are someone that makes alot of spelling and grammar mistakes
` ![](53.png) ![](54.png) ![](55.png) ![](56.png) ![](57.png) ![](61.png) ![](58.png) ![](59.png) ![](60.png) ![](62.png)
![](53.png)
![](54.png)
![](55.png)
![](56.png)
![](57.png)
![](61.png)
![](58.png)
![](59.png)
![](60.png)
![](62.png)
Now using this addon you can find your typos more easily (as it highlights them for you), effectively helping you find and fix them, so if english isn't your first language **definitely make sure that you run LTEX+ once after you finished writing your article, so that you don't leave spelling mistakes behind.**
**DISCLAIMER: a blogpost is NOT complete until it follows this quality standard** , if you find one that doesn't meet those requirements, do mention it on their [gitea issue](http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/blog-contributions/projects/1) or ping me directly about it on SimpleX.
**DISCLAIMER: a blogpost is NOT complete until it follows this quality standard** , if you find one that doesn't meet those requirements, do mention it on their [Forgejo issue](http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/blog-contributions/projects/1) or ping me directly about it on SimpleX.
Same thing if you want to contribute a blogpost that does not meet these quality requirements, **_i do not care, it is NOT finished until it meets those requirements._** Do not be suprised if i refuse your blog contribution for weeks on end if it doesn't meet the requirements. It may take a little more time to do things properly, but at least you're not lowering the quality of the overall blog by following it.
Same thing if you want to contribute a blogpost that does not meet these quality requirements, **_we do not care, it is NOT finished until it meets those requirements._** Do not be suprised if we refuse your blog contribution for weeks on end if it doesn't meet the quality requirements. It may take a little more time to do things properly, but at least you're not lowering the quality of the overall blog by following it.