Preview: https://asamalik.fedorapeople.org/modularity-docs-homepage-pr/modularity/

cc @sgallagh @psabata @langdon @ignatenkobrain @jmracek @dmach @tbowling

I think this is an improvement. My first response is to elaborate further on the end user experience, but I'm not entirely sure if that is appropriate or if I am biased towards the SysAdmin user experience and ignoring the developer user experience.

What I mean is this user story:

As a Fedora Desktop or Server user, I need more choices of options for the workloads that are important to me. This may include:

1. I need the latest version of xyz-20 for "some reason"
2. I need to upgrade from Fedora 29 to 31, but my application still needs a previous version of postgresql database. I would like to upgrade to the latest Fedora 31 to benefit from security updates and more, but my application is not yet ready to handle schema changes.

Item 1 above continues to provide some of the "latest features" that Fedora has already provided. However, this is very disruptive to many users and cited as one of the reasons many users use Ubuntu LTS or CentOS - they need more stability. Thus, item 2 serves to provide a level of stability more similar to Ubuntu LTS (though certainly not the same). And Item 2 mandates that stream switching must be decided on and approved by the user, else we risk breaking the workload they care about.

I'm not sure if this could be simplified into this overview message, or if this should exist in other, more detailed use case scenarios or FAQ. I think the last section on Compatibility touches on this but is less obvious that Modularity cannot break the sane distribution principles.

I think mentioning "Rawhide" in the first paragraph might be confusing. This page should probably be accessible to new Fedora users who may not know what that is (especially if we're mentioning it to tell them to stop using it).

I think Terry has a point, though. If we want to introduce users to the concepts, it might be best to have this front page walk them through one or two examples. Maybe talk about wanting to deploy an application on FN that needs a newer database than the default, but then later talk about upgrading to FN+2 which requires one even newer than that.

Thanks for the feedback @tbowling and @sgallagh! Initially I thought that introducing examples this early would make that page too long, but I played with it and it actually looks good. So I've updated the PR and the preview.

Since I'll be on vacation for the next two weeks, could someone please merge if this looks OK?

Also, I'm planning a new "Why modules?" section in the menu that would explain which problems modules solve and which they don't, and some guidance for packagers, using specific examples, that should help them with their "module architecture", for a lack of a better term. Or it could show that modules don't solve their particular problem, that's fine too, and I believe that being explicit helps.

But I don't have time left for this before my vacation, so if someone else wants to look into this, that would be great! Otherwise I'll continue when I'm back.

So I guess I should just merge this? :-)