18:32:26 #startmeeting docs 18:32:26 Meeting started Wed Apr 19 18:32:26 2023 UTC. 18:32:26 This meeting is logged and archived in a public location. 18:32:26 The chair is darknao. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 18:32:26 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:32:26 The meeting name has been set to 'docs' 18:32:35 #topic Roll call 18:32:37 #chair pboy darknao pbokoc py0xc3[m] 18:32:37 Current chairs: darknao pbokoc pboy py0xc3[m] 18:32:42 hi there o/ 18:32:52 .hello py0xc3 18:32:53 py0xc3naatMatrix: py0xc3 'Christopher Klooz' 18:32:57 .hi 18:32:58 pboy: pboy 'Peter Boy' 18:33:30 .hello hankuoffroad 18:33:31 hankuoffroad[m]: hankuoffroad 'None' 18:38:03 #topic Agenda 18:38:44 #link https://discussion.fedoraproject.org/t/docs-meeting-agenda-2023-04-19/81135 18:38:46 #info Announcements 18:38:48 #info Quick docs update 18:38:50 #info Docs plan for the next year 18:38:52 #info Open Floor 18:38:54 #topic Announcements 18:39:07 #info F38 has been released \o/ 18:39:16 #info We use GitLab to track work: https://gitlab.com/groups/fedora/docs/-/boards 18:39:21 anything else to add here? 18:39:34 Nope :) 18:39:55 #topic Quick docs update 18:40:05 anything to report on the quick docs side? 18:40:09 .hello copperi 18:40:10 copperi[m]: copperi 'Jan Kuparinen' 18:40:24 Not from me. 18:41:54 alright, so I guess the main topic of this meeting will be... 18:41:57 #topic Docs plan for the next year 18:42:02 #link https://discussion.fedoraproject.org/t/possible-docs-team-work-plan-for-the-f39-f40-period/81122 18:42:12 who want to start? 18:42:28 pboy: ? 18:42:53 Well, I wrote it, yeah. 18:43:27 The general idea is: we should concentrage on the most urgent and most needed tasks. 18:44:05 I suppose, most needed and most urgend are the Release Notes. 18:44:41 F38 RN seem to be in a sad state, on the first sight. 18:45:06 And the RN get some attention in the Fedora Community. 18:45:17 petr is on it 18:45:53 Yes, and I appreciate it very much. 18:46:08 but I agree that an automated way to deal with release notes would be a plus 18:46:28 Nevertheless, a script based approach as we discussed some months ago would help a lot. 18:47:43 And the general Fedora docs receive none or minimal attention, I think, Therefore we should not put to much efforts on it. 18:48:27 pboy: Which docs in specific? 18:48:46 So, we shoould concentrate on RN and on facilitate contribution support. 18:49:38 hankuoffroad[m] I think of admin tools, quickdocs, our landing page and all the information we collected there. 18:50:16 We put a lot of effort into it. But it doesn't enjoy much attention. 18:50:38 None of this appears on the new home page. 18:51:42 We don't work there for the trash, but for the filing in the background. 18:52:16 ok, most of issue ticket pending is on Pagure QuickDocs, and I think it is okay to improve it over time. Landing page uses the new CMS tool. On the new web site, I made a change request to the web team to tweak locations of documentation. 18:53:55 pboy: Sounds critical. We can focus on what's on pending and what we think important. 18:54:17 Yes Quickdoc has relatively many issue requests. But in the overall context still very few. 18:54:47 if you could draw a mockup of what you really want to see on the home page, documentation wise, I think that would be helpful 18:55:04 Quickdocs tickets are handled in pagure? (sorry for interrupting) 18:55:22 pboy: I think we need to reorganize the menu tree (nav.adoc) and prioritize pending issue to get assigned. 18:56:51 so one question regarding "Any FAS account would be allowed to comment on contributions directly" 18:57:02 Also any issue ticket that require technical review, we could shout out loud in Comms blog (like Ben Cotton does well) to recruit (i mean to get one time help) people for the tasks. 18:57:03 what do you mean by "comment on contributions" ? 18:57:05 I think, that Documentation is not part of the homepage is not a design issue, but an indicator what the community is regarding as important. 18:57:45 darknao Type, s/comment/commit 18:57:51 aah ok 18:57:55 make more sense 18:58:04 oh Type -> Typo 18:58:07 so I have one comment on that 18:58:15 in QuickDocs, we had a few subject matter specialists like yubikey. it is really valuable. 18:59:33 darknao: ok please 18:59:35 I think PR should be kept instead of direct commit access. First because it's easier to contribute with PR than direct commit access: you don't need any rights on the repository for that. And we should kept PR cause we can at least do a very minimal review of changes to make sure there is nothing breaking the documentation 19:00:14 darknao: I'm on that 100%. 19:00:20 wiki for instance, require some level of moderation, that we can't really afford here. So PR is the minimal amount of moderation that we can get 19:01:03 I'm not saying that we should review the content of all PR, but just a minimal one on asciidoc syntax and such, just to make sure the docs stays a safe place for everyone 19:02:06 but that just my opinion, if you think direct commit access is better, that's fine to me 19:02:13 that applies to 'minor' update label as defined. 19:03:00 darknao Okay, so we refrain from raising the quality of quickdocs and limit ourselves to defenses against formal errors? 19:03:07 I think major and minor labels are well defined for us to follow. And we can guide other people on the same manner. 19:03:59 * minor labels in GitLab are well, * same manner. We can adopt the same for Quick Docs? 19:04:28 darknao I have no particular opinion. I only see for myself that the high effort with which we started this is not worth it. 19:05:24 "Quickdocs tickets are handled in..." <- yes 19:05:34 We have moved strongly on the "quality initiative" that resulted from our discussion with the interns. 19:05:54 However, there is obviously no need for this. 19:07:02 Or at least we need to ask ourselves, is there evidence of a need that justifies the effort. 19:07:20 and I agree with you there, I'm just trying to find a middle ground between opening wide open the door of quick docs contribution to everyone without any form of moderation whatsoever and the current situation or PR get stuck without review for weeks (which is actually not the case anymore) 19:07:20 there are only 23 open issue tickets in Quick Docs. What do you suggest pboy 19:08:00 darknao: yes, we cleared PR in March 19:09:08 hankuoffroad[m] I think it is not only a question of open tickets. We started a qualitative initiative. Do we want to continue that? 19:09:50 Where are the readers for a high quality Fedora documentation? 19:10:08 Other than technical review, whaat is qualitative initiative? 19:11:06 Matthew shared site metrics weeks ago by top pages read 19:11:44 <+hankuoffroad[m] Do you have a link? 19:12:06 will search it..please carry on. 19:12:20 hankuoffroad[m] regarding qualitative initiative: Technical accuracy, correct, functional advice, good readability, quick comprehension, clear structure, .... 19:12:44 There are a lot of criteria for good documentation. 19:13:11 I can also ask web team to run latest stats - site metrics 19:13:29 The number of open issues is just a bare minimum. 19:14:26 hankuoffroad[m] I think it would be helpful to have a regulär statistical information about visits of our pages. 19:14:55 pboy: i'm bad at searching...plus after merging with ask, it is more challenging...i will ask the stats, leave it with me. 19:15:15 hankuoffroad[m] OK, thanks 19:16:51 pboy: ok, about quality, one of 'gig' I tried was use of linter to automate such style check..next would be to apply quality check by bulk update (need to check technical feasibility). Yes, I'm on it. It is much better than manually correcting style 19:18:38 pboy: agreed 19:19:33 Yes, tools will help a lot. But nevertheless, improving quality involves a lot of additional manual and organisation work. 19:19:55 we have 10 minutes left, can we move to open floor in case there is other topics to discuss? 19:20:35 Yes, we may have to continue on discussion and/or next meeting 19:20:42 pboy: yes true. After spending lots of manual correction, I started to think about linter and automation 19:20:57 #topic Open Floor 19:21:59 so is there anything for open floor? 19:22:12 py0xc3 (n/a at Matrix/IRC until May; use discussion.fp to contact me): you are back. How do you feel? 19:22:51 How are you? 19:22:57 At the moment, I am just watching and reading to slightly find out what is going on ;) A lot seems to have happened, which is good of course! :D 19:24:01 So I'm fine ;) Don't wonder that I am a little silent, I try to slightly catch up :) 19:24:17 Sure ake your time 19:24:20 take 19:24:56 Just one question I just have in mind 19:25:12 Is there still a plan to migrate the quick docs on the long term? 19:25:48 migrate to what? 19:25:54 It's me who wanted to stay at pagure 19:26:15 Because or a more efficient work organisation for me. 19:26:21 GitLab. Earlier it was planned to get everything there. But I think to remember that there was some issue with quick docs 19:26:49 py0xc3naatMatrix. Yeah, me. :-) 19:26:52 pboy: not only you...there are existing contributors who mostly spend time at Pagure, so we don't want to rattle users 19:27:32 OK, not only me , reassuring 19:27:51 ok xD yeah, I just remembered that something was with it. But if the majority of contributors prefer pagure that obviously makes totally sense. 19:28:08 pboy: many teams have repos on Pagure. it is neat and fast 19:28:47 hankuoffroad[m]> 19:28:47 i mean when using terminal and local fork 19:28:56 Yeah, I think it is much of a personal preference, some prefer that, some the other. There is not the one git service that is perfect for everyone 19:29:22 hankuoffroad[m] yeah, e.g. Server WG decided not to migrate to gitlab. becaus they mainly use terminal and CLI 19:30:08 Antora's strengths are to support multi-repo sites. which is exactly what design priciple Fedora team decided back in 2018. 19:32:14 Well, I think time is over. Thanks for the update :) 19:32:21 we are out of time! Thanks everyone for today 19:32:23 cool 19:32:30 see you next week 19:32:33 #endmeeting