|
1 | 1 | # team-compass |
| 2 | + |
2 | 3 | A repository for team interaction, syncing, and handling meeting notes across the JupyterLab ecosystem. |
3 | 4 |
|
4 | 5 | ## Weekly Developer Meeting |
5 | 6 | Weekly Developer Meetings take place on [zoom](https://zoom.us/my/jovyan). Minutes will be taken at [Hackmd.io](https://hackmd.io/Uscrk0N1RhCtX-p6ZHUuWQ). Each week an issue will be opened with that week's meeting minutes and the issue from the previous week will be closed. |
6 | 7 |
|
7 | 8 | ## Code of Conduct |
8 | 9 | As an official Jupyter Project, all communication across all repositories in this organization should adhere to the [Project Jupyter Code of Conduct.](https://github.com/jupyter/governance/blob/master/conduct/code_of_conduct.md) |
| 10 | + |
| 11 | +## Contributing extensions to the JupyterLab GitHub organization |
| 12 | + |
| 13 | +JupyterLab is built to foster a rich ecosystem of plugins. Occasionally developers of an existing JupyterLab extension will want to contribute the extension to Project Jupyter and maintain the extension in the JupyterLab GitHub organization under [Project Jupyter governance](https://github.com/jupyter/governance), which includes: |
| 14 | + |
| 15 | +* adopting the standard Jupyter license and copyright |
| 16 | +* adhering to Project Jupyter community guidelines |
| 17 | +* being subject to the Project Jupyter BDFL, Steering Council, and governance. |
| 18 | + |
| 19 | +Project Jupyter has [official guidelines](https://github.com/jupyter/governance/blob/master/newsubprojects.md) for adopting new subprojects. More specifically for contributing extension codebases to the JupyterLab GitHub organization, the process for contributing is: |
| 20 | + |
| 21 | +1. Post an issue on this repo describing your extension and linking to the existing code. The issue should address each point of the [criteria for subprojects](https://github.com/jupyter/governance/blob/master/newsubprojects.md#criteria-for-official-subprojects). |
| 22 | +2. The community reviews the proposal over at least a week. In addition to the criteria listed in the Project Jupyter governance: |
| 23 | + 1. a core maintainer will review the existing code |
| 24 | + 2. we will also take into account how involved the extension maintainers are in the JupyterLab community |
| 25 | +3. If the JupyterLab maintainers decide to accept the extension into the JupyterLab GitHub organization, the process in the Project Jupyter [incorporation guidelines](https://github.com/jupyter/governance/blob/master/newsubprojects.md#incorporation) is followed. Additionally: |
| 26 | + 1. JupyterLab maintainers and other relevant Jupyter leadership (such as BDFL) are given permission to publish the package. |
| 27 | + 2. Extension maintainers are given admin permission on the relevant `@jupyterlab/extension` npm package. To do this, a user must be added to a team, which then has access to packages (under "Teams"): |
| 28 | + 1. Admin logs in to https://www.npmjs.com |
| 29 | + 2. Select avatar dropdown and go to "Profile Settings" |
| 30 | + 3. Select the jupyterlab org |
| 31 | + 4. Go to Members |
| 32 | + 5. Click "Invite Members..." |
| 33 | + 6. Add the username or email |
| 34 | + 7. Click "Invite" |
| 35 | + 8. Click "Continue" |
0 commit comments