-
-
Couldn't load subscription status.
- Fork 1.9k
Improve contribution guide & readme, add code of conduct #5068
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
b733954
6df7dff
63fb73f
5f39303
7a402a3
3d931e2
594aeb2
58f1123
f9aec7d
96d1616
8fb8d80
32e374d
518d2ea
01dd22b
5c73c7c
e367692
f69d47d
191c829
c22e23b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -1,4 +1,27 @@ | ||||||
| # Contributing to plotly.js | ||||||
| # Contributing to Plotly.js | ||||||
|
|
||||||
| ### How do changes get made to Plotly.js? | ||||||
|
|
||||||
| The basic architecture of Plotly.js is to accept JSON representation of figures that adhere to the figure schema and draw graphical representations of these figures. Adding new attributes to the schema or new allowable values to existing attributes and adding the associated drawing code generally comprises a **new feature**. This project has a strong commitment to backwards-compatibility, so changing the graphical output for existing schema attributes and values, or changing the default value of an attribute, is generally only done as a mostly-backwards-compatible **bug fix**, for cases when the current graphical output is incorrect, non-sensical or otherwise very problematic. Non-schema-related features and bug fixes are possible as well, usually around performance, security, bundling, function signatures etc, and generally follow the same principles. | ||||||
nicolaskruchten marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
nicolaskruchten marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||
|
|
||||||
| The basic process for adding new features or fixing bugs is as follows: | ||||||
|
|
||||||
| 1. **Discussion** - A community member or maintainer creates an issue to discuss the use-case for the new feature. This usually entails describing the desired graphical output and discussing how close the current system can get to specifying or drawing such a figure. If the issue is percieved to be a bug, the discussion revolves around understanding how the current behaviour is incorrect or problematic, and how existing users of the system would be impacted by a change in this behaviour. | ||||||
nicolaskruchten marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||
| 2. **Proposal** - If the current system cannot specify or draw such a figure, or if the way to do it is too onerous, the next step is to discuss or propose a specific change to the schema: new attributes to be added or new accepted values to new attributes, along with a prose description of the proposed drawing code. If the issue is determined to be a bug rather than a feature, the same type of proposal is required: a definition of which attributes and values will be impacted by the proposed change. | ||||||
| 3. **Iteration** - The maintainers of the library or any other interested community member will then give feedback on the proposal, usually focused on consistency with the rest of the schema, and helping define a test plan to further elaborate potential edge cases. | ||||||
| 4. **Approval** - After a number of iterations, the maintainers of the library will generally approve a proposal with an informal "this seems like something we would accept a pull request for" comment in the issue. | ||||||
| 5. **Development** - A community member or maintainer creates a branch and makes the appropriate modifications to the code and tests and opens a pull request. | ||||||
| 6. **Review** - The maintainers of the library will review the pull request, working with the original authors to ensure the code is ready for merging. | ||||||
|
||||||
| 6. **Review** - The maintainers of the library will review the pull request, working with the original authors to ensure the code is ready for merging. | |
| 6. **Review** - The maintainers of the library will review the pull request, working with the original authors to ensure the code is ready for merging. Iterations during review may take a bit of time, so be patient! In some cases it may also happen that the pull request cannot be merged for some reasons, but the process of starting by a discussion in an issue reduces the occurrence of this situation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or something like that :-). I wanted to make sure that people know that it's not a completely linear process, sometimes unexpected difficulties arise, or life happens, or...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
put here a few sentences explaining the organization of this document? It is quite long so it might be worth it. In particular some people will be looking specifically for out to set up a development environment.