Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Gurneet1928/TryMLEasy/llms.txt

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

TryMLEasy is an open-source project that welcomes contributions of all kinds — bug reports, feature requests, code improvements, and documentation updates. Whether you’re fixing a typo, proposing a new ML model, or redesigning a page workflow, every contribution helps make TryMLEasy more useful for the no-code machine learning community.
The TryMLEasy repository is hosted at https://github.com/Gurneet1928/TryMLEasy. You’ll need a GitHub account to open issues or submit pull requests.

​
Ways to Contribute

There are several ways to get involved with TryMLEasy, regardless of your experience level:

Report a Bug

Found something broken? Open a GitHub issue with steps to reproduce so the team can investigate and fix it quickly.

Request a Feature

Have an idea for a new model, preprocessing technique, or UI improvement? Share it as a GitHub issue or check Improvement.txt for existing ideas to build on.

Submit a Pull Request

Fork the repo, make your changes on a new branch, and open a PR to main with a clear description of what you’ve changed and why.

Improve Documentation

Help clarify the README, add inline code comments, or expand this documentation site to make TryMLEasy easier to understand for new users.

​
Reporting Issues

Before opening a new issue, a quick search can save everyone time by avoiding duplicate reports.
1

Search existing issues

Visit the GitHub Issues page and search for keywords related to your bug or request. If an open issue already covers it, add a comment with any additional context rather than opening a duplicate.
2

Open a new issue with a clear title

If no existing issue matches, click New Issue and give it a short, descriptive title — for example, Dataset not retained when navigating back to main page rather than bug with upload.
3

Fill in the issue details

Include as much of the following as possible so the issue can be reproduced and resolved efficiently:
  • Steps to reproduce — a numbered list of exactly what to do to trigger the bug
  • Expected behavior — what you expected to happen
  • Actual behavior — what actually happened, including any error messages
  • Environment details — Python version, operating system, browser (if relevant), and Streamlit version
  • Screenshots — attach any screenshots or screen recordings that illustrate the problem

​
Submitting a Pull Request

Pull requests are the primary way code changes reach TryMLEasy. Follow these steps to make sure your PR is easy to review and merge.
1

Fork the repository

Navigate to https://github.com/Gurneet1928/TryMLEasy and click Fork to create your own copy of the repository under your GitHub account.
2

Create a new branch from main

Clone your fork locally and create a dedicated branch for your change. Using a descriptive branch name keeps the history readable:
git checkout -b feature/your-feature-name
For bug fixes, prefer a fix/ prefix:
git checkout -b fix/dataset-session-state
3

Make your changes with clear commit messages

Implement your feature or fix, then commit with a message that explains what changed and why:
git commit -m "Persist uploaded dataset in session_state on main page"
Avoid large, all-in-one commits — smaller, focused commits make review much easier.
4

Test your changes by running the app

Verify that the app starts and your changes work as expected before submitting:
streamlit run home_page.py
Step through the affected pages manually and confirm existing workflows are not broken.
5

Submit the pull request to main

Push your branch to your fork and open a pull request targeting the main branch of the upstream repo. In the PR description, include:
  • A summary of what the change does
  • The motivation or problem it solves
  • Any relevant issue numbers (e.g., Closes #42)
  • Screenshots of UI changes, if applicable

​
Code Style Guidelines

TryMLEasy does not enforce a strict linter, but following the conventions already present in the codebase keeps the project consistent and readable.
  • Follow existing patterns — look at home_page.py and the files inside pages/*.py to understand how pages are structured, how st.session_state is used, and how components are laid out before adding new code.
  • Use meaningful variable names — X_train, scaler, features, and target are examples of names already used in the project. Avoid single-letter names outside of short loop counters.
  • Comment complex logic — if a block of code does something non-obvious (e.g., reconstructing a Keras model from a session-state dataframe), add a brief comment explaining the intent.
  • Keep page modules focused — each file in pages/ corresponds to a single step in the ML workflow. New functionality that spans multiple steps should be carefully scoped to avoid tight coupling between pages.

​
Documentation Contributions

Good documentation is just as valuable as good code. Here’s how you can help on the documentation side:
  • README updates — if you add a new model, preprocessing method, or feature, update README.md to reflect it. The supported features lists and usage steps should stay in sync with the actual app.
  • Inline comments — adding docstrings or short inline comments to existing functions helps new contributors understand the codebase faster.
  • This documentation site — if you spot missing pages, outdated screenshots, or unclear explanations here, open an issue or PR just as you would for a code change.
For any questions not covered here, feel free to email the project maintainer directly at gurneet222@gmail.com.
The best place to find ready-made contribution ideas is the Improvement.txt file in the root of the repository. It lists planned enhancements across every page of the app — from UI themes and caching improvements to new layer types and encoding methods. Pick anything that interests you and open a PR!

Build docs developers (and LLMs) love

Get started for freeTalk to us