[BOARD] Fedora Docs working program

Specifically, @pbokoc and @darknao and anybody else for info and comment, the three of us are currently the members of Fedora Docs board and have taken special responsibility for the further development of Fedora Docs. According to my overview, the following matters need to be clarified and implemented in the short term.

1. Providing ongoing support for our GitLab issues and MR’s.

We have again accumulated a larger number of unprocessed issues as well as MR’s that have been unattended for more than 14 days. This state of affairs is unsustainable, discourages potential contributors (and rightly so!), and counteracts our ongoing efforts to revitalize our author base (see my talk at Flock and the planning for “collaborative writing” here).

We urgently need to make sure that someone takes care of this on a regular basis, either by direct action or by initializing a discussion here. I am not willing to waste my time on the GitLab GUI mess and the miserable editing and administrating procedures (It’s OK for me to commit direct content contributions via my local authoring environment directly, so without this GitLab GUI stuff).

Currently, I see 2 ways to improve the situation.

  1. One of us (i.e. @pbokoc or @darknao :smirk: ) will take on the task of monitoring our GitLab repos on a regular basis, and addressing posted questions or contributions within a short time frame, perhaps around 1 week).
  2. We close and deactivate issues and MRs on all our Repos and create an Issues repo on Pagure (or reuse an existent).

Anyone who can think of another option: you are welcome.

2. Improvement of Quick Docs

This is part of our work plan. Along with a few others, I have made sure that the partials of articles are fully re-integrated, making editing of articles much easier, especially for the inexperienced. And now every article includes category and tags, so we can move forward with an improved UX.

These Quick Docs improvements are central to our work to re-vitalize our authors’ community.

So we have to create

  1. A new QD start page, which lists the categories with underlying link to a page with a list of those articles (or maybe preferable an accordion for the list). And the same for the tags.
  2. A modified page structure without navigation bar but the associated categories and tags probably on the left side instead including an underlying link to the page with those articles (or an accordion again).

In order to use the momentum for Docs, we need to do this together with the new release F39.

That’s it for now from my side.

1 Like

I have reviewed most of MRs and issues posted on Contributor guide repo. I’m fairly comfortable with GitLab web UI overall, so let me take care of MRs and issues on that regularly.

If it is Docs build and UX stuff, we appreciate support from specialists.

Some issues or MRs may not have time criticality, so I wouldn’t put a time bar.

What about getting familiar with gitlab cli?

I’m afraid the GItLab CLI introduces a whole new set of commands. I would not recommend that.

That being said, we need to focus on our efforts in writing skill and craft, not tools.

  • Skill and craft: editing code snippets for better conventions, formats, and clarity/accuracy. Mastering plain English. How to work on comments and write better comments, so we bring writers community together.
  • Tools: it divides and dilutes our efforts.

Yes, it is possible to create a merge request without log-in to GitLab web UI.

Below article might help reduce the need for editing merge requests manually through the UI if anyone is interested.

GitLab (the web UI, mostly) is adding new features every month, which is welcome by some, but also feared by many. I hate to re-learn additional things in web UI that are not necessary for documentation maintenance, but are utterly distracting.

Whether GitLab UI is getting cumbersome every month or not, i have to do what’s absolutely required.