Summary

Register a new Fedora Council GitLab sub-group in the Fedora top-level group (i.e. namespace gitlab.com/fedora/council/

Background

I have two motivations for proposing this change:

1. Short-term: Creating a new repo (e.g. fedora/council/commarch) to track issues related to Fedora Community architecture and community engagement.
2. Long-term: Migrating and breaking up the Council docs Pagure monorepo to multiple docs repos in the Fedora GitLab sub-group for the Council.

The short-term gain is for me to have a more open way to manage my ongoing tasks and issues related to all things FCAIC and the Fedora Community at a high-level view. I want to use GitLab Issues to track "community stories" and use more advanced project management features than Pagure provides. My goal is to improve forecasting and program management of community work in a way that aligns with the Fedora Linux release cycles.

The long-term gain for migrating the Council docs is two-fold:

1. It moves the Council and Project docs closer to the Fedora Documentation Team, who also use GitLab.
2. It gives us a chance to better separate and identify thematically-different docs. Currently, we bundle multiple Antora modules inside a single repo (i.e. council, engineering, mindshare, project). Plus, the way we are bundling the modules inside the current mono-repo is actually a mistaken Antora anti-pattern. :scream: (I could elaborate more but I think it is extra information for now.)

The move to GitLab also gives us a proper excuse to fix this and migrate in the same go.

Details

In this ticket, I am seeking approval to do the following:

1. Register gitlab.com/fedora/council/
2. Create a commarch (or Community Architecture) repository within that namespace

This is what I want to raise for discussion in this ticket and ask for a vote on since it could impact our existing workflows with Pagure as the Council.

In a future ticket, I would propose migrating the Council Docs repos to GitLab, but I want to use a low-committment way to first migrate our user interface and workflows from Pagure to GitLab (e.g. issues, labels, project boards, etc.) and get to know GitLab better. I also want my own meta-repo first so I can track the long arc of efforts like this without keeping it in the Council tracker as an ongoing ticket. :grinning:

Outcome

1. FCAIC has an open and quasi-independent way to manage ongoing tasks and engage with the Fedora Community.
2. The Council slowly experiments with a GitLab workflow, with a possible migration of our docs and discussion ticket tracker during the F37 or F38 release cycles.