|
1 | | -# Welcome to OasisLMF contributing guide :wave: |
| 1 | +# How to contribute to the Open Exposure Data Standard |
2 | 2 |
|
3 | | -Thank you for investing your time in contributing to this project! |
| 3 | +There are a variety of ways in which you can contribute to the development |
| 4 | +and adoption of the OED standard. |
4 | 5 |
|
5 | | -<!-- Read our [Code of Conduct](./CODE_OF_CONDUCT.md) to keep our community approachable and respectable. --> |
| 6 | +We recommend that before contributing you: |
6 | 7 |
|
7 | | -In this guide you will get an overview of the coding style that we follow and of the contribution workflow from opening an issue, creating a pull request (PR), reviewing, and merging the PR. |
| 8 | +* Review the [OED documentation](Docs/) which provides an overview of the standard and introduces key concepts and terminology. |
| 9 | +* Review the OED specification which contains the main data components, field lists and valid values. |
| 10 | + * [Excel version](README.md#releases) |
| 11 | + * [Csv version](OpenExposureData/) |
| 12 | +* Review the [governance and release processes](Docs/ODS_Gov_Updates_Release_Processes_v1.1.pdf) documentation so that you are familiar with our processes for agreeing changes and releasing updates. |
8 | 13 |
|
| 14 | +## Proposing changes |
9 | 15 |
|
10 | | -## Coding principles |
| 16 | +If you would like to propose a change to the standard then you can do this by [submitting an issue](https://github.com/OasisLMF/ODS_OpenExposureData/issues). For instance: |
11 | 17 |
|
12 | | -The goal of the these coding guidelines is to ensure that the OasisLMF repositories are highly maintainable, well documented, and well structured. |
| 18 | +* if you have noticed an error in the specification or documentation. |
| 19 | +* if you have a proposal for revising or extending the standard. |
13 | 20 |
|
14 | | -Please adhere to the following principles when contributing to the code base: |
| 21 | +We recommend filing an issue as the first step, so that fixes and changes can be discussed with the community. |
15 | 22 |
|
16 | | - - be **DRY** (aka Don't Repeat Yourself): avoid code duplication as much as possible. If an element (variable, constant, data type, function, etc.) is already defined somewhere else in the package, then re-use or augment the existing definition. |
17 | | - |
18 | | - - add proper **documentation** to the code: |
19 | | - - on general terms, we follow the Google Python Style Guide for comments and docstrings: see [Chapter 3.8](https://google.github.io/styleguide/pyguide.html#38-comments-and-docstrings). |
20 | | - - all functions must have a docstring describing their purpose, the data type and the content of all input and output variables. Where external results (e.g., specific algorithms) are used, a short note or reference to the external source should be included. |
21 | | - - the docstrings need to be concise and essential, yet complete. |
22 | | - - in functions implementing non-trivial logic and/or complex algorithms, the code should be annotated with short and informative comments making clear the logic and the flow, and the reasoning behind non-obvious implementation decisions. |
23 | | - |
24 | | - - format the code to make it **PEP8 compliant**. This is easily done with tools like `autopep8`: see how to use formatters in [VS code](https://code.visualstudio.com/docs/python/editing#_formatting) and [PyCharm](https://www.jetbrains.com/help/pycharm/reformat-and-rearrange-code.html). |
25 | | - |
26 | | -When in doubt about the style, have a look at the [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html): it contains PEP-compliant style recommendations and examples. |
| 23 | +Changes will be carried out in line with our [governance and release processes](Docs/ODS_Gov_Updates_Release_Processes_v1.1.pdf). |
27 | 24 |
|
28 | | -Code that doesn't follow the above principles shall not be merged into the codebase. |
| 25 | +Please note that any proposed changes or data contributions you make must be done so under a CC0 1.0 Universal licence. |
29 | 26 |
|
30 | | -## Getting started |
31 | | - |
32 | | -### Issues |
33 | | - |
34 | | -**Create a new issue:** if you spot a problem with the code or the docs, search if an issue already exists in that repository. For example, for the OasisLMF/OasisLMF repository, see the [existing issues here](https://github.com/OasisLMF/OasisLMF/issues). If a related issue doesn't exist, you can open a new issue. |
35 | | - |
36 | | -**Solve an issue:** scan through our existing issues to find one that interests you. You can narrow down the search using `labels` as filters. If you find an issue to work on, you are welcome to open a PR with a fix. |
37 | | - |
38 | | -### Make Changes |
39 | | - |
40 | | -1. [Install `git`](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git). |
41 | | - |
42 | | -2. Fork the repository. |
43 | | -- Using GitHub Desktop: |
44 | | - - [Getting started with GitHub Desktop](https://docs.github.com/en/desktop/installing-and-configuring-github-desktop/getting-started-with-github-desktop) will guide you through setting up Desktop. |
45 | | - - Once Desktop is set up, you can use it to [fork the repo](https://docs.github.com/en/desktop/contributing-and-collaborating-using-github-desktop/cloning-and-forking-repositories-from-github-desktop)! |
46 | | - |
47 | | -- Using the command line: |
48 | | - - [Fork the repo](https://docs.github.com/en/github/getting-started-with-github/fork-a-repo#fork-an-example-repository) so that you can make your changes without affecting the original project until you're ready to merge them. |
49 | | - |
50 | | -3. Create a working branch and start with your changes! |
51 | | - |
52 | | -### Commit your update |
53 | | - |
54 | | -Commit and push the changes once you are happy with them. |
55 | | - |
56 | | -### Pull Request |
57 | | - |
58 | | -When you're finished with the changes, create a pull request, also known as a PR. |
59 | | -- Fill the PR template in all its parts. |
60 | | -- As a general rule, the **develop** branch is the target of all PRs for new features or bugfixes. |
61 | | -- Add the "Ready for Review" label to this PR. |
62 | | -- Don't forget to [link PR to issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) if you are solving one. |
63 | | -- Enable the checkbox to [allow maintainer edits](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/allowing-changes-to-a-pull-request-branch-created-from-a-fork) so the branch can be updated for a merge. |
64 | | -Once you submit your PR, a Docs team member will review your proposal. We may ask questions or request additional information. |
65 | | -- We may ask for changes to be made before a PR can be merged, either using [suggested changes](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/incorporating-feedback-in-your-pull-request) or pull request comments. You can apply suggested changes directly through the UI. You can make any other changes in your fork, then commit them to your branch. In many cases, we can help by implementing the required changes ourselves. |
66 | | -- As you update your PR and apply changes, mark each conversation as [resolved](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request#resolving-conversations). |
67 | | -- If you run into any merge issues, checkout this [git tutorial](https://github.com/skills/resolve-merge-conflicts) to help you resolve merge conflicts and other issues. |
68 | | - |
69 | | -### Your PR is merged! |
70 | | - |
71 | | -Congratulations :tada::tada: The OasisLMF team thanks you :sparkles:. |
| 27 | +## Promoting the standard |
72 | 28 |
|
| 29 | +You can also contribute to making the standard a success by promoting it within your team, organisation or community. |
0 commit comments