Skip to content
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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

cellar-door
Copy link
Collaborator

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.

Copy link
Member

@gregwhitworth gregwhitworth left a 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.
Copy link
Member

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.
Copy link
Member

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.
Copy link
Member

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.
Copy link
Member

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.
Copy link
Member

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.
Copy link
Member

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.
Copy link
Member

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.
Copy link
Member

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants