|
1 | | -# How to contribute |
2 | | -We would love to have your help. Before you start working however, please read |
3 | | -and follow this short guide. |
| 1 | +# Follow Our Updated Guide to See How You Can Contribute |
4 | 2 |
|
5 | | -# Reporting Issues |
6 | | -Provide as much information as possible. Mention the version of Jitsi Meet, |
7 | | -Jicofo and JVB you are using, and explain (as detailed as you can) how the |
8 | | -problem can be reproduced. |
| 3 | +Hello there! 👋 |
9 | 4 |
|
10 | | -# Code contributions |
11 | | -Found a bug and know how to fix it? Great! Please read on. |
| 5 | +We're thrilled that you're eager to contribute to Jitsi Meet! ❤️ |
12 | 6 |
|
13 | | -## Contributor License Agreement |
14 | | -While the Jitsi projects are released under the |
15 | | -[Apache License 2.0](https://github.com/jitsi/jitsi-meet/blob/master/LICENSE), the copyright |
16 | | -holder and principal creator is [8x8](https://www.8x8.com/). To |
17 | | -ensure that we can continue making these projects available under an Open Source license, |
18 | | -we need you to sign our Apache-based contributor |
19 | | -license agreement as either a [corporation](https://jitsi.org/ccla) or an |
20 | | -[individual](https://jitsi.org/icla). If you cannot accept the terms laid out |
21 | | -in the agreement, unfortunately, we cannot accept your contribution. |
| 7 | +Your interest in improving our platform means a lot to us. To ensure your contributions align seamlessly with our goals and processes, we've recently updated our guide. This guide will provide you with clear instructions on how to get involved effectively. |
22 | 8 |
|
23 | | -## Creating Pull Requests |
24 | | -- Make sure your code passes the linter rules beforehand. The linter is executed |
25 | | - automatically when committing code. |
26 | | -- Perform **one** logical change per pull request. |
27 | | -- Maintain a clean list of commits, squash them if necessary. |
28 | | -- Rebase your topic branch on top of the master branch before creating the pull |
29 | | - request. |
| 9 | +Ready to get started? Head over to our [Jitsi Meet Handbook](https://jitsi.github.io/handbook/docs/dev-guide/dev-guide-contributing/) and let's make Jitsi Meet even better together! |
30 | 10 |
|
31 | | -## Coding style |
| 11 | +### ❗️Additional Note |
| 12 | +Before sending us your code, double-check that it meets our coding standards. You can do this by running a command: `npm run lint`. If there are any issues, don't worry! You can fix them by running: `npm run lint-fix`. Once your code passes these checks, feel free to submit your pull request. |
32 | 13 |
|
33 | | -### Comments |
34 | | - |
35 | | -* Comments documenting the source code are required. |
36 | | - |
37 | | - * Comments from which documentation is automatically generated are **not** |
38 | | - subject to case-by-case decisions. Such comments are used, for example, on |
39 | | - types and their members. Examples of tools which automatically generate |
40 | | - documentation from such comments include JSDoc, Javadoc, Doxygen. |
41 | | - |
42 | | - * Comments which are not automatically processed are strongly encouraged. They |
43 | | - are subject to case-by-case decisions. Such comments are often observed in |
44 | | - function bodies. |
45 | | - |
46 | | -* Comments should be formatted as proper English sentences. Such formatting pays |
47 | | - attention to, for example, capitalization and punctuation. |
48 | | - |
49 | | -### Duplication |
50 | | - |
51 | | -* Don't copy-paste source code. Reuse it. |
52 | | - |
53 | | -### Formatting |
54 | | - |
55 | | -* Line length is limited to 120 characters. |
56 | | - |
57 | | -* Sort by alphabetical order in order to make the addition of new entities as |
58 | | - easy as looking a word up in a dictionary. Otherwise, one risks duplicate |
59 | | - entries (with conflicting values in the cases of key-value pairs). For |
60 | | - example: |
61 | | - |
62 | | - * Within an `import` of multiple names from a module, sort the names in |
63 | | - alphabetical order. (Of course, the default name stays first as required by |
64 | | - the `import` syntax.) |
65 | | - |
66 | | - ````javascript |
67 | | - import { |
68 | | - DOMINANT_SPEAKER_CHANGED, |
69 | | - JITSI_CLIENT_CONNECTED, |
70 | | - JITSI_CLIENT_CREATED, |
71 | | - JITSI_CLIENT_DISCONNECTED, |
72 | | - JITSI_CLIENT_ERROR, |
73 | | - JITSI_CONFERENCE_JOINED, |
74 | | - MODERATOR_CHANGED, |
75 | | - PEER_JOINED, |
76 | | - PEER_LEFT, |
77 | | - RTC_ERROR |
78 | | - } from './actionTypes'; |
79 | | - ```` |
80 | | - |
81 | | - * Within a group of imports (e.g. groups of imports delimited by an empty line |
82 | | - may be: third-party modules, then project modules, and eventually the |
83 | | - private files of a module), sort the module names in alphabetical order. |
84 | | - |
85 | | - ````javascript |
86 | | - import React, { Component } from 'react'; |
87 | | - import { connect } from 'react-redux'; |
88 | | - ```` |
89 | | - |
90 | | -### Indentation |
91 | | - |
92 | | -* Align `switch` and `case`/`default`. Don't indent the `case`/`default` more |
93 | | - than its `switch`. |
94 | | -
|
95 | | - ````javascript |
96 | | - switch (i) { |
97 | | - case 0: |
98 | | - ... |
99 | | - break; |
100 | | - default: |
101 | | - ... |
102 | | - } |
103 | | - ```` |
104 | | -
|
105 | | -### Naming |
106 | | -
|
107 | | -* An abstraction should have one name within the project and across multiple |
108 | | - projects. For example: |
109 | | -
|
110 | | - * The instance of lib-jitsi-meet's `JitsiConnection` type should be named |
111 | | - `connection` or `jitsiConnection` in jitsi-meet, not `client`. |
112 | | - |
113 | | - * The class `ReducerRegistry` should be defined in ReducerRegistry.js and its |
114 | | - imports in other files should use the same name. Don't define the class |
115 | | - `Registry` in ReducerRegistry.js and then import it as `Reducers` in other |
116 | | - files. |
117 | | -
|
118 | | -* The names of global constants (including ES6 module-global constants) should |
119 | | - be written in uppercase with underscores to separate words. For example, |
120 | | - `BACKGROUND_COLOR`. |
121 | | -
|
122 | | -* The underscore character at the beginning of a name signals that the |
123 | | - respective variable, function, property is non-public i.e. private, protected, |
124 | | - or internal. In contrast, the lack of an underscore at the beginning of a name |
125 | | - signals public API. |
126 | | -
|
127 | | -### Feature layout |
128 | | -
|
129 | | -When adding a new feature, this would be the usual layout. |
130 | | -
|
131 | | -``` |
132 | | -react/features/sample/ |
133 | | -├── actionTypes.ts |
134 | | -├── actions.js |
135 | | -├── components |
136 | | -│ ├── AnotherComponent.js |
137 | | -│ ├── OneComponent.js |
138 | | -│ └── index.js |
139 | | -├── middleware.js |
140 | | -└── reducer.js |
141 | | -``` |
142 | | -
|
143 | | -The middleware must be imported in `react/features/app/` specifically |
144 | | -in `middlewares.any.ts`, `middlewares.native.ts` or `middlewares.web.ts` where appropriate. |
145 | | -Likewise for the reducer. |
146 | | -
|
147 | | -An `index.js` file must not be provided for exporting actions, action types and |
148 | | -component. Features / files requiring those must import them explicitly. |
149 | | -
|
150 | | -This has not always been the case and the entire codebase hasn't been migrated to |
151 | | -this model but new features should follow this new layout. |
152 | | - |
153 | | -When working on an old feature, adding the necessary changes to migrate to the new |
154 | | -model is encouraged. |
155 | | - |
156 | | - |
157 | | -### Avoiding bundle bloat |
158 | | - |
159 | | -When adding a new feature it's possible that it triggers a build failure due to the increased bundle size. We have safeguards inplace to avoid bundles growing disproportionatelly. While there are legit reasons for increasing the limits, please analyze the bundle first to make sure no unintended dependencies have been included, causing the increase in size. |
160 | | -
|
161 | | -First, make a production build with bundle-analysis enabled: |
162 | | -
|
163 | | -``` |
164 | | -npx webpack -p --analyze-bundle |
165 | | -``` |
166 | | -
|
167 | | -Then open the interactive bundle analyzer tool: |
168 | | -
|
169 | | -``` |
170 | | -npx webpack-bundle-analyzer build/app-stats.json |
171 | | -``` |
| 14 | +Happy coding! |
0 commit comments