I feel like we kind of lost a little bit of focus and the message intended.
I think we need something like this:
There are many powerful application software for the Linux OS. One can find an equivalent for almost any application used on other systems on a variety of sources. We give here an overview and a guide to the installation.
Sources of Applications
Characteristic: Pure Open Source, QA by Fedora team, RPM format
Characteristic: TPD (don’t know)
Third Party RPM Repositories
Characteristics: Adjusted to Fedora or generic RPM, not as strict OSS as Fedora.
(List of 3rd party repos)
RPM downloads from project site
Foreign Repositories, e.g. deb
Brief discussion pros and cons, possible recommendation, note on precautions. Reference to the workstation debate about third party repos and the solution agreed to.
(Description, maybe Link to an Article “Using Gnome Installer”)
(Description, maybe Link to an Article “Using KDE Installer”)
Installing from source
(Short description, Link to Article)
Command line installation
It would be kind of combination of the old and the new version of the article.
What you suggests overlaps with various pages in the ‘Adding and managing software’ section. There are dedicated pages on repo, flatpaks, COPR, thirdparty repo. My suggestions in issue list were made after hours of testing and gap analysis.
To avoid duplication of efforts and contents, we need to address the previous comments left in the issue board. And after hours of reflection, I suggested ToC and how-to-guide rather than tutorial.
Could we wait for more comments and you can revert it to previous state.
Yes, I know. But we lack an article which provides an overview and some overall guidance. Maybe, we should make the section title “Adding and managing software” into an overview article with annotated links to the several details article.
Revert to previous state is not the solution. Maybe, we should turn the “Finding and installing …” article into 2 articles: “Managing applications with Gnome” and “Managing applications with KDE”.
The first three sections (package management system, dnf package manager, Fedora repositories) serve as introduction, which don’'t tell readers ‘how to’. This is exact opposite to what you pointed out, to be fair. So many intro, not enough how to.
Upstream docs on GNOME Software and KDE Discover were exactly the same - abundance of intro and not enough hands-on material.
I see latest articles have the overview section briefly. I’m rather careful of use of links overall as it can look messy and theoretical article/CS101 (first day). Rationales of links as content reuse seem plausible. But in reality, links used in abundance mean the article is not self-contained.
I also noticed recent pattern of its use on header or on reference section.
Ok, we gotta meet somewhere in the middle. I’ll dwell on how to restructure the article and many procedures I have to tackle for successful PR.
Not a bad idea to include a section on common language specific installers. In particular, pip comes up regularly on ask.fp.o and a best prescribed guide for using venv or toolbox for installing this way would be very useful. I feel like I often end up typing out the same things about this over and over, so having a well written stub for it would be helpful. It’s not specific to python, as ruby also comes up, but the gist is the same - use rvm or a container, etc, so you don’t risk conflicting with dnf installed libraries.
Thanks for your suggestion. There are dedicated pages and Fedora developer portal on language specific installers.
@pboy@darknao Suggestions made here converge upon existing QuickDoc articles. Splitting #521 into small pieces isn’t the answer for scope creep because we will see more duplicated content. We also need to consolidate some of old articles into new pages.
As a side, we need content review across multiple teams to have consistent content and reduce duplicate knowledge across other team pages and the Developer Portal. It sounds overwhelming, but if we include one other team that converges on a new article we produce, that’ll do.
Desktop specific GUI installers (GNOME Software, KDE Discover): Workstation SIG
Could there be notes added on which should be the most secure sources to the least secure? For example, and feel free to disagree, I think the Fedora repos are the most secure, followed by Flathub. After that a user should have more caution about using repos from any other source. There could be a blurb about what to look out for when deciding if an app is trustworthy (do you trust the developer, community, reputation of the app, etc). After that would be other sources to look like the Copr repos and other third party repos. Yes, there are lots of ways to get what you need, but you can’t trust all places equally.
I figure it’s still worth mentioning on a potential “how to install Linux applications” page, especially because there you can provide context for how trustworthy to consider each source in relation to others. It could also consist of just a little text box. But if that doesn’t happen it’s not the end of the world.
Relevant sections already have put provisos here. The term ‘secure’, ‘trustworthy’ , ‘blob??’ does not appear suited to ‘how-to’ guides. I’m also wary of many overused ‘call-out’ in the articles that get in the way of flow of reading. The Fedora documentation style guide also puts it;
Use Admonitions very sparingly
They strongly interrupt the reading flow and thus make it difficult to grasp a section of text or even the article as a whole in a meaningful way.
It’s a matter of displaying opinions and I have no means to agree with yours.
The six pages under the section “Adding and managing software” are loosely coupled, but incoherently progress page to page. This means we need to take into account those pages as ‘one intro chapter’ followed by repo types, but not in silo. I have noticed some duplication of content across the initial six pages.
I’m not saying that my latest commit was a better option. But it is rather ‘renovation’ that I hoped it to blend in. I admit I made a mistake to edit the source file directly as I was struggling with Pagure PR process. Now, it is solved following a shallow learning curve. I’ll keep to the best practice next time.
What bothers me is one super comprehensive update on #521 as recommended by community members here and @pboy would stick out of the entire section. To put it another way, it does not blend in but might look patched up if we push a comprehensive #521. That’s where my gut reaction kicked in to resist scope creep and pause.
We need to be aligned with the expectation.
Then we can reach a consensus on synopsis and break them down to pieces.
I think I need some more volunteers and co-authors who are interested in reorganizing this section and revise them in its entirety together. As these pages are closely related to Workstation/Spins/Labs, I think it will be effective to work cross-team.
If you are not sure about this, can we chat over the phone when you are free after FOSDEM? I’m new here, but sometimes struck by the wall of text in spite of best intention and appreciation of async communication. Best if I could go over to FrOssDEM, but I have other commitments this weekend.