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

Hey,

Ooops, I admired y'all sticking to the character limit, but then I went and
did 80 instead of 78... The horror! I was crafting those mails for hours.

Heh, I was worrying if I was coming on too strong, mostly due to editing
out "I think" statements that were all around my first draft. I probably was.

I shall prefix all my stuff with:
The words "MUST", "SHALL", etc are NOT according to RFC2119.

>> The stakeholder model is pretty much what we organically have right now.

> So that means the current project structure and stuff we're doing is fine
> as-is for now?

No, there are real challenges. I was just stating that they are better viewed
through the lens of what we have right now and applying incremental changes.

I think it is the nature of the project to invite highly specific additions
but to need conscious organization for long-term stuff, like maintenance.

I don't mean to restrict the conversation to my own point, but the way I see
it the challenge at hand would be project health. Our goals, something like:

* Take stock of existing people an empower them to contribute
* Make room in the processes for the community to take over
* Lower the skill bar for meaningful contributions

A goal I would find fair for you particularly, would be to be able to bundle
tasks that don't need your overall understanding of the project so you can
focus on tasks others can't do and probably have more fun working at.

The use-case workgroups are a good start, I think, even as empty concepts at
this point. They do represent something real about each community member.

Maybe we should brainstorm these categories and a list of roles to go with
each, and have those as additional role index flavors. On an issue then I
can wrap it up. Probably based off the existing tags in github.

I'm not sure I like the name "workgroup" for something that clearly means
use-case, I only like that it's clearly talking about _people_.

Tribes? lol.

Tagging issues for each of the tribes would be a good indicator for people
to swoop in and solve a problem in their domain.

The responsibility for each of them would be a different hat that you can
eventually hand over to other people, already there for them to claim.

It might be even more sellable for people using debops at work to justify
contributing to plumbing that they really depend on.

Timing should also be probably taken into account, leaving slack for the
community during the first months of a release cycle then wiping the low
priority stuff nobody picked up. As the community grows maybe we make an
event out of it.

There should also be a tag for `easy`. Like with that missing newline that's
hanging on the issue queue right now. Just with a name that will not startle
the issue submitter.

Ah, actually github proposes `good first issue`. Hopefully contribs will do
a second one after that. :)

I suppose `good first issue` also implies `priority:low`?

Imre has contributed some solid Project Manager work already, I bet he will
also have some informed opinions on this matter.

> The https://github.com/debops/debops-keyring

Oooh I had missed that.

Organizationally though, I mean, you care about it as a dev, and use it to
verify project health, not to trust a release.

> git

+1 for "history is history".

I'm no authority; I've been using git for a while, but the most advanced
stuff I'm familiar with is the rebases I've had to do for here. :)

> CREDITS

It seems like an ok format, flexible enough.

Yeah I'm not married to github, either.
I guess an email to reach each contributor is enough to reconstruct the
community outside github. I'm not sure if requiring publishing one's mail on
the repo and packages is a good idea, though. LDAP on the debops infra? ;)

GDPR-wise, it's clear that this information is intended for publication under
GPL. It should be removed if requested, but that's just human decency. :)

It's good to have tech solutions, but I think the matter at hand is more
about people.

> nobody reads the user manual.

SIR, I SHALL ASK YOU TO STEP OUTSIDE!!1 ;) ~style-force

So, I had a similar paragraph on my doc team mail but I edited it out as I
thought I was pontificating (I was). But here goes.

People read as much of the manual as they can take, often from the beginning:

* When grabbing their first loose role from galaxy
* When first using debops
* When integrating their first private role into debops
* Before contributing their first minor fix
* Before contributing their first debops role
* Before contributing their first improvement to the project as a whole

There's no fancy brochure website so we add management who are evaluating
debops to use on their admins. :)

After that, if they choose to follow the manual, it's probably more
manageable to follow the `[doc]` commits than to reread the whole thing.

Now these people have had a go at the manual for 1 up to 6 times.
Sure, people who have already done it a few times might skip a few steps.

People after that final point mostly just revisit the reference sections,
and those are handled pretty well by the automated solutions already in
place. Style guides are certainly a reference one would keep open.

The current sections offer a structure to accommodate speaking to users
depending on their current task and, say, "minimum required hardcore level".

This can inform cohort goals, such as "no need to dig into debops source to
implement your role against debops". It's also a milestone from many users,
and sometimes your project isn't even the one they'll cross it on.

Note to self: a short guide about `ack`ing the source. ;)

Also, I or anybody willing can point people to the manual, containing some
answer you gave days ago. Hell, it the first debops meet someone recited
like 5 minutes out of the ansible manual. No redhat dev involved. :p

Anyway, back to the list. That list is our onboarding path, from noob up to
vice-council-chairman of debops or whatever; Some pretty solid milestones on
the tool's learning curve.

Often, commercial projects focus on user acquisition. In terms of project
health, this project benefits when we get people all the way up to getting
involved with non-sexy maintenance.

There may be merit in discussing the non-profit scenario since, seen as a
stakeholder ecosystem, a way to financially support the ongoing development
would be a desirable way for many end users to play their part.

I mean, it's a tool people use for work work stuff.

Heh, I would totally work for a free software nonprofit.

Anyway, lol, I wrote a wall of text again.

Tasos
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEXbaOHtREtFSBLXcdOXguVye2c7EFAl8af/QACgkQOXguVye2
c7GnoA/9Gkiflzeru6znMZFUdteUR7pSgLK8ZU8Jq4zWCllmcqnMUtPQZB1baoeF
g61aIHH8+UKI8GRDt1vOLH+Rem/z/r0HIEqVonTnofvim9aH2oVodsxiWU4tlijU
i/1PN0F9Xvq+vslbIQ83UmMR6qWP++5Jo8nH6JuFtC9MUBI37Ab+q2ZOeGwTSOC6
cY3pxnG97bOYm94x9QKXdAD8esadM/Ad9WvC9mMfoQV8SP30al3zOgVUN/rC5hrA
vL6r1UjtEBYpPunmaU5I8mUKfM1kE5jNQnvvdmxtah06Hwvhqg56TR7IcW5rgfWN
YLBdVJKop1uwerI2kOUYYQM3GTVS28vukyzoNoXFIDtHMz8QldgHzFACSXegmacq
06R0l23Zd6/nP6YZmCWCwwbCTWKCR2jvQBVbPNNLU9stc0mrVyCiSm1um/r4d6Y8
ikdy5yj8GeTVFgHmFXWi9CQr7aaYXYBYCW4rZlsbfBzm+9qxiImTHtjiSbAhGxtk
g9x1HyMvg/qJHaA0BlYeXPaS90aKtVmTl/JsESy5rTt0ZAHa/d2Ulv41JW95btA7
2AISiP6jJhSnNUXRez51vmfy0chpxpBum9Lkeq7crd6rrNNbwnNdMjWtH6q7nDJy
wwPADdsIc08jM5zApXS35TrvmOSDbpOX8E8MGpL9dgOc1bnzfaY=
=vGt4
-----END PGP SIGNATURE-----