Howdy folks! This afternoon, I started playing around with GitLab epics as a way to track some of the high-level work we are preparing for with Fedora Badges. While a lot of our work today exists on GitHub, Pagure, and GitLab, hopefully in the long-term, we will gradually shift over to GitLab so we can keep track of things in one place. That will also make these epics more useful, because then we can group development work around the epics.
Take a look at the parent epic for Fedora Badges 2.0 below:
The parent epic and each of the child epics can have a description and anyone with a GitLab account can also comment on the child epics. I think this will be a good way to have more detailed discussion about each of the proposed steps in the ARC investigation roadmap. We can start collecting feedback and identify whether there might be any gaps in the proposed next steps.
Again, this is just an early look, but in next week’s roundtable, we can also take a look at this together and go over any questions. Of course, if you have time to look over it now and ask questions, you can add them here too!
Hi all, I added this topic to websites-and-apps-team due to a topic that came up in the monthly Badges roundtable today. (A summary from @amoloney coming soon.)
So, we are currently putting these epics into the W&A Team sub-group. @t0xic0der created a new Fedora Badges sub-group in the W&A Team sub-group.[1] We were trying to figure out whether it made sense to keep the epics in the W&A Team sub-group or move them to the Fedora Badges sub-group.
Pro: Keeping the epics in the W&A Team sub-group makes them visible across all W&A repos, and any issue remotely related to Fedora Badges could be grouped into an epic, regardless of whether it “fits” into Fedora Badges sub-group or not. Documentation and outreach on the main Fedora website were given as examples.
Con: There are a lot of epics, and it might clutter the existing W&A Team workflow when using other epics for specific projects. Currently there are ~16-17 epics for Fedora Badges.
Any thoughts on this?
Yes, a sub-group inside of a sub-group. So meta! ↩︎
I just returned to the desk this morning so I thought I would elaborate on why I thought having the epics pertaining to Fedora Badges 2.0 within the scope of the Fedora Badges subgroup[1] would be the right thing to do.
Having the epics available in a limited scope would help better group tasks and the elements involved in those within the said subgroup. This would happen to be the case for most of the repositories, eg. tasks/issue tickets pertaining to the Accolades API[2][3] would be associated with the epics available one step above the hierarchy and not with the ones available universally.
Associating tasks/issue tickets that do not belong to the said subgroup with the epics scoped there, is possible, albeit admittedly not as polished an implementation as you would expect. This would happen to be the case for only one or two repositories max. eg. tasks/issue tickets pertaining to the Documentation[4][5] would be associated with the epics available on the same hierarchy.
The Websites and Apps Team maintains a lot of websites and applications (duh) so having epics on the very root level of the subgroup would cause unintended clutter and can possibly scare away or intimidate newcomers by making it look like there is an awful lot to do with no clue where to start from. We would really like to ensure that this does not happen to be the case.
Just trying to pick the least bad option here, you see.
A repository that is available in the Websites and Apps Team group namespace and is in the equal hierarchy as that of the Fedora Badges subgroup namespace ↩︎