Picking a place to organize and implement Fedora Badges

Project Discussion
, ,
1

The discussions around finding a place to organize and implement the Fedora Badges system have been going on for a while now, both during the Fedora Badges Community Roundtable meeting call[1] and on Discussion threads[2][3][4] - Long enough for it to amount for a separate discussion thread to have conversations around it.

Cutting to the chase

So here is how this goes. I would go on to propose a structure for our projects[5] down below with some makeshift diagrams and folks can feel free to suggest additions and improvements to it.

gitlab.com [ROOT] <Index G>
|__ fedora [GROUP] <Index F>
    |__ websites-apps [SUBGROUP] <Index W>
        |__ badges [SUBGROUP] <Index B>
		|   |__ liberation [REPOSITORY] <Index L>
		|	|__ collection [REPOSITORY] <Index C>
		|	|__ messages-consumer [REPOSITORY] <Index M>
		|   |__ accolades-api [REPOSITORY] <Index A>
		|	|__ accolades-cli [REPOSITORY] <Index S>
		|__ documentation [REPOSITORY] <Index D>

Units involved

The following units will be involved and are proposed to be structured and utilized in the ways mentioned below.

Groups and subgroups

websites-apps

Existing namespace location → https://gitlab.com/fedora/websites-apps/

  • A subgroup under the fedora group
  • Has been used to manage team-wide goals and objectives
  • Houses a bunch of asset repositories and subgroups
  • Can create team-wide epics under the subgroup

badges

Proposed namespace location → https://gitlab.com/fedora/websites-apps/badges

  • A subgroup under the websites-apps subgroup
  • Can be used to manage initiative-wide goals and objectives using epics
  • Can house a bunch of asset repositories
  • Housing more subgroups under this would lead to complications

Shared units

documentation

Existing namespace location → https://gitlab.com/fedora/websites-apps/documentation

  • An asset repository under the websites-apps subgroup
  • Can be used to manage team-wide documentation-related issue tickets, pull requests and goals
  • Was moved here recently from the Pagure repository[6]
  • Houses the documentation for the team and the projects[7] that fall under its remit

Internal entities

liberation

Proposed namespace location → https://gitlab.com/fedora/websites-apps/badges/liberation

  • An asset repository under the badges subgroup
  • Can be used to manage repository-wide issue tickets, pull requests and goals
  • Can house the assets for the web interface
  • Issue tickets can be linked to epics belonging to parent subgroups/groups

collection

Proposed namespace location → https://gitlab.com/fedora/websites-apps/badges/collection

  • An asset repository under the badges subgroup
  • Can be used to manage repository-wide issue tickets, pull requests and goals
  • Can house the assets for the artworks and rules
  • Issue tickets can be linked to epics belonging to parent subgroups/groups

messages-consumer

Proposed namespace location → https://gitlab.com/fedora/websites-apps/badges/messages-consumer

  • An asset repository under the badges subgroup
  • Can be used to manage repository-wide issue tickets, pull requests and goals
  • Can house the assets for the conditions listener
  • Issue tickets can be linked to epics belonging to parent subgroups/groups

accolades-api

Proposed namespace location → https://gitlab.com/fedora/websites-apps/badges/accolades-api

  • An asset repository under the badges subgroup
  • Can be used to manage repository-wide issue tickets, pull requests and goals
  • Can house the assets for the backend service
  • Issue tickets can be linked to epics belonging to parent subgroups/groups

accolades-cli

Proposed namespace location → https://gitlab.com/fedora/websites-apps/badges/accolades-cli

  • An asset repository under the badges subgroup
  • Can be used to manage repository-wide issue tickets, pull requests and goals
  • Can house the assets for the client application and/or library
  • Issue tickets can be linked to epics belonging to parent subgroups/groups

Taking away the takeaway

  1. Kanban boards and Gantt charts for managing the entire initiative can be housed under the badges subgroup (i.e. Index B in the makeshift diagram).
  2. The aforementioned boards and charts can represent epics that pertain to the overall initiative and hence can be stored in the badges subgroup.
  3. The checkpoints mentioned in the exhaustive ARC investigation roadmap[8] can be prime candidates for being epics housed in the badges subgroup.
  4. We want to ensure that all the documentation for the projects that the Fedora Websites and Apps Team builds and maintains is housed in one repository[9] only.
  5. The said documentation repository is proposed to house, both the legacy[10] as well as the renewed documentation for the Fedora Badges system.
  6. Assets belonging to the internal entities, and the related issue tickets and pull requests are stored in the asset repositories under the badges subgroup.
  7. These issue tickets can be linked with the epics belonging to the parent subgroups/groups to have a granular measurement of roadmap progress.
  8. Documentation specific to maintaining the asset repositories can be housed within their internal Wiki while general docs can be in the shared repository.

That’s about it from my end.

Thoughts? Opinions?

  1. ↩︎

  2. ↩︎

  3. ↩︎

  4. ↩︎

  5. Please note that I am using the word “project” very loosely here, so this can include asset repositories, subgroups, planning boards and everything else in between. Rest assured, I explain what I mean when I mention the term “projects” whenever I use it here, on a case-by-case basis. ↩︎

  6. https://pagure.io/fedora-websites ↩︎

  7. Simply put, the websites and applications that we build and maintain ↩︎

  8. https://fedora-arc.readthedocs.io/en/latest/badges/index.html#proposed-roadmap ↩︎

  9. ↩︎

  10. https://pagure.io/fedora-badges/docs/ ↩︎

2 Likes
2

This is the part we should get started on next, so we can convert the ARC investigation next steps into trackable, modular user stories.

3

@t0xic0der I am +1 to moving badges to Gitlab and grouping this under Websites & Apps- it makes sense!

I have hopes that we wouldn’t need to manually move all the issues over to Gitlab, but if we do, I can pitch in.

A couple small notes:

  • @smeragoel and I will be triaging the current queue in the next couple days for the upcoming Outreachy application period (March 6th - April 3). Hopefully we can get some stale tickets closed out and trim the queue down a bit.
  • Not sure how quickly we are trying to move on this, but just in case someone is feeling motivated, I would like to request that any tickets involving artwork move after April 3rd to avoid confusion for applicants. Bug issues can go whenever from the design perspective :slight_smile:
4

I guess it depends whether the Pagure2GitLab tool is able to be scoped sometime this year. It is a question-mark and will come down to the capacity and resources that red-hat-cpe has for this. We are already asking a lot for Badges in general, so it isn’t clear.

https://pagure.io/cpe/initiatives-proposal/issue/25

At some point though, we will need to make a cut-over from Pagure to GitLab.

I don’t think it is urgent and we could probably even wait until after the Outreachy internship to do this? It would be worthwhile to first set up the new GitLab repo, configure the templates, get it working the way we like, and then update documentation and make the switch (assuming it is a manual process).

If we have the automatic tooling in place, it is probably less of an issue because the human burden is less.

5

I’m actually thinking: “Do we have to?”

Pagure Badges is entirely tied to the current implementation of badges. Why not keep it that way and start fresh in GitLab with the new implementation of Badges? Once the new Badges is going live, we will track issues in Git Lab and close down the Pagure issue tracker. That way current work like the internship can continue in Pagure and references in YAML files will stay intact [1].

Issues that need to be carried over can be hand-picked and references made in GitLab and Pagure. This will also allow us to scrutinize the issues before carrying them over. Whereas importing everything into GitLab will import a lot of issues that no longer apply or have been abandoned all together.

  1. Some of them still contain refrences to very old GitHub issues from before that was moved to Pagure. ↩︎

6

@gui1ty Realistically, I think we could hold off on doing this until more of the new system is in place, and we actually need to make changes to the workflow for getting the new system plumbed. This would be in some time, and for as long as the old system is in place, we can continue using Pagure.

To change directions though and move back to the top-post here… I posted a new topic earlier with an update about using GitLab as one of our tools in the planning and project management side of things. More details are over in this thread, and I encourage asking questions over there too. I’m also planning to highlight this in the roundtable next week: