FEP repo rights

Community SocialHub Policy
1

Hi Folks.

This is about rights to configure

I currently have rights to neither settings. If I wanted to add something like Automate the create_readme script and issue creation, I would need these rights.

Do we have a process on who has these rights? On how to obtain them?

If yes, could we define one. Also could I have them? If yes, I would write the automation for the above step.

3 Likes
2

It’s informal. Initially only @aschrijver and @weex had those rights, now I have them too.

I added you to the administrators team. Can you access repository settings now?

3 Likes
3

Thanks. I’ve now created:

This should automate most FEP facilitators tasks.

2 Likes
4

cc @fep.hosts

Just so that everyone is informed.

1 Like
5

I’ve merged the pull request. Getting it to work was harder than expected. A bug in the configuration arose due to one needing the private key in CI ending in a new line.

1 Like
6

Another thing, I just discovered

Screenshot 2025-01-20 at 13-23-00 Woodpecker
Screenshot 2025-01-20 at 13-23-00 Woodpecker1438Ă—306 34.3 KB

this means that currently, we need to approve the CI job if somebody submits a FEP. Is this the state we want?

Link to woodpecker settings: Woodpecker

7

Is manual approval required for every CI job, including on-push checks? In this is the case, I would prefer to not have it, because in my opinion automatic on-push checks have greater utility.

8

I changed it to no permission for now.

If there are any effects, please comment here.

9

No issues so far.

What are the consequences of changing it to no permission? The description says “This setting can be dangerous and is only recommended for private instances.” But what do they mean by “dangerous”?

10

I didn’t research woodpecker’s thinking. However, my understanding is:

  • Woodpecker keeps secrets, e.g. the deploy key to update the FEP repo.
  • You can give pull request jobs access to secrets.
  • So people can access to these secrets using appropriate pull requests.

So as long as we limit access to secrets to jobs triggered by “push” and “tag”, we are fine.

1 Like
11

I’ve just submitted a new FEP, everything is working as expected. Good job!

1 Like
12

Is there any objection to autogenerating the discussions link the issue? It should be available from the discussionsTo link in the FEP.

See #487 - [TRACKING] FEP-a974: All Actor types should be followable - fediverse/fep - Codeberg.org

1 Like
13

No objections.

<random text because discourse requires comment to have at least 20 characters>

1 Like
14
15

Thank you @helge and @silverpill for making it a transparent collective process.

2 Likes
16

In #22 - [TRACKING] FEP-1b12: Group federation - fediverse/fep - Codeberg.org, I commented about my desire for code blocks in FEPs having highlighting, e.g. using

```json
{
   "type": "AnimalSound"
}
```

instead of the option without json.

We could automate this type of checks with a markdown linter.

leads to about 2000 errors, which could be reduced by automatic fixing and disabling some rules to about 160.

Should we work towards enforcing such a concept of linting?

1 Like
17

No, linter shouldn’t block proposals.

Optional linting is fine.

1 Like