maintainers gitea preview

This commit is contained in:
oxeo0 2025-05-22 16:25:09 +02:00
parent f5c664c9b3
commit 0a907fa817
6 changed files with 13 additions and 55 deletions

Binary file not shown.

Before

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 80 KiB

BIN
maintainers/24.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 23 KiB

BIN
maintainers/25.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 53 KiB

BIN
maintainers/26.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

View file

@ -14,7 +14,7 @@ Becoming a Maintainer is the next step to contribute to the Opsec blog and Darkn
## **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):
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):
![](0.5.png)
@ -95,49 +95,19 @@ Here for example, the contributor "optimist" submits a contribution after having
![](9.png)
Going there you see that the contributor correctly made a PR, but you need to git clone it to review the changes:
Going there you see that the contributor correctly made a PR, but you need to review the changes:
![](10.png)
> Don't mind the different PR example in this section, we're back to the nextcloud one later
![](25.png)
![](26.png)
It is possible to view his markdown changes directly in Forgejo without cloning anything.
![](24.png)
```sh
[ 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](http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/blog-contributions/pulls/253#issuecomment-1997), or since this was a low effort you could simply post a low effort review like so:
Here as you can imagine, it 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](http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/blog-contributions/pulls/253#issuecomment-1997), or since this was a low effort you could simply post a low effort review like so:
![](23.png)
@ -154,24 +124,12 @@ On the contrary, if the user actually tried his best to write the contribution,
![](12.png)
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 the contributor pushes some more commits to fix their mistakes and ask for a second review:
![](13.png) ![](14.png)
![](13.png)
![](14.png)
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
` ![](15.png)
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)**
And from there, if there are still mistakes that they can improve on, tell them that the contribution is (depending on 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)**
![](19.png) ![](22.png)