FAD CommOps 2016

Postponed
Planning for this event has been postponed in the interest of focusing on the CommOps workshop at Flock 2016. There, we hope to revisit planning this event for the future.

This is the main page for the Fedora CommOps, which is a vFAD focusing on on-boarding new contributors, knocking down blockers for other teams in Fedora, and working on our ticket queue.

This event is intended to primary be a virtual FAD, as it not likely there will be a travel budget for this event.

Purpose

1. Our purpose is to complete the following primary goals:
   1. Clean up the existing queue of tickets and follow up on older / pre-existing tasks
      1. Also related: clean up and better organize our own workflow in a more centralized way (there's lots of stray git repos and Etherpads - finding a way to unify this information would be helpful for new contributors to CommOps)
   2. Work on new contributor on-boarding, specifically with the Badges series proposals that are in progress
   3. Build new ways CommOps can help contribute to supporting other sub-projects in Fedora
2. In addition, we will attempt to complete the following secondary goals as time allows:
   1. Better categorize and organize the wiki
   2. Develop a "satisfaction survey" for CommOps members to (anonymously?) provide feedback about how engaged they feel, what they think is working, what isn't, how we could improve, etc.
   3. Contribute art assets to the Badges Trac where possible

Impact

The completion of these goals will create the following positive change within the project:

1. On-boarding
   1. One of the founding principles and goals of CommOps is to help make it easier for new contributors to get involved with the project and help spend time and effort on the project.
   2. There are existing efforts in CommOps to help improve the process for newcomers by taking advantage of Fedora Badges, improving existing documentation by various sub-projects for getting involved, and devising solutions of how to make the barrier to entry much lower. Taking explicit time to focus on the existing tickets and ideas related to on-boarding specifically would allow us to help improve the "first experience" of a new contributor to Fedora IMMEDIATELY and DIRECTLY. This is work that would improve that user experience and draw more contributors into Fedora.
2. Increased efficiency
   1. As far as Fedora goes, CommOps is a newer sub-project and started (officially) around October 2015. When we first began, it was hard to be able to tell how things would go, and many of the original methods of organization and initial guidelines for how CommOps operates could be updated based on the current context of how things are now.
   2. At the vFAD, we would be able to spend time looking at our own tooling (Trac tickets, Pagure repos, etc.) and devise ways to improve organization, construct an efficient and effective workflow, and spend time improving the "foundation" of the "CommOps house". Ideally, this would allow us to more efficiently respond to new tickets, follow up on old ones, and keep current on where our time and efforts are best spent.
3. More heat and light
   1. Lots of things have started happening since CommOps started, and some older tasks and tickets have been neglected because of other (important) tasks. Having a time dedicated to revisiting older items and spending time working on them (or closing them, if necessary) would help us keep on top of tasks related to our objectives as a sub-project.
   2. These changes would benefit Fedora as a whole because it will allow us to better spend our time and efforts supporting Fedorans across the project in more relevant and important ways in the long run.

These outcomes connect with the following Fedora Community Objectives by advancing the development and progress of all Fedora sub-projects in a general sense, and it allows us to better bring new contributors into Fedora. With the on-going development of Hubs in progress (and not too far away from being in a "first demo" state), it is important for CommOps to spend the time and effort readjusting our own practices, supporting the on-boarding methods of other teams, and catching up on the queue of tasks so as to be prepared for a new generation of contributors and contributions, but also being able to support the existing contributors and contributions in the best way possible.

Detailed Work Items & Final Attendees

• See FAD_Fedora_Talk_2009_game_plan for an example

Planning Prerequisites

See the How to organize a FAD list; you can keep your to-do list here.

• Discuss objectives and goals, create proposal
• Work out budget (not applicable for this event, is virtual)
• Decide on dates / times
• Prepare resources and planned areas of focus for the FAD (organizing tickets into a list for vFAD?)
• Spread word about the FAD across project, invite others to contribute and support
• Create a Badge to award to vFAD participants
• More coming soon…(?)

Plan

1. Location: #fedora-commops / #fedora-meeting-4
2. Date: July 2 - 3
3. Schedule:
   • Hacking begins on July 2, 13:00 UTC
   • Schedule item
   • Schedule item
   • Schedule item
   • Hacking ends on July 3, 23:59 UTC
4. Important skills (one or more)
   • skill
   • skill
   • skill
5. Personnel (people who might fit the bill)
   • Name (location, role) Confirmed? (Y/N)
   • Name (location, role) Confirmed? (Y/N)
   • Name (location, role) Confirmed? (Y/N)
   • others?
6. Other considerations
   • Contributor V can offer a living room for evening social gatherings.
   • Contributor W has a car and is willing to do airport pick-ups.
   • Contributor X needs as much advance notice as possible.
   • Contributor Y has a schedule that is better on Fridays than on Tuesdays, and prefers weekend times after 4:28 AM.
   • Contributor Z is allergic to peanuts.

Logistics

Not applicable for this event.

Budget

Not applicable for this event.