Skip to content

Latest commit

 

History

History
79 lines (52 loc) · 4.19 KB

CONTRIBUTING.md

File metadata and controls

79 lines (52 loc) · 4.19 KB
Raw

How to Contribute

Thanks for wanting to contribute to Caliburn.Micro. Contributions don't need to take the form of code, submitting issues and writing documentation is just as important.

Raising Issues

The following information is incredibly helpful when raising issues:

  • Platform(s) - Caliburn.Micro runs on a lot of platforms and is tightly coupled with their UI stacks, knowing which platform or platforms you're experiencing the issue on helps immensely.
  • Steps - Steps on recreating the issue.
  • Sample Project - Even better that reproduction steps is a sample project that highlights the issue.

Getting started with the source

You can clone this repository locally from GitHub using the "Clone in Desktop" button from the main project site, or run this command in the Git Shell:

git@github.com:Caliburn-Micro/Caliburn.Micro.git Caliburn.Micro

If you want to make contributions to the project, forking the project is the easiest way to do this. You can then clone down your fork instead:

git clone git@github.com:MY-USERNAME-HERE/Caliburn.Micro.git Caliburn.Micro

Documentation of building the code is currently available on the Caliburn.Micro website.

How is the codebase organised?

The Caliburn.Micro is broken up into three groups of assemblies.

  • Core - This contains the building blocks of any MVVM solution such PropertyChangedBase, Screen & EventAggregator. It's a Portable Class Library designed to work on as many platforms as possible. However due to some limitations we create the Core assembly for Silverlight 5 and .NET 4.0 separately although they share code using linked files and compilation symbols.
  • Platform - For each platform Caliburn.Micro runs on we have a platform assembly, this contains the code that makes direct use of the appropriate UI stack and any code that could not be made portable. Most of the code is shared between the various platform projects using linked files and compilation symbols.
  • Extensions - For some platforms we have some special features to help development on that particular platform, these features live in the Extensions assembly for any applicable platforms.

Making Changes

When you're ready to make a change, create a branch off the master branch. We use master as the default branch for the repository, and it holds the most recent contributions, so any changes you make in master might cause conflicts down the track.

If you make focused commits (instead of one monolithic commit) and have descriptive commit messages, this will help speed up the review process.

Submitting Changes

You can publish your branch from GitHub for Windows, or run this command from the Git Shell:

git push origin MY-BRANCH-NAME

Once your changes are ready to be reviewed, publish the branch to GitHub and open a pull request against it.

A few little tips with pull requests:

  • prefix the title with [WIP] to indicate this is a work-in-progress. It's always good to get feedback early, so don't be afraid to open the PR before it's "done".
  • use checklists to indicate the tasks which need to be done, so everyone knows how close you are to done.
  • add comments to the PR about things that are unclear or you would like suggestions on

Don't forget to mention in the pull request description which issue/issues are being addressed.

Some things that will increase the chance that your pull request is accepted.

  • Follow existing code conventions. Most of what we do follows standard .NET conventions except in a few places.
  • Include unit tests that would otherwise fail without your code, but pass with it.
  • Update the documentation, the surrounding one, examples elsewhere, guides, whatever is affected by your contribution

Additional Resources