Contribute to Camp
Because we share ownership of Camp across teams, our design system is able to improve and evolve at scale from a variety of contribution types. Design system contributions can vary from to ideas and content suggestions, to component and documentation deliverables.
Contribute design
Determining contributions
When designing, you may be creating a design token, component, or pattern that doesn’t exist in Camp. If there is potential for it to be reusable or a helpful addition to an existing component, you can reach out to the Design Systems team to make a contribution. This can be done either by reaching out to us in #help-design-systems or attending one of our Design Systems office hours.
When a contribution has been identified, it is grouped into one of three categories:
- Light contribution: making a small design change to an existing component
- Medium contribution: making a bigger change to an existing component
- Heavy contribution: creating a brand new component, pattern, or token
For more examples of this model, reference Zalando’s Design System Contribution Model .
Contribution size examples
In addition to the flow chart above, you can use these examples to help understand the expected size of your contribution.
Light contribution
A light contribution is a small tweak that doesn’t require more than a few extra additions of documentation to what already exists. Good examples of this include changing the orientation of an existing component, such as as component like steps, where the design is exactly the same in both orientations and would be a simple direction variant addition to the existing component. Other potential examples for a light addition would be changing the size of a component, such as a new KPI card size, or adding the ability to include an icon in an existing component, such as inside of a chip.
Medium contribution
A contribution is escalated to medium when there is a gap in Camp that doesn’t support your design needs. A great example of this is our checkbox chip group, which could have potentially leveraged checkboxes, but would have been a much more awkward user experience as a result. By noticing the similarities it shares with chips and using that as a base instead of documenting an entirely new component, the scale of the contribution is a medium.
Large contribution
Simply put, large is anything bigger than a medium. By default this would include any new component, as well as any significant updates to large components such as rich text editor or tables that impact the usability of the entire component.
Contribution process
Below is a general outline of the contribution process. This may vary depending on both the size of the contribution as well as the level of commitment agreed upon between the designer and Design Systems team.
Reach out to us
Post in #help-design-systems or attend one of our Design Systems office hours to let us know the proposed contribution and, if applicable, provide any design work related to the contribution. This can be an idea, an initial concept, or it can be a design solution. The goal is to help us understand what you are trying to achieve, and why it can’t currently be achieved with Camp.
Kick-off
When contributions are set to move forward, a ticket is written on our Jira board for the work to be done. For medium and heavy contributions, a kick-off meeting is scheduled to agree on the scope of the contribution, discuss the involvement from both the designer and Design System team, and confirm timelines. For medium and heavy contributions, there will be additional documentation that needs to be added to Camp, or updates to the components in Figma themselves. In this kick-off meeting, the division of work will be agreed upon.
Collaboration
Collaboration can include all aspects of working on the contribution, including but not limited to:
- Component use cases and types
- Component anatomy, including any optional elements
- Component states
- Component localization and accessibility
Your time is valuable. We do not expect you to put together all (or any) of the documentation for a given component unless you want to, which will be discussed in the kick-off meeting beforehand.
Design review
Before we publish the contribution, we want to ensure that it conforms to our standards for accessibility, consistency, and usability. For medium and heavy contributions, they should first be peer reviewed by other designers either in our product design Slack channels or in design reviews. The Design Systems team will be responsible for a final design review, and fully vet the component and documentation from a design and engineering perspective.
Publication
If applicable, documentation is added to Figma page. If you have volunteered to add documentation to Figma, make sure the Design Systems team knows when it is complete so that the corresponding docs site is also updated, which needs to be done by us. Upon publishing, communicate with designers in one of our weekly meetings of the contribution so that they are informed of the update. For heavy contributions, consider demoing use cases and the problem it solves.
Contribute code
Get the conversation started! Reach out to us in the #help-design-systems channel in Slack.
Whether you want to contribute a bug fix or an entirely new component, early conversation with the Design Systems team can help in many ways. We can help to make sure the contribution makes sense to exist in Camp and provide any design or development guidance necessary.
Contributing a change
Refer to the Camp repo’s README.md documentation for details on setting up Camp locally, naming commit messages, etc.
When you’re ready, make an MR with your changes, pointed to the main branch and paste the link in the #help-design-systems Slack channel. Be sure to let us know your timeline and urgency so we can plan accordingly.
Testing your change
Whether you are contributing a bugfix or a new component, feature, or other enhancement, tests should either be included as part of the update or ticketed as a “fast follow” for urgent updates. You can reference the guides linked below for our current testing standards and practices, or ask a DS team member to help guide you toward what kinds of tests are required for your particular case.
DS testing practices | Visual test writing practices
Review process
When you’re ready, make an MR with your work, pointed to the main branch and share the link in the #help-design-systems Slack channel.
If you are working on something that requires these changes in a timely manner, let the Design Systems team know and we’ll do everything we can to make the approval process accommodate that timeline.
Once an MR has been submitted and the Slack notification has been made, the following journey will be initiated in order to approve the contribution.
Design review
We use a testing tool called Chromatic to help us detect visual updates and regressions in Camp components.
-
When visual changes are detected, a new component build is created in Chromatic and a designer is required to review and approve the changes
-
There may be feedback that comes from the design review that requires some updates to the component. When new changes are pushed up, a new build is created for another design review pass, and this continues until the visual updates are fully vetted and approved.
-
After the build has been approved, rerun the pipeline job and it should succeed! ✅
Code review
- A member of the DS team will review your MR
-
We may create an internal Jira ticket for reviewing the submission if needed
-
We will review all code changes and run local Storybook to confirm the changes are working as expected
-
During local review and depending on time constraints, Camp dev may add small changes as needed directly to the MR while reviewing to speed the process along
-
Code comments and a list of review items will be added to the MR for tracking
-
The Camp dev will communicate with the author and any other stakeholders required to review the design and talk through the items that need resolving for approval. This is often asynchronous, but if you’d like to meet and sync that way let us know and we’re happy to do so!
- Flexibility depending on the authors time constraints may be taken. Tickets may be made for the Design Systems team to resolve additional considerations, etc. that may not be mission critical to the component.
- Once review items have been resolved on the MR, it may be approved by the Design Systems team, then merged.
Debugging across packages
Sometimes you will need to debug a Camp component from within the application (e.g., ac-frontend or platform-monorepo). This is typically where npm link and yarn link are useful, but we have consistently had issues using across Camp and other packages. We have had success using yalc instead. Below are the steps we use.
Installation
// Install yalc locally
npm i -g yalc
// cd into the package you would like to work on in Camp and publish using yalc
cd camp/packages/components/dropdown
yalc publish
// cd into the project you are testing in the application (e.g. ac-frontend) and
// install the other package using yalc
cd ac-frontend
yalc add @activecampaign/camp-components-dropdownThe commands above will connect the two packages locally on your computer and you will notice it because of the package.json change, e.g. "@activecampaign/camp-components-dropdown": "file:.yalc/@activecampaign/camp-components-dropdown",
Reloading
When you make a change in the Camp component, it needs to be compiled and published using yalc. You can do that with one command:
yalc publish --push
Then you will need to restart your app on your end (e.g., in ac-frontend you might have to run yarn start again.)