Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/aws-samples/legacy-cycle-store-mvc-app/llms.txt

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

The Legacy Cycle Store MVC App is an open-source AWS sample project and contributions from the community are warmly welcomed. Whether you have spotted a bug, want to improve the documentation, or have an idea for a new feature, there is a clear path for getting your work into the project. This guide explains how to report issues, open pull requests, and follow the community standards that keep the repository healthy and approachable for everyone.

​
Reporting Bugs and Feature Requests

The project uses the GitHub issue tracker as the single source of truth for bugs, feature requests, and improvement suggestions. Before opening a new issue, search the existing list to check whether the problem or idea has already been reported — adding a reaction or a comment to an existing issue is often more effective than creating a duplicate. When filing a bug report, include:
  • Reproducible steps — a minimal sequence of actions that consistently triggers the issue
  • Expected vs. actual behavior — what you expected to happen and what actually happened
  • Code version — the commit SHA or release tag you are running
  • Modifications made — any local changes to the codebase that might be relevant
  • Environment details — OS, .NET Framework version, browser (for UI bugs), AWS region, and RDS engine version
For feature requests, describe the problem you are trying to solve and the solution you have in mind. If there are alternative approaches you considered, mention them so the discussion can start from a well-informed position.

​
Contributing via Pull Requests

1

Work against the latest master branch

Sync your local copy with the upstream master branch before starting any work. Stale branches lead to merge conflicts and may cause you to duplicate changes already landed upstream.
2

Check existing open and merged PRs

Search the pull request list — both open and closed — to confirm that no one else is already working on the same change. This saves you effort and avoids duplicated review cycles.
3

Open an issue for significant work

For anything beyond a small bug fix or typo correction, open a GitHub issue first and describe what you plan to build. This lets maintainers give early feedback on the design and confirm that the change is in scope before you invest significant time writing code.
4

Fork the repository

Create a personal fork of the repository on GitHub, then clone your fork locally. Create a feature branch from master with a descriptive name, e.g. fix/product-filter-null-subcategory or feature/pagination-support.
5

Make focused, reviewable changes

Keep your changes narrowly scoped to the problem at hand. Avoid reformatting unrelated files, renaming variables for style preferences, or mixing unrelated fixes into a single PR. Smaller, focused pull requests are reviewed faster and are easier to revert if a problem is discovered later.
6

Commit with clear messages

Write commit messages that explain why the change was made, not just what changed. A good commit message follows the pattern: a short imperative summary line (50 characters or fewer), a blank line, and then a paragraph of context if the change is non-obvious.
7

Submit the pull request

Push your feature branch to your fork and open a pull request against the upstream master branch. Fill in the PR description with a summary of the change, a link to the related issue, and any testing steps a reviewer should follow to verify the fix or feature.
8

Respond to CI feedback and review comments

Automated checks will run on your PR. Address any failing tests or linting errors promptly. When reviewers leave comments, engage with them constructively — push follow-up commits to the same branch to incorporate feedback rather than opening a new PR.

​
Finding Things to Work On

If you want to contribute but are not sure where to start, browse the GitHub Issues list and look for issues tagged with the following labels:
  • help wanted — issues that maintainers have explicitly flagged as suitable for community contributions
  • bug — confirmed defects that need a fix
  • enhancement — approved feature ideas that have not yet been implemented
  • documentation — improvements or corrections needed in the docs or inline comments
Picking up a help wanted issue is the most reliable way to ensure your contribution will be welcomed, since the need has already been validated by the maintainers.

​
Code of Conduct

All participants in this project are expected to uphold the Amazon Open Source Code of Conduct. The code of conduct applies to all project spaces, including the issue tracker, pull request comments, and any other channels used to discuss the project. You can read the full code of conduct at https://aws.github.io/code-of-conduct. Instances of unacceptable behavior may be reported to the project maintainers. All reports will be reviewed confidentially.

​
Security Issues

Do not create public GitHub issues for security vulnerabilities. Publicly disclosing a security problem before a fix is available puts all users of the project at risk. If you discover a potential security vulnerability — including issues with authentication, SQL injection, credential exposure, or access control — please report it privately through the AWS vulnerability reporting program at https://aws.amazon.com/security/vulnerability-reporting/. The AWS Security team will acknowledge your report, investigate the issue, and coordinate disclosure.

​
License

The Legacy Cycle Store MVC App is released under the MIT No Attribution (MIT-0) license. MIT-0 is a permissive open-source license that allows you to use, copy, modify, merge, publish, distribute, sublicense, and sell the code without any requirement to include attribution or a copyright notice. By submitting a pull request, you confirm that:
  1. You have the right to submit the code under the MIT-0 license.
  2. Your contribution is your original work or you have obtained the necessary rights from the original author.
  3. You agree that your contribution will be licensed under the same MIT-0 terms as the rest of the project.
You do not need to sign a Contributor License Agreement (CLA) to contribute to this project.

Build docs developers (and LLMs) love

Get started for freeTalk to us