#197 Community change process to parallel the current engineering change process
Opened 2 years ago by ankursinha. Modified a year ago

Hello!

I filed a ticket to discuss the creation of a change process for community changes, similar to the change process we have in place for engineering related changes, with the Council:

https://pagure.io/Fedora-Council/tickets/issue/291

It's being discussed on the council-discuss ML now. Could mindshare please weigh in?

https://lists.fedoraproject.org/archives/list/council-discuss@lists.fedoraproject.org/thread/NT3JI4QIA7D2UJWCOV662FZHOV6BUBLJ/


Hi @ankursinha, thanks for opening this ticket. We discussed this in our Mindshare Committee weekly meeting and from the attendees, we are in favor of formalizing a Community change process. As we didn't have all our attendees, we think it would be best to pose a series of questions or statements for people to vote on and discuss.

Mindshare Committee members, please weigh in on the following.
(Anyone, not just Mindshare members are welcome to reply as well.)
Any explanations on answers or additional feedback also welcome.

+1, or no and an explanation:
Mindshare Committee sees the necessity for a Community change process.

Mindshare Committee wants to help shape the Community change process.

Mindshare Committee wants to own the Community change process.

Mindshare Committee believes FESCo should have a vote in the Community change process.

Mindshare Committee believes the Council should have a vote in the Community change process.

Mindshare Committee wants to define an ideal process or workflow first, and focus on the tools to implement after.

Mindshare Committee recognizes that Community changes will be unique and special requirements or changes to our process may need to be taken based on individual needs.

Open ended questions and things to think about:
What kind of things should run through this process?

Would we consider doing a community poll for changes?

Do we want to try to align with the change submission process to avoid recreating the wheel?

I look forward to people's input! :)

For the Mindshare Committee members who haven't followed the council-discuss thread, I'm opposed to a process for this (take note of the date: a program manager said "we don't need a process for that" :laughing: ). What we need is better, more visible communication, not an approval process.

I believe it was Justin who first suggested using the announce list (and if not, I apologize). I was reluctant about that at first, but I've warmed to the idea. With defined guidance on how to publicize changes, and a concerted effort to make sure people are aware of the channel(s) where announcements are made, I think we get the benefit we're looking for without adding the overhead of a Process.

If you do move ahead with creating a process, there should really be one approval body. Whether that's Mindshare or the Council isn't particularly important, but if FESCo, Mindshare, and Council have to vote, 1. it slows the process down and 2. can cause problems when there's not consensus between the three bodies.

I agree with @bcotton here. I have experienced this most of the time that creating processes itself is a huge effort and requires a lot of time and it is specially cumbersome because of the volunteers involved (they do stuff when they get time to, which is fair enough).

We should spend our precious time in making this volunteer based community more awesome, and not making it more hard for anyone by locking things down with tons of processes which consumes time, efforts and eventually die down.

IMHO as Ben said, our first and more important problem is that these changes do not reach out to every individual timely, we should try to solve that instead of making it more complicated. Thanks!

Thank you so much for discussing this. :)

I understand the general animosity we all have towards processes, but a process by itself is not necessarily cumbersome and hard to develop. So, in that way, I disagree with both @amsharma and @bcotton . When it comes to the community, I strongly feel that a process/structure would enable and guide the community and is well worth the initial effort that its development would require.

Please note that I have not said anywhere that the idea is to have an "approval process". That isn't the idea at all. Sorry if that came across from my communications on the subject.

No one is saying that we clone the current change process. It works so well, that it is the obvious template, but I think we all agree that it has a lot of bits that are not required for community changes. So, a heavily stripped down, bare-bones version of the current change process would perhaps serve as a good template to start with that will evolve as it is implemented and lessons are learned.

So, here are my answers to the relevant questions:

  • Mindshare Committee believes FESCo should have a vote in the Community change process.
  • Mindshare Committee believes the Council should have a vote in the Community change process.

I think a good way to go would be:

  • Mindshare will reach out to the relevant governance bodies for advice when the change requires it.

So, it'll be on a change by change basis. Not everything needs to go to FESCo/Council. Next, while other governance bodies would be able to advise Mindshare, I think it would be best if only Mindshare voted/decided the changes. That keeps the decision making bit simple and also ensures that the process doesn't get too tightly tied up with the various processes/schedules of these other governance bodies.

  • Mindshare Committee wants to define an ideal process or workflow first, and focus on the tools to implement after.

+1

  • Mindshare Committee recognizes that Community changes will be unique and special requirements or changes to our process may need to be taken based on individual needs.

+1: as said above, a bare-bones framework that can evolve over time or with the particular change process would be a good start.

  • What kind of things should run through this process?

I'm for a suitably vague definition here. Anything that a community member feels will affect the community should go through this process. This allows community members to use this process to get guidance from Mindshare + the community. If certain changes are very simple and do not need detailed tracking etc., bits of the process can be ignored. However, just the fact that the stakeholder will have the chance to discuss with the community + mindshare already shows the value of the process.

  • Would we consider doing a community poll for changes?

If by poll we mean voting, I'm -1. I'd rather just have a channel where the change can be discussed (as with the current change process on -devel). This ensures that the community is aware and has the chance to give feedback to the stakeholders. A consensus works better than a vote IMO. At the same time, it leaves community members enough room to experiment. Also saves us from adding "set up a poll" to the process.

  • Do we want to try to align with the change submission process to avoid recreating the wheel?

As I said above, I think this would be a good way to go. The current process works very well. It could be stripped down to remove all the bits that aren't necessary, and other bits could be made optional to be included or not depending on each particular change.

  • Since @bcotton mentioned "approval process", I'd like to add another point: Should Mindshare serve as an approval body, or merely an advisory one?

I'm strongly on the side of being an advisory body: based on the discussion that the stakeholder will have with the community (including Mindshare), the default expectation is that stakeholders would tweak their proposals. Additionally, Mindshare would be able to say "so, these tweaks would make the change better" or "how do you think these concerns that have been tabled can be addressed?" instead of saying "No, this doesn't work. Proposal rejected.".

Effectively, it makes this process one that allows Mindshare to enable awareness, discussion, and accountability in community changes. This fits with what I'd written in the Council ticket:

These changes should be announced to the whole community so that everyone is:

  • aware of the changes,
  • is aware of how it may affect them,
  • has the chance to weight in,
  • has a chance to join and help with the change.

I want to add that when I say we are in favour of formalizing a process, the "process" could be very simple, and completely align with what Ben is suggesting.

For example:
- post it on a wiki to have a source of truth about the proposed change
- present it at a Council meeting to get feedback
- present it at a FESCo meeting to get feedback
- publish 5 blog posts on the community blog
- tweet about the proposed change 8 times
- drop links in telegram 5 separate times
- start a conversation on discussion.fedoraproject.org
- send notifications to devel, announce, etc mailing lists
- solicit community feedback 3 times during the change process

These are all just options, doesn't have to be these exact, or this many, or this little. I think agreeing as a community and a group about what the desired level/amount of communication around community changes is a good place to start.

I'm +1 to a simple process, we still need to decide what steps are need, the @riecatnor examples are good, we can take it as a base.

@riecatnor:
I want to add that when I say we are in favour of formalizing a process, the "process" could be very simple, and completely align with what Ben is suggesting.

I understand the incentives to not have a process for yet another thing. But not documenting this as a process limits knowledge to a narrow subset of Fedora contributors who do know how to propose and pitch changes about the Fedora Community. One way to think about it is, there already is a process. It just depends if anyone has written it down before.

I like @riecatnor's first draft outline. A few specific comments below:

@riecatnor:
- present it at a Council meeting to get feedback
- present it at a FESCo meeting to get feedback

According to the Fedora orgchart, I think the Fedora Council should be a liaison for FESCo. I don't think Community Changes (or whatever we call these) need to go to FESCo for approval because there is no parallel for Fedora Changes to go through Fedora Mindshare.

I think using the Council as a liaison of FESCo (and knowing there is a FESCo seat on the Council) reduces complexity.

@riecatnor:
- publish 5 blog posts on the community blog

Maybe just one post? I like what @bcotton does with Council Policy changes where a Change gets one CommBlog post, and then that post gets sprinkled across Fedora mailing lists and social media for a week or two.

@riecatnor:
- tweet about the proposed change 8 times

Maybe time-box this to "8 times in two weeks" during the Change review process

@riecatnor:
- drop links in telegram 5 separate times

Maybe best to combine this into "social media outreach" with most-public groups and rely on Fedora Community to forward messages around (e.g. https://t.me/fedoranews as a single "Source of Truth").

@riecatnor:
- start a conversation on discussion.fedoraproject.org
- send notifications to devel, announce, etc mailing lists

:thumbsup:

@riecatnor:
- solicit community feedback 3 times during the change process

Maybe edit this to be clear on where feedback should be delivered. The outreach to different platforms encourages discussion in different places. Send a clear message on where feedback is most convenient to curate and where it has the best probability to be listened to.

Otherwise it is a "death by a thousand platform paper-cuts" where people speak up but their feedback is inadvertently missed.

When people think of procedures, they think of something cumbersome and time consuming because this implies commitment and to keep simple, people come and go..... specially in Open Source project.

I'm agree with @bcotton in:

What we need is better, more visible communication, not an approval process.

@riecatnor steps will can be as sample.... +1

Whatever we decided, we should keep this in mind -> Simple, Transparent, Inclusive and Adaptability

Regards.,

What we need is better, more visible communication, not an approval process.

Whatever we decided, we should keep this in mind -> Simple, Transparent, Inclusive and Adaptability

+1 to keeping the process more Simpler, Transparent, Inclusive and adaptable for a wide audience of Stakeholders.

I want to add that when I say we are in favour of formalizing a process, the "process" could be very simple, and completely align with what Ben is suggesting.
For example:
- post it on a wiki to have a source of truth about the proposed change
- present it at a Council meeting to get feedback
- present it at a FESCo meeting to get feedback
- publish 5 blog posts on the community blog
- tweet about the proposed change 8 times
- drop links in telegram 5 separate times
- start a conversation on discussion.fedoraproject.org
- send notifications to devel, announce, etc mailing lists
- solicit community feedback 3 times during the change process
These are all just options, doesn't have to be these exact, or this many, or this little. I think agreeing as a community and a group about what the desired level/amount of communication around community changes is a good place to start.

I'm also +1 to the Process, We can set it up as a baseline for us to further improve it.

Hello,

Thanks everyone for your time here. What would the next steps here be? I was thinking that the "teams directory" that the Council is setting up would be an excellent candidate for this new community wide change process? It requires all teams to be aware of the teams directory and their new responsibilities there?

https://lists.fedoraproject.org/archives/list/council-discuss@lists.fedoraproject.org/thread/NGFVTLWHJG47CL7JNN5VJSVV6ELYYEFQ/#EXCJJFXBATBPJHKR4RVVVRT5DGQXZSAE

Edit: "teams directory", not "docs directory"!

Note that the "teams directory" change has already gone through quite a few of the steps that were outlined for the community change process here, but it being announced as a community wide change process would greatly increase its visibility---which is critical to ensure that the directory and all the other pages where teams list their information are up to date and in sync with each other.

Edit: "teams directory", not "docs directory"!

Quick update: based on the discussion on the council ML, we thought it best to have the initial version of the team directory set up before publicising it using the change process here.

Anyway, what are the next steps here? I'll be happy to help where possible :sparkles:

Hi, given that the Community Outreach Revamp and the Websites & Apps Revamp are both started as Objectives, does it make sense to continue this ticket discussion?

I feel like the "Community Change" process discussed here is reflected through the Objective process. Objectives require coordination across many groups, and I am of the belief that any major "community-oriented" change should be driven through the community in this way.

Any thoughts? Agreements? Disagreements?

Hrm, no I don't think the Objectives process is the same as what we're discussing here in the same way that Objectives are different to "System wide" or "Self contained" changes on the engineering sideof things :thought_balloon:

For example, what happens to smaller community related changes that don't qualify as Objectives?

Hey folks, we took a quick look at this in the Mindshare Committee meeting today. Didn't have much time to come to conclusions, though a couple notes can be added here:
- It does seem like community changes occur without a process (new coc, revamps, etc), though I am not sure that means we don't want to define something here
- I personally see the greater need being the promotion/communication to the entirety of Fedora @ankursinha - is this the case?
- Looking back at this comment https://pagure.io/mindshare/issue/197#comment-641278 I see my suggestions are all related to communications

Yes, the main idea of having a well defined step by step "process" is to ensure that changes are communicated to the whole community, and that there's ample time for feedback. This is pretty much what the engineering change process does (with some additional approval from FESCo etc. when necessary).

In the absence of a well defined process, we just do it whatever we think is best---but there's no reference that we can look at to make sure that we're not missing things.

I think the new CoC etc are good examples. It was communicated on the community blog for example, which is perhaps now the default location for announcements. So, a page that says, for example: "remember to post on the community blog and set up a topic on discussion.fp.o to gather feedback" would be useful---especially since I assume that we don't want community changes to be limited to a top-down fashion where they are initiated at the Council/Mindshare etc. and go down to the community---it'll be great to have more community members working on changes that propagate up to mindshare etc. (when needed).

I think the word "process" makes it sound very formal, but we've discussed that there' no need to make it into a tedious collection of tickets and approvals. May be call it a "SOP" or "guidelines" or something that has a less onerous connotation?

The community-announce list proposal I just posted on the Council Discussion may address the need here.

Login to comment on this ticket.

Metadata