Re: A Community Change process to mirror the System Change process

On Wed, Apr 1, 2020 at 9:07 AM Justin W. Flory <jflory7@gmail.com> wrote:
>
> First, it creates a parallel with the more established development
> processes of the Fedora community. The community side of Fedora (in my
> view) has always been improvised. This could build more structure and
> order into something that has always been mildly chaotic.
>
I wholly agree with the second part, but I don't think the "parallel
process is good" argument follows from this. A more structured
approach to community is good, but not necessarily one that looks like
the engineering process. After all, engineering and community require
different skills. I think a better approach here would be "what would
a good community change process look like?" not "how can we copy the
engineering process for community?"

> Second, it also addresses the catch-22 that volunteers often fall into,
> where they need "permission" (or a gentle nudge) to become empowered to
> push forward a change that affects other Fedorans in the community. As
> someone who has spent all of my time in Fedora as a volunteer, this
> makes a lot of sense to me.
>
This is an excellent point.

> (snip)
> Focusing on messaging right *now* adds significant stop energy
> to the conversation. Not that it doesn't deserve more focus later, but
> we can't know what works unless we try something first. :-) After all,
> we are pretty good at being First with a lot of things in Fedora.
>
I don't see it as stop energy, I see it as a necessary and possibly
sufficient step. We already know there's a lack of engagement with
what we're putting out. Fixing *that* may obviate the need for a
formal process, whereas a formal process that's not engaged with is
just asking people to do work.

None of my arguments should be taken as "this is a bad idea and we
should not do it." They're intended as "this is a more complicated
issue than it seems on the surface."

Shifting gears a bit, I think there are two categories of things here:
1. Broadcasting information
2. People doing work

Those are intentionally vague and broad buckets, but I it helps to
decompose the problem into the related issues of "how do we
communicate better?" and "how do we empower people to make changes
that serve the community?". The first also serves the second.

I'm a little leary about over-broadcasting the same message to many
channels. How many mailing lists, fora, Telegram channels, IRC
channels, etc do we need to hit before we've hit a sufficient value of
"everyone"? If we send too many messages, they will either get lost in
the shuffle or cause people to withdraw from those. For example, we
could send a lot more stuff to announce@lists.fp.o, but we
intentionally keep it low-volume to keep people from unsubscribing.
How much is "too much"? Well that's the question. But in general, for
a community this large, I'm more inclined with a "here's where to go
if you're interested" approach.

Which leads to the next question: how do people know where to go? Ah!
That's a problem I think we can fix immediately. 4 times a year, we
announce releases (2 beta and 2 ga) to a pretty wide audience. If we
modify the announcement boilerplate to remind people that the
Community Blog and the council-discuss mailing lists are the places to
stay on top of project governance issues, that should help get more
people looking at the places we're already publishing information. The
Council has decided that the Community Blog is the place we post
announcements, but how many people are on this list or read the
Community Blog? Not enough, so they never saw that we're doing this.
Piggy-backing on the existing announcements doesn't add additional
messages, but it does spread the word better.

As for the second part, I don't have a fully-formed idea around this,
but some of it would seem to fit the Objectives process pretty well
already. The move to Weblate potentially fits into that. Other things
might be a little smaller than an Objective, but a mini-objective
process could fit. What would a mini-objective process look like?
Something in between Objectives and Changes. Like I said, this isn't a
fully-formed idea yet, I'm just tossing something out for
consideration.

--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
council-discuss mailing list -- council-discuss@lists.fedoraproject.org
To unsubscribe send an email to council-discuss-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/council-discuss@lists.fedoraproject.org