Skip to content

Latest commit

 

History

History
40 lines (27 loc) · 3.22 KB

getting_started.md

File metadata and controls

40 lines (27 loc) · 3.22 KB
Raw
title description keywords author
Getting started
How to get started as a contributor to the project
karolikl

Getting Started

In order for you to get started easily, we have created an overview of how the project is structured and how you can get the application up and running.

If you haven't already familiarized yourself with the Contributor Guide, please do so before proceeding.

Eager to get started right away? Have a look at the example application.

Setting up your development environment

Make sure you have the required development environment set up.

Understanding the project structure

CBS has been divided into 5 bounded contexts (or projects/modules). Each module is isolated from the others, and the communication between them is event-driven. This means that the module you are working in will process incoming events from other modules and emit events for other modules to process.

Source code

Each module has its own subfolder in the Source folder, containing a .sln file. Everything you need to build and run the module can be found within the specified folder for said module.
For example: Everything you need to build and run the "Volunteer Reporting" module, can be found in the Volunteer Reporting folder under Source.

Documentation and backlog

In addition to this, each module has its own documentation and its own backlog. The documentation can be found in the Documentation/Projects folder while the backlog can be found on the GitHub project page.
For example: The documentation for the "Volunteer Reporting" module can be found in the Volunteer Reporting folder. The backlog can be found on the "Volunteer Reporting" project page.

Any issue labeled "good first issue" will be linked to a project/module so that you will be able to find the source code and documentation for the module as explained above.

Next steps

  1. Find an issue you want to work on. Issues labeled "good first issues" are issues that should be relatively easy to get started on without too much background information.
  2. Create a fork. In order to contribute to this project, you will need to fork this repository.
  3. Make changes, test them and ensure the documentation is up to date. All commits SHOULD be related to an issue by adding a #{number of issue} to the comment.
  4. Synchronize your fork. Keep your fork synchronized with the CBS repository to avoid conflicts, as described here.
  5. Create a pull request. Once your changes are ready, create a pull request and reference the issues you have worked on.