-----BEGIN PGP SIGNED MESSAGE-----
Here's my two cents
Another way is to use the model used by the Linux kernel developers,
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
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
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
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
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
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,
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
With the current arrangement it's just keeping Maciej from doing more
In practice any way we decide to split the work, Maciej will have to
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
I'm mentioning this purely in the spirit of not letting it stand in the way
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
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
git and I really like the fact that it would enforce a style guideline, but
good commit message is not directed to the same _audience_.
Plus it would get full of cruft like "fixed typo in obscure_task", just
Should I point out all the issues in the pull request before the
the original authors could rework the patches, rebase where necessary
provide a set of clean commits? To be honest that seems a bit imposing to
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
to contribute to free software. I was super happy when you made suggestions
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" by American feminist Jo Freeman.
Non-required reading - just came to mind. :)
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----