Renamed generators to generation and added to ARCHITECTURE.md

.github/workflows/generate-readme.yml

@@ -30,7 +30,7 @@ jobs:
         run: pip install -r requirements.txt || true
 
       - name: Run script to generate README
-        run: python ./source/scripts/generators/readme_generator.py
+        run: python ./source/scripts/generation/readme_generator.py
 
       - name: Commit and push changes
         run: |

resources/PORTAL.md

@@ -0,0 +1,16 @@
+
+# The Portal
+The place that connects everything related to definitive-opensource.
+
+### Lists
+[ALL](README.md)
+[Windows](readmes/windows.md)
+[MacOS](readmes/macos.md)
+[Linux](readmes/linux.md)
+[Selfhost](readmes/selfhost.md)
+
+### Contributing
+
+### Development
+
+## GitHub Actions

resources/dev/ARCHITECTURE.md

@@ -1,4 +1,17 @@
 
-## Architecture
+# Architecture
 Here's a look at how the "backend" of the list works. 
 
+## README Generation
+All applications are stored inside [```applications.json```](source/data/applications.json). Categories are declared inside [```categories.json```](source/data/categories.json). Instead of a nested format with subcategories as on object of it's parent, we've given subcategories a ```parent``` attribute. There's also a [```tags.json```](source/data/tags.json). Instead of putting the emoji inside of the ```tags``` attribute in ```applications.json```, the id is used, for example, ```commercial``` or ```disruptive```.. These id's are mapped to their corresponding emoji for when the READMEs are generated and makes ```applications.json``` more readable. 
+
+The generation scripts are inside of the [```source/scripts/generation```](source/scripts/generation) directory. [```mainheader_generator.py```](source/scripts/generation/mainheader_generator.py) generates the very top header with the dynamic project count. Then, depending on the platform being generating, it inserts [```header.md```](source/components/header.md), [```macosheader.md```](source/components/macosheader.md), etc. [
+
+[```tableofcontents_generator.py```](source/scripts/generation/tableofcontents_generator.py) generates the table of contents. It creates one, expandable but hidden by default, with all subsections listed alphabetically. The default TOC shows parent categories alphabetically with subcategories underneath, also alphabetically.
+
+```contents_generator.py```](source/scripts/generation/contents_generator.py) generates the actual list.
+
+Lastly [```readme_generator.py```](source/scripts/generation/readme_generator.py) brings everything together, calling the other scripts to generate one main list, and more for several platforms. 
+
+## Maintenence
+[```applications.json```](source/data/applications.json) stores a lot of information that the README does not display such as last commit, language, and license. These are for a future web version of the list that would pull data from the json file. [```stats_updator.py```](source/maintenance/stats_updator.py) runs every midnight and updates all application stats. Each application object in the json file also has a ```flags``` attribute. For example, the ```custom-description``` flag tells the stats_updator script to skip updating the description for that app. For more into on flags, consult the [```DOCS.md```](resources/DOCS.md)

source/components/footer.md

@@ -32,11 +32,11 @@ The current system could also be considered a stepping stone to guage the commun
 
 <details>
   <summary><b>Stars aren't a good metric to guage popularity/quality.</b></summary> <br />
-The minimum star count of 1k has been a major point of contention. Admittedly, star counts don't always reflect project popularity and quality. Stars are biased towards developers because they are the ones with a GitHub account, thus leaving out the input of the end users. But no solution is going to be a __one size fits all__ solution. It's critically important that as the list scales it doesn't devolve into a clutter trap, even if the price is some projects getting left out.
+The minimum star count of 1k has been a major point of contention. Admittedly, star counts don't always reflect project popularity and quality. Stars are biased towards developers because they are the ones with a GitHub account, thus leaving out the input of the end users. But no solution is going to be a one size fits all solution. It's critically important that as the list scales it doesn't devolve into a clutter trap, even if the price is some projects getting left out.
 <p>&nbsp;</p>
 Stars tend to be synonomous with community recognition, making it a good starting point for further vetting to check for contributors, future plans, and popularity. Most compotent software will have no trouble reaching the 1k star count. This requirement is also just the first step for further vetting.
 <p>&nbsp;</p>
-Artificial star counts (EX: buying stars) has also been brought up. This isn't that big of a problem, again, stars are just to quality a project for further vetting. A popular project should have lots of community activity, GitHub issues, pr's, etc. Evidence of foul play will disquality a project. 
+Artificial star counts (EX: buying stars) has also been brought up. This isn't that big of a problem, again, stars are just to quality a project for further vetting. We check community engagement, developer responsiveness and the project's statistics over time. A popular project should have lots of community activity, GitHub issues, pr's, etc. Evidence of foul play will disquality a project. 
 </details>
 
 ## License