I’m taking a liberty of creating a new thread with the subject that matches the topic. @hamrheadcorvette thanks for sharing ideas.
The vast majority of Quick Docs articles works for frequently used activities like adding repo, system update, which are not affected by release cycle. However, part of the content gets outdated according to release notes and a change to upstream projects.
Maintenance of documentation is equally important as well as creating new sections of articles.
I’d intentionally stop commenting about how to solve contributor’s pathways and the scope of Quick Docs, so folks in various working groups/SIGs can join our effort to maintain docs.
From my experience, I would create small PRs per each article and change on a topic. You can manage this by creating a feature branch to your fork. I don’t believe there is a need for multiple forks.
Also best practice on PRs tells us about making small PRs that fulfill a single purpose.
The beauty of all this, is that you don’t need to know a programming language to engage in a computing community. You bring what you can, All of this is wide enough to cover many walks of life and all are welcome ! That’s the beauty of Community based projects.
For me, finding Go-To persons is a godsend to any obstacles I faced along contributor journey.
Go-To persons are not necessarily technical reviewers or maintainer. For example,
if pipeline failed on a pull request: find who can help
if merge conflict happened
build script throws out error
when I don’t know what to do with new article ideas
the moment I hit obstacles
Matrix Chat is the best place to know people casually as well as discussing documentation bugs and technical issues. There is no way to have contributor guide for all of obstacles we might face.
I do 90% my collaboration on the phone. Weblate is somewhat usable (even though I am totally confused how to find the correct pages of interest) but Gitlab… or even Git at all.
Localization team will be able to assist you with workflow. Some of working groups use voice/video call feature of the Matrix chat. Docs team also uses it when required like Docs workshop.
Hiya, on another note, I feel quickly drained if I work like a lone writer with zero interactions and go radio silence. Collaborative writing goes a long way.
If you want to go fast, go alone; if you want to go far, go together.
I do have a proposal for the docs-team about Quick Docs. The mentioned above had in my opinion, missing/confusing information.
The missing information/example was to restrict size and or cleaning older entries with journalctl. And as a bit confusing I find the “foo” variables commonly used in documentations. In a quick doc, I think it would be great to use “real world” examples. This would make them more readable, and also would be more for users where not have a tech. or programming background.
I wanted to know if we in the ask.fp.o section could agree for a tag, where we could mark quickdocs where need some adjustments ? Not to to tell you, that you would have to change them, more as a mark for new members of the doc-team that they could pick some ask.fp.o cases if they want to try to do something on their own. Or if you need material for the workshops you make for the new members of the team.
I was thinking on something like #quickdoc-edit or so ? What do you think. Would this make sense for a kind of collaboration in between the ask team and the docs-team?
If someone complains about a missing documentation we will invite them to help with creating the missing content. Being more transparent with the whole workflow, to create good docs/quick docs.
Hiya, many thanks for taking time to offer suggestions.
We got to face the fact that articles get outdated and leff unattended and not maintained. That’s why we also call it docs bugs.
Some articles have admonition or header paragraph clearly indicating ‘this article is out of date’. Others may not have that warning at all. I would jump in to update the paragraph containing outdated information (meaning pull requests) if I spotted something that I know very well.
You could also report the issue in Quick Docs repo directly using the magic button on the top right corner of the page.
‘Edit this page’ - middle button
‘Report an issue’ - last button
To be fair, I would disagree with an idea to create another tag in discussion as I have seen lots of suggestions to create all sorts of tags and it is hard to find necessary ones. That is sort of additional layers of efforts, asking people to put another tag.
My aim is to lower burden of super helpers in Ask Fedora and get more done by users self-help.
That’s fine. The idea is not to persuade helpers to go through Docs process and write articles. You already help users a great deal. You don’t have to feel obliged to write articles in Quick Docs.
But please understand it is not entirely Docs team’s role to write, review and maintain Docs. The work has to be spread across various working groups and one-time contributors as well as external contributors (we have some).
stop commenting about how to solve contributor’s pathways and the scope of Quick Docs, so folks in various working groups/SIGs can join our effort to maintain docs.
Discourse ! 
I feel the same way.
