Skip to content

contributing.md

Latest commit

 

History

History
248 lines (190 loc) · 5.95 KB

contributing.md

File metadata and controls

248 lines (190 loc) · 5.95 KB
Raw

Contributing Guide

Thank you for your interest in contributing to Life in Between XR! This guide will help you get started.

Table of Contents

Code of Conduct

  • Be respectful and inclusive
  • Welcome newcomers and help them learn
  • Focus on constructive feedback
  • Respect different viewpoints and experiences

Getting Started

  1. Fork the repository on GitHub
  2. Clone your fork: 
    git clone https://github.com/YOUR_USERNAME/XRTrainRide.git
cd XRTrainRide
  3. Add upstream remote: 
    git remote add upstream https://github.com/Caerii/XRTrainRide.git
  4. Set up the project (see Setup Guide)
  5. Create a branch for your work: 
    git checkout -b feature/your-feature-name

Development Workflow

Branch Naming

  • feature/ - New features
  • fix/ - Bug fixes
  • docs/ - Documentation updates
  • refactor/ - Code refactoring
  • test/ - Test additions/updates

Commit Messages

Follow conventional commit format:

type(scope): subject

body (optional)

footer (optional)

Types:

  • feat: New feature
  • fix: Bug fix
  • docs: Documentation
  • style: Formatting
  • refactor: Code refactoring
  • test: Tests
  • chore: Maintenance

Example:

feat(search): Add autocomplete filtering by transit line

Implemented filtering of search results based on selected
transit line to improve relevance of location suggestions.

Keeping Your Fork Updated

git fetch upstream
git checkout main
git merge upstream/main
git push origin main

Coding Standards

C# Style Guide

  • Naming Conventions:

    • Classes: PascalCase (e.g., LineSelector)
    • Methods: PascalCase (e.g., SelectLine)
    • Variables: camelCase (e.g., selectedLine)
    • Constants: UPPER_CASE (e.g., MAX_LINES)
    • Private fields: m_camelCase or _camelCase

  • File Organization:

    • One class per file
    • File name matches class name
    • Scripts in Assets/Scripts/

  • Code Formatting:

    • Use 4 spaces for indentation
    • Use braces for all control structures
    • Add XML comments for public APIs

Unity-Specific Guidelines

  • Component Organization:

    • Use [SerializeField] for private fields exposed in Inspector
    • Use [Header] and [Tooltip] attributes for better Inspector UX
    • Keep MonoBehaviour scripts focused and single-purpose

  • Performance:

    • Cache component references in Awake() or Start()
    • Avoid FindObjectOfType() in Update()
    • Use object pooling for frequently instantiated objects
    • Minimize allocations in hot paths

  • Scene Organization:

    • Use clear, descriptive GameObject names
    • Organize hierarchy logically
    • Use empty GameObjects as containers when needed

Example Code

using UnityEngine;

/// <summary>
/// Manages transit line selection and state.
/// </summary>
public class LineSelector : MonoBehaviour
{
    [Header("Line Configuration")]
    [Tooltip("List of available transit lines")]
    [SerializeField] private List<Line> m_linesList;

    /// <summary>
    /// Selects a transit line and deselects all others.
    /// </summary>
    /// <param name="selectedLineName">Name of the line to select</param>
    public void SelectLine(string selectedLineName)
    {
        if (string.IsNullOrEmpty(selectedLineName))
        {
            Debug.LogWarning("Line name cannot be null or empty");
            return;
        }

        foreach (Line line in m_linesList)
        {
            line.selected = line.name == selectedLineName;
        }
    }
}

Pull Request Process

Before Submitting

  1. Update documentation if you've changed functionality
  2. Add tests if applicable
  3. Test on target devices (ARCore-compatible Android device)
  4. Ensure code compiles without warnings
  5. Follow coding standards

PR Checklist

  • Code follows project style guidelines
  • Self-review completed
  • Comments added for complex code
  • Documentation updated
  • No new warnings generated
  • Tested on target device
  • Changes tested in relevant scenes

PR Description Template

## Description
Brief description of changes

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update

## Testing
How was this tested?

## Screenshots (if applicable)
Add screenshots for UI changes

## Checklist
- [ ] Code follows style guidelines
- [ ] Self-review completed
- [ ] Documentation updated
- [ ] Tested on device

Testing Requirements

Before Submitting

  1. Test in Unity Editor:

    • Open relevant test scenes
    • Verify functionality works as expected
    • Check for console errors/warnings

  2. Test on Device:

    • Build and deploy to ARCore-compatible device
    • Test AR functionality
    • Verify performance is acceptable
    • Test on different Android versions if possible

  3. Test Scenes:

    • Test00_Autocomplete.unity: Test autocomplete features
    • Test01_3dMap.unity: Test 3D map rendering
    • Scene00_MainMenu.unity: Test main menu flow

Test Coverage

  • New features should include basic test scenarios
  • Bug fixes should include regression tests
  • AR features must be tested on physical devices

Review Process

  1. Automated Checks: PRs are checked for build success
  2. Code Review: At least one maintainer reviews
  3. Testing: Reviewer may test on device
  4. Feedback: Address any requested changes
  5. Merge: Once approved, PR is merged

Questions?

Thank you for contributing to Life in Between XR!