-
Notifications
You must be signed in to change notification settings - Fork 0
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
Initial RFC process proposal - Using Carbon and React as examples. #4
base: main
Are you sure you want to change the base?
Conversation
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.
I think we should have the template prior to landing this. I think it's really important that we take inspiration from component libraries and assume that they will take this shape as well. And also that something like select
or a new HTML element can leverage the exact same document.
|
||
It is necessary to follow the RFC process when you are intend to create any significant changes to the OpenUI Design System. Examples of these types of changes are: | ||
|
||
* A change which provides significantly alters existing functionality, provides new functionality, or a new primative component. |
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.
remove "provides" or re-word
|
||
## What the process is | ||
|
||
To get a change into the design system, the RFC will first be merged into the repo under the `/rfcs/active` directory. At that point, work on inclusion of the code and documentation can begin. Once the RFC is accepted it will be moved into the `/rfcs/accepted` directory to provide history on the decision process for each component. |
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.
I don't follow this from a structure perspective. We currently leverage "front data" within the json to reflect whether it is a proposal or not. Granted this is a bit different for the component lib itself and so this may make sense in this context.
* A change which provides significantly alters existing functionality, provides new functionality, or a new primative component. | ||
* The removal of an existing feature or functionality | ||
|
||
Another way to look at it is, if your suggested change will require a new semantic version, or breaking change to an existing feature, it will need to go through the RFC process. |
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.
We should detail how we intend to do versioning, you reference here so it implies we'll leverage the common semver paradigm but it would be good to call this out in the Readme or elsewhere. Not a blocking change to the PR.
|
||
## Implementing an RFC | ||
|
||
The author of the RFC does not have to be the person to implement it, however they should be ready to help once it is set to active if they would like to see it finally accepted. All community members are also welcome to help with the implementation of any active RFC. |
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.
I'd prefer to use some stronger verbiage here, such as "does not have to be the person to implement it; however, we do recommend this approach as it helps speed up the RFC process."
|
||
The author of the RFC does not have to be the person to implement it, however they should be ready to help once it is set to active if they would like to see it finally accepted. All community members are also welcome to help with the implementation of any active RFC. | ||
|
||
If you are interested in working on an active RFC, please engage the communtiy in the Discord channel to discuss how best to get started. |
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.
Link to channel, also we should come up with the working model for this. We have this section on Open UI but it has its own issues. https://open-ui.org/get-involved/#standardizing-an-open-ui-web-component
To create a new RFC you will: | ||
|
||
* Fork the OpenUI Design System repo - https://github.com/openui/design-system | ||
* Copy the `/rfcs/0000-template.md` file to `/rfcs/active` and rename it to `0000-proposed-component.md` where "proposed-component" is a descriptive title of your component. |
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.
Can you provide an example of this? We have a template here but we have moved away from it. We should know what we want the end result to be inspired by common design systems and component libraries
|
||
# Basic Example | ||
|
||
If the proposal involves a new or changed component, includ a basic code example. Omit this section if it's not applicable. |
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.
"includ" -> "include"
|
||
# Alternatives | ||
|
||
What other designs or features have been considered? What is the impact of this not being included. |
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.
Add in here, does a solution already exist within OpenUI, if so what makes this solution different?
Here's a first take at the RFC process borrowing from Carbon, React and others.
It should provide us with a way to accept and discuss community proposals and a process for beginning the implementation of them into core.