Skip to content

Latest commit

 

History

History
162 lines (125 loc) · 10.4 KB

CONTRIBUTING.md

File metadata and controls

162 lines (125 loc) · 10.4 KB
Raw

Contributing

As an open source project, Mesa welcomes contributions of many forms, and from beginners to experts. If you are curious or just want to see what is happening, we post our development session agendas and development session notes on Mesa discussions. We also have a threaded discussion forum on Matrix for casual conversation.

In no particular order, examples include:

  • Code patches
  • Bug reports and patch reviews
  • New features
  • Documentation improvements
  • Tutorials

No contribution is too small. Although, contributions can be too big, so let's discuss via Matrix OR via an issue.

To submit a contribution

  • Create a ticket for the item that you are working on.
  • Fork the Mesa repository.
  • Clone your repository from Github to your machine.
  • Create a new branch in your fork: git checkout -b BRANCH_NAME
  • Run git config pull.rebase true. This prevents messy merge commits when updating your branch on top of Mesa main branch.
  • Install an editable version with developer requirements locally: pip install -e ".[dev]"
  • Edit the code. Save.
  • Git add the new files and files with changes: git add FILE_NAME
  • Git commit your changes with a meaningful message: git commit -m "Fix issue X"
  • If implementing a new feature, include some documentation in docs folder.
  • Make sure that your submission works with a few of the examples in the examples repository. If adding a new feature to mesa, please illustrate usage by implementing it in an example.
  • Make sure that your submission passes the GH Actions build. See "Testing and Standards below" to be able to run these locally.
  • Make sure that your code is formatted according to [the black] standard (you can do it via pre-commit).
  • Push your changes to your fork on Github: git push origin NAME_OF_BRANCH.
  • Create a pull request.
  • Describe the change w/ ticket number(s) that the code fixes.
  • Format your commit message as per Tim Pope's guideline.

I have no idea where to start

That's fine! Here's a rough outline where you could start, depending on your experience:

I'm a modeller (but not an experienced developer)

You already know how to build Mesa models (if not skip below), and probably have found things Mesa can't do (elegantly). You want to improve that. Awesome!

First step is to install some proper tools, if you haven't already.

Learn the tools, talk to us about what you want to change, and open a small PR. Or update an example model (check open issues)!

I'm a developer (but not a modeller)

Awesome! You have the basics of open-source software development (if not check above), but not much modelling experience.

First step is to start thinking like a modeller. To understand the fine details about our library and contribute meaningfully, get some modelling experience:

  • Go though our Introductory Tutorial and Visualization Tutorial. While going through them, dive into the source code to really see what everything does.
  • Follow an ABM course (if possible). They might be a bit outdated programming language wise, but conceptual they're sound.
  • Go though multiple of our examples. Play with them, modify things and get a feel for Mesa and ABMs.
    • Check our open issues for the examples.
    • If you see anything you want to improve, feel free to open a (small) PR!
  • If you have a feel for Mesa, check our discussions and issues.
    • Also go thought our release notes to see what we recently have been working on, and see some examples of successful PRs.
  • Once you found or thought of a nice idea, comment on the issue/discussion (or open a new one) and get to work!

I'm both

That's great! You can just start working on things, reach out to us. Skim to the list above if you feel you're missing anything. Start small but don't be afraid to dream big!

I'm neither

Start with creating your own models, for fun. Once you have some experience, move to the topics above.

Testing and Code Standards

:target: https://codecov.io/gh/projectmesa/mesa

:target: https://github.com/psf/black

As part of our contribution process, we practice continuous integration and use GH Actions to help enforce best practices.

If you're changing previous Mesa features, please make sure of the following:

  • Your changes pass the current tests.
  • Your changes pass our style standards.
  • Your changes don't break the models or your changes include updated models.
  • Additional features or rewrites of current features are accompanied by tests.
  • New features are demonstrated in a model, so folks can understand more easily.

To ensure that your submission will not break the build, you will need to install Ruff and pytest.

pip install ruff pytest pytest-cov

We test by implementing simple models and through traditional unit tests in the tests/ folder. The following only covers unit tests coverage. Ensure that your test coverage has not gone down. If it has and you need help, we will offer advice on how to structure tests for the contribution.

py.test --cov=mesa tests/

With respect to code standards, we follow PEP8 and the Google Style Guide. We use [ruff format] (a more performant alternative to black) as an automated code formatter. You can automatically format your code using pre-commit, which will prevent git commit of unstyled code and will automatically apply black style so you can immediately re-run git commit. To set up pre-commit run the following commands:

pip install pre-commit
pre-commit install

You should no longer have to worry about code formatting. If still in doubt you may run the following command. If the command generates errors, fix all errors that are returned.

ruff .

Licensing

The license of this project is located in LICENSE. By submitting a contribution to this project, you are agreeing that your contribution will be released under the terms of this license.

Maintainers

Some notes useful for Mesa maintainers.

Releases

To create a new release, follow these steps:

  1. Ensure all pull requests (PRs) have a clear title and are labeled with at least one label. Check this link to see if all PRs are labeled. These labels will be used when drafting the changelog using the .github/release.yml configuration.
  2. Navigate to the Releases section in the GitHub UI and click the Draft a new release button.
  3. Specify the upcoming tag in the Choose a tag and Release title fields (e.g., v3.0.0).
    • For pre-releases, add a a, b or rc and a number behind the version tag (see Versioning), and check the box Set as a pre-release.
  4. Use the Generate release notes button to automatically create release notes. Review them carefully for accuracy, and update labels and edit PR titles if necessary (step 1).
  5. Write a Highlights section summarizing the most important features or changes in this release.
  6. Copy the release notes and save them by clicking the grey Save draft button.
  7. Open a new PR to update the version number in mesa/__init__.py and add the copied release notes to the HISTORY.md.
  8. Once this PR is merged, return to the Releases section and publish the draft release.
  9. The release.yml CI workflow should automatically create and upload the package to PyPI. Verify this on PyPI.org.
  10. Finally, after release, open a new PR to update the version number in mesa/__init__.py for the next release (e.g., "3.1.0.dev").

Special Thanks

A special thanks to the following projects who offered inspiration for this contributing file.