-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Here's my two cents

> Another way is to use the model used by the Linux kernel developers, where
> there are essentially "layers" of contributors.

:) 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.

> GPG signatures on git

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

> Give interested people 'ownership' of parts of the code.

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...

> Cleaner git commits in lieu of less verbose Changelog file

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.

> Should I point out all the issues in the pull request before the pull, then
> the original authors could rework the patches, rebase where necessary and
> provide a set of clean commits? To be honest that seems a bit imposing to 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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEXbaOHtREtFSBLXcdOXguVye2c7EFAl8Za94ACgkQOXguVye2
c7GVihAAmvP/HmEf3ppsc4/A4qYuGGCokgFHKjswdfVERqwaQKxlTT5Jve7uu612
oQHXuDYcRbmf5o/Th5pEuuIsWWDDB/W7F1jT4IKUkysYsDr6Rr4yzrTJnXjjA+Rf
875FAMweotemS8xR5RW8nY4TlBFR/x1mcre3tm4KD5cmCm/3EbkC43Bpf6to7X35
JXc3QhpDXQeke60AjKCXgh/8nzmDUrLHkmZGY2XWddbtPDhMJi5Hv4PXEwAURG7I
W9Tj+r+kA1K6iEsm5MNBENWic5wg2LYOpIuqzQ3ymAgiXtbLgdM1eRnWRgUf+bim
Nb4Q7lLcv5u0QEdZVg8H67nmv0f1nU/OYY7OJYaLlwbViWxdIUYY1D8FhamKYyfq
YxPEG+9wFzLSr+T8Jipeq3J7DQxBV7jn/aBydzFDEHiOYcRcqa1JSk8Hh9XC1jd6
evpdastSxh0/kHU4qy7fX0EgXrhbna0aYJVS5Dq+VlTVb2aVFiK0S+5gVtZzksS9
cRpOXQ8irwIYTG7CxwSFwqDMF/dj/2mg6WSJiM/oYD09XxAGXOSyojeTMJmb5bRp
QCjkg7tBDdeg/dLXEjKtvehHkezbK6XoqJu7NtJK1ITewwMK/YZsEov3Noge6zeV
FOO3YEn79/cCpxi32Du/6C1Js4rsALrG2pOX8iK8tvfH4rggceY=
=tcpa
-----END PGP SIGNATURE-----