From 2ab69e081674596352f3fd4a2af874fad9abfdcf Mon Sep 17 00:00:00 2001 From: erikjohnston Date: Wed, 13 Dec 2023 15:42:43 +0000 Subject: deploy: 8613f7693ea284a023dc625c9a35b9ff482f5fd0 --- develop/development/contributing_guide.html | 38 ++++++++++++++--------------- 1 file changed, 18 insertions(+), 20 deletions(-) (limited to 'develop/development/contributing_guide.html') diff --git a/develop/development/contributing_guide.html b/develop/development/contributing_guide.html index 6975222cb4..29eee06328 100644 --- a/develop/development/contributing_guide.html +++ b/develop/development/contributing_guide.html @@ -124,10 +124,10 @@ - + - + @@ -162,14 +162,15 @@

Contributing

This document aims to get you started with contributing to Synapse!

1. Who can contribute to Synapse?

-

Everyone is welcome to contribute code to matrix.org -projects, provided that they are willing to +

Everyone is welcome to contribute code to Synapse, +provided that they are willing to license their contributions under the same license as the project itself. We follow a simple 'inbound=outbound' model for contributions: the act of submitting an 'inbound' contribution means that the contributor agrees to license the code under the same terms as the project's overall 'outbound' license - in our case, this is almost always Apache Software License v2 (see -LICENSE).

+LICENSE).

+

TODO THIS NEEDS UPDATING

2. What do I need?

If you are running Windows, the Windows Subsystem for Linux (WSL) is strongly recommended for development. More information about WSL can be found at @@ -222,8 +223,8 @@ cp docs/sample_log_config.yaml log_config.yaml

And then run Synapse with the following command:

poetry run python -m synapse.app.homeserver -c homeserver.yaml
@@ -236,19 +237,19 @@ resolve any issues and re-run until successful.

 
5. Get in touch.

 
Join our developer community on Matrix: #synapse-dev:matrix.org!

 
6. Pick an issue.

-
Fix your favorite problem or perhaps find a Good First Issue
+
Fix your favorite problem or perhaps find a Good First Issue
 to work on.

 
7. Turn coffee into code and documentation!

 
There is a growing amount of documentation located in the
-docs
-directory, with a rendered version available online.
+docs
+directory, with a rendered version available online.
 This documentation is intended primarily for sysadmins running their
 own Synapse instance, as well as developers interacting externally with
 Synapse.
-docs/development
+docs/development
 exists primarily to house documentation for
 Synapse developers.
-docs/admin_api houses documentation
+docs/admin_api houses documentation
 regarding Synapse's Admin API, which is used mostly by sysadmins and external
 service developers.

 
Synapse's code style is documented here. Please follow
@@ -256,12 +257,9 @@ it, including the conventions for build docs to a book
+build docs to a book
 to check that your contributions render correctly. The docs are written in
 GitHub-Flavoured Markdown.

-
Some documentation also exists in Synapse's GitHub
-Wiki, although this is primarily
-contributed to by community authors.

 
When changes are made to any Rust code then you must call either poetry install
 or maturin develop (if installed) to rebuild the Rust code. Using maturin
 is quicker than poetry install, so is recommended when making frequent
@@ -376,7 +374,7 @@ configuration:

 
  • To run with Postgres, supply the -e POSTGRES=1 -e MULTI_POSTGRES=1 environment flags.
    • 
 
  • To run with Synapse in worker mode, supply the -e WORKERS=1 -e REDIS=1 environment flags (in addition to the Postgres flags).
    • 
 
-
    For more details about other configurations, see the Docker-specific documentation in the SyTest repo.
    
+
    For more details about other configurations, see the Docker-specific documentation in the SyTest repo.
    
 
    Run the integration tests (Complement).
    
 
    Complement is a suite of black box tests that can be run on any homeserver implementation. It can also be thought of as end-to-end (e2e) tests.
    
 
    It's often nice to develop on Synapse and write Complement tests at the same time.
@@ -398,7 +396,7 @@ Here is how to run your local Synapse checkout against your local Complement che
 
  • If setting WORKERS=1, optionally set WORKER_TYPES= to declare which worker
 types you wish to test. A simple comma-delimited string containing the worker types
 defined from the WORKERS_CONFIG template in
-here.
+here.
 A safe example would be WORKER_TYPES="federation_inbound, federation_sender, synchrotron".
 See the worker documentation for additional information on workers.
    • 
 
@@ -452,7 +450,7 @@ in the format of PRnumber.type. The type can be one of the followin
 
  • removal (also used for deprecations)
    • 
 
  • misc (for internal-only changes)
    • 
 
-
    This file will become part of our changelog at the next
+
    This file will become part of our changelog at the next
 release, so the content of the file should be a short description of your
 change in the same style as the rest of the changelog. The file can contain Markdown
 formatting, and must end with a full stop (.) or an exclamation mark (!) for
@@ -480,7 +478,7 @@ chicken-and-egg problem.
    
 add the changelog file to your branch, or:
    
 
 
  • 
-
    Look at the list of all
+
    Look at the list of all
 issues/PRs, add one to the
 highest number you see, and quickly open the PR before somebody else claims
 your number.
    
-- 
cgit 1.5.1