Meeting started at 2026-06-30 13:01:15 UTC

The Meeting name is 'Fedora Docs Team Meeting - 2026-06-30'

!hi

Peter Boy (ServerWG, Docs): Peter Boy (pboy)

!hi

Petr Bokoc: Petr Bokoč (pbokoc)

!hi

Hristo Marinov: Hristo Marinov (hricky) - he / him / his

!hi

Justin Wheeler: Justin Wheeler (jflory7) - he / him / his

~hi

er

!hi

Jocelyn Gould (UTC-4): Jocelyn Gould (korora) - she / her / hers

!hi

Eli Ridge: Eli Ridge (egret)

All right, I suppose that's all of us for today. Let's move on to announcements

Sorry I am a bit late !hi

✋️

Okay, announcement number one, I continue to melt

Other than that, I only have one announcement today I think - as you might have noticed in #docs, @pboy has been opening a ton of new issues largely related to project organization and to the Docs Initiative. Most of them are in Quick Docs. I encourage everyone to go check them out and share their thoughts in the comments. It's a lot of new stuff but don't be intimidated!

[EOF] for me 🙂

Yeah, and I will open some discussion on discussion, e.g. about improving Quality.

Oh yeah, and the agenda for anyone looking for it 🙂

Peter Boy (ServerWG, Docs) Don't forget that we don't have notifications for new discussion topics, so when you open a thread, link it in chat. A lot of people don't check the forums regularly so let's make sure it gets visibility

Anyone else have anything to announce?

All right, moving on!

So, we discussed this before Flock, it's about whether team members should be allowed to do 1) direct pushes and 2) opening PRs without forks.

I would prefer it if we didn’t have to impose any detours, which require additional clicks, maintenacne etc.

From fork should be the regular case.

This would be for all repos in our org, right? `docs/*`?

But maybe omitted

The majority consensus was that it shouldn't be completely banned, because there are circumstances when it's warranted (e.g. a quick fix to the configs in docs-fp-o or other repos if the site stops building), but we should strongly discourage everyone from doing it regularly

Yeah

I was thinking about this too, because I usually make feature branches on the main repo instead of forking, but as we grow/scale, I think it makes more sense to lean into forks. Also, if people use AI agents to do more stuff, and the AI agent goes off the rails… better to do it from a fork, not the shared upstream repo 😅

IMHO direct pushes should only allowed for the Docs org owners and no one else.

I think our config repos like `docs/docs-fp-o` would need tighter default branch protections

Versus, say `docs/quick-docs`

A good use of ‘fork’ is for more extensive changes that require more in-depth discussion.

Unfortunately there doesn't seem to be a way to do this on Forgejo's side. Like a big honking red button where you have to type "yes I really need to do this" and solve a differential equation before it allows you to push

I think this is true for non-content repos, IMHO. For content repos, I feel like there is room for us to trust people to do the right thing

The non-content repos are where things can go off the rails if changes are not validated

(and impact a lot of docs contributors/writers, not just an individual component or content repo)

OK, direct push for owners is ok. This is usually for urgent fixes to avoid confusion.

And absolutely no one else.

Justin Wheeler: I think it is the same for content repos. 'They can generate a lot or confusion or security risk.

Regular member should not be able to direct push to `main` branch without opening a PR first. A minimum one approval review should be also mandatory.

Maybe, although I think content owners are usually the right people to know the risks and issues. That said, I'm not blocking on anything here. And a common standard will likely help reduce doubts for everyone

During Flock, I had a brief discussion with Chris. Red Hat’s legal and/or security team has some issues with parts of our documentation. I’m still waiting for further details. But if necessary, this will need to be resolved quickly,

I'm differentiating "content owners" from "Docs Team org owners on Forgejo"

Do you mean [@py0xc3:fedora.im](https://matrix.to/#/@py0xc3:fedora.im)?

This feels like something we could put out for a team vote

I would be +1

Alright. After the meeting I'm gonna go dig in repo settings and look at what I can actually do in settings without making it too obtrusive. I think what Hristo is suggesting is reasonable. Justin Wheeler We should also be able to add individual people to individual repos with specific permissions, so we can set up any content owners with the same permissions that the docs-owners group has, that's not an issue

Justin Wheeler: I agree with 'content owners'. Someone who regularly maintan an article should be free to modifyi it as they wish.

Nice, yeah, I think adding people as collaborators with elevated rights is perhaps how we can "promote" content owners beyond the basic permissions given to all Docs Team members

I like that approach

I have set up some protections like this in other repos. I might have even done it for our tickets repo, I forget. I can dig up some examples if you need them

!hi

sorry I am late :)

Ro: Rowan Puttergill (goroboro) - he / him / his

Hi Ro

Anyways, I'm happy to punt this with an `!agreed` or `!info` and plug forward, if we feel we have consensus on a direction.

Hey there [@goroboro:matrix.org](https://matrix.to/#/@goroboro:matrix.org) 👋🏻

IMHO, that does not mean the it's work should not be reviewed at all.

IMHO, that does not mean that it's work should not be reviewed at all.

Hristo Marinov: agreed!!

My understanding was that direct push is basically only for typo errors

Sure, but usually content owners know the difference between small changes which can be pushed directly, and content which warrants bigger review. I think we should trust content owners to know the difference for when to do what

Wait hang on, the adding people to repos with elevated privileges thing isn't necessary anyway, since most repos aren't "ours" anyway :D

I tend toward the fork model as much as possible... I know that branching and merging are great when you have a very coherent team with a long shared history. But in this kind of environment it makes sense for PRs

I've only been reading this with the assumption we were speaking about `docs/*` repos

Right, yeah. But in those the "content owners" are us

But anyway

I default to fork, changes, push origin, pr to main

(me always does prs even in my own single-owner repos because it helps to do a self review before merging)

I would consider myself a content owner for the Docs Team team docs, but not Quick Docs, for instance

Proposal !agreed. Normally, and particularly in the case of changes that require lengthy discussion and refinement, a pull request should be submitted via a fork. Owners and content owners who maintain an article on an ongoing basis may also submit a pull request or push directly.

Time's ticking though, so let's move on

+1 to what both of you wrote!

+1

I'm +1 to both

I know! It's nearly half past three! :D

Let's push forward!

Go for the next topic, [@pbokoc:fedora.im](https://matrix.to/#/@pbokoc:fedora.im) 😄

Hristo Marinov, can you give us a quick rundown?

It seems like finding a way to build our Antora container image in a pipeline could take a long time. We briefly talked during Flock about improving the docsbuilder script.

Yup

Any progress on that? I remember you saying you could drop most of the dependencies :)

I have a draft of the Python script we talked about on Flock. I'll open a PR in a repo I mentioned above so we can track the progress and discuss it. I'll also comment in the issue with my thoughts on what should be done next.

I suppose, we need 2 docsbuilder scripts, one for local and one for the build process.

Awesome. Let's talk in the issue comments

I mean the repo in the stg instance in `playground` org.

[@hricky:fedora.im](https://matrix.to/#/@hricky:fedora.im) Any questions or guidance you need now from the team, at large?

Drop a `!link`?

Thanks!

[@hricky:fedora.im](https://matrix.to/#/@hricky:fedora.im) What is the biggest cause of complexity for the delay? Is it the container registry part of Forgejo, which we discussed in Brno?

Or is it something else?

This will be a huge change. When I push something we'll need testing.

While I think it would be _ideal_ to use Forgejo container registries, it might not be practical to use them yet. I'd rather use Quay then let perfection be enemy of progress

Even Fedora Forge team uses Konflux and `quai.io` for the container build and registry for the Forgejo Fedora fork.

This is also what the Atomic variants will use eventually. So I think we should start planing in that direction.

Hristo Marinov: If you write a proposal with a rationale, I'm happy to support whichever pathway you find to be the best choice!

It sounds like this ticket will need some more research and planning time before another meeting discussion

Should we remove it from the future meeting agendas, and you can triage it as `meeting topic` label when it is ready for follow-up, Hristo Marinov? Also, I wonder if we should set a target deadline for this work to be done

F45 Release Day?

(thinking of Release Notes as a particular heavy use of our infra – changing our infra right before Release Notes are published might not be that good)

In the short therm I think local building of the image is fine. We will document how to do it and how to use the script.

'

I will do that.

That covers the discussion I was thinking about for this ticket

Is there anything else to discuss, or should we look at the CI topic overall?

BTW it is the same with bootc and Hummingbird.

To #49?

Yeah let's at least quickly plug https://forge.fedoraproject.org/docs/tickets/issues/49 without turning it into a proper topic.

There's a big new comment from Brett in there that's very interesting, I suggest everyone interested in CI give it a look

I will also comment in the ticket after the meeting.

Just saw you pinged me. It was RH Product Security, not Legal. But it seems nothing time critical. We are in exchange with them, and they wanted to provide a list of Docs that contain security issues. They didn't come back to us yet about this topic. I update you once they send us the list :) Either they or we will then open a topic anyway, concerning how to tackle that, also in future, and if and how far the Security SIG can help. I already shared your thoughts with them ;)

Moving on!

Just saw you pinged me. It was RH Product Security, not Legal. But it seems nothing time critical. We are in exchange with them, and they wanted to provide a list of Docs that contain security issues. They didn't come back to us yet about this topic. I update you once they send us the list :) Either they or we will then open a topic anyway, concerning how to tackle that, also in future, and if and how far the Security SIG can help. I already shared Peter's thoughts with them ;)

This is gonna be Justin Wheeler's topic :)

Ack! I haven't had a chance to read the comment yet either. Looks interesting!

Just saw you pinged me. It was RH Product Security, not Legal. But it seems nothing time critical. We are in exchange with them, and they wanted to provide a list of Docs that contain security issues. They didn't come back to us yet about this topic. I update Peter once they send us the list :) Either they or we will then open a topic anyway, concerning how to tackle that, also in future, and if and how far the Security SIG can help. I already shared Peter's thoughts with them ;)

OK, so!

(Also, thanks for clarifying!)

So, for #50, the ask to the team is whether anyone else wants to join in on this pilot program.

The idea is that we have multiple people who are engaged in the Fedora Docs Team, and also have a leading role in a SIG, WG, or other team in Fedora as a docs lead for that team.

Part of what needs to be done first is creating a concept for the role and how to measure the value of such a role

Do we increase membership in the Docs Team as a target? Do we have better documentation about who owns what components in the Fedora Docs?

There are lots of ways to answer these questions

What we have informally discussed online and at Flock is for folks like jforbes to help with Fedora kernel and booting content (which currently has a well-organized section in Quick Docs), @rathann (sp?) to help with multimedia-related docs (which are in Quick Docs, but quite scattered), and then me for AI/ML SIG.

I believe jforbes and rathann got to chat with either Petr Bokoc or Peter Boy (ServerWG, Docs) at Flock about this.

Is anyone else interested in taking such a role?

Or is there someone who feels like they are already doing that role for another WG/SIG? 😄

One aim of this pilot is to ensure that QD remains up to date, not so much by chance but by introducing a structure that is at least somewhat more reliable,

+1. More subject-matter experts are encouraging to take ownership of docs which make sense for them to do so. All three of the initial targets (kernel/booting, multimedia, AI/ML) have sections in Quick Docs with varying levels of maintenance. Some good, some not so good

These three targets would likely make an exit from Quick Docs to a new docs site/Antora component

Maybe something relate to containerization, although Podman has excellent docs.

I might have written too much text, maybe folks need time to process 😛 This is all I have for now, and unless someone has questions or wants to join up as a volunteer for this, we can probably shift to open floor.

I might consider something like this in the future, but I need to gain a bit more experience here and also work out what my commitment is going to look like at some stage.

Or we move Quick Docs as a whole to something like FedDocs or GenDocs

Hristo Marinov: Podman upstream, or Podman in Fedora Docs?

I definitely think better documentation about ownership and points of contact would help a lot

Ro: That's fair! We also need more folks spending time on the core Docs Team work too, so here is a perfectly fine place to hang out and remain 😄

Podman upstream.

Hristo Marinov: Good to know!

Petr Bokoc: I will yield back to you, if there are no other questions or volunteers. Yet 😄

Our documentation should focus on Fedora-specific procedures and provide valuable, informative and precise documentation for the upstream community.

Of course, anyone that wants to chat more about the docs captain role can find me in #docs:fedoraproject.org

Yeah that's been a long-term pain point. We eventually want to force every repo to have ownership and contact info in the index + the readme

Our documentation should focus on Fedora-specific procedures and provide valuable, informative and precise linksfor the upstream community.

I'll be owning this ticket and helping drive the pilot for #50 from the AI/ML SIG side

Our documentation should focus on Fedora-specific procedures and provide valuable, informative and precise links to the upstream doc.

#HelpWanted for someone to help liaise between Docs Team and Kernel/Booting + Multimedia, though!

2 minutes left btw

Petr Bokoc: Sending the hot potato back to you 🙂

I can help with the leasing if I can get some contacts

I can help with the liasing if I can get some contacts

RobinSheps: Nice, that would be awesome! Would you mind dropping a comment on Ticket #50? That will help me remember to follow up with you in more detail soon. We have them in mind, but need to organize some stuff on the Docs Team side for what this pilot will look like

So that way, we guide people into a process with a plan, instead figuring it all out as we go 🙂

I guess this is the end of the hour for us, though.

Alright everyone, our time is up so thank you all for coming and let's take further discussion back to the pirate lai... I mean #docs:fedoraproject.org!

See ya!