18:30:54 #startmeeting docs 18:30:54 Meeting started Wed Jun 1 18:30:54 2022 UTC. 18:30:54 This meeting is logged and archived in a public location. 18:30:54 The chair is bcotton. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 18:30:54 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:30:54 The meeting name has been set to 'docs' 18:31:13 #topic Roll call 18:31:17 .hi 18:31:18 pboy: pboy 'Peter Boy' 18:31:29 .hi 18:31:30 darknao: darknao 'Francois Andrieu' 18:31:33 .hello py0xc3 18:31:34 py0xc3[m]: py0xc3 'Christopher Klooz' 18:32:22 Er... I'm new here, what should I do? 18:32:38 #chair pboy darknao 18:32:38 Current chairs: bcotton darknao pboy 18:32:43 welcome, MateusRodCosta ! 18:33:06 Welcome too, we had a short discussion 18:33:33 you can add yourself to the log with `.hello ` (but also just speaking notes that you're here) 18:33:44 .hello mateusrodcosta 18:33:48 MateusRodCosta[m: mateusrodcosta 'Mateus Rodrigues Costa' 18:34:21 welcome MateusRodCosta[m o/ 18:34:35 Welcome Mateus 18:34:58 #topic Agenda 18:35:09 #info Announcements 18:35:09 #info Review action items 18:35:10 #info Content plan office hours 18:35:19 #info GitLab followup 18:35:19 #info Revitalization status 18:35:19 #info Open floor 18:35:30 #topic Announcements 18:35:39 #help Some release notes still need written: https://discussion.fedoraproject.org/t/how-to-write-fedora-release-notes/38311 18:35:45 #info We're using the docs-fp-o repo to track meta-work 18:35:45 #link https://pagure.io/fedora-docs/docs-fp-o/issues 18:35:55 #info The Write the Docs Prague CfP is open (conference will be held online this year) 18:35:55 #link https://www.writethedocs.org/conf/prague/2022/cfp/ 18:36:04 #topic Previous action items 18:36:21 #info pbokoc to finally add a relnotes guide to the contributor docs 18:36:41 #action pbokoc to finally add a relnotes guide to the contributor docs 18:37:00 #info bcotton to propose new text for the Mindshare box on the docs home page 18:37:00 #link https://pagure.io/mindshare/issue/341 18:37:01 this is in Mindshare's hands now 18:37:07 #info bcotton to share office hours post on cloud, devel, desktop, iot, kde, mindshare, server mailing lists 18:37:13 #action bcotton to share office hours post on cloud, devel, desktop, iot, kde, mindshare, server mailing lists 18:37:19 i haven't done this yet, but soon! 18:37:40 #topic Content plan office hours 18:38:01 #link https://communityblog.fedoraproject.org/fedora-docs-is-about-to-change-significantly-check-it-out-still-in-statu-nascendi/ 18:38:26 apart from my #action to share the link with the appropriate teams, is there anything to note on this topic this week? 18:38:42 I don#t think so. 18:39:03 I hope we are all present on thuesday? 18:39:27 bcotton will you chair the meeting? 18:39:57 i can do that 18:40:02 thanks 18:40:58 #topic GitLab migration 18:41:02 #link https://pagure.io/fedora-docs/docs-fp-o/boards/GitLab%20migration 18:41:09 so there were a couple of items related to this that got a mention on Discussion 18:41:49 darknao, can you expand on these? 18:42:05 yes 18:42:21 so the first one is about how we are going to handle permissions: https://discussion.fedoraproject.org/t/fedora-docs-gitlab-permissions/39545 18:42:56 for now, access are granted manually 18:43:36 but we can link gitlab to FAS group for a better (more centralized) permission managment 18:43:42 #link https://discussion.fedoraproject.org/t/fedora-docs-gitlab-permissions/39545 18:44:03 #info We currently grant access manually, but we can link GitLab to Fedora Accounts for centralized permission management 18:44:19 are there downsides to linking to FAS? because that seems like the way to go 18:44:31 I would prefer linking the FAS group, but I don't know if that is technicaly favourable. 18:44:34 but if we are doing that, I think we can't assign permission manually anymore to individual repository 18:45:01 darknao that's not good, I guess 18:45:15 we should be able to do that. 18:45:55 which means, for repository not completely maintained by us (like the flatpak or packaging guideline) that may cause some issues 18:45:55 so all of the repos in the docs group would have the some ACLs? 18:47:08 ACLs are assigned on the Fedora Docs group, and all repositories inherit from it 18:48:01 arguably, that's good. permissions on repos are currently all over the place, which is confusing. if we're not the ones maintaining a repo, it shouldn't be in the Fedora Docs group 18:48:18 Is there a way to "subgroups" ? e.g. core, external, .... 18:48:19 but maybe we can do both, like using SAML groups (FAS) on Fedora Docs group itself, and still be able to grant access to individual repositories behind it 18:50:34 can i #action you to find out if that's possible? 18:50:43 yes 18:51:15 #action darknao to find out if we can use SAML groups on Fedora Docs GitLab group and still grant additional access to individual repositories 18:51:56 anything else on permissions before we move to the second GitLab item? 18:51:57 I already ask that on the discussion thread, will see if ryanlerch know the answer 18:52:08 great 18:52:31 assuming this is not possible, what will be our position on this? 18:53:13 does that mean we only allow docs repository maintained by us in this group ? 18:53:20 Then we should start with a strict pull request model 18:53:25 that's the route i'd go 18:53:41 repos not maintained by the docs team should be in a different group, imo 18:53:48 darknao I think so. at least at the beginning. 18:54:37 ok, so I will hold on the migration of both flatpak and packaging guideline repositories for now 18:55:09 and maybe the l10n one too, since we are not the one maintaining it either 18:55:12 sounds good. thanks, darknao! 18:55:38 #agreed Repos not maintained by the Docs team shouldn't be in the Fedora Docs group on GitLab 18:56:10 ok so second topic, pboy already did a nice transition to it, since it's about pull request model 18:56:10 #info We will hold off on migrating the flatpak, Packaging Guidelines, and l10n repos until we know if we can grant additional repo permissions 18:56:43 more precisely, on how protected branches work on gitlab 18:57:12 by default on gitlab, the `main` branch is protected 18:57:54 meaning only users with `mainteners` role can push commit or merge PR 18:58:32 basically, everyone must use pull request workflow to push some code (or any content) 18:59:23 question is: do we want to enforce this (the default) or should we relax it a bit, so at least team members can push directly 18:59:47 From a non-technical view: If a take responsibility for e.f repo Anaconda guide, I would like to be able to commit directly, and commit PRs 19:00:17 And it would be nice to have a team, that can do it that way. 19:00:26 personal opinion: I think we are not enough in the team right now to enforce this policy and add the need to review every single change 19:00:43 i like the idea of relaxing. i think we should do PRs for significant changes, but it'd be annoying to require it for trivial changes, typo fixes, etc 19:00:50 darknao +1 19:01:08 We need somethink like QA 19:01:30 if you have access to the docs group, I guess we trust you enough to push commit, just like it is on Pagure 19:01:59 IMHO, if I were to contribute writing docs, I would prefer my contributions to be reviewed first until I got tthe hang of the process and writing style 19:02:16 for external users, in other hand, we keep the MR workflow, of course 19:02:45 MateusRodCosta: even if you are allowed to directly push, you can still do a pull request if you are not sure about the content :) 19:02:47 by external users, I mean users that are not in the Fedora Account Docs group 19:03:10 Ok, got it! 19:03:22 we can also add a number of required approval to merge MR 19:03:43 I should not make it too complicated. 19:03:51 I -> We 19:04:08 agreed. i think if someone with commit access approves the MR, we should merge it 19:04:25 What is a MR? 19:04:27 i'd love for us to have enough people actively contributing to require 2 approvals, but we're definitely not there yet 19:04:34 MR = PR (Merge Request) 19:04:40 thanks 19:04:54 Gitlab uses MR, where Github uses PR 19:05:10 so 1 approval required then? 19:05:14 bcotton: in the long run yes 19:05:35 darknao We should begin that way. 19:06:08 we can revisit it at later time if that doesn't work well an 19:06:12 anyway* 19:06:22 indeed 19:07:02 I don't know if we have the time, but I have a third topic that cross my mind just now 19:07:15 go for it 19:07:22 alright 19:07:25 CI ! 19:07:53 Once upon a time, there was a project to implement CI in docs 19:08:46 the goal was to build the whole documentation website somewhere, and make it available in each PR made all around for every single documentation repositories 19:09:52 that was never implemented, mainly because you'll need to monitor each repository for PR, using fedora-messaging for instance, and that can become very complicated 19:10:21 But now, we have gitlab-ci to the rescue 19:11:23 We can easily implement that for every repository we manage, but that will most likely only build the doc component alone instead of the whole website 19:12:08 question is: Do we really need to build the whole website for that, or can we just limit ourselves to the component we are currently testing? 19:12:38 if it's just the component, that's still better than we have now 19:12:45 Question: Does it mean that I have the complete doc site locally available? Or do I got it totally wrong? 19:13:12 and it will catch maybe 80% of issues? thinks like cross-module includes and xrefs won't be right, but most things will 19:13:29 pboy: basically, the CI system will run the build.sh script and make the result available for previewing in your PR 19:13:42 OK 19:14:04 that is for the base job, we can then add whatever check we want to that 19:14:54 like, checking links or syntax... 19:15:38 sounds interesting. Something like a private stg 19:16:01 if a component does a lot of cross link to another component, we can add it to the site.yml 19:16:25 and include it in the CI build 19:16:36 pboy: yes, exactly 19:16:58 would be great, practically 19:18:07 alright so I can configure all the repositories already in gitlab with that in mind 19:18:25 agreed 19:18:26 we can start with a simple build on the repos we manage and build out additional checks (and docs for others who want to use CI) over time 19:19:21 yep sounds good 19:19:29 you can action me on that 19:20:18 #action darknao to configure the docs repos in GitLab with CI to run builds on MRs (we can add additional checks later) 19:20:27 anything else on GitLab? 19:20:55 I think that's it for me 19:21:11 oh actually one last thing 19:21:22 what about the docs-fp-o repository? 19:21:54 can we migrate it now, or do you want to leave it for a bit? 19:22:03 may be we migrate that last? 19:22:18 yeah, i thought we were going to leave that for last 19:23:08 well, there is not much left to migrate 19:23:25 the last one is quick-docs 19:23:55 I see, I must hurry with my account 19:23:56 and all others are maintained by other team, so we may end up not migrate these in the end 19:24:39 did we do release notes? 19:25:04 I don't think there was a ticket for that one 19:25:35 whoops 19:25:39 looks like there wasn't 19:25:53 that one's a little more complicated since we don't actually want to declare bankruptcy there 19:26:27 #action bcotton to start discussion of how to handle the Release Notes repo move 19:27:25 okay, we're near the end of the hour. anything else that needs to be discussed this week? 19:28:00 don't think so 19:28:07 not in 2 mins 19:28:14 Hi, where and how I should I start contributing? 19:28:26 last one, we should close this ticket: https://pagure.io/fedora-docs/docs-fp-o/issue/189 19:28:37 I mean, do the changes, then close 19:29:00 I can handle the fedora-docs group on Pagure, but I don't have access to the Fedora Account one 19:29:11 okay, i can do that 19:29:12 Could we wait until we have time for the topic we miss today? 19:29:14 #action bcotton to make the group changes in https://pagure.io/fedora-docs/docs-fp-o/issue/189 and close the issue 19:29:31 the revitalizaiton status? 19:29:37 yes 19:29:51 makes sense 19:29:57 #undo 19:29:57 Removing item from minutes: ACTION by bcotton at 19:29:14 : bcotton to make the group changes in https://pagure.io/fedora-docs/docs-fp-o/issue/189 and close the issue 19:30:08 i'll put that at the top of the list for next week since we've missed it the last few times 19:30:28 MateusRodCosta[m> 19:30:50 MateusRodCosta[m can we discuss your contribution on mailing list? 19:30:59 contribution options 19:31:08 pboy: Mailing list or Discussion? 19:31:32 discussion, we have no mailing list anymore. :-( 19:31:43 Ok, sure 19:31:47 okay, thanks everyone! 19:31:49 #endmeeting