Here’s the agenda for the meeting 2023-03-08T19:30:00Z in #fedora-meeting-1:
- Tickets review: there is one ticket flagged for the meeting on GitLab :
- Quick docs update
- New fedoraproject.org website feedback
- Everything about ui-bundle
- Your topics here!
- Open floor
Just of note, I mentioned in the Docs Matrix channel that I was planning to write about S0ix and it was agreed that it would be useful to have it as part of Quick Docs.
And, while I didn’t start writing that Quick Doc yet, I did create a Discussion thread about asking for improving the current state of S0ix in general on Linux:
Another thing is that I still didn’t continue writing the Dnf guide, bit I believe I have a good idea of what to write.
Essentially as basics the user should know
dnf remove and
dnf search, optionally also knowing
dnf autoremove, so O could write it in a single page.
dnf repoquery and
dnf history could be their own pages, and I am not sure where to fit
This gives me a good enough start point for the rest of the guide.
Out of curiosity, is it fine if the guide is based on a toolbox or does it have to be on a Workstation system?
the basic idea was, to transfer and update the dnf part if the current outdated administration guide (https://docs.fedoraproject.org/en-US/fedora/latest/system-administrators-guide/package-management/DNF/) into its own guide. But that is basically what your ideas are.
What do you mean by “toolbox”? It’s not just for Workstation, but e.g. server and cloud as well as the non-gnome package based spins and Labs, So I think it is basically the CLI.
Could we discuss about the new website?
Documentation under top menu ‘contributors’
And we should discuss about the current status of a “Documentation” item (visibility).
And I would discuss shortly about the difference or no-difference in the ui bundle of our various repositories. Is the ui-bundle versioned?
README.md file on Quick Docs require an update, so I submitted PR for your review.
Issue ticket is here to give an overview why an update is necessary.
README.file gives a project curb-side appeal. We need an up-to-date information for contributors.
Happy Saturday, folks!
I think about potential topics for next week’s Docs meeting.
It is about sharing Docs activities and suggestions to make team presentations on the community events like release party.
Tagline: Docs improvements and new energy
Curation: category, tag
Quick Docs issue management and PR
Number of contributions: issues closed, PR merged, number of contributors (on Pagure and GitLab)
Test your changes locally (Docs QA)
You can build and run the website on your machine to preview your changes using Podman container. Why?
When you make changes such as;
- Change links and navigation bar
- Consolidate multiples pages into one page
- Update images and add metadata, alt text
- Section levels reorganized (Example: h2 to h3) for readability and reading flow
- Code block updated
- Fix inactive navigation bar and link pages
- Reorganize navigation bar
- Rejuvenate, rewrite some outdated pages
- Reiterate changes with vale linter
you need local writing environment to render the changes predictably.
Docs linter for styling and Docs quality: pilot for Contributor guide
Docs website changes: what is going on?
I can cover Docs QA concept (Test your changes locally). I took some inspirations from my day work on User Acceptance Testing.