Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/FranksGP/Gestor_de_tareas/llms.txt

Use this file to discover all available pages before exploring further.

Gestor de Tareas is an open, collaborative project — and new contributors are very welcome. The application was born as a university workshop that placed Git and GitHub workflows at the centre of its development process, so contributing follows the same collaborative spirit the project was built on. Whether you want to fix a bug, improve the user experience, or tackle one of the planned features from the roadmap, this guide walks you through everything you need to get started.

​
Getting the code

1

Fork the repository on GitHub

Visit https://github.com/FranksGP/Gestor_de_tareas and click Fork in the top-right corner. This creates your own copy of the repository under your GitHub account where you can freely experiment.
2

Clone your fork

Pull your fork down to your local machine so you can make changes:
git clone https://github.com/<your-username>/Gestor_de_tareas.git
cd Gestor_de_tareas
Replace <your-username> with your actual GitHub username.
3

Create a feature branch

Never work directly on main. Create a dedicated branch with a descriptive name that reflects your change:
git checkout -b feature/my-improvement
For bug fixes you can use the prefix fix/, for example fix/invalid-index-message.

​
Code style

Gestor de Tareas is a single-file Python project (index.py, roughly 70 lines). Keeping that simplicity intact is a goal in itself. Follow these guidelines when writing or modifying code:
  • Spanish naming convention for functions. Existing functions use a camelCase blend with Spanish vocabulary — cargarTask, guardarTask, agregarTask, listarTask, tareaCompletada. New functions should follow the same pattern so the codebase stays internally consistent.
  • Single responsibility per function. Each function does exactly one thing: cargarTask reads from disk, guardarTask writes to disk, and so on. Do not combine multiple concerns inside a single function.
  • User-facing messages in Spanish. All print() calls and input() prompts must be written in Spanish to stay consistent with the existing UI (e.g. "Tarea agregada exitosamente.", "Opción inválida, intente de nuevo.").
  • Standard library only. The project intentionally uses only json and os from the Python standard library. Avoid introducing third-party dependencies unless there is a compelling reason — and if you do, open an issue to discuss it first.

​
Running the project

Because Gestor de Tareas relies exclusively on the Python standard library, there is no installation step, no virtual environment to activate, and no packages to install. Simply run: 
python index.py
The program creates Tareas.json in the current directory on first use and reads from it on every subsequent run. Python 3.13 or newer is recommended (as noted in the project README), though any modern Python 3 release should work fine.

​
Submitting a pull request

Once your changes are working as expected, push your branch and open a pull request against the main branch of the upstream repository. A few things to keep in mind before you submit:
  • Write descriptive commit messages. Each commit should explain what changed and why, not just how. Prefer messages like "Add input validation for empty task titles" over "fix bug".
  • Test your changes manually. Run python index.py and walk through the full menu — add a task, list tasks, mark one complete, delete one, then exit. Make sure nothing you changed broke an existing flow.
  • Keep the diff focused. A pull request that does one thing is much easier to review than one that mixes several unrelated changes.
If you are planning a large or structural change — such as adding a new menu option, changing the storage format, or refactoring multiple functions — please open a GitHub Issue first to discuss the approach before writing the code. This saves everyone time and avoids duplicated effort.
The original workshop brief asked each contributor to make at least 6 commits with clear, meaningful messages. Even outside the workshop context this is good practice: small, well-described commits make the project history easier to follow and pull requests easier to review.

Build docs developers (and LLMs) love

Get started for freeTalk to us