Previous Page

nihilist@Mainpc-PrivateVM-Debian12 - 2025-03-21

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, 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:

For example, to brainstorm with the contributors and adjust todolists:

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.

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

Make sure that you also take part in the criticisms and debates in the public 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.)

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 it 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:

[ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [~]
→ cd Documents

[ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [~/Documents]
→ torsocks git clone http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/optimist/blog-contributions blog-contributions.optimist
Cloning into 'blog-contributions'...
remote: Enumerating objects: 6608, done.
remote: Counting objects: 100% (6608/6608), done.
remote: Compressing objects: 100% (5362/5362), done.
remote: Total 6608 (delta 3302), reused 3611 (delta 1133), pack-reused 0 (from 0)
Receiving objects: 100% (6608/6608), 342.55 MiB | 522.00 KiB/s, done.
Resolving deltas: 100% (3302/3302), done.

[ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [~/Documents]
→ cd blog-contributions.optimist

If they wrote their changes in a separate git branch, switch to the correct branch like so:

[ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [blog-contributions.optimist/opsec/nextcloud] → git switch branchname

[ 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 local browser you can assess if the contribution is completed, and if it follows the quality standard:

Here as you can see, this is clearly garbage, so you can make the following assessment:

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:

[ 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

Then, locally you can do a git pull to review their updates:

From there, there are still a few minor mistakes that they can improve on:

And lastly they fixed the remaining issues and now upon reviewing that's now an OK contribution:

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.

Then the administrator issues payment for both the contributor and to you the maintainer, for correctly reviewing a contribution.