Meeting started at 2026-06-02 13:00:26 UTC

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

!hi

Petr Bokoc: Petr Bokoč (pbokoc)

!hi

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

!hi

!hi

!hi

Eli Ridge: Eli Ridge (egret)

shaunm: Shaun McCance (shaunm) - he / him / his

Brandon Nielsen: Brandon Nielsen (nielsenb)

!hi

Jonas Hubeny: Jonáš Hubený (jonashub) - he / him / his

Hello everyone, as usual I'll give it a couple minutes for people to show up

- https://forge.fedoraproject.org/docs/tickets/issues/43

- Announcements

- Open Floor

- https://forge.fedoraproject.org/docs/quick-docs/issues/910

- https://forge.fedoraproject.org/docs/tickets/issues/48

- https://forge.fedoraproject.org/docs/tickets/issues/19

- https://forge.fedoraproject.org/docs/tickets/issues/46

!hi

!hi

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

MatH: Mat H (theprogram)

Sorry I'm late!

Just finished another meeting

Hey Justin :)

Let's start with announcements, I have a couple

👋

And the second one is

If it turns out we're missing some that would be useful, it's easy to add them, either at the org level or on a per-repo basis

Woohoo, organization! 🗃️

jflory7 has already given cookies to pbokoc during the F44 timeframe

Oh, also. Currently some bigger repos (quick docs!) don't have labels applied to most issues. There's a ton of them and I didn't have time, I did do it for the others. But if someone was really bored and wanted to go through Quick Docs issues and label them properly, that would be awesome :)

Ah yeah, forgot that existed

Does anyone have any other announcements? If not then let's move on to issues

All right then

!hi

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

Sorry, being late

Hey there Peter Boy (ServerWG, Docs) 👋

So this popped up at me while I was doing issue housekeeping, it's an older report. Basically the system upgrade page in Quick Docs covers this weird upgrade path that isn't supported.

I wonder if the upgrade docs could have a better home

It is the #1 single page I always revisit

But maybe not the topic at-hand right now

The question is, do we really want to keep this? If it's unsupported, and there is a supported alternative, we might wanna just drop this part so people don't use it to shoot themselves in the foot.

+1 for less self-inflicted wounds

I think, the home is OK. But all 3 variants needs updates

No, don't keep it. The fact it mentions deltarpms tells me even if it was a upgrage path we want to support, this documentation is old.

Hehe right, yeah

Perhaps we shouldnt keep it

Alright, anyone in favor of keeping (and updating) this?

+1 to deprecate

We should keep this version, but specify under which condition is is usable.

It is specifically for some non-podman, but supported container techniques.

-1 to deprecate

Well, we already document an upgrade procedure using the commandline, one that actually works, so this is just an extra alternative that noone should actually use. I have no idea why this would be necessary.

If the support path is in an EOL version of Fedora, I don't think it serves us well to keep it IMHO

It gets us into the scenario where we get a mess of old docs, I think

Yeah.

In Fedora, we should focus on only documenting things which are not EOL. There is git history for anyone who really needs something from EOL days

Nothing about the documentation implies container to me, it even suggests I'll be in a graphical environment.

AFK for 2-3 minutes, BRB—

Also, I notice there are a couple of author names on top of the page. We should probably ask them why they wrote this in the first place, so we don't just Chesterton's Fence it. But I suspect it was written to solve some ancient problem that doesn't really exist anymore.

!hi

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

Brandon Nielsen: it needs an update, yes.

But the same is treu

File an issue, reach out to the authors, and put a 'archive' date if it is not actioned, within say two months

The same is true for the desktop related doc: https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-new-release/

Sure, but that's for an update method that's intended to be supported.

And we should not deprecate it, either. But update!

I like this as a compromise

Someone has to want to update it, though 🙂 And we have a lot of things to do. Sometimes, we might need to say no and know when to hold off on something.

I think Mat suggested a good compromise

Putting a clear announcement at the top of the page that is outdated and needs a maintainer is the call-to-action

+1 to Mat's suggestion

If someone wants to own it, this gives them clear pathway to do that

The archive proposal is a no-go! It we proceed that way with all aritcles, there will be max a 1/3 left.!

Yeah. I mean, looks like we're not going to solve this today, and we've already spent plenty of time on this, so let's move on and take it to issue comments :)

But if nobody steps up, then we know that we don't have the people-power to keep it updated

I think we put Mat's idea as `!idea` and then move on?

That middle-ground is probably worth noting

Next up

Eli opened this earlier

Do we even have any repo-level boards anymore? I can't think of any.

The main one is the Tickets one

Right, yeah, there are a couple in tickets actually

i'm in favor of them being consolidatd to a single plce

+1 to unifying to one place

And we have the meeting planner on org level, which is okay, it should cover all repos

This is why I had originally turned _off_ repo-level projects, but then we hit that bug where turning them off for the repo also prevents you from adding org-level projects

Oh, right.

Okay yeah, I'm also for keeping it at the org level. Is anyone against?

I'd turn off repo-level projects if I could, but if we want to agree to avoid using repo-level project boards as a team policy/rule, that makes sense to me

So possibly we leave it turned on but try to just use the org level as a place to put the projects out of habit

+1 with some sort of documentation about not making repo-level projects unless _absolutely necessary_

Writing it down somewhere will help us remember later that we agreed to something like this

The problem is, in the projects you refer to tickets.

And as far as I know, you can't refer to tickets in another repo

I figured the projectss and issues are for different things, so leave them as is and only use projects rarely, for really big projects

Peter Boy (ServerWG, Docs): How do you mean? If we use organization-level project boards, you can use them in every repo in the entire organization. The two links above show that we have two project boards at the org-level and four at the repo-level.

Yeah, but keeping projects at org level means you can refer to issues in any repo within the `docs` organization. You can refer to issues from only one repo, that's fine, but you have the ability to use others as well. It's more flexible and I don't see a downside.

Do we know who made the existing projects in the repo scope?

Yeah, that's basically what we're doing already anyway

The way forward is probably asking the owner(s) of the repo-level projects to either close the repo-level projects or migrate them to the org-level

Petr Bokoc: I didn't know that. In this case, we should use the org lef

Petr Bokoc: I didn't know that. In this case, we should use the org level for all or most projects.

I smell consensus? 🙂

I believe Peter Boy (ServerWG, Docs) originally opened the 4 projects in `tickets`. But they have only a couple issues each so moving them up to the org will be easy

All right then!

I can move the contributor docs one, if forge will let me

2. Document somewhere (_where?_) that we use org-level projects as a Docs Team convention

Potentially new `!halp` or `!action`, if someone wants to raise their hand?

1. Reach out to existing repo-level project board owners and ask them to close projects or migrate to org-level.

okay can do them all then

In thw meantime I have a lot more on my planning paper. But I have to enter them anyway

jflory7 has already given cookies to egret during the F44 timeframe

theprogram has already given cookies to egret during the F44 timeframe

Peter Boy (ServerWG, Docs) I'll try to migrate the 4 boards as soon as possible. (Probably tomorrow because I'm in meetings literally all afternoon.) But I'll let you know when I'm done so you can attach issues to the new boards

Oh, or actually Eli Ridge says he'll move them, nvm :D

Im keen to give it a go

Okay

Petr Bokoc: I think we have an `!action` for Eli Ridge 😎

@action Eli Ridge to migrate the 4 boards from tickets to the docs org

Grrrrr

Thanks Eli!

And let's move on!

Any updates Hristo Marinov?

I think the issue is not with the script itself, but the container image it pills.

So latest is outdated?

In short term I can ope a PR to update the base container image.

In short term I can open a PR to update the base container image.

Just as a reminder: Part of our program is to improve the preview container.

Then I would suggest to create a separate repo for the script and the conatiner.

Then I would suggest to create a separate repo for the script and the continer.

We want to support aarch64 and integrate the httpd into the contaioner and do a on-demand rebuild

+1

All that should be possible. We can even build the image in Fedora Forge and push it to `quay.io`.

I have a question related to this.

Go on

No specific preference for quay.io, but I guess due to lagging export control policies, some users in some countries cannot access container images in quay.io. Maybe this has changed but just something to think about, since Forgejo does have container registries as a feature

There is a org in the staging instance of Fedora Forge named `docs`. I can not currently provide the link as the stg instnce is down.

The question is who owns this org? It is currently empty.

Not sure for the staging site

We can experiment in this org as we already doing it for other orgs.

Yeah, I have no idea. Maybe it was automatically created? But then I'd expect it to have the same ownership.

Anyway that's something either infra or the forge team would know

I can reach to the Fedora Forge team and ask for assistance if the docs team is OK with this.

Yeah :)

+1

Absolutely. Also please drop a comment in the original issue so we don't have to remember this

I might

What is the link?

to the docs org on staging?

OK, let's continue the conversation in the ticket.

Justin Wheeler Probably https://forge.stg.fedoraproject.org/docs

Cool

"Application is not available"

Hmmm

Awesome. Alright, moving on

Yeah, it's down from an 20 min. or so.

So this popped up last week, there's already some consensus on enforcing forking. Please check out the issue and drop your 2 cents if you have an opinion, some already did, plus IIRC Eli Ridge also said something similar in chat earlier

I missed that one. my immediate response is that we need to be as accessible and available to newcomers as possible

I'm not sure about this. I would like to keep it as simple as possible.

I am a porponent of forking and merging from forks unless the change is someting small (type, spelling, etc). I feel that main should be a protected branch. (but that's me)

Well, a newcomer will have to fork anyway, there really isn't a way around that

Did we say we can direct push still if its a super small typo?

Sorry, reading the issue, I agree to enforce opening forks to work on

It is the method, I as a beginner, have always used on Pagure and with Fedora

Th QD teams mostly commits and pushes directly to the repo - for years. We should not change this!

Oh history! While it is my understanding that forking first is best practice, we should not interrupt others practices.

I don't really mind if someone direct-pushes when it's some tiny bug fix. (Or in this case, there was actually a PR, but it was created directly from the repo, not from a fork)

Is there a concrete issue that we are attempting to solve?

One point is: several articles have dedicated "owners". The maintain the specific article for years.

We should not make this more complecated.

Always with simplicity, going foward with docs. People over technology.

I'd say we allow team members the possibility to contribute directly, but let's call it "not encouraged"

There isn't really an issue, not yet. It's just Michael Winters did it and someone noticed and it was odd. It might become an issue in the future.

jflory7 has already given cookies to theprogram during the F44 timeframe

I'd prefer if people weren't dropping entire articles just straight to main

I don't think forking a repo adds any complexity to the developer's workflow.

Thats because you are a super developer!

It's literally just one click and one `git remote add` :)

I'm not a devolper, and I fork

me too

Thanks, but I'm not. 🙂

theprogram gave a cookie to hricky. They now have 20 cookies, 2 of which were obtained in the Fedora 44 release cycle

MAYbe. But it adds 2-3 more steps.

Okay, we're running out of time and we still have one more agenda topic, so let's take it to the issue comments

Heck, I have it _scripted_... (does that make me a script kid? :P)

I think, a fork is demanded for completely new artricles.

But every kind of maintenance should be more flexible

We must really take care here! There a some developers / maintainers, who explicitely don't want engage in AsciiDOC / Antora,but keep updating their docs in the wiki.

Another one that is progressing but I'd like to bring it to everyone's attention. Christian Strauf has been doing heroic work of "gardening" the wiki, and by gardening I mean flamethrowering. There are still a bunch of pages remaining and we want to get rid of all of them. Everyone on the team should be able to edit the wiki, which means you can wipe a page and set up a redirect, as described in the issue - just delete the entire page text and replace it with that template.

looks like Christian has already deleted them with Kevin

Peter Boy (ServerWG, Docs) This is specifically about the "Docs Project" category on the wiki, those are just old docs-related articles. We don't want to delete anyone else's stuff, obviously.

Last comment All pages in the category "Docs Project" have either been deleted or added the following redirected"

Another well known issue is the ARM doc

MatH There's still a bunch left in subcategories.

Ready to watch them 🔥🔥🔥

I don't know about any categosidation. I just had a discussion about moving to Antora with several developers (and the ARM sig)

After I had deprecated their wiki articles

Anyway, I poke at it occasionally as well, the good thing about this sort of task is that you can just do a couple at a time while you're maybe waiting for your coffee to brew :)

Christian Strauf++ for leading this invisible work of redirecting the abandoned Docs Team wiki pages to the Fedora Docs Team docs page

jflory7 has already given cookies to cstrauf during the F44 timeframe

Peter Boy (ServerWG, Docs) It's this category: https://fedoraproject.org/wiki/Category:Docs_Project

Noone needs an "Editing DocBook with vi" page

I have to check these.

It is specifically for Server admins 🤪

Petr Bokoc++ thanks for chairing today!

jflory7 has already given cookies to pbokoc during the F44 timeframe

Yeah we're outta time, so let's end here and I'll see you back in #docs:fedoraproject.org. Thank you everyone!