| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Looking for a quick guide to PatternFly React Contribution? Go Here
New to contributing to PatternFly React? Here's how to get started quickly:
Need help? Join us on PatternFly Slack in the #patternfly-react channel!
We want to recognize and celebrate our amazing community contributors who have made significant contributions to PatternFly React in the past year! 🎉
The following contributors (excluding PatternFly team members and bots) have made outstanding contributions to the project:
Thank you to all our community contributors for helping make PatternFly React better! Every contribution, whether it's code, documentation, bug reports, or feature requests, helps improve the library for everyone.
This list is updated periodically and reflects contributions over the past 12 months. If you'd like to join this list, check out our contribution guidelines below!
This project is governed by the Contributor Covenant version 2.1. All contributors and participants agree to abide by its terms. To report violations, send an email to patternfly@redhat.com.
Please reference PatternFly's AI-assisted development guidelines if you'd like to contribute code generated using AI.
We use issues to track work items, such as bug reports and feature requests. Issues can be found in the issue tracker or project board. We use the project board to help visualize and manage status of an issue, and we use labels to help prioritize and identify issues.
Our issue tracker utilizes several labels to help organize and identify issues. Here's what they represent and how we use them:
Since the components in patternfly-react are based on patternfly, we want to make sure these components stay in sync with the core patternfly components as documented on patternfly.org. To help make sure component contributions are consistent with the design documentation and html/css implementation, we use the following labels during the PR review process.
We sync our issues to PatternFly's private Jira board. Once an issue is sync'd, a link is added to the issue description in GitHub if someone were to want to track the Jira ticket. Any issue can be assigned an assignee in GitHub or Jira and that information will be sync'd. If an issue is closed in Jira, it will also be closed in GitHub.
If you find a bug within the repo, please help us track the issue by following these steps:
To create an issue for adding a new component to the repo, please observe the following process:
Components that are ready to be contributed can be found on the project board in the backlog column. They are identified with the text “Component” in the issue title.
Once you’ve identified a component to contribute, component contributions should observe the following high level process:
If you submit a pull request, then please also contribute by reviewing other pull requests. Please remember that reviewing other contributions is just as important!
Ideally, all the styles that are needed for the components in patternfly-react would be defined in the core patternfly repo. However, there may be cases where additional styles are needed to complete the patternfly-react component contribution. In the case where the styles are specific to the component implementation in the patternfly-react repo, then the styles would remain in the repo. In the case where the component does not exist yet in the core pattenrfly repo and styles are needed for the component in the patternfly-react repo, then the styles would only remain in the patternfly-react repo until the component is added to the core patternfly repo. Once the styles are available as part of core patternfly repo, it will be removed from the patternfly-react repo.
When it is necessary to add styling in the patternfly-react repo, the styling should be done in both Less and Sass (in the future a converter will be provided, see Issue #169).
Inside the package directory:
Please ensure that all React UI components contributed meet the following guidelines:
All files and folders under your package's src/components should name with PascalCase except index.js files
If you need a constant file, it should be called {Component_Name}Constants.js (Component_Name with PascalCase)
Each component should treat as a standalone package and live under its own folder. If you think your component can be made completely independent from other components, create it as a new package. This reduces the dependency tree and improves performance downstream. It also makes exported bundles lighter.
Single file per component with default export
Avoid using the bindMethods syntax for attaching methods to a class. Instead use class properties for example testMethod = () => { return 'test'}
When component is a set of components (e.g., ListGroup and ListGroupItem), they should live in the same folder named on the parent component (e.g., ListGroup)
Each component folder should have an index.js file with named exports of all the relevant components in the folder
Always prefer default imports between components in the same folder
Components that are not getting exported (to consumers) from the index.js file should be in a subfolder named InnerComponents
Provide documentation for your component with a single Markdown file. (e.g., ListGroup.md) See how to write documentation in the react-docs README
When destructuring or spreading expressions , use ...props as the variable name.
Please see the getting started README for additional information in getting started with building PatterFly react components.
Adhering to the following process is the best way to get your work included in the project:
Fork and set up the repository (More information about forks from GitHub)
Set up your development environment
Prerequisites:
Setup commands:
# Install dependencies
yarn install
# Build the project
yarn build
# Run tests to verify setup
yarn test
# Start development server (optional)
yarn startVerify your setup:
yarn build
yarn testEnsure no lint errors are introduced in yarn-error.log after running this command.
Note to Windows users: you may need to change the path for the lint script in package.json to be node_modules/eslint/bin/eslint
Follow commit conventions - This project uses lerna to do automatic releases and generate a changelog based on the commit history. So we follow conventional commit formatting for all commit messages. Please follow this convention for your commit messages.
Create a pull request
Open a pull request with a clear title and description against the main branch. Please be sure to include all of the following in your PR:
A link to the demo documentation will be automatically generated and posted as a comment after the pull request build is complete.
Once your pull request has been reviewed, if all conditions above have been met your pull request will be approved and merged.
Please help in ensuring all relevant issues are closed and that any subsequent issues needed have been noted with this pull request.
Build Failures:
Test Failures:
Linting Errors:
Development Server Issues:
Integration Issues:
Still having issues?
The documentation for becoming a maintainer has been taken from Foreman and adapted for the PatternFly project.
As a maintainer, it is your responsibility to help manage and maintain the health of the PatternFly project. A PatternFly maintainer has commit permissions to one or more of the repositories under the PatternFly organization. To see a list of maintainers to the PatternFly project, view the PatternFly GitHub Teams page.
Maintainers are members of the PatternFly community who exhibit most of the following behaviors:
If you want to become a maintainer, we expect you to:
Other things that are nice to do:
One person has to nominate you to the group of existing maintainers. The person who nominates you has to:
This nomination is public and should be sent to the PatternFly mailing list. After the nomination is submitted, two other maintainers have to second the nomination. If no one objects in one week, the nomination is accepted.
Such objections may happen in public on the nomination e-mail thread. However, not everyone is comfortable giving objections publicly. Therefore, it is acceptable for other maintainers to raise their concerns with the sponsor and/or other maintainers privately if they wish to do so. The sponsor is expected to update the nomination e-mail thread to show that it is on hold pending private concerns.
Regardless, while objections are discussed either in private or public, the nomination is on hold until the objections are resolved or the nomination is rejected. In the event of a failed nomination, the sponsor (as part of the discussing group) will know the grounds for the rejection, and can pass along constructive feedback to the candidate. Care should be taken to do this sensitively.
The maintainers team will be reevaluated periodically to ensure it remains up to date. If you are inactive in the community for six months, we will remove you from the maintainers list and revoke your permission, but we will make a mention of you on a list of previous maintainers. In the event that a maintainer continues to disregard good citizenship (or actively disrupts the project), we may need to revoke that person’s status.
The process for revoking someone's maintainer status is a discussion limited to the maintainer team given the sensitive nature of this conversation. The maintainer being discussed should be made aware of the reasons their membership is being discussed and why. It may be that this person simply does not have time and agrees to opt out of this role without any further discussion. If more is required, the process is similar to a nomination. A member should suggest the revocation with a good reason, two people second the motion, and a vote may be called if consensus cannot be reached. Someone from the maintainer team is required to follow up with the person being removed to update them and pass along constructive feedback. Again, care should be taken to do this sensitively.
| Back | FazBrowse Home | New Git URL |