On lip 24, Tasos Alvas wrote:
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.
I just use vim, it has automatic wrap for files in the 'mail' mode.
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.
Well, what's fun for me is designing the infrastructure, trying out new things
and integrating everything at various levels. For example coming up with the
'parse_kv_config' and 'parse_kv_items' filters over the course of a few
where in each iteration I honed in on a good generalized approach to
configuration was rewarding. Or finding out a good way to manage LDAP
configuration and data in the directory via Ansible. But that's basically the
crux of the DebOps project as a whole - bring different stuff together and
integrate it into a working solution. What I would like to do is focus on that
That's why for me it's hard to delegate writing stuff to other people - if
I design a way to do something, it's basically identical to writing the actual
code, so I might as well do it right away... But that's probably something
I will have to rein in to allow for more collaborative work in this project.
Adding contributions to DebOps requires at least some understanding of how
everything works, and DebOps has a steep learning curve on top of Debian and
Ansible, not to mntion the whole sysadmin work with designing your
infrastrucure, etc. I'm not sure how we can lower the bar to entry apart from
documenting everything extensively.
Maybe more detailed instructions in the DEVELOPMENT.rst documentation that
show how contributions are reviewed and what common mistakes can be easily
avoided could be useful for new developers.
The use-case workgroups are a good start, I think, even as empty
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_.
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.
You probably nailed it with the hat idea. I'm not sure about specific
categories from the point of view of a software project, but if we look at it
from a sysadmin perspective there's usually separation of concerns in larger
teams - networking, hypervisor management, application deployment, DBA,
firewall and security, etc. These roles could be applied in DebOps
development, where different experts in each field chime in when things get
It will be heard to implement review notifications via codeowners though,
since a single file named 'defaults/main.yml' in most roles can have
configuration from multiple fields - firewall config, webserver, database,
LDAP, and so on. We would probably have to have a "general pipeline" of sorts
through which everything is pushed before being committed to the main
repository, not unlike LKML. Then people can chime in if they see obvious
issues, they can be corrected before final version is committed to the
official repository. And I guess this is why 'debops-devel' mailing list was
created, we would just have to start using it more.
Just thinking aloud here... I'm not sure how feasile would implementation of
this be in the current state of DebOps and how it is developed.
It might be even more sellable for people using debops at work to
contributing to plumbing that they really depend on.
Meaningful contributions are expensive. You need to set up a development
environment if you want to write a proper role, test everything, write
documentation, fix all linting issues, etc. I've heard about many cases of
people that use DebOps and a few custom roles added on top of it. The custom
roles are barebones just to make things work your environment, and they are
left in a barebones state because they work for them.
Overcoming the above hurdle is really hard; some people even ask me to write
the roles properly from scratch which I'm happy to do, although they either
have to wait, or I have to drop whatever I'm currently working on to do their
thing. And then something else comes along that requires attention, either in
te project or at th workplace, and I'm distracted yet again. I guess that's
the life of a system administrator for you.
Timing should also be probably taken into account, leaving slack for
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.
Or we could go in the other direction similar to how Linux kernel went, and do
short release cycles every couple weeks or so. If your change or a new role
didn't make it to the last release, that's fine, just wait to the next one.
But that probably requires a dedicated person just for the task of combining
all the changes and making a release. Linus became de facto that person after
many years of developing Linux, when the community was large and diverse
enough to let the development momentum go on without his involvement. Not to
mention that the whole model of a 'stable branch' would have to be redesigned
and handled by more people. DebOps has a looong way for that to happen. For
now, I guess we're stuck.
There should also be a tag for `easy`. Like with that missing newline
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. :)
You mean ? Fixing that would require diving into the bowels of the 'pki'
role and messing with the shell scripts. I guess if you call that "easy", we
can go with that. :-)
I suppose `good first issue` also implies `priority:low`?
For the issue and pull request labels, I went with a system described here,
you might want to check it out. I wouldn't say that low priority is synonymous
with a good first issue... First issues can be spelling mistakes, a missing
comma, wrong number of empty lines in 'defaults/main.yml' between variables,
something that's obvious to see in the code you browse at the moment.
I would say, forget about it. The separate keyring repository was created to
coordinate access to hundreds of various role repositories in the 'debops'
GitHub organization. With the move to a single monorepo, keeping your own fork
in which you can work on separate branches and do pull requests from them
became trivial, so there's no need to track the GPG keys of coontributors.
I guess when the CREDITS file gets added, when can specify the GPG
fingerprints of people in it and it will be enough to gather the keys via
a script. And we will have a proper source of truth for that as well.
Organizationally though, I mean, you care about it as a dev, and use
verify project health, not to trust a release.
For me as a release manager (another hat, hmmm), GPG signing a release doesn't
really matter, that's more important for the downstream - eventual Debian
package will depend on a signed release to authenticate it.
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? ;)
You might have a good idea, a proper LDAP server for various services in
DebOps could allow for even more "dogfooding" and provide access to the wiki
and other services if they crop up. I currently don't have access for a cheap
and performant enough VM to set it up externally. I'll check with my workplace
to see if I can have a dedicated VM for the project that could hold LDAP and
some other authentication stuff. Imre proposed access to a VM on his
infrastructure, I wonder if we could use it for that purpose...
> nobody reads the user manual.
SIR, I SHALL ASK YOU TO STEP OUTSIDE!!1 ;) ~style-force
Hook, line and sinker... :-)
Often, commercial projects focus on user acquisition. In terms of
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.
Yup, it would be nice to set one up eventually, maybe when enough people
declare that they would back it financially.. I don't really have time or
resources to do that at the moment though. But moving out from a single work
environment to focus entirely on writing shared infrastructure used by other
organizations would be an interesting job. Less stress from dealing with daily
issues of empty mailboxes, full disk drives, user calls, etc. Basically a
Tier 4 - infrastructure research and development for multiple organizations.
Maybe someday. :)