In December, the Fedora Council met in Minneapolis, Minnesota for several days of meetings. With the holidays now behind us, here’s our summary of what happened.

Strategic direction update

The most important part of the meeting was our update to Fedora’s strategic direction. You may have read the Community Blog post about this already. While the wording — or at least the fact that we’ve written it down — may be new, the ideas aren’t. This document represents the next step from the efforts that began with Fedora.next back in 2013. Our goal is to allow members of the Fedora community to build solutions that focus on the specific requirements of their target users. This means, among other things, a more decomposed and self-service build process.

The earlier post generated a lot of discussion and feedback. I’m planning a series of Community Blog articles summarizing and responding to that feedback — stay tuned!

Objective updates

We also heard from three of the four current Objective leads. (Our Internet of Things lead, Peter Robinson couldn’t make the meeting, unfortunately.) The CI/CI Objective is wrapping up and Dominik Perpeet will be publishing a summary soon. The Modularity Objective is also ending its current phase. Modules for Everyone was a key feature of Fedora 29, and the Modularity team is continuing to improve the technical implementation as well as make it more approachable for community contributors. Both Objective leads will be proposing next steps to the Council in early 2019.

The Lifecycle Objective is just getting started. It has two goals: make the release process scale and allow & encourage more community ownership for deliverables. This ties in tightly to the strategy update — this work is required to get us to where we want to be. Paul Frields is working to gauge what’s needed to implement this now, including the proposed long cycle for Fedora 31 (discussed on the devel mailing list). The Council in general would prefer to keep to the regular six-month cycle.

Mindshare

The Mindshare team previously adopted a policy of spending up to $100 for release parties with minimal approval required. This has been successful, and the Council would like Mindshare to build on this with further investment. We agreed that Mindshare should adopt a policy of allowing up to $150 for activities that promote the use of Fedora solutions in communities. This could include release parties, web hosting, or other relevant activities. We want to encourage experimentation, so we’re not requiring the activities to be successful to get reimbursed — they just need to be successful to get future funding. The Council’s goal is to have 100 of these proposals funded in FY2020 (which starts in March of 2019). In order to encourage funding these proposals throughout the year, unallocated funds from this budget will be pulled into the Council budget at the end of each fiscal quarter. Look for guidance from Mindshare on how to make these requests soon.

Communication

We’ve started experimenting with using Discourse as the asynchronous communication tool for some teams. For synchronous communication, some teams are using Telegram in addition to — or instead of — IRC. Each platform has strengths and weaknesses. After discussion, the Council came to the conclusion that communication fragmentation is unavoidable. In a project as big as Fedora, people work in different ways and have different preferences. We leave it to each team to decide what communication methods work best for their team.

To help connect everyone together despite this, we have requested a central project management service from the Infrastructure team — probably Taiga, although we’re asking the team to also look at GitLab for this purpose. We’ll have a dedicated instance, likely hosted, and we ask each team to have a minimum presence on that tool, whether they use it otherwise or not. The presence should, at a minimum, indicate the team’s communication methods for synchronous and asynchronous communication and where project information may be found if not in the shared tool. That way, there will be an automatically-curated list of active teams. (See https://tree.taiga.io/discover for an idea of what this would look like — imagine each project there is a Fedora team.)

Infrastructure

The success of our strategy depends on improvements to our infrastructure. The Infrastructure team has limited resources, so we need to ensure they’re able to work on areas that add the most value to the project. This means a shift away from running all layers of the stack and focusing more on application management. The goal is to have the Infra team administering applications, not low-level infrastructure. (Even if that makes the team name confusing — sorry!) We want agility in our applications and deployment. We want drive-by contributors to be able to realistically contribute to the infrastructure team.

We also talked about GitHub. Ideally, we want everything to be on open source services (e.g. Taiga, Pagure, or GitLab). But, as a pragmatic matter, we recognize that GitHub has a huge network effect — there are millions of users and developers there, and millions of open source and free software projects hosted there, including software that’s fundamental to the Fedora operating system. We’d like better integration and syncing with tools like Pagure to give access to that network effect on all-free software, but we also know that there isn’t a lot of developer time to make and maintain those kind of features. Therefore, we’re willing to accept people in Fedora hosting their subprojects on GitHub. We’ve got to focus on what we do that’s unique (and only do things which are unique when we have a special need to meet our project goals). Git hosting is not one of those things.

General Council business

The Council wants to make it clear that community input is welcome on Council matters. Members of the Fedora community may provide non-binding votes on Council tickets and participate in meetings. Speaking of meetings, we’re replacing the Subproject report meetings with regular updates from the FESCo, Mindshare, and Diversity & Inclusion representatives. This should help provide better visibility into those organizations for the Council and the community at large.

We will also move all Council policies out of the wiki to docs.fedoraproject.org. The Council will use the wiki only as a scratch space for works in progress. Durable documentation will live on the docs site. We encourage other teams to consider doing the same.

Meeting Minutes

We didn’t actually conduct the meeting in IRC, but we took minutes in the same way. Here’s our detailed record.

#startmeeting Fedora Council Hackfest 2018

#chair mattdm bcotton tyll contyk dperpeet langdon dgilmore bex jonatoni sumantro stickster

#topic Mission overview + Strategic framework

#info Community Members are encouraged to contribute to the decision process with non-binding votes

#link https://qz.com/work/1468580/the-four-layers-of-communication-in-a-functional-team/

#info mattdm shows his favorite graph

#topic Fedora Project Strategy: “How do we make our mission real?”

#action Dominik will speak more loudly

#agreed Council will replace subproject report meetings with updates from FESCo, Mindshare, and D&I rep

#agreed Council adopts the strategy proposal (+9, 0, -0)

#action mattdm to post the strategy proposal to commblog

#agreed Council will make a final vote on the strategy proposal on 9 January 2019 (+8,0,0)

#topic Moving Council Policies to Docs

#agreed Council will move all Council policies and other durable Council documents from the Wiki to docs.fedoraproject.org and remove old wiki pages. (8,0,-0)

#info policies should be kept in a repo separate from other documents for ease of watching

#topic Objective Update: CI/CD

#action

dperpeet to write up final objective report for publication on Community Blog by January 1

#action dperpeet to propose a new Objective for future CI/CD work

#info the new Objective should include working with other stakeholder groups including IoT and SilverBlue

#topic Objective Update: Modularity

#action langdon to propose a new Objective for future Modularity work

#topic Objective Update: Lifecycle

#topic $150 release parties

#agreed Mindshare should move the easy process to $150 and encourage more non-RP uses (+9,0,-0)

#agreed: Mindshare should start providing $150 base support for solutions to help them grow (+9,0,-0)

#agreed: Mindshare should start attracting larger requests and develop a process. These requests are judged using Council provided Fedora Project strategy as guidance. (+9,0,-0)

#agreed: Mindshare should target at least 100 $150 events in FY20 (+9,0,-0)

#agreed Unspent budget allocated to the $150 event program will be pulled into the Council budget at the end of each fiscal quarter beginning with FY20 (+10,0,-0)

#topic Localization

#action bex to begin a conversation in the translation community about a platform that meets the needs of the translation workflow

#topic Logo

#info Adam Miller will not get a tattoo with our current logo because people will ask him why he has a Facebook tattoo

#info The design team is working on getting a proposal to the community to vote soon so we can select the new one by January 31 in final form for production

#topic Infrastructure

#agreed The Council supports greater efficiency in the infrastructure to allow more to be done, even when this means that we move away from self-hosted or self-maintained infrastructure. (+9,0,-0)

#agreed The Fedora Project wants to advance free and open source software and as a pragmatic matter we recognize that some infrastructure needs may be best served by using closed source or non-free tools today. Therefore the Council is willing to accept closed source or non-free tools in Fedora’s infrastructure where free and open source tools are not viable or not available. (+9,0,-0)

#action contyk, FESCo to work with Infra to examine current applications and determine: 1. which applications can be moved out of the datacenter immediately or in the short term, 2. Which applications have industry-standard open source or proprietary alternatives that we could move to.

#topic Communication

#agreed Fedora will offer a central place for teams and SIGs to be discoverable, do project management, etc. Having a landing page will be a requirement for all teams and SIGs in Fedora. (+10, 0, -0)

#agreed The Council will ask the Infrastructure team to evaluate providing the central place as Taiga versus Gitlab based on requirements provided by Council. (+10, 0, -0)

#action mattdm to write requirements doc for these two things above.

#agreed The Fedora Council embraces fragmentation in our communication platforms — this is a reality we can’t fight. The Central Place will provide a way for anyone to find the communication tools used by any group. (+10, 0, -0)

#topic Ticket #198

#agreed Document proposed in ticket #198 is accepted for delivery to Legal for drafting updates to the Trademark policy. (+10, 0, -0)

#topic Code of Conduct enforcement

#agreed The FCAIC is empowered to take action on Code of Conduct reports with an additional +1 from another core Council member or the Diversity & Inclusion Advisor and report back to Council. (+10, 0, -0)

#topic Ask Fedora and getting help

#agreed Council authorizes the hosting of a separate Discourse instance to replace ask.fedoraproject.org to be funded out of Fedora community budget. (+9, 0, 0)

#endmeeting