grow-with-open-source/python-projects

1. Repository Role

This is a curated monorepo of independent Python learning projects, designed for open-source contributions and public project discovery. It is not a single deployable application: each top-level project directory generally owns its executable script, dependencies, and optional documentation.

2. Project Execution Boundaries

Projects run independently from their own entry points; there is no shared runtime package or central dispatcher. Examples span CLI, GUI, computer-vision, games, and ML/data workflows:

• CLI/utility scripts: Duplicate-File-Finder/duplicate_finder.py, File_Organizer/file-organizer.py, Web-Blocker/blocker.py

• Interactive apps/games: UNO/app.py, Secure_Password_Manager/gui/password_manager_gui.py, Music-Player/music_player.py

• Vision/automation: Motion-Detection/OpenCvPROJECT.py, Gesture_Volume_Control/volume_control.py, Bowling-Action-Tracking/main.py

Each project’s dependency boundary is local where requirements files exist, e.g. Auto-Clicker/requirements.txt, Titanic-Survival-Prediction/requirements.txt, and Spell-Sense/requirements.txt.

3. Data Science and Model Pipelines

Several directories implement stage-based local data workflows rather than services. Titanic prediction is the clearest pipeline: preprocessing, training, exploration, and prediction are separated in Titanic-Survival-Prediction/preprocess.py, Titanic-Survival-Prediction/train.py, and Titanic-Survival-Prediction/predict.py. Dataset-backed notebook work is isolated in projects such as Weather_Forecasting/Weather_Forecasting.ipynb with CSV inputs under Weather_Forecasting/Datasets/, and credit-card-fraud-detection/DBSCAN_clustering.ipynb.

4. Multi-Module Application Components

Most contributions are standalone scripts, but a few projects have meaningful internal composition:

• Encryption separates algorithm implementations from the executable coordinator: Encryption_Project/main.py, Encryption_Project/encryption/aes.py, Encryption_Project/encryption/sha.py.

• UNO separates application setup, game rules/state logic, deck modeling, and display behavior: UNO/app.py, UNO/deck.py, UNO/logic_rich.py.

• Image watermarking places reusable transformation logic behind an app entry point: Image_watermark_Adder/app.py, Image_watermark_Adder/utils/watermark.py.

5. Documentation and Public Site

The repository itself is published as a Jekyll GitHub Pages site. The root landing/documentation sources are README.md and index.md; Jekyll configuration and HTML customization reside in _config.yml and _includes/head-custom.html. Project folders and their README files are the source content surfaced for visitors, while visual assets are under assets/img.

6. Contribution Metadata Automation

Repository-level automation maintains the contributor-facing catalog and metadata. Scripts in .github/scripts/update_index_md.py and .github/scripts/update_contributors_log.py update site/index and contributor information, with durable contributor data in .github/data/contributors-log.json. These are governance/content-management flows, separate from all project runtimes.

7. CI, Deployment, and External Infrastructure

GitHub Actions is the primary infrastructure boundary. .github/workflows/python-linter.yml validates Python contributions; .github/workflows/deploy-gh-pages.yml deploys the Jekyll site to GitHub Pages. Additional workflows automate PR assignment, labeling, comments, staleness, and contributor-detail updates. External services are GitHub/GitHub Actions, GitHub Pages, and project-specific third-party Python libraries declared per project; no shared backend, database, or API gateway is indicated.