Modularity

    • How does it work
      • Building Software
        • Module name and ID
      • Consuming Software
        • DNF Behavior
    • Making Modules
      • Adding New Modules
      • Updating Existing Modules
      • Defining Modules in modulemd
      • Building Modules
      • Managing Defaults
      • Inspecting Build Failures
      • Building Modules Locally
      • Naming Guidelines
    • Hosting Modules
    • Using Modules
    • Community
      • Teams and Working Groups
    • FAQ
    • References
Modularity master
  • CommOps
    • master
  • Diversity and Inclusion
    • master
  • Engineering Teams
    • master
  • Fedora
    • rawhide
    • f28
    • f27
    • f26
  • Fedora Council
    • master
  • Fedora Docs
    • master
  • Fedora Documentation
    • master
  • Fedora Project
    • master
  • Fedora Silverblue
    • master
  • FESCo
    • master
  • Flatpak
    • master
  • Mentored Projects
    • master
  • Mindshare Teams
    • master
  • Modularity
    • master
  • Packaging Guidelines
    • master
  • Quick Docs
    • master
  • Home
  • Modularity
  • Community
  • Teams and Working Groups
Edit this Page

Working Groups and Teams

Modularity is driven by the Modularity Working Group

However, Modularity couldn’t happen without other working groups contributing a significant portion of effort into it, i.e.:

  • Server Working Group

  • Fedora Release Engineering

  • Fedora Infrastructure

This page was built using the Antora default UI.

The source code for this UI is licensed under the terms of the MPL-2.0 license.