The react-magma team puts a lot of time, effort, and thought into making decisions around all aspects of the implementation of this component library. That effort includes ensuring that the react-magma code maintains a consistent look and feel across the entire repository. Before starting on your first PR please make sure to have a look at other components to see the different convention choices and structure. If you do see something that you believe should be changed, added, or might benefit from your unique perspective, please bring it to the react-magma team for discussion before making that change in your new component or fix.
Similarly, the docs pages should follow the existing conventions as well. Each component should have a corresponding mdx page to appear within the docs site with relevant examples. Look at the docs pages for other components as examples, and please try to stay as consistent as possible with wording and writing style.
If, while you're looking through the repository, you see something outside of your component that you are focused on that you believe should be changed / fixed please let the team know. For your PR, make sure you stay focused on what you were originally intending on working on. That does not mean that we can't make changes outside of your component, but we want to make sure it's the right choice and if it is, we will create a separate PR as there may be side effects.
We appreciate the help with anything that comes in through a pull request, but please realize that we will not be rushing anything through and any developer should expect a decent amount of feedback on any pull request. Being a library that is used across multiple teams means that we need to make sure we are thinking of as many situations as possible, so even if you believe the component is ready for your team there could be more that we ask for to allow for the component to be used in a broader scenario.
We want to make sure that a11y and performance are in the front of our minds in everything we develop. As we are a library being used in multiple products, we would like to make sure that we build in the best practices to ensure quality across the board. When implementing your PR, please keep these in mind as we will not accept any PRs that do not meet these standards.
We have a base theme built out and allow for the consumer to use their own, separate theme if need be. Make sure not to hard code any colors or refer directly to the magma theme in those implementations. Instead, components should use the ThemeContext, which will use the magma theme by default. If you do not see a color that you need to use as part of the magma theme, please talk to the team and we can find out where that color should live.
The react-magma team welcomes your suggestions and contributions. This project works best as an open, cross-organization collaboration. Please bring your ideas and constructive criticism to the team and we can brainstorm, engage in healthy debate, and work together towards the best possible solution. Because the react-magma team is ultimately responsible for the ongoing development and support of these components, the core team will make (and own) final decisions regarding public API, internal implementation details, build tools, coding style, and which work is the priority. Once a decision has been made, everyone involved needs to be willing to disagree and commit in the interest of moving forward.
Communicate often. Make sure you are giving progress updates for any PR. With more communication we can catch things earlier and help you develop using the conventions and practices that we have built in. This will also ensure a much faster PR approval if we are on the same page the whole time.