# Galaxy Project Management and Contribution > 📊 View as slides ## Learning Questions - How do I contribute to Galaxy? - What is Galaxy's governance model? - How does the release process work? ## Learning Objectives - Understand the contribution workflow - Learn about Galaxy's open governance model - Understand the CI/CD pipeline ## Contributing Quick Start Contribution guidelines: [https://bit.ly/gx-CONTRIBUTING-md](https://bit.ly/gx-CONTRIBUTING-md) ## Pull Requests Nearly all changes should come in through GitHub Pull Requests. The exceptions include security patches, packaging and release process artifacts, and backporting fixes to older releases. ## Security (SECURITY_POLICY.md) In brief, to responsibly report security issues e-mail [`galaxy-committers@lists.galaxyproject.org`](mailto:galaxy-committers@lists.galaxyproject.org) Check out the full policy in [SECURITY_POLICY.md](https://github.com/galaxyproject/galaxy/blob/dev/SECURITY_POLICY.md). ## Branches ![Branches](../_images/core_branches.mindmap.plantuml.svg) ## Committers & Open Goverance All repository goverance is done in the open on GitHub via Pull Requests and voting. Galaxy goes beyond open source to open goverance. > "The committers group is the group of trusted developers and advocates who manage the core Galaxy code base." > "Galaxy Project committers are the only individuals who may commit to the core Galaxy code base." > "Committers may participate in all formal votes, including votes to modify team membership, merge pull requests, and modify [policies]." ## Working Groups [https://galaxyproject.org/community/wg/](https://galaxyproject.org/community/wg/) > "Galaxy has grown a lot over the years, going from a project at one university in 2005 to the global community it is today. Several parts of the Galaxy ecosystem have become avowedly and obviously community driven during that time, including tools, code, training, and several other international efforts. Galaxy Working Groups push this global model to other areas of Galaxy as well." ## Code of Conduct (CODE_OF_CONDUCT.md) Describes expectations, encourages diversity, and describes how to report issues such as unacceptable behavior. Check out the full policy in [CODE_OF_CONDUCT.md](https://github.com/galaxyproject/galaxy/blob/dev/CODE_OF_CONDUCT.md). ## Release Process New large releases are issued roughly every 4 months. The process is guided by an auto-created self documenting release issue. Check out the [25.1 release issue](https://github.com/galaxyproject/galaxy/issues/20952) as an example. Working groups create roadmaps aligned with each release and coordinated with project leadership. ## Organizing Issues and Pull Requests Extensive use of Github tags are used to try to organize the numerous issues and pull requests of the Galaxy repository. The tags are described in detail in [issues.rst](https://github.com/galaxyproject/galaxy/blob/dev/doc/source/project/issues.rst). ## Continuous Integration (CI) ![Galaxy CI](../_images/core_ci.png) If you get Red Xs - take a second to ponder whether they make sense and don't be afraid to ask, it is a complex system with a lot of noise! ## Linting and Code Formatting Part of the Galaxy CI process includes linting and checking the format of both the backend Python and frontend ES 6 code. This linting process captures many common problems as well as enforcing a common code style. The output reports from the CI process are relatively straightforward, but it is a good process to lint changes and formatting your code before opening pull requests for them. Execute the `format` make command to format the backend code and then use `tox` to lint the formatted code. ``` $ make format $ tox -e lint ``` Execute the `client-format` make command to format the code and then the `client-lint` command to lint the formatted code. ``` $ make client-format $ make client-lint ``` ## mypy and Python Types Starting with release 21.01, portions of the Galaxy backend have Python 3 type annotations and static checking is performed as part of CI. Imported library types are not enforcing and [mypy](https://mypy.readthedocs.io/en/stable/) does a fair job inferring types in most situations, so this process should be relatively transparent to contributors. If there are problems with typing, the CI produces explicit output about how to correct problems. These problems generally just require a single type annotation. Feel free to request help on a pull request for what that should look like. To run a subset of the python type checking locally, `tox` again can be used: ``` $ tox -e mypy ``` A quick overview about why to add type annotations to Python code and how to use them can be found on this [blog post](https://dev.to/dstarner/using-pythons-type-annotations-4cfe). Additional useful resources include [this cheat sheet from mypy](https://mypy.readthedocs.io/en/stable/cheat_sheet_py3.html) and the Python docs for the [typing module](https://docs.python.org/3/library/typing.html). ## Development Environments Galaxy developers use a wide range of IDEs and we don't offer any formal recommendation of one over another. However, Marius has assembled some documentation on debugging the [Galaxy server](https://docs.galaxyproject.org/en/master/dev/debugging_galaxy.html) and [tests](https://docs.galaxyproject.org/en/master/dev/debugging_tests.html) using VS Code. ## Development Environment - Gitpod Galaxy does have a Gitpod configuration that is enabled to allow editing and testing PRs [https://www.gitpod.io/.](https://www.gitpod.io/.) Video from Marius presenting Gitpod at the Galaxy Developer Roundtable ([https://www.youtube.com/watch?v=3e71DFg3gsw#t=39m0s](https://www.youtube.com/watch?v=3e71DFg3gsw#t=39m0s)) ## docs.galaxyproject.org ![docs.galaxyproject.org](../_images/core_docs.png) All these documents as well as versions code and deployment documentation and release notes can be found at [docs.galaxyproject.org](https://docs.galaxyproject.org). ## Key Takeaways - Open governance through pull requests and voting - Working groups coordinate major efforts - Regular release cycle (~4 months) - Extensive CI/CD with linting and testing