At a glance:
- Location: Red Hat Czech, Purkyňova 111, 621 00 Brno, CZ.
- Dates: January 29-31, 2018
- 1 Purpose
- 2 Impact
- 3 Participants
- 4 Planning prerequisites
- 5 Logistics
- 6 Schedule
- 7 Appendix
- 8 External links
The purpose of the CommOps FAD is to
- Pursue plan of deploying a GrimoireLabs dashboard, visualizing fedmsg data
- Launch Fedora Appreciation Day in 2018
- Analyze Fedora Elections and develop year-long plan to improve community engagement in elections
- Evaluate critical areas of Fedora that fedmsg integration would be helpful; create development plan for them (e.g. Fedora Magazine / Community Blog)
Fedora CommOps aims to improve "heat and light" inside of Fedora. This translates to "contributions and exposure". CommOps does this with technical work (e.g. fedmsg, data studies, etc.) and non-technical work (community engagement, Community Blog, elections, etc.). The tasks above fit into our greater purpose of bringing more exposure to various areas of Fedora and increasing contribution to key areas.
Primary goals are our most urgent tasks that set the minimum bar for what we want to accomplish.
fedmsg is a powerful tool, but its power is available only to those who know how to use it; a GrimoireLabs dashboard enables others to learn valuable insights from the data without writing any code.
fedora-commops#114 discusses this task. So far, we evaluated a few different solutions before deciding Grimoire as a best-fit for our use case. We understand already that a fedmsg plugin needs to be written. As a Python tool, it also fits in nicely with the "Fedora stack".
The following list explains use cases of visualized fedmsg data in a dashboard with charts, graphs, and other visual aids:
- Determine what times (days / months) people contribute the most
- Planning internal Fedora team sprints when more people are contributing
- Evaluate event success if new contributors enter the community after an event is completed
- Understand new contributors better and where they snap off (if they do)
- The Epic Journey of the New Fedora Contributor (i.e. using the visualizations to see pathways / successes / failures of new contributors entering the community for the first time)
- Leveraging Fedora Hubs research to build a dashboard like this
The FAD allows us the bandwidth to spend time to discover our needs, map out the development plan for the plugin, and design use cases for potential visualizations. Different parts of this task are addressed in parallel instead of in a linear way. While mapping out the technical requirements, we will discuss what visualizations we want to prepare at launch and how to introduce Fedora contributors to this tool with documentation.
Our end deliverable is a year-long plan for how to develop, implement, and promote a GrimoireLabs dashboard powered by fedmsg.
Fedora Appreciation Week
We plan to initiate the first-ever Fedora Appreciation Week in 2018, a week where contributors and users are encouraged to say "thank you" to each other for the hard work put into Fedora.
The Fedora Appreciation Week is discussed in [fedora-commops#110 https://pagure.io/fedora-commops/issue/110], although the idea pre-dates the ticket. Implementing the idea is difficult because the idea is still broad. This presented an obstacle for us to organize this remotely.
The FAD enables us to brainstorm a plan to do a soft launch in 2018 and outline long-term goals that were identified by Brian at the Fedora Diversity FAD in the future. We will evaluate our options for any tooling or automation to make this event require less manpower to run (ensuring consistency for running it in the future). After deciding on implementation details, the team will decide on milestones to track progress for launching the event. This helps us establish communication goals for raising awareness of the event and keep our flow as the event comes closer.
Our end deliverable is a proposal for Fedora Appreciation Week, with clear guidelines for what the event is, how the community can participate, and how we will raise awareness in 2018 for this event.
Secondary goals are other important tasks that are valuable to discuss in person, but are not "mission critical" for the success of our FAD. The depth of discussion on secondary goals depends on our progress with primary goals.
Improving Fedora elections
Fedora elections are a critical way to engage with the contributor community to shape the direction of the progress; we want to find ways to make elections more interactive and engaging both for candidates and the community.
The last election motivated this item to make it on our FAD agenda. Historically, CommOps supports the release manager in launching the elections each cycle, but the relationship was never formalized or documented. In recent releases, core team members were absent and not able to assist the release manager, but the lack of documentation on supporting tasks for the election led to skipped measures.
Our FAD provides an opportunity to…
- Document and formalize our supporting role with Fedora Elections
- Improve engagement in community elections to increase participation
First, we need to document our supporting tasks in organizing Fedora Elections and create a standard operating procedure, so routine tasks aren't missed. This helps both CommOps and the release manager ensure consistency between election cycles. Second, after identifying our supporting tasks, we want to address community engagement. Are questionnaires useful? How can candidates clearly communicate their platform to the community? What does the community want to know from candidates? What would make the elections more interesting? We hope to answer these questions and create new goals for the Fedora 28 elections (and beyond) to improve engagement.
Our end deliverables are two new internal pages that document our supporting tasks for the elections and a "checklist" of things to do every election, as well as a proposal for new changes for the Fedora 28 elections in Summer 2018.
Adding new fedmsg integrations
fedmsg is found in many Fedora applications, but it's biased towards technical areas of Fedora; our goal is to identify key community-related areas that have a potential pathway for fedmsg integration and determine how to implement support.
An example of this goal is in [fedora-commops#108 https://pagure.io/fedora-commops/issue/108], about the Fedora Magazine and Fedora Community Blog. This specific example is a non-technical area of Fedora, but it has a pathway for integrating to fedmsg (via WordPress plugins).
We will identify more areas focused on non-technical areas of Fedora and evaluate if a fedmsg integration is possible before our FAD. Our primary targets is WordPress, but we plan to have more identified before the FAD. Our time together in-person will be spent exploring technical details of integrating the platforms and determining the amount of work required. After, we will outline how to implement an integration. This will include identifying subject-area experts who may be willing to assist, as well as coming up with our own development outline and plan.
Our end deliverable is a list of areas that could support a fedmsg integration and a plan (undetermined length) of how to implement them.
- Is this realistic to accomplish?
- We separated our primary goals out from our secondary goals to make a reliable estimate of work we will accomplish in three days. The worst case scenario is that only the primary goals are met and we never cover the secondary goals. The best case scenario is we cover everything and meet all proposed end deliverables.
- A lot of this is technical work. Is CommOps the right group to address some of these things?
- Yes. Writing code may be one activity of our FAD, but it is not a primary task. Our discussions focus on the strategic and far-reaching goals and visions for the technical work. We hope to spend time together mapping out a path forward and communicating clearly with other Fedora developers to mutually support our efforts.
- Why so soon?
- The dates are soon, but we chose them to maximize the convenience of the DevConf / FOSDEM week. Many Fedora contributors travel to DevConf and/or FOSDEM, and this allows us to gather people who may not easily attend our FAD. Even if costs are more expensive to book now than a month or two ago, we believe the costs are still less for us to organize during this time because of travel costs we don't have to pay.
Each goal explained above has its own unique impact to the Fedora community.
- GrimoireLabs dashboard
- fedmsg for the masses: Make fedmsg data more accessible to everyone in Fedora, even without programming knowledge
- Avoiding pitfalls: Fedora community members can use data to measure impact with their own efforts and understand the health of their own project
- Fedora Appreciation Week
- Good morale all around: Emphasize Friends part of Four Foundations and increase positive interactions in community
- Set an example: Set an example and the tone for how we treat each other in Fedora community, both for our contributors, potential contributors, and members of other open source projects
- Improving Fedora elections
- Restore confidence: Instill confidence in community of the election process (in turn, instills confidence in the community leadership bodies)
- Increase engagement: More candidates participating in elections, better understand of candidate platforms, more voters in elections
- Adding new fedmsg integrations
- A whole new world: Potential to understand non-technical areas of the project in a way we have not accurately measured before
|Justin W. Flory||X||X||X|
Review proposal as team at Monday, Dec. 11 meeting Calculate final budget Submit proposal to Fedora Council before Wednesday, Dec. 13 meeting
- Complete supporting research leading up to FAD
- Gather on Jan. 29!
We propose our FAD dates immediately after DevConf in Brno, Czech Republic.
- Location: Red Hat Czech, Purkyňova 111, 621 00 Brno, Czech Republic (TPB-B Argentum meeting room)
- Date: 2018 January 29 – 31
- Participants arrive on Jan. 28 (or Jan. 25 to participate during DevConf as well – accommodation during DevConf not covered)
- Participants leave on Feb. 01
|Contributor||Travel Plan||Estimated Travel Cost||Accommodation|
|Bee Padalkar||MUC <=> VIE <=> Brno||~$130 (air) + ~$23 (bus) = $153.00||$184|
|Justin W. Flory||ROC => VIE => Brno : BRQ => ROC||~$405 + ~$23 (bus) + ~$450 = $878.00||$123 ($246 /2 shared room)|
|Sachin Kamath||COK => VIE => Brno : BRQ=>COK||~$550 + $23 (bus) + ~$520 ~= $1100||$123 ($246 /2 shared room)|
- Travel: $2131.00 USD
- Accommodation: $429 USD (Not the final value - will be less.)
- Location: $0
- Red Hat Office Brno (TPB-B Argentum meeting room)
- Meals: $460 USD = $72 per attendee + $100 for one social dinner (breakdown below)
- Supplies: $0 for anything else you may need
Total budget: $3020.00 USD
- $9 USD /ea
- $15 USD /ea
- Total per person:
- $9 + $15 x 3 days = $72 USD
Total food cost: $460 USD
Determined in early January, closer to FAD.
To be completed.