#fedora-meeting-1 log

19:31:51 <darknao> #startmeeting docs
19:31:51 <zodbot> Meeting started Wed Jan  4 19:31:51 2023 UTC.
19:31:51 <zodbot> This meeting is logged and archived in a public location.
19:31:51 <zodbot> The chair is darknao. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
19:31:51 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:31:51 <zodbot> The meeting name has been set to 'docs'
19:31:59 <darknao> #topic Roll call
19:32:01 <darknao> #chair pboy darknao pbokoc py0xc3[m]
19:32:01 <zodbot> Current chairs: darknao pbokoc pboy py0xc3[m]
19:32:08 <pboy> .hi
19:32:09 <zodbot> pboy: pboy 'Peter Boy' <pboy@uni-bremen.de>
19:32:16 <py0xc3[m]> .hello py0xc3
19:32:17 <zodbot> py0xc3[m]: py0xc3 'Christopher Klooz' <py0xc3@my.mail.de>
19:32:22 <py0xc3[m]> but only as guest :)
19:32:27 <AnthonyMcGlone[m> Hi
19:32:47 <hankuoffroad[m]> .hello hankuoffroad
19:32:50 <zodbot> hankuoffroad[m]: hankuoffroad 'None' <allegrovelo@gmail.com>
19:33:26 <pboy> Wonderful, full house today.
19:33:44 <pboy> haooy new year to all
19:34:20 <darknao> \o/
19:34:28 <darknao> alright, let's start then
19:34:33 <py0xc3[m]> happy new year too!
19:34:38 <darknao> #topic Agenda
19:34:44 <darknao> #link https://discussion.fedoraproject.org/t/docs-meeting-agenda-2023-01-04/45512
19:34:46 <darknao> #info Announcements
19:34:48 <darknao> #info Tickets review
19:34:50 <darknao> #info Quick docs update
19:34:52 <darknao> #info Open Floor
19:34:55 <darknao> #topic Announcements
19:35:02 <darknao> #info Old Fedora docs (anything older than F26) have been retired.
19:35:04 <darknao> #info Beta version of the category system for Quick Docs has been deployed on stg
19:35:06 <darknao> #link https://docs.stg.fedoraproject.org/en-US/quick-docs/categories/administration/
19:35:08 <darknao> #info Next milestone is F38 (2023-04-18)
19:35:10 <darknao> #info We use GitLab to track work: https://gitlab.com/groups/fedora/docs/-/boards
19:35:31 <darknao> #topic Tickets review
19:35:47 <darknao> We have 2 tickets in the list
19:35:57 <darknao> #link https://pagure.io/fedora-docs/quick-docs/issue/536
19:37:24 <pboy> The discussion about this one is
19:37:33 <pboy> #link https://discussion.fedoraproject.org/t/a-few-tasks-in-quick-docs-requiring-admin-access/44683
19:37:43 <pboy> #link https://discussion.fedoraproject.org/t/quite-urgent-need-for-work-on-quick-docs-repo/44705
19:39:49 <pboy> Hm, are we waiting for the link to the 2nd ticket or do we start to discuss the one above?
19:40:01 <darknao> we can start with this one first
19:40:56 <pboy> Well, Ankur would like to completely enforce the PR workflow.
19:41:28 <pboy> I am a bit hesitant and would like to change as little as possible for those who are currently contributing.
19:41:54 <pboy> Would not like to possibly scare away one or the other.
19:42:58 <pboy> A second point is: I would like to have a clear structure that makes it clear who is doing what and how many people are involved.
19:43:53 <pboy> Right now it's a long list of people, but most of them haven't done anything for a long time, or only very selectively on a specific article.
19:44:10 <pboy> This can be misleading.
19:44:12 <darknao> not sure why the PR workflow will scare anyone as it's already what's used here
19:44:21 <hankuoffroad[m]> pboy: I recall no direct commits are permitted with that decision in Pagure.
19:44:22 <pboy> <eot>. :-)
19:45:15 <pboy> Currently, direkt commits are possible for committers, as far as I get it.
19:45:31 <darknao> yes, but most contributors don't have direct access
19:45:38 <darknao> so it's PR mostly
19:46:19 <pboy> Yes, but Ankur wants to enforce (even) that.
19:46:49 <darknao> if a contributors want to get more involved in quick docs, I see no issue giving them commit rights
19:47:08 <copperi[m]> +1
19:47:16 <darknao> I don't mind enforcing the PR workflow either, but that mean we need some people to actually review and act on those PRs
19:47:46 <copperi[m]> I see problem being nobody doing reviews
19:47:54 <darknao> and we don't have a lot of people around for that kind of task
19:48:02 <darknao> copperi[m]: right
19:48:03 <pboy> Indeed.The PR workflow currently has a bad reputation. Too many PRs go unnoticed for a long time.
19:48:30 <hankuoffroad[m]> darknao: For transparency, it needs to be consistent with the Team charter and update if needed, https://docs.fedoraproject.org/en-US/fedora-docs/organizational/charter/
19:49:19 <pboy> hankuoffroad[m]  +1. we need to keep track of this
19:50:12 <pboy> Regarding permission: the single members as well as the fedora-docs group can commit directly. That are a lot. of people.
19:50:37 <pboy> Same is true for the quick-docs-committers group  even more people.
19:50:52 <AnthonyMcGlone[m> Would a rotation of reviewers work? Person A does it one week, Person B does it the next week and so on? I guess that comes back to the problem of needing dedicated reviewers.
19:51:37 <pboy> A direct commit is possible for more than 30 people.
19:53:09 <pboy> And I'm not sure, if the most active contributers are included, e.g. AnthonyMcGlone[m> or hankuoffroad[m]
19:53:10 <py0xc3[m]> Anthony McGlone: The question is if everyone can review everything. I guess the topics are too widespread and complex.
19:53:41 <pboy> py0xc3[m] Yes, that is a big issue.
19:55:30 <py0xc3[m]> Since most Fedora people do not review the GitLab but are regularly on discussions.fp, it might be worth to consider a weekly discussion topic on discourse about review requests? So, a list of pages that need a review with a short summary of the topic
19:56:06 <pboy> Good idea!
19:56:55 <py0xc3[m]> We have not done it often, but requests for specific reviewes on discussion.fp or ask.fp have already achieved here and there individuals to make a "one time contribution" if used to the topic, without longer/deeper commitments.
19:57:36 <py0xc3[m]> The diversity team does it if they have something to be done (e.g., updating a page for a specific topic or sucH).
19:57:41 <pboy> Yes, the two of us did that with virtualization. :-)
19:58:41 <darknao> one other solution would be to not do review ourselves, just merge it, and let users reviews/fix the docs as they read them
19:59:07 <py0xc3[m]> pboy: Indeed :D
19:59:39 <pboy> darknao we do that already, but it may make a bad impression if we have too many of those.
19:59:56 <hankuoffroad[m]> <pboy> "And I'm not sure, if the most..." <- At the moment, my bandwidth is small. I give comments to selected topics.
20:00:26 <darknao> you'll find reviewer more easily if the doc to review is actually available in the docs site instead on a MR lost in some pagure repository
20:00:31 <pboy> hankuoffroad[m] Maybe, but. you do!
20:01:08 <pboy> darknao +1! That's the reason we have stg with  server
20:02:04 <py0xc3[m]> darknao: I am not sure if the average user does consider to review, or is even qualified. I think that hope already contributed to the problematic Docs reputation. Unfortunately, we have not the social dynamics of Arch but most users just want to use the Docs, and cannot do more. We have to comply to Fedora's approach to serve not just "superusers", and many are none.
20:03:26 <pboy> If we use e.g. devel mailing list or user mailing list, we may have a bias for the "more knowable" users.
20:03:39 <py0xc3[m]> Just publishing and hope that someone at some point will review might bring us back to where we begun a year ago.
20:04:54 <pboy> Well, what do we want to do?
20:05:14 <pboy> Maybe, further discuss it on discussion for a week or two?
20:05:16 <py0xc3[m]> pboy: the mailing list is one possibility. A discussion topic would be a second. There are lots of people daily reviewing discourse who specialize in some realms (btrfs, grub, and so on). Its a bigger audience for review (e.g., the editors of the magazine).
20:06:13 <hankuoffroad[m]> py0xc3[m]: I assign a reviewer (at least one) for MR and approver for major revision. I only had three MRs, but I saw no issues.
20:06:38 <darknao> I don't think we have a strong agreement on how to proceed right now, so let's resume the conversation over discourse for now ?
20:06:49 <pboy> agreed!
20:06:56 <hankuoffroad[m]> This principle could apply to Pagure workflow, which is similar to GitLab
20:07:10 <darknao> we have a few other topics on the agenda :)
20:07:39 <hankuoffroad[m]> darknao: +1
20:07:51 <darknao> alright, moving on then
20:07:51 <py0xc3[m]> hankuoffroad[m]: Ma argument was related to the suggestion to merge first and then wait for review
20:08:10 <darknao> #link https://gitlab.com/fedora/docs/fedora-linux-documentation/release-docs-home/-/issues/4
20:08:38 <darknao> This is an old issue regarding the missing install guide and a few broken links we can find on our websites
20:08:46 <darknao> we need to fix those
20:08:49 <pboy> The current proposal is using page-alias
20:09:04 <darknao> right, the second one is to actually fix those links
20:09:24 <pboy> I couldn't figure out what is the page-alias for some of the pages.
20:09:27 <darknao> but both solution require to have the right pages to link to (or aliases)
20:10:38 <pboy> For the alias solution I think I just know the proper address for the "old" link, e.g. the installaton guide. Or am I wrong?
20:11:40 <darknao> you still need to put this alias on an existing page
20:11:50 <darknao> but what page?
20:12:39 <darknao> for instance: https://labs.fedoraproject.org/en/verify.html
20:12:48 <pboy> No, the failing links refer to our page, e.g. installation guide. And we have to add that page as alias to the current one (e.g. getting started)
20:13:03 <darknao> at the bottom, there is a link to know more about how to verify your images
20:13:11 <darknao> the getting started page has nothing about that
20:13:50 <pboy> Yes, the link is https://docs.fedoraproject.org/en-US/fedora/latest/install-guide/install/Preparing_for_Installation/#sect-verifying-images
20:14:05 <darknao> it will be very frustrating for the user to be redirected to some page that has not the information they are looking for
20:14:13 <pboy> On the new page we have to add that as aliase, correct?
20:15:01 <pboy> darknao we don't have a generic installation guide. We have to link to the current alternatives.
20:15:33 <pboy> Which is the better and appropriate information.
20:16:03 <pboy> Otherwise we would perpetuate the improper, misleading information.
20:16:07 <darknao> so what is the current alternative for the verify link? because the getting started is not one of them
20:16:23 <pboy> wait a moment
20:17:06 <darknao> basically, what I'm looking for, is a list of existing alternatives for all the links listed in the ticket
20:17:28 <pboy> I just see, we didn't publish that page because of objections by Chris.
20:17:29 <darknao> then we can decide if we use the alias method, or if we modify the websites with the correct link
20:17:42 <pboy> So we have to improve that page first.
20:18:56 <pboy> darknao maybe, for some cases we have currently not a proper link.  We have to fix that.
20:19:29 <pboy> But many od the dead links refer to the installation guide. And we have a rfeplacement
20:20:02 <hankuoffroad[m]> pboy: Installation process might be generic regardless of spins or labs, right (Anaconda and script)? Could we not link to QuickDocs page?
20:20:02 <darknao> if there is no good page for some of them, maybe the right choice is to remove those links?
20:20:34 <pboy> maybe, it saves us the stress to fix it.
20:20:49 <hankuoffroad[m]> pboy: +1
20:20:50 <pboy> But we have to add those information sooner of later anyway
20:21:43 <pboy> Maybe we start with page alias for those address we have a page ready?
20:22:09 <pboy> And have a closer look at those, we can't fix with the current text body.
20:22:16 <darknao> that's fine to me
20:23:16 <pboy> I would start with the installation guide it I knew or were able to figure out the alias address. Do you know it?
20:24:20 <darknao> https://docs.fedoraproject.org/en-US/fedora-docs/contributing-docs/asciidoc-markup/#_url_redirects
20:24:33 <darknao> fedora:install-guide:index.adoc
20:24:54 <pboy> Thanks, I'll start with that.
20:26:21 <darknao> Ok, I don't think we have enough time for the Quick docs update, so is it ok if we move to Open Floor for the last 5 minutes?
20:26:41 <pboy> Well, probably just a short info?
20:26:51 <darknao> #topic Quick Docs update
20:26:57 <darknao> go ahead :)
20:27:05 <pboy> Transferred Wiki article Using Yubikeys (QD #153)
20:27:13 <pboy> #link https://docs.fedoraproject.org/en-US/quick-docs/using-yubikeys/
20:27:54 <AnthonyMcGlone[m> For me, still reviewing the partials from issue #522.
20:28:00 <pboy> I would ike someone to **proofread** it (not necessarily review) It is about formal errors, such as typos, omissions, citation errors, etc.
20:28:26 <pboy> Same with #524
20:28:39 <pboy> OD #524 (Reset Bootloader Password)
20:28:43 <hankuoffroad[m]> I have done halfway testing https://pagure.io/fedora-docs/quick-docs/issue/521
20:28:48 <pboy> #link https://pagure.io/fedora-docs/quick-docs/issue/524
20:29:17 <pboy> hankuoffroad[m]. Thanks, that was one of my questions.
20:29:49 <pboy> That' all from me. Most important for me is the proofreading
20:30:15 <pboy> And the yubi article
20:30:17 <pboy> link https://docs.fedoraproject.org/en-US/quick-docs/using-yubikeys/
20:30:42 <pboy> That's it
20:30:43 <darknao> great work everyone
20:31:27 <hankuoffroad[m]> pboy: As the software installation process diverges based on which desktop environment, it takes time. I have done XFCE. KDE takes some more time,
20:31:43 <pboy> Thanks.
20:32:05 <pboy> May be we should divide it in separate aricles?
20:32:45 <pboy> Otherwise it may get too long?
20:33:01 <hankuoffroad[m]> pboy: I could cover it in one doc. Will let you know
20:33:25 <pboy> OK.
20:34:19 <darknao> ok, thanks everyone!
20:34:23 <darknao> #endmeeting