From Fedora Project Wiki

Revision as of 19:03, 5 July 2016 by Jflory7 (talk | contribs) (→‎How do we bridge them?: Not just talking about problems, but talking about solutions too)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This is a CommOps retrospective generated using the Marketing retrospective SOP (sort of).


History

This is the first-ever CommOps retrospective for a Fedora release. Taking a page from the Marketing retrospective, the CommOps retrospective is a chance for us to reflect on our progress and accomplishments as a team, evaluate what worked well, what didn't work well, and how we can improve. 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 to help better gauge how we are doing and what we can do better.

In the past year, a lot of things have happened. Firstly, CommOps became a thing! We officially began around October or so, judging by our first meeting date. We've created over 70 tickets in our Trac, closed roughly half of them, and are helping bring unity and cohesion to the project. One of the deliverables from our work is the Community Blog, which recently hit over 100 posts. With coming release cycles, we hope to accomplish more as a team and a project together. Some of the largest objectives for coming release cycles is improving the on-boarding process for new members of sub-projects and teams, as well as helping improve communication of information across teams, such as with Ambassadors and Design.


Good Stuff

What did we do right?

"We really did a goob job with… …because…"

  • The Elections cycle for December 2015 was handled very well and become the fourth most participated election of all-time in Fedora. Using the Community Blog as a publishing platform for candidate interviews helped share candidate platforms and also help build readership of the Community Blog. The overall communication about the elections went smoothly and helped set the bar for what's needed for future elections. --Jflory7 (talk) 15:01, 5 July 2016 (UTC)
  • Introducing the Community Blog as a publishing platform and separating it from the Magazine helps us specialize between "marketing" and "internal communication". The CommBlog is great for publishing contributor-specific news about development, events, and updates across the project. It allows the Magazine to have a more strategic approach in reaching out to non-contributors and users as well. --Jflory7 (talk) 15:01, 5 July 2016 (UTC)
  • Extensive use of tickets by Justin was fantastic. It helps people keep track of what has happened during meetings and provides them the opportunity to discuss and participate. This is especially helpful for those who are not able to attend meetings or have forgot about certain things mentioned during the meetings. --Woohuiren
  • The Python3 porting vFAD was a successful event that got a fair amount of attention and traction. Utilizing communication platforms like the CommBlog and Magazine proved effective, and helping coordinate getting a badge created for this event was also helpful. I think we helped establish a precedent for organizing future vFADs and how to best promote them. See ticket #4 for this discussion and planning. --Jflory7 (talk) 18:53, 5 July 2016 (UTC)
  • Helping with some Flock items this year was a big plus. We helped communicate the bid process, made the official announcement across the entire project, and hopefully helped simplify the process for some of the organizers. --Jflory7 (talk) 18:53, 5 July 2016 (UTC)

What can we do better?

"We could have done… …better by trying to…"

  • Google Summer of Code and Outreachy students are required to be posting weekly breakdowns. It'd be great for them, and for commops, to carry their updates on the CommBlog to help generate interesting content, and prove value in future cycles. --Decause
  • It's always been my concern that the meetings move at a pace that might be difficult to follow as a new contributor. Adding 30 minutes to our meeting time helped considerably with this, but sometimes, I feel like the discussions may be constructed in a way where they are too one-sided. Is there a way we can help open up discussions? I feel like the meetings should be more participatory instead of observational. Obviously there will be time where this cannot be helped, but are there things we can change now to lower the barrier for participation further? --Jflory7 (talk) 18:56, 5 July 2016 (UTC)

Improvements

Where did we have gaps?

"There were gaps with how we… …because…"

  • Lack of participation in CommOps from diverse regions. Most of the things happening on the Community Blog is often EMEA or US region. Discussions and meetings lack geographic diversity as well. --Woohuiren
  • Sometimes it felt like we assigned almost too much to our plate for things to work on. Keeping a realistic view of the assigned work was a challenge at times. --Jflory7 (talk) 18:58, 5 July 2016 (UTC)
  • There are not enough "low-hanging fruit" contribution areas for newcomers or even experienced members from other parts of the project to tackle. Looking at a meeting or our tickets might be overwhelming, and it might be hard to find a place to break in and start contributing as a new member of CommOps. --Jflory7 (talk) 18:58, 5 July 2016 (UTC)

How do we bridge them?

"We can solve… …by…"

  • Try reaching out to the more well-known folks that are active in the region and invite them to participate or share what we do. --Woohuiren
  • For more complicated tasks, we should be mindful of what exactly is a complicated task, and if necessary, break it down into smaller pieces or tickets, so as not to overwhelm a single person or the team at once. --Jflory7 (talk) 19:03, 5 July 2016 (UTC)
  • Intentionally and deliberately creating "low-hanging fruit" tickets or tasks would be considerably helpful to the future growth and life of CommOps. We want to bring new contributors into the team, but to do that, sometimes you need to start small to reach a level where you're contributing at a rate that is personally doable for an individual contributor. I'd like to possible allocate time at our Flock workshop to create low-hanging fruit tasks and actions so we can try to build our numbers as a team. --Jflory7 (talk) 19:03, 5 July 2016 (UTC)

Ideas and Wishlist for F25

"I wish for…"

  • A continued tight loop with Electioneering communications. --Decause
  • A tighter loop publishing the goings-ons of the Fedora Council (even just re-posting the mailing list update wouldn't be bad). --Decause
  • A tighter loop with FAmSCo (Soon to be FOSCo?) where we help their agenda and action items reach out further into the community. --Decause
  • A dedicated place where GSoC metrics are published and viewable (skamath and [[User:bee2502}bee2502]] are working on this to make it a reality this summer cycle. --Decause
  • CommOps involvement in the Docs team, to help get a better pipeline between release notes -> alpha/beta/ga announces. --Decause
  • More help for the FPL to do 5tftw. --Decause
  • More help for Ambassadors to get their event reports reposted (will help with budget proposals in the future!) --Decause
  • Everyone to know how proud decause is of the members of this team who have built a very healthy community architecture where new members and contributors can feel welcome and get started in their journey into FOSS :)

FriendsFeaturesFreedomFirstForever, --RemyD.

Improve this retrospective!

If you see a way to improve this retrospective, please go ahead and edit the page - you don't need to ask for anyone's permission. Read more about our contribution philosophy.