Skip to main content

​
Welcome Contributors!

Thank you for your interest in contributing to OdontologyApp! This guide will help you get started with the development workflow and best practices.

​
Code of Conduct

By participating in this project, you agree to maintain a professional and respectful environment for all contributors.

​
Getting Started

Before contributing, make sure you have:
  1. Set up your development environment - Follow the Setup Guide
  2. Familiarized yourself with the codebase - Browse the Architecture documentation
  3. Checked existing issues - See if your idea or bug is already being discussed

​
Development Workflow

1

Fork and Clone

Fork the repository and clone it to your local machine:
git clone <your-fork-url>
cd OdontologyApp2
git remote add upstream <original-repo-url>
2

Create a Feature Branch

Create a new branch for your feature or fix:
git checkout -b feature/your-feature-name
# or
git checkout -b fix/your-bug-fix
Branch naming conventions:
  • feature/ - New features
  • fix/ - Bug fixes
  • refactor/ - Code refactoring
  • docs/ - Documentation updates
  • test/ - Test additions or modifications
3

Make Your Changes

Implement your changes following the code style guidelines below. Test thoroughly before committing.
4

Commit Your Changes

Write clear, descriptive commit messages:
git add .
git commit -m "feat: add patient search functionality"
Commit message format:
  • feat: - New feature
  • fix: - Bug fix
  • refactor: - Code refactoring
  • docs: - Documentation changes
  • style: - Code style changes (formatting, etc.)
  • test: - Adding or updating tests
  • chore: - Maintenance tasks
5

Push and Create PR

Push your changes and create a pull request:
git push origin feature/your-feature-name
Then open a pull request on GitHub with:
  • Clear title describing the change
  • Detailed description of what and why
  • Screenshots for UI changes
  • Reference to related issues

​
Code Style and Conventions

​
JavaScript/Svelte Style

  • Use JSDoc for type annotations
  • Follow camelCase for variables and functions
  • Use PascalCase for Svelte components
  • Prefer const over let when possible
  • Use template literals for string interpolation
  • Keep functions small and focused
<script>
  // Component props with JSDoc
  /** @type {string} */
  export let title;
  
  /** @type {() => void} */
  export let onClick;
  
  // Local state
  let count = $state(0);
  
  // Computed values
  let doubled = $derived(count * 2);
</script>

<button on:click={onClick}>
  {title}: {count}
</button>

<style>
  button {
    /* Component-scoped styles */
  }
</style>
  • Use proper HTTP methods (GET, POST, PUT, DELETE)
  • Return consistent JSON responses
  • Include proper error handling
  • Validate input with Zod schemas
import { json } from '@sveltejs/kit';
import { pool } from '$lib/server/db';

export async function GET({ params }) {
  try {
    const [rows] = await pool.query(
      'SELECT * FROM patients WHERE id = ?',
      [params.id]
    );
    
    if (rows.length === 0) {
      return json({ error: 'Patient not found' }, { status: 404 });
    }
    
    return json({ patient: rows[0] });
  } catch (error) {
    console.error('Error fetching patient:', error);
    return json({ error: 'Internal server error' }, { status: 500 });
  }
}
  • Always use parameterized queries to prevent SQL injection
  • Use the connection pool from $lib/server/db
  • Handle errors appropriately
  • Close connections properly (pool handles this automatically)
// Good: Parameterized query
const [rows] = await pool.query(
  'SELECT * FROM patients WHERE cedula = ?',
  [cedula]
);

// Bad: String concatenation (SQL injection risk)
const [rows] = await pool.query(
  `SELECT * FROM patients WHERE cedula = '${cedula}'`
);

​
Permission Checking

Always check user permissions before allowing access to sensitive operations: 
import { checkPermission } from '$lib/server/checkPermission';
import { PERMISSIONS } from '$lib/permissions';

export async function load({ locals }) {
  // Check permission
  await checkPermission(locals.user, PERMISSIONS.VIEW_PATIENTS);
  
  // If permission check passes, continue...
  // If not, it throws an error automatically
}
Available permission constants can be found in src/lib/permissions.js.

​
Testing Requirements

Before submitting your pull request: See the Testing Guide for more details on testing approaches.

​
Pull Request Process

1

Self-Review

Review your own changes before submitting:
  • Check for console.log statements to remove
  • Verify code formatting is consistent
  • Ensure no unnecessary files are included
2

Update Documentation

If your changes affect:
  • API endpoints - Update API documentation
  • User features - Update user guides
  • Developer setup - Update this contributing guide
3

Submit PR

Create a pull request with:Title: Clear, descriptive summaryDescription:
## What
Brief description of the change

## Why
Explanation of why this change is needed

## How
Technical details of implementation

## Testing
Steps to test the changes

## Screenshots
(If applicable)

Closes #issue-number
4

Code Review

  • Respond to feedback promptly
  • Make requested changes
  • Push updates to the same branch
  • Be open to suggestions and discussions
5

Merge

Once approved, a maintainer will merge your PR. Thank you for your contribution!

​
Areas for Contribution

Here are some areas where contributions are especially welcome:

Bug Fixes

Help identify and fix bugs in the application

Features

Implement new features from the roadmap

Testing

Add unit tests and integration tests

Documentation

Improve or add to the documentation

Performance

Optimize queries and improve load times

Accessibility

Improve accessibility for all users

Security

Identify and fix security vulnerabilities

UI/UX

Enhance the user interface and experience

​
Questions?

If you have questions about contributing:

​
License

By contributing, you agree that your contributions will be licensed under the same license as the project. Thank you for helping make OdontologyApp better!

Build docs developers (and LLMs) love

Get started for freeTalk to us