Docs meeting agenda: 2022-09-21

Here’s the agenda for the meeting 2022-09-21T18:30:00Z in #fedora-meeting-1

  • Announcements
  • Action item followup
    • None
  • @ankursinha’s improvements for the preview.sh/build.sh (see below)
  • How to proceed with Release Notes Fedora 37
  • Discussion of the Fesco ticket, (Issue #2868: Release Notes Improvement - fesco - Pagure.io) Not overly lively so far. Is my reasoning OK or do we need to add something.
  • Status variant-orientated docs plan
  • Additional repo ownership of “Fedora Linux Workstation and Spins User Guide” (Nr. 1 of #4)
  • Maintenance strategy for “Fedora Linux Workstation and Spins User Guide” (Nr. 2 of #4)

Concerning Ankur’s improvements, see the related topic beginning at this post: Improved build script for doc repos (with change detection!) - #11 by ankursinha - Fedora Discussion

And the related MR: feat: add new builder script (!4) · Merge requests · fedora / Fedora Docs / Templates / Documentation Template · GitLab

And of course the “clean” alternative to the “quick and dirty” approach: fedora-docs-builder.spec · main · Ankur Sinha / fedora-docs-builder · GitLab

I cannot participate today (I have a very arbitrary month :), but in case the agreement goes towards the quick and dirty approach of updating each repo individually, you can assign me for the GitLab repos.

1 Like

There’s also this question of how to license the various scripts we use in docs (I was only looking at the builder script, but there are probably a few more for deployment and so on) given that Legal no longer considers CC0 appropriate for code:

A very good point! In cases of such little & simple scripts, I am a fan of making it as flexible as possible. So my suggestion would be Apache 2.0: widespread, wide compatibility to be used in other projects, flexible/“lax”, no copyleft, patent termination.

I saw in the GitLab Fedora repos we have already something with Apache 2.0 and something with MIT. So not increasing the number of used licenses might also keep things in general KISS. So I suggest to at least stick with one of these two.

Major difference: MIT is compatible also with GPLv2, Apache is compatible only with GPLv3 (because of the patent termination).
MIT has no patent termination & can cause patent issues / treachery, but Apache is prepared for that (although I think some see this attribute of Apache not only as advantage).

For our purposes here, I think the differences are not worth much discussion and we might use just one of the two we already have in the repo… :wink:

1 Like

Another topic, if you have some time left at the end:

  1. I lost the owner rights of the “Fedora Linux Workstation and Spins User Guide” repo when it was transferred to the Docs. I would like to have ownership rights for this repo again. There have already been some actions I cannot do atm.

  2. To get a maintenance strategy that avoids the “Fedora Linux Workstation and Spins User Guide” to end up with the same problems as the old Docs, I have added an “interim” strategy as example, which might be discussed: see the MAINTAINER.md in the repo. Especially the “warning” status (or category) might be interesting, and could be developed into an alternative approach on its own (we talked already in the past about the warning sign for old content). Just to have something to start a discussion.
    Don’t forget: we do not need a strategy that facilitates massive amounts of pages → Fedora users can and do use upstream docs because Fedora keeps compatibility upstream (our demand is different to other communities). Ask.fp triggers appropriate forwarding, too. But the few Fedora-related pages we need to provide have to be trustworthy (or at least let the users know when and where they can rely on what they see). (We can learn from Silverblue in this respect, but should not forget that their unified way of Docs delivery/provision differs to ours:)

Some other topics are:

I think @pboy 's topics should be focused first. My first topic about the ownership of the repo would be nice to be solved, but my second topic is less time critical than @pboy s. It can be postponed.

Supplement: I have adjusted the agenda accordingly.

1 Like

Minutes and full logs are available.

Highlights

  • None

Action

  • None