Ankur opened this ticket[1], but I want to bring the discussion to the mailing list because I think that's a better venue for open discussion.
[1] https://pagure.io/Fedora-Council/tickets/issue/291
My initial response: The biggest question I have is "where is the whole community"? There's not a good way to reach everyone (assuming we even have a good definition of what "everyone" means, which I'd argue we don't).
I think the bigger problem is people not paying attention to the broader community. I get this; many of us are volunteers and we only have so much time that we can devote. I'm not sure adding process gets us much value here until we have a better way of getting the message out.
On 4/1/20 8:40 AM, Ben Cotton wrote:
Ankur opened this ticket[1], but I want to bring the discussion to the mailing list because I think that's a better venue for open discussion.
[1] https://pagure.io/Fedora-Council/tickets/issue/291
My initial response: The biggest question I have is "where is the whole community"? There's not a good way to reach everyone (assuming we even have a good definition of what "everyone" means, which I'd argue we don't).
I think the bigger problem is people not paying attention to the broader community. I get this; many of us are volunteers and we only have so much time that we can devote. I'm not sure adding process gets us much value here until we have a better way of getting the message out.
Without riffing on details, I think a Community Change process is a good idea for the following reasons:
1. Create a parallel to established development processes 2. Gives "permission" to volunteers who often have imposter syndrome
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.
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.
To counter one point, I think we have become much more effective at "getting the message out" over the last five years than we have before. Some of this is a centralized process like the CommBlog, but a lot of what I've seen change over the years is a shift towards decentralization, like forwarding messages across mailing lists, forwarding Telegram messages across multiple groups, etc. For a community the size of Fedora, I don't think we can rely on a centralized metric to evaluate whether we are "getting the message out" effectively or not. 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.
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.
Hey Ben!
On 4/1/20 9:43 AM, Ben Cotton wrote:
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."
To put this first, it didn't come off to me that way and constructively addressing the nuance will bring us closer to something that does work.
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?"
By parallel process, I mean to contrast "there is a process for engineering" and "there is not a process for community." I agree with your framing of the question.
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"? [[snip]]
Reaching "everyone" is impossible because we don't know who everyone is. Successful outreach in a large, spread-out community depends on decentralized mechanisms of communication, loosely tied to some central authority or mandate (e.g. Council/Mindshare/FESCo/etc).
A comparison I can think of is Matthew's "rings" model for Fedora, but instead for communication and outreach. Where the center ring is that "core" active group, and the outermost ring are folks like Bex's llama farmers making their own Fedora spin. :) You have to depend on folks in-between those two rings to help communicate the message out too.
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.
Aren't the Objectives a mostly engineering-focused process? ;-) Just teasing.
I like the idea in theory of Mini Objectives. I think there is some potential to explore further there.
Thanks, Ben!
On Wed, Apr 01, 2020 08:40:16 -0400, Ben Cotton wrote:
Ankur opened this ticket[1], but I want to bring the discussion to the mailing list because I think that's a better venue for open discussion.
[1] https://pagure.io/Fedora-Council/tickets/issue/291
My initial response: The biggest question I have is "where is the whole community"? There's not a good way to reach everyone (assuming we even have a good definition of what "everyone" means, which I'd argue we don't).
The whole community is all over the place. BUT, announce/devel-announce are official channels that community members that want to keep up with announcements can subscribe to. This works well for the dev change process.
I think the bigger problem is people not paying attention to the broader community. I get this; many of us are volunteers and we only have so much time that we can devote. I'm not sure adding process gets us much value here until we have a better way of getting the message out.
Basically, I've been wondering why the motivation for the dev change policy is not relevant to community changes. Honestly, all of it applies but we don't have a community change process yet: https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_fed...
As you've said in your next e-mail, the idea here is not to copy the dev change process, but it does serve as a rather excellent example of what works. Perhaps it can trimmed to remove the unnecessary bits: a community change surely won't require FESCo discussion, for example.
Le 2020-04-01 17:13, Ankur Sinha a écrit :
As you've said in your next e-mail, the idea here is not to copy the dev change process, but it does serve as a rather excellent example of what works. Perhaps it can trimmed to remove the unnecessary bits: a community change surely won't require FESCo discussion, for example.
Hi Ankur, the question you are asking is really interesting! We have a clear process for what is dev focused, but nothing for community activities.
What I don't understand, is that you say the move to Weblate would have benefit such a process.
Could you be more explicit of what you mean? It typically is a subject that was prepared on mailing list so we are ready for decision-making at Flock, then council for funding, then a change process, have a tracking page and receive regular updates on community blog. We had a GO/NOGO on translator mailing list with an unanimous agreement.
If this isn't sufficient for community, then I don't know what can be done. I followed the System Change process, and to be honest, it is time consuming but worked fine.
I feel like the list of examples you gave requires more details to understand the issues to solve. The community may understand the reasons to have some subjects moving fast with a limited team, while other requires more communication for people to understand the reasoning behind it.
Is the global issue more related to decision-making or to change management?
Jean-Baptiste
On Wed, Apr 01, 2020 21:24:20 +0200, Jean-Baptiste Holcroft wrote:
Le 2020-04-01 17:13, Ankur Sinha a écrit :
As you've said in your next e-mail, the idea here is not to copy the dev change process, but it does serve as a rather excellent example of what works. Perhaps it can trimmed to remove the unnecessary bits: a community change surely won't require FESCo discussion, for example.
Hi Ankur,
Hi Jean-Baptiste,
the question you are asking is really interesting! We have a clear process for what is dev focused, but nothing for community activities.
What I don't understand, is that you say the move to Weblate would have benefit such a process.
I was merely giving examples of community changes that happened recently. The intention was not to say that these changes were not handled well. I apologise if it came across that way.
Could you be more explicit of what you mean? It typically is a subject that was prepared on mailing list so we are ready for decision-making at Flock, then council for funding, then a change process, have a tracking page and receive regular updates on community blog. We had a GO/NOGO on translator mailing list with an unanimous agreement.
If this isn't sufficient for community, then I don't know what can be done. I followed the System Change process, and to be honest, it is time consuming but worked fine.
Exactly. So, even though it was a community change, you ended up using the System Change process---because no community change process is currently in place.
I feel like the list of examples you gave requires more details to understand the issues to solve. The community may understand the reasons to have some subjects moving fast with a limited team, while other requires more communication for people to understand the reasoning behind it.
Is the global issue more related to decision-making or to change management?
It is both. All community changes would benefit from a defined process/method/system/whatever we call it. In general, while the primary stakeholders are the ones that make the decisions in any changes, the idea is that the community as a whole should be aware, and have the chance to either participate in the change if they feel they have the necessary know-how or simply prepare themselves by learning the new processes/tools that they may need to work with in the future.
(I was not involved in the Weblate change at all. My only stake in the process was to be aware that we were moving to a new platform so that if newcomers came to the Fedora-Join SIG who were interested in translation, I knew where to point them.)
On Wed, Apr 1, 2020 at 4:08 PM Ankur Sinha sanjay.ankur@gmail.com wrote:
If this isn't sufficient for community, then I don't know what can be done. I followed the System Change process, and to be honest, it is time consuming but worked fine.
Exactly. So, even though it was a community change, you ended up using the System Change process---because no community change process is currently in place.
But it also had a significant technical component, so even if there was a community change process in place, it might have better fit the engineering changes process anyway.
I think that's part of what I'm struggling with here: how do we define the scope? If there are two separate processes, how do we decide which one is appropriate? Some are obvious, but there are a lot of gray areas. The Weblate migration and the Ask Fedora migration are two examples of things that could have fit in either category. Weblate moreso because it's tied to a release, whereas Ask could have been an Objective (Objectives don't have to be technical) or a mini-objective if such a thing existed. Which brings me back to the thought that we don't need a new capital-p Process, we need to do a better job of making our existing communication more visible.
Le 2020-04-01 22:15, Ben Cotton a écrit :
I think that's part of what I'm struggling with here: how do we define the scope? If there are two separate processes, how do we decide which one is appropriate? Some are obvious, but there are a lot of gray areas. The Weblate migration and the Ask Fedora migration are two examples of things that could have fit in either category.
Is it really an issue to link major community changes to releases? Why couldn't we simply use the same process?
Jean-Baptiste
Le 2020-04-01 22:07, Ankur Sinha a écrit :
On Wed, Apr 01, 2020 21:24:20 +0200, Jean-Baptiste Holcroft wrote:
What I don't understand, is that you say the move to Weblate would have benefit such a process.
I was merely giving examples of community changes that happened recently. The intention was not to say that these changes were not handled well. I apologise if it came across that way.
No hard feeling. I'm sure Weblate migration is not perfect, but I had trouble to understand, thanks for clarification.
Jean-Baptiste
I've just been catching up with the gitforge thread, and there are multiple examples of instances there where a structured, transparent community change process would've helped. If nothing else, to ensure that community changes were given as much importance as dev changes, and to at least ensure that as much of the community as possible were informed of changes in the community---a lot of which occur "under the hood".
I stay on 30+ Fedora mailing lists, and even then a lot of the information being shared in the thread is very new to me. :(
Perhaps it only needs improved communication, but the only way I see this being achieved at the moment is using a minimal but well defined process. I cannot recall such issues coming up with dev changes, because there's ample opportunity for people to a) be aware b) be clear on what's happening c) weigh in d) help/assist/monitor e) learn and evaluate.
Maybe we shouldn't overthink this and go looking for a new "perfect" process. Let's just adapt the current change process, which we know works, and then tweak it later? Nothing in Fedora is written in stone. :)
On Thu, Apr 02, 2020 at 09:54:30PM +0100, Ankur Sinha wrote:
Maybe we shouldn't overthink this and go looking for a new "perfect" process. Let's just adapt the current change process, which we know works, and then tweak it later? Nothing in Fedora is written in stone. :)
This all sounds good to me. :)
On Fri, Apr 3, 2020 at 10:08 AM Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Apr 02, 2020 at 09:54:30PM +0100, Ankur Sinha wrote:
Maybe we shouldn't overthink this and go looking for a new "perfect" process. Let's just adapt the current change process, which we know works, and then tweak it later? Nothing in Fedora is written in stone. :)
This all sounds good to me. :)
As Jean-Baptiste pointed out, we can already use the Changes process. So maybe let's just start there. Like I said, creating a new process, even one that is very close to the existing Changes process, is more complicated than it looks on the surface.
I think what may be needed here is policy (well really guidance), not process. I'm going to try really hard to come up with something specific to discuss that may address the concerns without requiring me to develop and manage a new process.
On Fri, Apr 03, 2020 10:13:47 -0400, Ben Cotton wrote:
On Fri, Apr 3, 2020 at 10:08 AM Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Apr 02, 2020 at 09:54:30PM +0100, Ankur Sinha wrote:
Maybe we shouldn't overthink this and go looking for a new "perfect" process. Let's just adapt the current change process, which we know works, and then tweak it later? Nothing in Fedora is written in stone. :)
This all sounds good to me. :)
As Jean-Baptiste pointed out, we can already use the Changes process. So maybe let's just start there. Like I said, creating a new process, even one that is very close to the existing Changes process, is more complicated than it looks on the surface.
I think what may be needed here is policy (well really guidance), not process. I'm going to try really hard to come up with something specific to discuss that may address the concerns without requiring me to develop and manage a new process.
I wasn't thinking that this would be managed by the FPgM at all actually. Community changes do not necessarily sync with the release cycle, so I was thinking this process would be largely independent of it, and thus not something the FPgM (who is in-charge of running the release on schedule from what I understand) would oversee.
My initial thought would be that Mindshare/CommOps (community operations?) would oversee it. The process remains similar to the change process, the template remains similar, what is done in Bugzilla can get implemented in Pagure (or any other ticket platform that we end up using), and a set of people would do what you do all by yourself.
Any Mindshare/CommOps folks here to weigh in? :)
(I'm not officially on either team, so I don't want this to come across as me volunteering people to do more work. I've always assisted whatever team can use me, so I'll keep doing that. The idea is just to ensure that changes in the community are treated the same as the engineering related changes currently are.)
On Fri, Apr 03, 2020 at 10:13:47AM -0400, Ben Cotton wrote:
As Jean-Baptiste pointed out, we can already use the Changes process. So maybe let's just start there. Like I said, creating a new process, even one that is very close to the existing Changes process, is more complicated than it looks on the surface.
Including devel-list for discussion and FESCo for approval?
I'm just thinking out loud here but maybe we need a community-announce list, next to the devel announce list? Not all community topics are development ones, and not all development topics are of general interest to the community.
On Fri, Apr 3, 2020 at 12:56 PM Matthew Miller mattdm@fedoraproject.org wrote:
Including devel-list for discussion and FESCo for approval?
Potentially. It's not necessary for all things, but FESCo has historically been good at "what the heck, +1" when it's something that doesn't really fit.
I'm just thinking out loud here but maybe we need a community-announce list, next to the devel announce list? Not all community topics are development ones, and not all development topics are of general interest to the community.
Agreed. We'll want to think about the scope because we want it to be broad enough that people will post to it, but not so busy that people unsubscribe.
On 4/3/20 12:56 PM, Matthew Miller wrote:
I'm just thinking out loud here but maybe we need a community-announce list, next to the devel announce list? Not all community topics are development ones, and not all development topics are of general interest to the community.
Or, perhaps announce@? :)
I think another mailing list is confusing. Also given there is no community-focused equivalent for devel@. The closest is council-discuss@ which doesn't come near devel@ activity.
I do think community topics are tied directly or indirectly to development topics. Thinking of community topics as separate from the development folks creates different groups for software and non-software contributors. Which isn't a completely wrong assumption, but also not completely true either. The community is for everyone.
On 4/3/20 1:49 PM, Ben Cotton wrote:
Agreed. We'll want to think about the scope because we want it to be broad enough that people will post to it, but not so busy that people unsubscribe.
For a mailing list that gets used a handful of times a year, this is a frequent reason not to use that list over the last 5-6 years I've been around. :) I wonder, what is the worst that could *really* happen?
On Fri, Apr 3, 2020 at 3:12 PM Justin W. Flory jflory7@gmail.com wrote:
Or, perhaps announce@? :)
That's a possibility, too. It's a change from how we've historically used the announce mailing list, but that doesn't mean we're locked into it forever.
I do think community topics are tied directly or indirectly to development topics. Thinking of community topics as separate from the development folks creates different groups for software and non-software contributors. Which isn't a completely wrong assumption, but also not completely true either. The community is for everyone.
+MAX_INT
For a mailing list that gets used a handful of times a year, this is a frequent reason not to use that list over the last 5-6 years I've been around. :) I wonder, what is the worst that could *really* happen?
You're right that we intentionally keep announce very low traffic. Too low? Maybe. There may come a point when people unsubscribe, at which point we lose the value of using the list. But I honestly have no idea what the traffic rate that would drive off a non-trivial number of people. We've traditionally been very conservative in this regard, and I'm willing to believe that we're far too conservative. But I don't want us to take the brakes off entirely. I think we should come up with some intentional guidelines, if for no other reason than to indicate to the community that "yes, your message qualifies".
-- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis
On 4/3/20 3:26 PM, Ben Cotton wrote:
You're right that we intentionally keep announce very low traffic. Too low? Maybe. There may come a point when people unsubscribe, at which point we lose the value of using the list.
I wonder what the value of that list is today as it is currently used (or not). :) I am already subscribed to the mailing lists I want to be subscribed to. Please don't make me subscribe to another one to keep up with news I want to know.
I think we should come up with some intentional guidelines, if for no other reason than to indicate to the community that "yes, your message qualifies".
Valid. Otherwise I might come asking someone to approve my announcement email for the latest release of the Llama Farmer Fedora remix. :)
Have a nice weekend folks!
Oi.
Have you consider that probably a solution is not to create more resources but to simplify the ones that are currently available?
El vie., 3 abr. 2020 a las 18:27, Justin W. Flory (jflory7@gmail.com) escribió:
On 4/3/20 3:26 PM, Ben Cotton wrote:
You're right that we intentionally keep announce very low traffic. Too low? Maybe. There may come a point when people unsubscribe, at which point we lose the value of using the list.
I wonder what the value of that list is today as it is currently used (or not). :) I am already subscribed to the mailing lists I want to be subscribed to. Please don't make me subscribe to another one to keep up with news I want to know.
I think we should come up with some intentional guidelines, if for no other reason than to indicate to the community that "yes, your message qualifies".
Valid. Otherwise I might come asking someone to approve my announcement email for the latest release of the Llama Farmer Fedora remix. :)
Have a nice weekend folks!
-- Cheers, Justin W. Flory (he/him) justinwflory.com TZ=America/New_York
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.fedorapr...
On Sat, Apr 04, 2020 08:05:57 -0400, María Leandro wrote:
Oi.
Have you consider that probably a solution is not to create more resources but to simplify the ones that are currently available?
Hrm, we're not creating new resources here. We're trying to come up with process, one that isn't specific to any community teams, for managing/discussing/tracking/disseminating community related changes. The obvious initial candidate is the Change process[1].
If there's already something that does this, tweaking/generalising it would indeed be preferable. Is there?
[1] https://docs.fedoraproject.org/en-US/program_management/changes_policy/
Le 03/04/2020 à 18:56, Matthew Miller a écrit :
On Fri, Apr 03, 2020 at 10:13:47AM -0400, Ben Cotton wrote:
As Jean-Baptiste pointed out, we can already use the Changes process. So maybe let's just start there. Like I said, creating a new process, even one that is very close to the existing Changes process, is more complicated than it looks on the surface.
Including devel-list for discussion and FESCo for approval?
Mindshare could be the approval committee, but shouldn't we find the way to have mindshare people to get elected too?
Hi, we discussed this at the weekly Mindshare Committee meeting and provided an update on this ticket:
https://pagure.io/mindshare/issue/197
Input welcome!
Thanks,
riecatnor
council-discuss@lists.fedoraproject.org
-
Ankur Sinha -
Ben Cotton -
Jean-Baptiste -
Jean-Baptiste Holcroft
-
Justin W. Flory -
Marie Nordin -
María Leandro -
Matthew Miller