How to become a Maintainer
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: You should have contributed at least 3 times, having submitted contributions that were already nearly finished (95%) in one go. 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 when doing contribution reviews, therefore i expect that they show that they understand it.
Onboarding new Contributors
First of all if there are new contributors that want to join in and contributors, maintainers need to invite them to the contributors chatroom, (and if said maintainer is an administrator, give them their git account credentials):
Once added in private messages, the user can be invited (and can safely get their new git account credentials) :
In the Contributors chatroom, the contributors will be able to communicate with maintainers directly:
Converting Criticism into todolists
As a maintainer, you get to also be paid for writing valid (and actionnable) todolists , 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 the public OPSEC chatroom.
As a maintainer, you are getting rewarded 2 euros per valid todolist , 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. So if you write a new todolist, please make sure that you save the link to the todolists that you wrote so that you can ask to recieve payment at the end of the month for all of the todolists you wrote, in one go.
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) to then write alot of todolists , 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).
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
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.)
If you want to save the criticism somewhere on the git repo for later, go into the maintainers project board and create a git issue there, with the title starting with "Criticism - For the tutorials XYZ", and make sure you add the label "criticism to convert into todolists" , that'll help us make sure that criticisms aren't lost forever, but rather are stored somewhere, to be treated at a later time:
See this git issue for instance, that i created to contain the valid criticism i recieved for the Sensitive VMS tutorial, that i saved here to treat (or let another maintainer) treat at a later time.
When you decide to turn criticisms into todolists, follow the usual format as detailed in the previous "how to become a contributor" tutorial:
to be explained: (why + what)
-
-
-
to be showcased: (How)
-
-
-
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. (With only other maintainers or administrators being able to overrule your judgement)
Assigning contributors onto todolists
As a maintainer you also get to assign people to work on todolists:
You get to have authority on deciding what todolists get to contain (with only the other maintainers and administrators being able to overrule your decisions), you can validate them or edit them however you wish, only if they are not yet assigned (do not change a todolist if there's already someone working on it).
(don't forget to move the issue into the "assigned" column on the project board aswell:
Reviewing Contributions
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 this issue:
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 the quality standard, as a maintainer, you are supposed to make sure that they follow that standard whenever they try to contribute new content.
Here for example, the contributor "optimist" submits a contribution after having followed the "how to contribute" guide, and lets you know in the contributors chatroom:
Going there you see that the contributor correctly made a PR, but you need to git clone it to review the changes:
[ localhost ] [ /dev/pts/23 ] [~/Documents]
→ torsocks git clone http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/optimist/opsec-blogposts opsec-blogposts.optimist
Cloning into 'opsec-blogposts'...
remote: Enumerating objects: 2110, done.
remote: Counting objects: 100% (2110/2110), done.
remote: Compressing objects: 100% (2106/2106), done.
remote: Total 2110 (delta 62), reused 1996 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (2110/2110), 193.91 MiB | 146.00 KiB/s, done.
Resolving deltas: 100% (62/62), done.
If they wrote their changes in a separate git branch, switch to the correct branch like so:
[ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [opsec-blogposts.optimist/nextcloud]
→ git switch branchname
Then in the cloned repository, navigate to the new tutorial folder to get the path:
[ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [~/Documents/blog-contributions.optimist]
→ cd opsec/nextcloud
[ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [blog-contributions.optimist/opsec/nextcloud]
→ pwd
/home/nihilist/Documents/blog-contributions.optimist/opsec/nextcloud
And in there from your vscodium editor you can assess if the contribution is completed, and if it follows the quality standard.
Here as you can imagine, 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 the following assessment, or since this was a low effort you could simply post a low effort review like so:
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.
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:
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:
Then, locally you can do a git pull to review their updates, in order to review their contribution locally again:
[ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [blog-contributions.optimist/opsec/nextcloud]
→ cd ../..
[ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [~/Documents/blog-contributions.optimist]
→ torsocks git pull
` 
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. Otherwise confirm that the contribution is OK and ready to be merged (using the good to merge git label)
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.
- 1 back and forth: (easy review) 3 euros
- 2 backs and forth: (average review) 5 euros
- 3+ backs and forth: (tedious review) 8 euros
Obviously, no need to be an ultra-perfectionnist for every detail that doesnt truly matter, however The top priority here is that the blogpost needs to be CRYSTAL CLEAR 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. 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.
Dealing with Lazy and Incompetent Contributors
Just warning you, this is the most annoying part of being a maintainer, so if the reviewing is extra-tedious because you are facing an incompetent or lazy contributor, don't worry i'll send you extra monero your way for your trouble.
I don't want this blog to contain ANY half-assed content, the only acceptable content is VALID, FINISHED, QUALITY content. 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). if contributor A is not going to write a tutorial correctly before the deadline, REJECT THEIR CONTRIBUTION , contributor B will write it correctly later on (Sum Nihil, don't care who does what, only care about what they do).
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.
I repeat, If a contributor doesn't contribute quality after being told to do so, DO. NOT. CARE. REJECT THEIR CONTRIBUTION. It's not for you to do it for them, it is for them to step up to do it themselves, 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.
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.
Suggest changes
nihilist 2025-03-21
Donate XMR to the author:
8AUYjhQeG3D5aodJDtqG499N5jXXM71gYKD8LgSsFB9BUV1o
7muLv3DXHoydRTK4SZaaUBq4EAUqpZHLrX2VZLH71Jrd9k8