Skip to main contentIBM Cloud-Native

Contributing

Roles and responsibilities

Consumers

Consumers are members of the community who are applying assets to their development projects. Anyone who wants to apply any of the assets can be a user. We encourage consumers to participate as evangelists and contributors as well.

Evangelists

Evangelists are members of the community who help others become consumers of the assets. They do so by:

  • Advertising the assets and encouraging others to use them
  • Supporting new consumers and answering questions, such as on Slack (IBM internal)
  • Reporting bugs or missing features through GitHub issues

Contributors

Contributors are members of the community who help maintain, improve, and expand the assets. In addition to using and evangelizing the assets, they make the assets better by:

  • Resolving issues in GitHub to fix bugs, add features, and improve documentation
  • Submitting changes as GitHub pull requests

Maintainers

Project maintainers (aka maintainers) are owners of the project who are committed to the success of the assets in that project. Each project has a team of maintainers, and each team has a lead. In addition to their participation as contributors, maintainers have privileges to:

  • Label, close, and manage GitHub issues
  • Close and merge GitHub pull requests
  • Nominate and vote on new maintainers

Types of teams

Core team

Core team members are IBM employees responsible for the leadership and strategic direction of the set of Catalyst projects as a whole. The core team also directs how the Catalyst strategy will evolve with IBM Cloud product decisions. Core team responsibilities include:

  • Actively engaging with the projects’ communities
  • Setting overall direction and vision
  • Setting priorities and release schedule
  • Focusing on broad, cross-cutting concerns
  • Spinning up or shutting down project teams

The core team will operate the technical steering committee.

Governance

Support

Have questions? Found a bug? Learn where to go and what to do by visiting the Support page.

Contributing

Requirements

Set up your SSH Key GitHub account and install node.js 11 or higher.

Make a pull request

Note: Before you make a pull request, search the issues to see if a similar issue has already been submitted. If a similar issue has been submitted, assign yourself or ask to be assigned to the issue by posting a comment. If the issue does not exist, create a new issue.

When you’re at a good stopping place and you’re ready for feedback from other contributors and maintainers, push your commits to your fork:

Commit tip

Writing commit messages

  • <type> indicates the type of commit that’s being made. This can be: feat, fix, perf, docs, chore, style, refactor
  • <scope> The scope could be anything specifying place of the commit change or the thing(s) that changed.

Commit message format:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

Do not submit pull requests from the master branch of your fork.

git checkout -b { YOUR_BRANCH_NAME }
git add .
git commit -m "fix(table): IE11 positioning error" -m "Fixes #34"
git push origin { YOUR_BRANCH_NAME }

In your browser, navigate to IBM/carbon-components and click the button that reads Compare & pull request

Is it a Breaking Change?

We want to respect semver. It’s important to discern whether your pull request contains breaking changes or not. Sometimes, renaming or removing things in the code can result in breaking changes.

Here are some examples of breaking changes… changing, renaming or removing any of the following:

  • HTML attributes
  • Folders or Files
  • Any SCSS @mixin, $variable or function
  • Any JS function or class

We also practice graceful deprecation when something is slated to be removed — we mark it as deprecated in the current version and remove it in the next major version.

Before you create a pull request, change the base branch depending on what kind of change you’re submitting.

  • Pull requests with non-breaking changes like patches and minor updates use the master as the base branch.
  • Pull requests with breaking changes use the latest major version number branch as the base branch (i.e. 7.0.0 or whatever the next major version is).

Write a title and description then click Create pull request

Updating a pull request

Stay up to date with the activity in your pull request. Maintainers from the Design System team will be reviewing your work and making comments, asking questions and suggesting changes to be made before they merge your code.

:tada: You no longer need to squash commits :tada:

When you need to make a change, add, commit and push to your branch normally.

Once all revisions to your pull request are complete, someone from Design Systems will squash and merge your commits for you.

Edit this page on GitHub