BakingTray
  • BakingTray Documentation
  • Getting Started
    • Hardware requirements
    • Known issues
    • Initial Installation
      • Software installation
      • Setting up ScanImage
    • Hardware setup
      • Motor Setup
        • PI stage setup
        • Calibrating a linear actuator
        • Verifying stage motions
      • Setting up a VT1000 vibratome
      • Setting up the laser
    • Finishing the install
      • Check the noise on your amplifiers
      • Starting BakingTray
      • Settings Files
      • Calibration
        • Basic calibrating procedures
        • Calibrating image size
        • Achieving high stitching accuracy
        • Fine-tuning positioning accuracy
        • Stitching tweak walkthrough
    • Stitching data
  • Users
    • Introduction
    • Sample preparation
    • User Guide
      • Starting BakingTray
      • Step 0: Loading the sample
      • Step 1: Setting imaging parameters
      • Step 2: Preparing the sample
      • Step 3: Selecting the imaging area
      • Step 4: Starting the acquisition
      • Step 5: Concluding the acquisition
      • Setting up checklist
      • Resuming an acquisition
      • Manual ROI acquisitions
    • Excitation choices
    • Choosing imaging settings
    • Troubleshooting
      • Hardware problems
      • Computer problems
      • Cutting problems
      • Imaging problems
    • Data structure
    • autoROI
  • Developers
    • Developers
      • Code overview
      • Developer notes
      • Motion control classes
      • The recipe file
      • Auto-ROI
      • Simulated mode
      • Contributing
    • FAQ
    • Gallery
Powered by GitBook
On this page
  1. Developers
  2. Developers

Contributing

PreviousSimulated modeNextFAQ

Last updated 4 years ago

Contributions to BakingTray are welcome.

  • You should and keep your fork up to date .

  • New functions you add should have detailed help text like that in

  • If you modify the arguments in an existing function you should also update the function's help text.

  • Many small commits are better than single big ones.

  • Keep your pull requests clean. e.g. do not include commented-out test code, temporary functions, or highly specialised functions such as BakingTray_forMyRigOnTuesdays.m.

  • Do not add your own INI files, recipe files, or other settings files. The SETTINGS and SETTINGS_BACKUP directories must be empty but for the .gitignore file.

  • Use spaces instead of tabs for indenting.

Branches

Development is distributed across three branches:

  • master - Finalised code ready to be shared with others. Must be stable. Merge into here from prerelease.

  • prerelease - Tested code that can be run on a live system but may have bugs. Merge into here from dev.

  • dev - All development goes here. Unstable.

You should keep the number of commits low on master and prerelease. The development cycle goes as follows.

  • Check out dev and ensure it's up to date with master and prerelease.

  • Make changes and commit to dev.

  • Perform basic tests. e.g. ensure no obvious bugs are present. Run any unit tests, should they be available, or write unit tests.

  • List changes in the changelog. Assume the changelog will be read by users.

  • Merge to prerelease with a merge-commit to keep things neat.

  • Run the system on prerelease for a time to ensure no regressions are present.

  • Merge prerelease into master with a merge-commit to keep things neat in the master branch.

fork the repository and send contributions as a pull request
or it will become difficult to merge your changes
stitchSection.m