Re: Project development and governance model

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Here's my two cents :) Contributors far as the eye can see! I feel that with the current number of contributors, we're more likely to see results by concentrating on what each person can offer than dreaming up an organization to last the ages. The layers approach certainly applies to merging itself; I'm in no hurry to see more people having that access. The stakeholder model is pretty much what we organically have right now. Like, me too, long term I will make sure stuff on my critical path, which will include up to web python stuff like django, is going to keep working; plus I want to volunteer some work for the health of the project itself. I think that a split between use-cases would be good to define _work groups_, like, `self-hosting` or `privacy` would be a meaningful way to group devs. A benefit is that it would lower the bar for being "on top of" a specific use case: Knowing all of the `self-hosting` roles is enough to advocate for the use-case and provide review and support to others. In terms of actual roles, there's bound to be a ton of overlap. Such a separation already exists in a way in the `site` playbook, at least in the ways that matter to implementation. I don't think this should leave a footprint outside `CODEOWNERS` and maybe the doc. Apart from stakeholder groups, which would exist unofficially anyway, gruntwork groups such as `doc` and `code-style` could offer opportunities for new devs to make themselves useful and familiarize themselves with the project. I have seen this kind of work successfully used as an onboarding tool in Godot. With the current arrangement it's just keeping Maciej from doing more specialized work. In practice any way we decide to split the work, Maciej will have to oversee it until he knows "reviewed by x" is good enough to merge. Anyway, let's see some volunteers. I'm posting a proposal on doc on a separate thread, so it doesn't take focus away from this discussion; It has plenty to do with what we're talking about here, though, so do check that as well. Frankly, @drybjed has the only signature that matters to the outside world. I find it both fun and useful to sign our commits for internal verification, but as an end user my trust is based on the signed merge. I would think the contributors' sigs have fulfilled their purpose when they reach @drybjed and a signed release tag by him might be all that's needed on the user side. I'm mentioning this purely in the spirit of not letting it stand in the way of getting things done. As long as the actually useful functions of trust and attribution do not break, it is there to serve development. Okay I am replying to Maciej in third person for some reason :) I like codeowners. @ypid has a ton of stuff there too. I think authors of roles should automatically go there and opt out later if they choose. It would set an expectation for maintenance that I think should go together with the rest of the debops code standards. I hear rumors of a _doc team_ gathering in the nearby woods... Users rely on the changelog. I guess it would be cute to autogenerate it from git and I really like the fact that it would enforce a style guideline, but a good commit message is not directed to the same _audience_. Plus it would get full of cruft like "fixed typo in obscure_task", just written well. then me. You make the spec. It is all the rest of us have to go on. Being up-to-spec with a project like debops is a net benefit to anyone receiving your guidance. Learning is one of the core reasons people volunteer to contribute to free software. I was super happy when you made suggestions on my first PR and then let me fix it. Now, having to say it twice instead of pointing at a doc is an issue. Searching the issues and PRs themselves for this history on github can get pretty messy too. But do read my other thread. Still here? Here's a link to an influential essay called "The Tyranny of Structurelessness"[1] by American feminist Jo Freeman. Non-required reading - just came to mind. :) [1]: https://www.jofreeman.com/joreen/tyranny.htm Tasos