18:30:55 <darknao> #startmeeting docs
18:30:55 <zodbot> Meeting started Wed Sep  7 18:30:55 2022 UTC.
18:30:55 <zodbot> This meeting is logged and archived in a public location.
18:30:55 <zodbot> The chair is darknao. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:30:55 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:30:55 <zodbot> The meeting name has been set to 'docs'
18:31:04 <darknao> #topic Roll call
18:31:18 <pboy> .hi
18:31:19 <zodbot> pboy: pboy 'Peter Boy' <pboy@uni-bremen.de>
18:31:26 <py0xc3[m]> .hello py0xc3
18:31:27 <zodbot> py0xc3[m]: py0xc3 'Christopher Klooz' <py0xc3@my.mail.de>
18:31:34 <py0xc3[m]> but I'm only "part-time" here
18:31:38 <darknao> #chair pboy darknao pbokoc py0xc3[m]
18:31:38 <zodbot> Current chairs: darknao pbokoc pboy py0xc3[m]
18:31:46 <darknao> hey everyone
18:31:54 <py0xc3[m]> Good evening
18:32:18 <pboy> hi
18:33:28 <darknao> ok let's go
18:33:31 <darknao> #topic Announcements
18:33:37 <darknao> #info Some F36 release notes still need to be written https://pagure.io/fedora-docs/release-notes/roadmap/F36
18:33:47 <darknao> #info F37 Beta Freeze is underway
18:33:53 <darknao> #info F37 Beta Go/No-Go is tomorrow: https://calendar.fedoraproject.org/meeting/10209/
18:34:02 <darknao> #info We use GitLab to track work: https://gitlab.com/groups/fedora/docs/-/boards
18:34:14 <darknao> anything else?
18:35:00 <darknao> alright
18:35:02 <darknao> #topic Previous action items
18:35:12 <darknao> #info pboy (and perhaps likeanushka) was to develop a step-by-step plan for the re-formed product-oriented docs
18:35:39 <pboy> Still working on it
18:36:02 <darknao> ok
18:36:06 <darknao> #action pboy (and perhaps likeanushka) to develop a step-by-step plan for the re-formed product-oriented docs
18:36:12 <pboy> Will finish at the end of this week with a 1.  proposal
18:36:48 <darknao> nice
18:37:17 <darknao> no other action from the previous meeting, let's move to the next topic
18:37:41 <darknao> #topic Improving Release Notes process/attention
18:38:21 <darknao> So F37 is approching fast, and we still have some F36 release notes in the backlog
18:39:39 <darknao> any idea to make this process easier and find a way to catch up?
18:39:53 <pboy> I suppose, nobody devotes special attention to F 36 now
18:40:18 <pboy> In general, we (resp. FESCO)need to bring more liability  to the release notes process.
18:41:40 <pboy> Proposal: Release notes must be included in the change proposal as an indispensable prerequisite for acceptance.
18:42:11 <pboy> It's a FESCO thing.
18:42:18 <darknao> maybe we should try to organize some kind of hackfest where we all try to write a couple of release notes?
18:42:30 <darknao> pboy: I like that proposal
18:43:28 <pboy> We can edit the final release notes and maybe polish the wording and formatting.
18:43:29 <darknao> I think it would be much easier if we just had to copy/paste the notes written by the change owner instead of looking for the required information ourselves
18:44:28 <pboy> We can't write the substantial content. We simple don't know what a package owner is doing.
18:44:30 <py0xc3[m]> +1 for pboy's proposal. Much more efficient, and might facilitate a permanent improvement.
18:45:02 <py0xc3[m]> ...and we cannot ensure the working hours of sufficient people, who have to contribute even more to get into the respective topics
18:46:50 <pboy> OK. So one of us should approach FESCO and discuss it with them.
18:47:07 <darknao> just for information: https://docs.fedoraproject.org/en-US/program_management/changes_guide/#_release_notes
18:47:37 <darknao> the release note is already part of the change process template, but most of the time, it's left empty by the owner
18:48:15 <darknao> this should probably become mandatory
18:48:18 <py0xc3[m]> When we just do the rest for the owner, we reward and educate them to keep it that way... making even more doing it that way
18:49:08 <pboy> darknao, mandatory, that is what i meant. And part of the acceptance decision.
18:49:47 <py0xc3[m]> looks like a consensus ;)
18:49:59 <pboy> (I left it empty myself, I've to admit. :-). )
18:50:38 <pboy> OK, so who writes the FESCO ticket?
18:51:02 <pboy> Maybe, it is easies for me ?
18:51:18 <darknao> #agreed proposal to FESCO: Release notes must be included in the change proposal by the owner as a prerequisite for acceptance.
18:51:23 <py0xc3[m]> I'm not really deep into this topic
18:51:34 <darknao> pboy: can I action you?
18:51:43 <pboy> yes
18:52:00 <darknao> #action pboy to submit the release note proposal to FESCO
18:52:09 <darknao> cool, thanks
18:52:46 <darknao> what about our current backlog?
18:53:21 <pboy> I think: For F36 leave it as is.
18:54:55 <pboy> Hardly anyone will care at this point. Everyone is awaiting F37
18:55:04 <darknao> ok for F36, but what about F37 then?
18:55:32 <pboy> For F37 we need someone who cares about it.
18:55:46 <pboy> What about pbokoc ?
18:56:12 <pboy> But again, we can't write release notes!
18:57:34 <pboy> We may be able to create a template, just in case there isn't already one.
19:00:15 <darknao> if I look at few changes for F37, most of them have at least a summary which seems to describe the change enough (at least enough to be mention as is in the release note)
19:00:53 <darknao> it'll probably be not as good as what we are used to have, but I think it's still better than nothing at this point
19:01:08 <pboy> Yes, the summary is mandatory
19:01:28 <pboy> And yes, it it better as an empty space.
19:02:20 <pboy> I think, the release note entries are processed automatically ? Do you know something about that?
19:02:44 <darknao> in the docs?
19:03:25 <pboy> I don't know where. Maybe it is a kind if wiki makro?
19:04:08 <darknao> don't know, I've never heard of anything automated for release notes
19:04:38 <pboy> Maybe, #bcotton knows.
19:05:23 <pboy> Can we ping him via IRC?
19:06:20 <darknao> or maybe on discussion?
19:06:30 * bcotton reads
19:06:48 <darknao> oh hey bcotton :)
19:07:03 <py0xc3[m]> Good evening :)
19:07:20 <bcotton> There's nothing automatic about the release notes
19:07:34 <pboy> OK. what a pitty
19:08:20 <bcotton> It's better than the old model we had, where docs contributors took a "beat" and had to do their own research
19:09:03 <bcotton> I think a sufficiently-motivated contributor could write release notes entries for accepted Changes fairly easily in most cases
19:09:23 <bcotton> I wrote a dozen or so in an hour-ish for F36, none of which are in my particular technical areas of expertise
19:11:48 <pboy> I think, the "beats" model is very susceptible
19:12:29 <darknao> I'll take a shot at writing a couple of them and see if I manage
19:13:00 <pboy> Even if there is a text, it would be quite a punishing job to copy that manually.
19:13:21 <pboy> We should try to automate it.
19:14:10 <pboy> All change proposals are in one place, the text is "tagged", so it should be doable. Or?
19:15:09 <pboy> Exen to take the summary, if the Release Notes tag is. empty
19:15:22 <pboy> Exen -> Even
19:15:32 <darknao> well, if we can get the release note section from the changes already written, I guess we should be able to code something
19:16:10 <darknao> but the release note also needs to be categorized
19:16:38 <pboy> I think, instead of writing foreign release notes, you should better develop automation.
19:17:26 <pboy> If necessary, the change proposal must receive an additional field / tag
19:19:57 <darknao> ok we can continue this topic on discussion or in the next meeting. I think there is one other topic we need to discuss before the end
19:20:10 <bcotton> I don't like the idea of making change owners figure out which release notes category it belongs in. that's docs' decision
19:21:35 <pboy> bcotton I'nnot shure about that. the change owner an select from a set of categories.
19:21:45 <py0xc3[m]> The other one is not critical. We can skip that.
19:21:55 <py0xc3[m]> Just added it as I thought we will be done early
19:22:35 <pboy> py0xc3[m] your proposal is important. We need to have a look on the open issues!
19:23:32 <darknao> #topic Issues triage
19:24:17 <darknao> #link https://gitlab.com/fedora/docs/community-tools/fedora-accounts-docs/-/issues/8
19:24:20 <py0xc3[m]> Well, I think the major question is if one of them (the two old issues) can be simply closed, and if not, if it makes sense to make it/them "good first issue". I expect everyone has currently other things to do.
19:24:44 <darknao> #link https://gitlab.com/fedora/docs/community-tools/fedora-accounts-docs/-/issues/9
19:24:50 <py0xc3[m]> I think this would be a good first issue. It contains work and I think we cannot do it for now, but it is not highly technical and easy to get into
19:25:02 <py0xc3[m]> I was referring to #8
19:25:31 <darknao> py0xc3[m]: I agree with that, that sounds easy enough to document
19:25:33 <py0xc3[m]> It would be also something tangible for new people
19:26:03 <py0xc3[m]> So #8 -> keep in triage + add good first issue?
19:26:18 <darknao> and the actual procedure is simple enough for new contributors
19:26:23 <darknao> py0xc3[m]: +1
19:29:16 <py0xc3[m]> #9 is a bit the opposite: not that much to do but it needs already some background experience. I am also not sure if this is really needed, although it seems to be an improvement if the arguments are right (I have not worked with that function before). Would be a good first issue for experienced people who had worked with that function, but I assume it will remain in triage for very long ^^
19:29:48 <darknao> as for the second one, I'm not familiar with fkinit, but that sounds like it's just about moving an existing doc from the wiki
19:30:17 <darknao> on other hand, the wiki page is an infrastructure one, and they have their own documentation namespace
19:30:53 <py0xc3[m]> Well, in either case, I have not the time to get into the topic to verify it.
19:32:49 <darknao> honestly, we can barely keep up with the Fedora Linux documentation right now, I would say the documentation about Nogin should not be our responsibility
19:33:01 <py0xc3[m]> The question is, keep it in triage?
19:33:05 <py0xc3[m]> I think we are overdue. If everyone agrees, I will add the "good first issue" to the easy one, and we can handle the rest later?
19:33:18 <darknao> yes we can keep it that way
19:33:32 <darknao> ok let's end this
19:33:43 <darknao> thanks everyone!
19:33:48 <darknao> #endmeeting