Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to delegate trust ? #17

Open
rzr opened this issue Nov 12, 2023 · 1 comment
Open

How to delegate trust ? #17

rzr opened this issue Nov 12, 2023 · 1 comment

Comments

@rzr
Copy link
Contributor

rzr commented Nov 12, 2023

I have described some procedure to make this org scalable but I don't want to be the one in charge of trust that's the reason I proposed to offlne this task to existing oss orgs.

See:

https://abandonware.github.io/

abandonware/noble#317

@Apollon77
Copy link

I see several things on that ...

1.) In fact my example is the proof that this do not work ... I proofed myself several times by quality commits and also fast fixes in case of introduced issues, I also have commited to maaaany OSS projects as contrubuter, maintainer and such. My history should be exactly what the idea of your requirements are - but my requests to become official maintainer in here are stale since months. And noone decides. This is just blocking and not helpful

2.) In my eyes the "trust" issue is very simple to solve because many repositories show how to do it: if you require a review from a second developer - even for official maintainers - and also forbit admins to bypass this in general - then you need at least TWO people agreeing on a change. In my eyes this became best practice in OSS projects. if we would have enough maintainers we could also require 2 approvals and such (but honestly ... we are far away from that situation).

Ideally the original noble owners would allow interested developers to take over the original repo, but also here several tries to contact them were without any response, thats a shame to be honest. I don't care abotu the money they collected on that "opencollective" account, but just the option to drive such a great project into the future without needing to fork it :-( But it is as it is.

This is my statement to this. I do not see any issue that can not be solved by such best practices as soon as there are minimum 2 "Kind of active" maintainers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants