Community Ops goals from community feedback

Most of this feedback is generated from Flock 2023, but may also include community feedback from post-Flock.

Possible options for the below columns:

• accept
• reject
• discuss

Feedback	Justin	Sumantrom	Alberto	Outcome
Managing organizational & project processes	Conditional accept. This should not compete with other bodies, e.g. Council, Mindshare, FESCo. CommOps shre, FESCo. CommOps should	yes, we share this with council.Exactly why we should report to council directly. That should help. accept.	Conditional accept: It's unclear to me what kind of organizational activities are not handled by Mindshare, FESCo, CoC Commitee, or the council.	Accept. Documentation of existing processes, how things work, helping teams figure out how to make things more clear.
Support for community folks	Reject. Needs more specificity.	Discuss. I believe, support for users for problems in distro is ask. Support community to organize events is Mindshare. We can support with upcoming community bettering initiaves and changes. These will be placed under "council" and "SOP will be needed"	Reject, need to be more specific.	Reject. "Support" means a lot of different things to different people. Other items could better capture the idea.
Finding stuff-n-things (triage)	Reject. Needs more specificity.	Accept. Commops should be one stop answer to bettering processes and discussions related to geo-specfic process implementation.	Accept	Conditional accept. Reframing: CommOps is the first landing place for sharing feedback/input on processes in the community (generally). We want the incoming Operations Architect to help with this part.
Enhance Fedora community collaboration and effectiveness	Accept. Vision/mission statement criteria?	As one of the Goals. Yes. Accept. Should however be noted that we will still be relying on existing platforms/meduim of communication and structure in place to achieve. We WILL NOT be owning creation of new systems, unless that is the direction, the whole project benefits from..	Accept	Accept. For Impact/Outcome. Candidate for inclusion in vision/mission statement.
Execution on strategic plans (project management / PgM)	Reject. CommOps should not be PgM.	Discuss.	Reject	Reject. CommOps is not PgM.
Implement and provide feedback on Fedora Council policies	Reject. CommOps could provide feedback as individual members, but this is ultimately a Fedora Council responsibility.	Accept. Policies that involve community's wellbeing, growth and manifesto. We will not solicit feedback for things that are running as initiatives which come directly under council.	Accept. I like the reframing	Conditional accept. Reframing: CommOps increases awareness across the community when the Council is adopting/revising policies that may impact collaboration and engagement in the Project. Fits under "storytelling/messaging" umbrella.
Define and quantify the roles and responsibilities of CommOps team so as to remain focused and head off scope creep.	Accept? I mean, this is what we are doing now.	Accept. Revisit Mindshare Commops represenation.	Accept	Accept. As an impact/outcome (CommOps team purpose is clear). As an activity/output (documentation, explaining the type of work done but not the work of an individual person per se).
Care and nurturing of the community	Conditional accept. Same thoughts as Sumantro.	Disscuss. Needs scoping. Almost accept, Caring for a growing community needs constant checkups and finding the proactive people. To keep the community retention needs us to refine process of overall contribution much more a11y friendly, DEI friendly and all of that falls under Program Management and FCA.	Accept but needs more discussion about the outcomes of this activities	Conditional accept. Reframing: CommOps has a pulse on the health of the community and can talk about what is working and what is not working. What needs more care and nurturing in the community? Possible output: A community scorecard (green/yellow/red) for certain parts of the project.
Health and belonging in the community	Conditional accept, group with above.	Same as above. Club together.	Accept	Group with above. Belonging specifically belongs with the DEI Team (see what we did there?).
Ensuring member safety	Reject. This is a better fit for the DEI Team.	Reject. Mindshare's DEI rep, FCA, council members then serving and legal has that. CoC is very adaptive. IF somone thinks more is to be added, they need to talk to any/all the abovementioned parties.	Reject	Reject.
Inclusion programmes	Reject. CommOps could redirect ideas/feedback to the DEI Team, but CommOps should not own inclusion programmes.	Yes. Accept. DEI is still with Council. We will help with emerging inclusiveness ie a11y as of today. We wont own, it will be owned by DEI or a11y WG as the end product. We only help with launch and implementation. Kinda like incubator.If we get many such, we might consider talking to someone from relavant field to understand the levarage the change/programme bring in to fedora as whole.	Reject, sounds like a DEI activity	Reject. Needs more specificity to avoid overlap with the DEI Team.
Code of Conduct	Reject. CoC Committee responsibility.	No. See above.	Reject	Reject.
Maintaining harmony	Reject. Needs more specificity. Probably a CoC / DEI overlap anyways.	Discuss. With? other communities? between members? between groups? with redhat? with other communities in the industry?	Reject	Reject.
Creating spaces for community discussion and interaction	Accept. CommOps should facilitate interactions across the community and team by making spaces for interaction.	yes and no. The scope is to have discussion related to problem in process (existing or about to be implemented). We dont create any NEW system/space , we reply on existing solutions . We can help with discussion subsection or a private ticket in pagure/gitlab BUT not anything new. Infra team takes care of the space and council keeps tab on these spaces enforcing CoC. The official channels are as far as we can go.	Conditional accept	Conditional accept. Reframing: Making space for community discussion and interaction in existing channels/systems.
Communication	Reject. Needs more specificity.	Vague. See above comment. Reject.	Reject	Reject. Communication can make sense for CommOps but we need to narrow it down to something more specific to be meaningful for CommOps. Not overlapping with Marketing.
Identifying the needs that are common across communities and addressing them from that broader perspective	Accept. I think this is different from inclusion programmes, but this broader view is what CommOps is about in my opinion.	Inclusive program has commenrs about this. Accept.	Accept	Accept. Candidate for vision/mission statements as an Outcome. Needs clarification on what is meant by "communities". Inside or outside of Fedora?
Manage chat platforms behind the scenes so people can meet and work easily in the community	Reject. CommOps is not a moderation team.	No. Moderators do that. Commops can publish a list of mods to public for knowledge and reporting mechanism for clarity. Reject.	Reject	Reject. CommOps would be the team to help a Moderation WG/SIG launch, but not own moderation itself.
The cement between the bricks, OR the oil keeping the engine running	Accept. I mean, conceptually. This is like a vision/mission statement sort of thing.	Discuss.	Discurss	Reject. The thought is right, but the specific phrasing here is not universal so we should avoid using it in a charter/vision/mission.
Infrastructure contributor / user experience	Discuss.	Discuss.	Discuss.	Conditional accept. Likely for Phase 2, not our initial phase. Reframing: Helping connect feedback about infrastructure/app user experience to the right stakeholders.
Politics and diplomacy	Reject. Needs more specificity. Politics and diplomacy sounds like Fedora Council to me.	Politics and diplomacy has two opposite meanings. We do side with the right thing. We can be wrong but its not one or two person who take the decision, its a lot of us. We do however want to keep things stable and not do the "call-out" on behalf of commops. We are all a part of a bigger organism herein Fedora and we will do what's better for Fedora overall.	Conditional accept. The reframing is good	Conditional accept. Reframing: Helping navigate difficult conversations when there is friction in processes, workflows, getting things done in Fedora, etc. CommOps does not help reverse a decision made somewhere else in the community. A CommOps contributor is not a special person who can undo decisions or make people reconsider something. We facilitate, but do not dictate.
Sociology and group dynamics	Discuss. This was Greg's point, and to a certain point, I think group dynamics is part of what this is about. But it needs more specificity.	Discuss. We promote things like neurofedora. we can have another specialized arm which can help evaluate our group dynamics but thats not commops starting focus.	Reject.	Reject. Other points capture the motivation of this point. Interpretation of this point is likely not universal.
Swag and funding	Discuss. CommOps should not be a budget-deciding body, but I could REALLY use help on decentralizing the swag creation and distribution duties.	Mindshare. People from commops can reach out to commops rep in mindshare who can assist with funding tickets and event organization, given the criteria set up Mindshare are respected. ie Approaching commops rep 1 weeks before the event and asking for budget and swags, wont work.	Conditional accept.	Conditional accept. Not about budget, but about execution of the swag process. Activity: Creating a community survey for the swag that the community wants to see. Output: Working with Design Team to scope out the popular items, working with Mindshare Committee on budget approval. Execution of designing, ordering, and distributing the swag.
Governance	Reject. CommOps works within the governance of Fedora but does not create something new.	No. Reject. Unless something is buring down contributor's wellness and prospects of innovation by contributor.	Reject
Partnering with bigger contributors	Accept. In terms of getting a wider range of contributors involved at the start. Not really a "responsibility" per se.	Discuss.	Discuss
Coordinating projects across multiple teams and making connections	Conditional accept, on the basis that CommOps is not PgM-as-a-Service.	Read incusion programme and Enhance Fedora community collaboration and effectiveness	Conditional Accept
Event planning & promotion	Reject. Fix Mindshare first before delegating events elsewhere.	Mindshare does this. Reject.	Reject.
Facilitating meetups and processes for teams	Reject. I think CommOps should avoid being a process group, actually. I would like CommOps to do the "afterburn" of these things, i.e. reporting and messaging on how meetups went, the outcomes of a decision-making process, etc.	Meetups of different sub teams –> then discuss Meetup of team members for events –> Reject.	Reject
Conflict resolution	Reject. Code of Conduct Committee.	Council's +FCA. Reject.	Reject
Events	Reject. See previous events item.	vague. Reject, we have events talked about above.	Discuss, maybe make some process docs for events and talks will be benefitial for Ambassadors and advocates
Community advocacy towards Red Hat, or maybe Red Hat advocacy towards community (RH propaganda??)	Reject. This sounds more like my job. :-)	Discuss. This sounds very dramatic to me. It has the angle to politics which we dont want to participate or delve in.	Reject
Building and maintaining systems and workflows for community releases	Reject? Probably Ops Architect responsibility.	Releases? Fedora Releases? That's Fedora Program Manager, he/she/they sit out of Council and Commops can extend suggestive feedback (not sure if they will implement) about a certain type of workflow and system.That might helpful to certain members of commops to partcipate in other areas of the project.	Reject
Creating and updating governance processes	Reject. Originally, I was like "yes processes!" But lately, I am feeling like "no, report on the outcomes of processes instead of creating more opaque bureaucracy."	No. Reject.	Reject
Organize the community??	Reject. Needs more specificity.	in order to? facilitate ?	Reject
Contributor journey	Accept. Someone mentioned the idea of owning the onboarding pipeline after Join. This feels like that.	Accept. Storytelling is commops thing.	Accept.	Accept. Also, the Join team is reactive. We (as part of the join team) don't have a promotion strategy. We only receive newcomers and try to help them meet the SIGs more adequately.
Supports community members who are getting started in the project (technical, resources, etc.)	Accept. Although I think it needs a defined scope.	Yes. Accept. Commops exclusively relies on Join. Commops might come up with a playbook which can give more info about the Project overall. A project playbook , if you may. This will talk about journey of Fedora and community members across the globe. Will be broadly story telling.	Accept. I love the idea
Check-ins with groups	Accept. In the past, CommOps was successful by actively seeking out other groups and being visible where people worked, instead of waiting for people to come to us. I want to go back toward that direction.	We can help develop playbook with accordance with WG and ask them if they have something specfic in the process they want us to talk about or address.	Accept
Follow-ups	Reject. Needs more specificity. Probably fits with above point.	valgue. discuss.	Reject.
Establishing SOPs	Conditional accept, in terms of not creating new processes but making existing processes more clear.	yes.accept.	Accept
Fingerposting: manned or unmanned	Reject. I think this term is unclear, it was explained to me at Flock but I already forgot what it meant, and it is probably confusing to others too.	with SOPs and process. Internal communication,yes	Discuss
Driving transparency	Accept, on the basis that I think this is an outcome of of CommOps, but not necessarily an activity or output.	Vague. Reject. Transparency comes in all shapes and sizes. viz if this is about budget, yes. If this is about who has the most amount of CoC tickets in their name and what we discuss with legal, then no.	Discuss
General “glue work”	Accept, on the basis of impact/outcome and not activity/output.	Yes. Commops is the blood of the system. It carries oxygen and freshness, it glues multiple siloed functionality and can help connect dots in some cases.	Accept.
Transparency	Duplicate, see above "Driving transparency".	Reject	Reject
Coordination of community and goals	Accept. See "Check-ins with groups" for my thoughts.	Discuss	Accept
Manage cross-org infrastructures (community metrics, fedmsg, Fedora blogs, Fedora policy docs)	Conditional accept, on the basis that we should make it easier for people to use/know about these things, but not necessarily to hack on them.	Nopes. Reject.	Discuss
“Progress, not perfection.” To be a catalyst of wharever you interact with.	This feels more like a mantra than an activity/output, but I like it. :-)	Reject	It sounds nice but is more than a how-to and not like an objective
Do not just talk (or write, or whatever).	I mean… yes! Generally, this is good but not CommOps-specific.	Discuss	Discuss
Statistics	Accept. See Project Aspen / Linux / confused metrics group identity.	maybe ? long term?	Accept. I have experience on this kind of things, so I can help
Responsible for contributor analytics	Accept, but same thought on driving and not responsible for.	responsible no, can drive ..maybe	Discuss
A report on community health	Discuss. I think this could be an amazing output for a 6-12 month Initiative. Might make a great Output.	Mindshare does survery, reject.	Discuss, maybe we can contribute with other complementary metrics.
Establish an initiative to track new contributors through their first contributions and for a period after to determine if they are a drive-through/fly-by contributor	Reject because this sounds very involving, although this might make a good "Phase 2" for CommOps if our first phase of relaunching the team is successful.	reprting… tracking… sound slike data science and yep maybe in looong term or as initiative.. reject for now.	Discuss. I have often wanted to know how good Fedora is at onboarding and retaining contributors. I can make some data science but maybe for a second revision of the commops objectives but this metric is essential for decision bodies like Mindshare and the Council.
Enhance engagement and diversity	Accept, but on the basis of being an Outcome/Impact.	too broad …discuss?	Discuss
Recruit, mentor, develop	Reject. Needs more specificity. Recruiting and mentoring people in cross-project areas is good but we are not a developer group.	what? process? community folks?	Discuss
CommOps supports the community by providing help in turning ideas into results	Conditional accept. Needs more specificity on the "how".	yes conditionally	Conditional accept.
Own the contributor funnel or lifecycle after the Join SIG stage	Accept as a long-term goal? Vision/mission statement	scoping needed	Discuss
CommOps brings together teams in Fedora, helping them to achieve goals which improve the community as a whole	Accept on the basis of this is something that we want to do long-term. :-) Vision/mission statement, probably.	ehh? IMO thats what we do? how and what needs answering I suppose	Accept