We had the April Fedora Badges Round-table today, which was attended by the following people:
Sandro (penguinpee/gui1ty)
Michal Konecny (zlopez)
Akashdeep Dhar (t0xic0der)
Roland Taylor (rolandixor)
Aoife Moloney (amoloney)
Nikita Tripathi (nekonya3)
Ida Delphine (idadel)
Jhennifer
Chris Onoja Idoko
Roseline Amarachi
Erolkeskin
Megha Sharma
Ngobiri Falyne Chinaero
As well as myself, the chair for today’s call.
Announcements & News
We had one very exciting piece of news from @amoloney and @t0xic0der: the Community Platform Engineering team has planned in some time to work on refactoring the Badges back-end in the upcoming quarter!
Topics
Finalizing Charters, Gitlab Structure, & Epics
The folks at today’s roundtable finalized the Engineering and Design sub-team charters, which will be moved to the Badges Gitlab under the Wiki section. Next we reviewed and approved @t0xic0der’s proposed structure for the Gitlab, as well as @jflory7’s proposal to track our work using Gitlab Epics. Once the charters and documentation is in place on the Gitlab, we will start assigning and tracking the project work. If you are just hearing about the Engineering & Design charters, structures and Epics proposals, you are still welcome to comment on the Discussion threads, and we will consider any suggested changes.
Sharing knowledge on pushing badges
We checked in with @gui1ty on his quest to discover more information and instructions on creating rules for pushing badges. @gui1ty and @sayanchowdhury were able to meet once in the past month, and are planning to meet again in the coming month. The bits of information that are relevant to the back-end from our current Badges system to the revamped system will be documented.
Prep for the upcoming Badge Design internships
Our last topic covered preparation for the upcoming Fedora Badges Design internship through the Outreachy program (May 29th-Aug 25th). We are thrilled to share that we will be having two interns working on Fedora Badges Design! The team discussed how to approach padding in the updated Badges art template with respect to our New Front End (whatever that will be!). We agreed that padding should be addressed in the design of the front end, and not in the art template. Based on this, @smeragoel, @nekonya3, and myself, will work on finalizing the updated style guide, template, and palette files before the internship begins.
Until next time!
This has been the April Fedora Badges Roundtable summary. We encourage you to follow our progress under the #badges-team tag here on Discussion. All are welcome to join the efforts in the Badges channel on Element/Matrix and to join our monthly call. The next Round-table is on 2023-05-17T12:00:00Z→2023-05-17T13:00:00Z.
I made a start and moved the charters and the structure to the wiki. The wiki structure may evolve, but for now this should suffice.
I also took a look at the epics. It seems I don’t have sufficient permissions in the Website & Apps subgroup to move them over. @t0xic0der could you take a look? I might need temporary developer/manager permissions to be able to move the epics.
It turns out every wiki needs a home (just likes humans do). I adjusted the structure in order to have a wiki landing page. It’s a bit empty right now, but I’m sure it will get filled over time.
Gentle nudge @t0xic0der (or someone else, maybe?). It would be great if I could move the epics before our next get together on Wednesday.
Thanks. I received a notification regarding updated settings.
However, I just looked at the options and it appears GitLab currently is still not supporting moving epics to subgroups.
So, I re-created the parent epic in the badges subgroup by copying the content and meta data manually. That allows me to link the existing child epics to the new parent epic. But that keeps all the child epics anchored in the website & apps group.
It feels like that’s not what we want. Re-creating all child epics in the subgroup is a bit tedious, but not too much work. However, that way we will lose existing comments / issues tied to the current child epics.
Before I continue, I think it’s good to discuss on how we’d like to proceed from here. Maybe there’s some low level plumbing (pass the please) available that I haven’t discovered yet. For example, the wiki part is just a special git repository that one could edit locally and then push possibly to a different location. Not sure if epics have something similar. I’ll try to dig up some more information. But maybe someone else already knows…
I just noticed we started using the GitLab Wiki for Badges. Any thoughts on using our Fedora Badges docs site for this content? I find GitLab Wikis difficult to find information in and it is not always the first place I start looking for Fedora information.
Maybe I am wrong and we should keep the wiki, but then I think we should make a call on sunsetting the Fedora Docs site for Badges so there are fewer places to maintain accurate information.
Also, I am willing to take an action item to move the Badges docs site into GitLab from Pagure if that makes using the Fedora Docs site more compelling.
I just noticed we started using the GitLab Wiki for Badges. Any thoughts on using our Fedora Badges docs site for this content? I find GitLab Wikis difficult to find information in and it is not always the first place I start looking for Fedora information.
+1
While setting up the wiki it didn’t feel very natural. The case of the
landing page (uninspirationally called home) for example and the fact
that I cannot add a global TOC to that page.
But it’s also a matter of getting used, first steps, etc.
Maybe I am wrong and we should keep the wiki, but then I think we should make a call on sunsetting the Fedora Docs site for Badges so there are fewer places to maintain accurate information.
Also, I am willing to take an action item to move the Badges docs site into GitLab from Pagure if that makes using the Fedora Docs site more compelling.
I’m totally for maintaining information in one place. But I’m not sure
GitLab is the right place for that.
On the other hand GitLab’s wiki does support AsciiDoc format, which is
used for the current doc pages as well. I may just try a CopyPasta™ to
see how it looks.
May I suggest that we put this on the agenda (last minute rules ) for tomorrow’s meeting?
I planned on having the documentation related to the community process and interaction workflow on Fedora Docs and those related to the codebase itself could stay somewhere close to wherever the code is located i.e. GitLab Wiki. Understandably this would end up with us having two places to refer to when interacting with the Fedora Badges system but it does make sure that the ones who just want to use it are not overwhelmed with the information related to developing and maintaining the project and the ones who want to work on it are able to find just what they are looking for immediately.
While setting up the wiki it didn’t feel very natural. The case of the
landing page (uninspirationally called home) for example and the fact
that I cannot add a global TOC to that page.
You technically could. Surely it would be a manual process - rather than having something that automatically generates the table of contents based on the pages available throughout the wiki but it is possible to do that. I would not recommend doing though as it adds one more thing to change in case of an addition, removal, or renaming of a page. The sidebar present on the wiki should be capable enough to automatically change itself to reflect the modifications done - thus leaving us with one less thing to take care of while maintaining the documentation on project development and maintenance.
May I suggest that we put this on the agenda (last minute rules ) for tomorrow’s meeting?
+1 to this. I am curious to hear what others have to say regarding this. Albeit I am not too sure I would be able to make it to this community roundtable meeting but let’s see.
One consideration that if we use the Fedora Docs site, this will manifest as a GitLab repo with AsciiDoc source material. It can be rendered and edited from GitLab. See here as an example:
In that sense, the docs would still live close to the code. But we would benefit from the fancy, searchable interface that Fedora Docs has, as well as benefit by getting indexed by search engines too.
When I said I would commit to this work before, I meant setting up a repo for Badges similar to the Mindshare repo linked above. This would be more or less simple for me to do and I could work with the Docs team to make sure the source is built from GitLab and not Pagure.
As a member of the Docs team, from a systematic POV it’s quite a bad idea to use just another WIKI for user documentation. We decided once a while ago to gather all user documentation in Antora / assciidoc which gives us a unified appearance, the possibility of referencing all docs and facilitates discoverability for users. We moved most of the user documentation content from Fedora Wiki to Antora. And to start now another Wiki is really not good. And it’s almost a guarantee that users will have a hard time finding the documentation, if at all.
Doc content can be in the same repo as all other badge team items and can be on both pagure and gitlab. The Docs team is happy to assist with the launch.
My preference is to make the docs source into its own independent repository. Sometimes I think team docs can become buried and forgotten in repos primarily meant for other things.
I could be wrong here though, and happy to be proven otherwise.
+1 for keeping code and docs separated. That’s what we have now on
pagure. Docs is a subrepo of badges that can be checked out on its own.
One additional advantage: changing docs won’t change code and people can
work on docs independently.
Are we intending to move the current docs repo from Pagure to GitLab? Or
do we want to (re)build docs from scratch as well? The current docs are
already written in Antora / AsciiDoc.
please) available that I haven’t discovered yet. For example, the wiki part is just a special git repository that one could edit locally and then push possibly to a different location. Not sure if epics have something similar. I’ll try to dig up some more information. But maybe someone else already knows…
) for tomorrow’s meeting?