Skip to content

Latest commit

 

History

History
90 lines (66 loc) · 4.99 KB

CONTRIBUTING.md

File metadata and controls

90 lines (66 loc) · 4.99 KB
Raw

How to contribute

CSLA .NET is developed and maintained by a global development team composed of volunteers. We welcome your help!

Read this entire document before starting any work.

Getting started

  1. Review the Code of Conduct
  2. Make sure you have a GitHub account
  3. Download, print, sign, scan, and return the contributor agreement (CLA)
  4. Engage
    1. Bring up your idea in a Discussion and talk it through with the community
    2. Join the Discord server and talk it through there
    3. Submit an Issue for your suggestion; check first to see if one already exists
  5. For beginners we suggest
    1. This online course on contributing to OSS projects on GitHub
    2. This excellent blog post on Being a good open source citizen
    3. Information on the CSLA git flow used on this project

Contributor Agreement (CLA)

  • Print, sign, and email the contributor agreement document to Marimer LLC
    • Email to rocky at marimer dot llc
    • Include your GitHub username in the email
    • You will recieve an email from GitHub inviting you to the organization and repo once we've reviewed your CLA
  • We will not accept large changes without a signed CLA, but we may accept small edits to the existing codebase
    • By submitting a change, large or small, you grant ownership of the code and related IP to Marimer LLC, and you certify that you have the right to transfer such ownership

Making Changes

We have rules around:

  1. Using Git
  2. Using GitHub
  3. Doing the work
  4. Git commits
  5. Submitting Pull Requests
  6. Reviewing PRs

The rules are detailed below.

Using Git

Using GitHub

  • Make sure you are working against an Issue in the backlog
    • If an issue doesn't exist, engage with the dev team via Discussions or Discord to discuss your concern
  • Create a fork of the MarimerLLC/csla repo
  • In your fork, create a topic/feature/issue branch from where you want to base your work
    • We recommend naming your branch using the format dev/issueNumber-test such as dev/1234-enhance-dataportal
  • Assign the issue
    • If you have permissions, assign the Issue to yourself
    • If you don't have permissions, make a comment in the issue saying that you are working on the issue
  • Schedule the issue
    • Issues in progress must be part of a Project
    • If you have permissions, assign the Issue to a project
    • If you don't have permissions, engage with the dev team via Discussions or Discord to discuss

Doing the Work

Commit to Git

  • Git commit text should include the backlog issue number; for example #1234 Fixed an issue

Submitting a Pull Request

  • Pull requests are submitted against a backlog issue; make sure you have an issue number before proceeding
  • Submit a pull request (PR) to the repository in the Marimer LLC organization.
    • Normally to the main branch
    • If you are changing an older version, submit to the vX.0 branch (confirm with Rocky that we're still doing releases on older versions before doing your work)
  • In the PR description use Closes #1234 or Fixes #1234 to link the PR to the issue
  • Submitting a PR will trigger a CI build; make sure the CI build passes with your changes and new unit tests

Reviewing a Pull Request

  • All PRs require at least one approving review before they can be merged
  • You may add your review to a PR, or you may be requested to review someone's PR
  • PR reviews should be positive and constructive, but also thorough; don't approve something if you think it is wrong in terms of code, style, testing, etc.

Additional Resources