Этот документ помогает держать публичные описания репозиториев в едином коммерческом стиле.
| Репозиторий | Позиционирование | Что сделать |
|---|---|---|
AI_TRADING_BOT |
Главный private case study по Python, ML, data engineering, backend и trading infrastructure. | Держать private до очистки и стабилизации публичного README. Пока использовать профильный case study. |
DataScientist_at_SENATOROVAI |
Учебное портфолио по Data Science. | Добавить чистый README: структура курса, notebooks, навыки, выбранные результаты. |
Data-Science-For-Beginners-from-scratch-course |
Forked learning material. | Не делать главным проектом, если нет явно выделенной собственной работы. |
Outsourcing_-26 |
Потенциальное workspace для коммерческого портфолио или outsourcing материалов. | Добавить README перед pin. Переименовать, если репозиторий станет публичной витриной. |
python-open-source-standards-course |
Практика Python quality и open-source standards. | Использовать как supporting repo, не как главный коммерческий кейс. |
Описание должно коротко отвечать: что это, какую задачу закрывает и какой стек показывает.
Adaptive ML-first trading infrastructure: MOEX/Finam ingestion, feature pipelines, dataset artifacts, offline training, validation, and FastAPI services.
Suggested topics:
python, machine-learning, trading, data-pipeline, fastapi, postgresql, pytorch, rabbitmq
Data Science learning portfolio with Python practice, notebooks, statistical analysis, and applied ML exercises.
Suggested topics:
python, data-science, machine-learning, notebooks, portfolio
Outsourcing portfolio workspace for commercial development materials, project presentation, and client-facing delivery structure.
Suggested topics:
portfolio, outsourcing, documentation, commercial
Python open-source quality practice: PEP 8, documentation standards, tests, linters, and maintainable project conventions.
Suggested topics:
python, open-source, pep8, testing, linting
Первый экран каждого репозитория должен отвечать на вопросы:
- какую проблему решает проект;
- для кого он сделан;
- что уже реализовано;
- как его запустить или проверить;
- какой стек и инженерный уровень он демонстрирует.
Закреплять стоит не больше шести репозиториев. Не стоит закреплять пустые, непонятные, fork-only или work-in-progress репозитории, если README не объясняет их ценность.