- * xref:index.adoc[Quick Intro]

- * xref:reporting-module-bugs.adoc[Reporting Module Bugs]

- * **Community**

- * xref:community.adoc[Communication]

- * xref:community/teams.adoc[Teams and Working Groups]

- * xref:community/project-tracking.adoc[Project Tracking]

- * xref:reporting-issues.adoc[Reporting Project Issues]

- 

- = Communication

- This page lists the communication channels and meetings of members of the Modularity Working Group (Modularity WG).

- https://webchat.freenode.net/?channels=fedora-modularity[{hash}fedora-modularity] on freenode::

- https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/[devel@lists.fedoraproject.org]::

- https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org/[server@lists.fedoraproject.org]::

- The https://fedoraproject.org/wiki/Server[Server SIG] also discusses Modularity at times as the Server Edition is a primary stakeholder in the goals of the https://fedoraproject.org/wiki/Objectives#Current[Modularity Objective].

- == Meetings

- Meetings are listed on the https://apps.fedoraproject.org/calendar/modularity/[Modularity calendar].

- Currently, there are two alternating meetings on Tuesday:

- Modularity WG::

- A formal meeting of the Modularity WG to discuss, post updates, and make decisions.

- Office Hours::

- No formal agenda, members of the Modularity WG promise to be present at this time for questions or discussion.

- = Project Tracking

- 

- The work and an overall progress is being coordinated and tracked on the https://tree.taiga.io/project/modularity-wg/epics[**Modularity WG Kanban Board**].

- 

- User feedback such as bugs and feature requests is being collected in the https://pagure.io/modularity/issues[**Modularity issue tracker**].

- 

- == What is being tracked

- 

- 1. https://tree.taiga.io/project/modularity-wg/epics[**Goals (epics)**] — A specific definition of a state we want to achieve, ideally a https://en.wikipedia.org/wiki/SMART_criteria[SMART] goal. Sets the direction of the project.

- 2. https://tree.taiga.io/project/modularity-wg/kanban[**Actions (cards)**] — Tasks that get us closer to a specific goal. Defines actionable work items contributors can complete.

- 3. https://pagure.io/modularity/issues[**Feedback (issues)**] — User feedback such as bugs, ideas, questions. Influences the project from outside.

- 

- == How we operate

- 

- We work with an Agile mindset. We have designed our system to transparently communicate our goals and intentions without the need to understand every single piece of work that is being done. It also allows us to display actionable tasks that are clearly defined and prioritized so anyone can help us move forward.

- 

- Because Agile is not making things up as we go, but rather iteratively working towards specific goals, the first thing that needs to exist are goal definitions.

- 

- === Setting and tracking the goals

- 

- Goal definitions are ideally SMART — specific, measurable, actionable, relevant, and time-bound. At the absolute minimum, they always must have a clearly defined purpose — so we know why do we want to achieve them, and a definition of done — so we know when exactly are they achieved. This way we can communicate the direction of the project.

- 

- Goals (epics) are owned by a single person who acts as a feature driver. The owner doesn't necessarily do all the work, but makes sure that actionable tasks that lead towards a completion exist at all times, and is responsible for the goal being completed. This way the project can be scaled across a large community of contributors.

- 

- Epics are defined in the https://tree.taiga.io/project/modularity-wg/epics[Epics view of our board]. This view is used for strategic planning and for monitoring the overall progress of the project. It also allows to drill down into idividual epics for more specific details about each goal.

- 

- The specific epic detail shows the purpose of the goal, the definition of done, and other information such as a delivery deadline. It also lists all the actions (cards) that lead to a completion of this epic. Epic owners use this view to define and manage individual cards.

- 

- === Making progress

- 

- To work on the project, contributors visit the https://tree.taiga.io/project/modularity-wg/kanban[Kanban view of our board] showing all existing cards sorted into different columns, each representing a specific state. Contributors can choose any card in the "Next" column they want to work on.

- 

- To work on a specific card, contributors can simply assign themselves to any card in the "Next" column and move it to the "In Progress" column. This way they indicate to other contributors that this card is already being worked on.

- 

- While working on a card, updates can be posted to the comment section of the card. Contributors can also mention other people in the comments to ask questions or to notify them about specific information. It is also encouraged to coordinate with other using the xref:community.adoc#_channels[usual communication channels] such as IRC.

- 

- When a card is complete, contributors are expected to post an update to the comments, and move the card to the "Done" column in the https://tree.taiga.io/project/modularity-wg/kanban[Kanban view of our board]. This step updates the progress of the epic the card belongs to which is useful for tracking progress.

- 

- If new actions appear as a result of a card completion, contributors should coordinate with the Epic owner about creating new cards for the new actions to ensure there is always next step in the queue.

- 

- === Reporting issues

- 

- Issues such as bugs or feature requests can be created by anyone in the https://pagure.io/modularity/issues[Modularity issue tracker]. This issue tracker is then processed by the team and new cards or even epics may be created as a result. Separating user feedback from the work lowers the pressure on the person who reports the feedback — they don't have to understand our tracking system.

- = Working Groups and Teams

- 

- Modularity is driven by the https://fedoraproject.org/wiki/Modularity_Working_Group[Modularity Working Group]

- 

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

- 

- * https://fedoraproject.org/wiki/Server[Server Working Group]

- * https://docs.pagure.org/releng/[Fedora Release Engineering]

- * https://fedoraproject.org/wiki/Infrastructure[Fedora Infrastructure] 

- = Modularity

- Modularity enables you to choose a particular stream (major version) of content that has been natively built and tested for your system, and to receive the right updates for it.

- That means you're no longer limited to a single version of each package for a given Fedora release. And because many streams are now available in multiple Fedora releases, you can install a specific version of software regardless of what Fedora release you're running.

- == Examples

- **Scenario 1**: Some users install packages coming from a different Fedora release in order to consume a specific version of a database that is compatible with their application. But thanks to Modularity they might not need to do that anymore, because multiple versions of the database can available in each Fedora release. All they need to do is to consume the specific stream of that database right from the Fedora repositories for their system.

- **Scenaro 2:** There were cases when users couldn't upgrade their system to a new Fedora release because their application wouldn't function with the new version of a language runtime coming with the upgrade. Modularity can fix this problem by providing the same language versions in both Fedora releases. With that, the user can consume a specific stream of the language and keep it even when they upgrade their system. And when the application is ready for the new language version, it can be upgraded later, independently from the OS, by switching to a different stream.

- == Compatibility

- Modularity is built to be 100% compatible with existing expectations and workflows. The installation and update experience continues to work the same way — even when there are multiple versions of packages — thanks to default streams.

- For example, the following two commands work the same way on systems with and without Modularity:

-     $ dnf install httpd

-     $ dnf update

- On systems with multiple httpd streams available, the default stream is automatically enabled and consumed. xref:using-modules.adoc[Learn more about using modules]. 

- = Reporting Issues

- 

- TIP: This page is about reporting project issues against Modularity. To report bugs against Fedora content — modules and RPMs — in their respective Bugzilla space, see the xref:reporting-module-bugs.adoc[Reporting Module Bugs] page.

- 

- There is a main issue tracker to report general issues. However, if you know you need to report an issue for a specific component, there is a list of below, too.

- 

- * https://pagure.io/modularity/issues[**General Modularity issue tracker**] — For general issues or when it is not clear where to report specifically

- 

- Specific components:

- 

- * https://pagure.io/fm-orchestrator/issues[MBS (Module Build Service) issue tracker] — Issues regarding MBS upstream project specifically. If your issue or RFE changes the syntax or semantics of the MBS input or the MBS output (RPMs built in a module or resulting modular metadata), it does belong to https://pagure.io/modularity/issues[**General Modularity issue tracker**]. If your issue is related to particular module build in Fedora infrastructure, it belongs to https://pagure.io/fedora-infrastructure/[Fedora Infrastructure issue tracker]. Any other MBS issue can be filed in the MBS issue tracker.

- * https://github.com/fedora-modularity/libmodulemd/issues[libmodulemd issue tracker] — Issues regarding the modulemd specification and the libmodulemd library.

- * https://src.fedoraproject.org/rpms/dnf[DNF issue tracker] — Issues regarding the "dnf module" command.

- = Reporting Module Bugs

- 

- NOTE: This page needs to be written

- 

- TIP: This page is about reporting bugs against Fedora content — modules and RPMs — in their respective Bugzilla space. To report project issues against Modularity, see the xref:reporting-issues.adoc[Reporting Project Issues] page.

- 

- Bugs against Fedora modules are reported in http://bugzilla.redhat.com[Bugzilla].