On Wed, Apr 1, 2020 at 9:07 AM Justin W. Flory <jflory7@xxxxxxxxx> 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@xxxxxxxx.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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to council-discuss-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
