After the latest Fedora 30 release, its time for CommOps to look back on our progress and accomplishments as a team in the last 6 months. Incidentally, this retrospective also gives us a chance to reflect on the purpose of our team in the greater scheme of things.
I’ve created a wiki page [1] with a basic template taken from our F24 retrospective [2]. This retrospective is open for participation to any and all contributors. Whether you contributed once to a topic in a meeting or if you closed 100 tickets, your opinion and thoughts are equally valued in this retrospective. Feel free to share your thoughts on either this thread or directly on the wiki page.
Hi @dhanesh95, I appreciate you kicking this off and apologies on a late reply. I think this thread is an important place for us to start piecing together what’s next for CommOps.
One thing that was in the back of my head this year was thinking about what it is CommOps really does. When I read through our docs site about who we are and what we do, there are a lot of things listed there that we haven’t done for a long time, like supporting the elections and working with metrics. Partly because roles have changed and people have come and gone. But one thing I think we continue to do (and really what our original vision was all about) is how we can help other sub-projects be better at what they do and how to connect the pieces of the Fedora community.
An idea of an area I thought we could focus more on is project management. One thing that has struck me in the last few years is we have developed an interesting workflow of how we piece together tasks and break them down into smaller pieces. This is a skill and it’s something a lot of teams are working to be better at. From a recent conversation with @bcotton in #fedora-council, he also expressed an interest in creating a group to support project management in the Fedora community, but wasn’t really sure where that would go or what it would look like. I feel like this could be one area CommOps could start to specialize in just by documenting our own workflows and how we do things. But for this to work, we need to get more feedback on our processes and also learn how to adapt it for other teams’ specific needs.
Another idea is provide people resources and support to other teams in Fedora too. One example of this that comes to mind is helping other teams get “bootstrapped” with Fedora Docs. Since the recent migration to the new docs site, more teams in Fedora are putting their sub-project or SIG documentation onto the docs site. But a lot of teams don’t have the resources to do this or might need help with the first steps in doing this. They might need documentation or resources to help them do this effectively. This is one area that CommOps could try to pivot towards and find ways to partner with other teams to help them be successful together.
I also think we need to address the lines in our documentation about the FCAIC (currently @bex) and FPgM (currently @bcotton). When CommOps first began, we had a different dynamic. Remy (decause) took an active role in leading and engaging the team. His approach was to use CommOps as a community of people to help with some of the tasks he did as part of his responsibilities at the time as FCAIC. We also worked closely with the previous FPgM during elections and met with him on how we could be resourceful for the elections, and we divided up tasks based on the feedback we got from him.
For reasons not at the fault of anyone, the relationship the predecessors had with CommOps was not communicated and probably not thoroughly communicated. I think we need to reevaluate what we have written on our docs site and check in with both @bex and @bcotton about what their thoughts are their current involvement and participation with CommOps. Maybe now is a good opportunity to ask them how we could make their participation easier and have less friction in CommOps. Or maybe we need to rethink something else.
Admittedly I feel like my reply is really scattered and not extremely constructive, but I also acknowledged that I can’t keep putting this off too and we need to start moving forward somehow. I hope we can start kicking off that conversation now and find ways to make a constructive and positive step in the right direction!
Does anyone else have anything to add here? I think there are two types of feedback we need:
How to update our documented goals and mission to account for what CommOps does today
Ideas of small tasks we can start doing in 2019 to have a positive impact in the community (maybe branching off some of my suggestions above—or not!!)
Justin touches on some great points here. My thoughts on this, like his, are also a bit scattered.
If CommOps sees itself as helping other teams with people-power or project management, it feels like the team is then artificially segregating itself from those who it is helping. For example, if we have people to help with onboarding people to the docs site … why aren’t they on the docs team helping that team with the site regularly?
I have some other thoughts … but they are not yet fully formed. In general though, I wonder if we have an too many teams of 1-3 people and if we should combine a bit to reduce overhead.
The actual conversation is an excellent opportunity to bootstrap many ideas about the future activities of CommOps.
The actual multi-team composition of CommOps gives us many advantages as being a bridge between teams, have many different approaches to the problem-solving and rapid adoption of new tools in the always changing Fedora Project Ecosystem. @jwf 's ideas are very constructive. We need to update our documentation and set some goals for this year.
I think then like many of the *Ops teams we need focus on creating/update/adopt tools and process documentation to provide to the other teams the capacity to auto support they tasks.
One of my particular goals is to update our metrics tools and share it with the community; the first approach can be to generate the command line tools and base packages/APIs and in the second time retake the Dashboard initiative maybe as part of a GSoC project. I think that metrics are critical for every team because we can’t improve what we can’t measure.
In my own opinion, the Fedora Project has many small but specialized teams; this particular set of skills can be hard to get. Combine teams can difficult the original work of those teams I think will be better supporting the onboarding process.
Some activities than we can plan for this cycle can be:
Plan the next Fedora Appreciation Week.
Update metric tools.
Document the best practices and tools for Project Managing under the Fedora Project scope.
I agree with @bt0dotninja. CommOps is a team of generalists instead of specialists. We focus on the “people” aspect of our sub-projects and how to support community-focused needs of sub-projects.
For example, I am not a designer, but I know a great first contribution to the Design Team is to design a Fedora Badge. I might never open Inkscape but I know what the Badges workflow is and tips to get started as a designer. I may know Quick Docs is a great first contribution to Fedora Docs and I label Pagure issues and tickets for newcomers, but I may not write AsciiDoc every week.
CommOps fills gaps and connects dots between teams, similar to Mindshare Committee’s original goals from the 2017 FAD. Instead of a committee model of governance, CommOps opens mindshare-like tasks for anyone in the community to help with and contribute. When we see a “people” problem, our goal is to identify resources and a strategy to address it – because often, these problems aren’t faced by one individual team or sub-project, but many.
I always wished to have done more with metrics in the last two years. In 2015-2016, we led more metrics activities and I believe they had a positive, direct impact on the project. The metrics guided not only CommOps but also Fedora leadership to know what we were doing well and what could be improved. I give a big to make small steps to “owning” this metrics tasks again.
The metrics dashboard was always one of the dream projects. I think we could drive this idea through a Summer Coding project next year, but I am also concerned that this is a giant task for volunteers to take on alone. If we had support from one member of the Fedora CPE team along with CommOps members, I think this could be a sustainable pathway to getting the dashboard idea back on the table.
That said, I suggest not focusing too much time on the metrics dashboard just yet because it is a huge project and I think we need to identify more allies to help make it a reality.
I am on board for all of these. I ordered them by priority, but it is my opinion:
I see updating our docs as a way for us to re-state our purpose and goals. Almost like changing the direction of the ship. Maybe one way to help this move along is to put our docs into a Google Doc and ask for suggested edits there. Then we can move it back to the Fedora Docs site once we have a version we are happy with.
Next, I think documenting our own workflow and updating metrics our next steps we can take. I think it is better to document our own workflow and how we operate first before helping other teams. We can discuss ourselves what works and what doesn’t, and try to get that right. Then we can work more closely with other teams to make suggestions and help them with this kind of work. As for metrics tools, I think this is a good focus but it needs breaking down into smaller pieces. Maybe we could come up with one or two “mini-projects” for metrics that are not too ambitious. This could help us find our groove again and work up to bigger things.
I think FAW 2019 is important, but it can probably wait until end of August / early September to begin planning. Fortunately the tools we used last year are ready to go, so we have a “recipe” to follow for this year. Hopefully that makes it easier versus when we were winging it all the way to the first year.
What do you say? Does this action plan sound doable? Curious to know everyone’s thoughts here.
CommOps helping with project management makes a lot of sense. Not every sub-project / team may have the required resources and CommOps can always step in and help out in such cases.
I remember CommOps has done some similar tasks as part of providing support for on-boarding new contributors. We re-formatted the wiki pages for a couple of teams (as far as I remember) to make them more friendly and informative. This idea by @jwf makes it more specific and fits the CommOps mould.
A couple of those examples seem like something that the Fedora Join team has jurisdiction on. Just want to make sure that we are not stepping on each others toes here.
I’m onboard for all the three activities and agree with @jwf that we should hold back a bit on the metrics tasks.
Apart from that, I think we should also have a chat with @bcotton and @bex (as suggested by @jwf) on how CommOps can help with their tasks and probably start supporting them with a couple of simple ones, just to get a hang of it.
Admittedly, I’ve been out of touch with CommOps for quite some time. So please forgive me if I sound out of context in some places.
to make small steps to “owning” this metrics tasks again.
I think we could drive this idea through a Summer Coding project next year, but I am also concerned that this is a giant task for volunteers to take on alone. If we had support from one member of the Fedora CPE team along with CommOps members, I think this could be a sustainable pathway to getting the dashboard idea back on the table.
Maybe one way to help this move along is to put our docs into a Google Doc and ask for suggested edits there. Then we can move it back to the Fedora Docs site once we have a version we are happy with.