Structuring the Fedora Badges sub-teams

Howdy folks! Our first community roundtable for Fedora Badges was earlier today, and we covered a lot of ground in our one hour. One thing we did not cover were the sub-teams, initially discussed in a previous topic.

So, let’s use this topic and expand these sub-teams out as semi-independent groups within the Fedora Badges project. I’ll start with questions for everyone to consider (and answer here!), as well as my own thoughts about the sub-teams.

As a reminder, we previously discussed two sub-teams, Design and Development. Each sub-team would be stewarded by two co-captains (acting in Project Manager roles).

My questions

  1. What are short-term and long-term goals for each sub-team?
  2. What are good topics for introductory meetings in each sub-team?
  3. How often does each sub-team need to meet in order to be on track?

Context

Here is a quick recap of how I currently understand sub-teams based on our last discussion…

The Design sub-team organizes and leads the design programs around Fedora Badges. This includes artwork design, managing templates and brand kits for new Badges, and possibly a UI/UX component for Fedora Badges 2.0. Currently, @ekidney and @riecatnor volunteered to co-captain this sub-team and organize efforts.

The Development sub-team organizes the rewrite outlined in the conclusion of the ARC investigation. This includes software development, system architecture, engineering, integration, and possibly system administration work on Badges. This sub-team will target a rewritten, modern platform for Fedora Badges with an aim for long-term maintenance. Currently, @t0xic0der and @jefferson2z volunteered to co-captain this sub-team.

What I’d like

More and earlier planning is required to successfully execute a new project from start to finish, as compared to feature development on an already-established project with a release cadence. So, each sub-team needs a set of clear, measurable goals[1] and to come up with ways to know whether the sub-team is on track or not.

For the Design sub-team, I feel like badge artwork creation has a good workflow. I want a metric to know how many Fedora Badges receive an approved final design each month. At first, we could manually track the new badges created every month in order to demonstrate steady activity of badge design, while also calling out community attention to new badge-earning opportunities. Later on, this could become automated with support from the Development sub-team. The UI/UX work is not as defined to me, so it would be good for members of the Design sub-team to determine whether UI/UX is an area they want to own or to defer to another Fedora team (e.g. Websites & Apps, or Design).

For the Development sub-team, I think a Gantt chart would be a useful first deliverable for the team. Given what we know so far about the proposed stack, what would be key milestones to reach project completion and how much time should each key milestone take? Something like a Gantt chart as a blueprint makes mapping new development easier. Work can be divided with clear requirements for each milestone’s success. Even if the blueprint is not perfect and needs to be adapted over time, coming in first with a plan for how we will deliver a rewritten platform keeps us moving toward a clear finish line.

This is my early thinking on sub-teams. What do y’all think? Is anything here surprising or that you feel is missing? Or does this make sense?

My hope is that by the end of this topic, each sub-team and the co-captains feel prepared and ready to take on the first steps for Fedora Badges 2.0.


  1. I like S.M.A.R.T. criteria goals: Specific, Measurable, Achieveable, Relevant, Time-bound. These goals work well for a team focused on delivering for a single project. ↩︎

2 Likes

Maybe we could start a Gantt chart on a shared Google Sheets, so that we can iterate/discuss the milestones/timelines and later transition to another tool for it? Or would there be a better tool for the job? (There’s LibreOffice Calc, but I’m thinking about the sharing part of it)

1 Like

@jefferson2z That is a great question. I don’t know of a FOSS-y tool for Gantt charts that also provides simple collaboration. I don’t mind using Google Sheets and I can participate with that, but I know some folks expressed previously that they don’t have a Google account and don’t intend to make one. That said, we might be able to have a completely open document where even anonymous users can make edits.

What about gitlab? They have great tools for that.

@bogomil I’m open to using GitLab for something like this. I am familiar with Gantt charts but I have explored zero of how GitLab could be used for that. I would like to learn!

That would also tie into my motivation to unify the messy world of Fedora Badges across GitHub, GitLab, and Pagure into one single git forge, i.e. GitLab ideally. @t0xic0der has a pending action to kick off a discussion thread about unifying our git forges; keep an eye out for that one soon.

1 Like

Gitlab would be ideal. Do we have the premium version of it as a FOSS project?

We definitely have a paid tier but I’m not sure exactly which one it is.

I can show you but in a nutshell, there it is: Project Management with GitLab | Status Hero

If we go this way, I can help set some projects up for success, based on their needs. (in terms of setting goals and tracking their completion of course)

1 Like

fedora · GitLab is “ultimate tier”.

S.M.A.R.T. criteria, definitely, happens to be, in my honest opinion, the most standardized way of deciding the checkpoints we would want to decide for ourselves. These checkpoints can be further broken down into bite-sized tasks which can be put on the Gantt chart using the shades of colours inherited from the colour used to represent the checkpoint they fall under. Folks would want to circle back to the roadmap[1] to get an idea about the expected work as I want to ensure that we have a complete (read, maximum) picture of the involved tasks, before settling for a tool/workflow to manage them.

Because we are working on a system (i.e. a collection of projects and not just one project), there will be a lot of disjointed work from teams of different disciplines that would depend on those of some other teams’. Say, for instance, the frontend side of development would have to wait on the completion of the mockups from the design side[2] which would run parallel to the development of the messages consumer and Accolades API[3]. Let us be really sure that the tooling we use to manage these tasks, accounts for their concurrency and dependencies, natively and with as less effort as possible.


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

  2. https://fedora-arc.readthedocs.io/en/latest/badges/index.html#:~:text=Step%205%20-%20Connect%20with%20the%20Fedora%20Design%20team%20to%20begin%20with%20the%20mockup%20designs ↩︎

  3. https://fedora-arc.readthedocs.io/en/latest/badges/index.html#:~:text=Step%206%20-%20Develop%20and%20document%20the%20Messages%20Consumer%20alongside%20Accolades%20API ↩︎

Epics and roadmaps seem to be the way to go! This looks very sleek. My feeling now is that we should lean into that, but we first need to sort out where the git “home” of Fedora Badges will be.

My feeling is that each of the steps in the roadmap could be an epic, and then have multiple issues that fit underneath each epic. Then we could start to visualize these over a span of time, e.g. 10-12 months.

1 Like

Yes, sir. Git Lab allows the inclusion of issues from different “teams” under an epic owned by another team, so this perfectly fits the use case. I am now managing a backlog of x-team dependencies with more than ten teams, so I know what you are talking about,

1 Like

@jflory7 thanks for kicking off the thread! I hope to connect with @ekidney next week about the Badge Design side of things and one or both of us will provide feedback here.

1 Like

I didn’t expect any less. :stuck_out_tongue_winking_eye:

It has been suggested earlier to move the Badges Pagure Git repo to GitLab. Seeing the benefits [1] I’m backing the move to GitLab. The hard part will be moving all issues from Pagure to GitLab. We need these, since they are being referenced in the badges.

The rebuild may also give opportunities in that respect. Since we are planning to rewrite everything, the GitHub projects can stay in place. Once Badges has been migrated, they can be retired. But they do not need to move to GitLab.


  1. I briefly looked into the board feature of Pagure. But it seems it’s lacking a few features and doesn’t and feels not quite intuitive when using it. ↩︎

1 Like

Eventually, at some point down the line, there might be an automatic tool that helps us manually migrate Pagure repositories over to GitLab. The Red Hat CPE team is investigating this as a possibility, but there are no concrete details yet. Hopefully @zlopez or @t0xic0der can share more about this when the time is right.

That said, I don’t think we should wait for this tool to be developed before moving. We can kickstart a new repository over on GitLab and manually move over the important tickets as we get to them.

When the time is right, we can also archive the GitHub repositories and update the READMEs to point to the right place. Archiving the repositories will set them to read-only and disable new issues and comments being posted to the issue tracker.

Hey folks! @ekidney and I had a chance to connect today about the structure of the Badge Design sub-team. I will do my best to summarize our thoughts here and we welcome feedback and follow up questions. @ekidney please do chime in if desired :raised_hands:

  • Our first thought is that @ekidney would be responsible for leading the UI/UX design work and I would be responsible for leading the badge design work. We saw there is a new discussion thread from @t0xic0der about Discourse being the front-end for badges (where I commented, and linked at the bottom of this post) which would likely make a significant difference in the design efforts that need to be made. If we were to use Discourse as our badges front-end then @kidney and I would both focus mostly on badge design work.

  • @smeragoel and I are discussing co-mentoring a Fedora Badge Design intern through Outreachy for the summer session. @ekidney is also interested in helping with the co-mentorship. This would provide a great opportunity to build on the great work @nekonya3 did this past summer- as well as have someone working on the badge designs full time for 12 weeks.

  • We plan to attend as many of the monthly Badge calls as possible providing input as we can. The UI/UX design would need to be built in tandem with a re-haul of the back/front ends- and I think @ekidney will have more to add if we go that way. The badge design work could start as soon as we have the specs for whatever we are using for the front-end (most importantly: padding and file sizing). There is some preparatory work that can be done before then, but we don’t want to redo work to then redo work. It would be great to understand the specs for the art before the intern starts so that they can work on updating the art (laid out in the next bullet point).

  • Once we understand the updated specs for the art we can get to work. This will be no small feat as there are now 600+ badges, and many need some updates, improvements, or complete redoes. Using Discourse as a front end would also change this process some, and add work in. I am also guessing we also need to use the exact file names as the old art so as to not break things? The steps in broad strokes will be:

  1. Generate new template files
  2. Move the art over badge by badge, improving and updating art as needed
  3. Generate new PNG & SVG files and push them to the repo

On the subject of Discourse as a Badges front-end, my comment can be found here:

1 Like