Start contributing to VPDS

Prep: Identify and validate the work

Before proposing a new component, pattern, or enhancement, make sure your code contribution is necessary. Start by exploring existing resources and checking the VPDS backlog.

1. Explore existing resources: Browse components and patterns to avoid duplication.
2. Check the VPDS backlog: Search for open items labeled “contribution” or “in progress” in the VPDS backlog (internal only).
3. Assess design support: Determine if you need design support, especially if you’re introducing a new visual pattern (not just fixing a code bug).

Note: At this time, the VPDS team only has an outlined process for internal code contributions from Visa employees. External contributors may create new issues to work on, but don’t have access to our Jira backlog.

Questions to ask

• Does your contribution solve a common problem?
• Is it flexible enough to serve multiple use cases?
• Will it help other design system users?
• Does it replicate anything in the system? If so, is there evidence that your solution is more effective?
• Is it an enhancement of an existing area of the system, or something new?
• Does it align with Visa’s accessibility and brand standards?
• What impact could your solution have on existing implementations?
• Do you have the necessary resources—such as people, time, and tools—to ensure the contribution meets VPDS standards?
  
  

Intake: Propose your idea

Once you’ve confirmed there’s a gap or opportunity, formally propose your idea. Contributors should submit a detailed proposal and the VPDS team will provide feedback and schedule follow-ups if needed.

1. Determine your type of submission
   a. For bug fixes: Assign the ticket to yourself after reviewing the VPDS backlog (internal only).
   b. For enhancements or new contributions: Complete the VPDS contribution intake form (internal only) and include all required documentation.
   
2. Define acceptance criteria: Clearly outline what success looks like for your issue using our acceptance criteria template (internal only).
3. Initial review: The VPDS team will review your submission, provide feedback, and schedule follow-ups if needed.
4. Present to the contribution guild (for new contributions): If your proposal moves forward, you’ll be invited to present it to the VPDS guild. This meeting provides the opportunity to explain your idea, answer questions, and gather additional feedback.
5. Guild decision (for new contributions): After your presentation, the guild will review and vote on your proposal, considering priorities, business needs, and feasibility. You’ll be notified once a decision is made.

Plan: Align and scope

If your idea is approved, you’ll move into the planning phase. Here, you and the VPDS team will work with you to define the scope and clarify roles.

1. Form a working group: Collaborate with the VPDS team—including design, content, development, and accessibility experts—to align on roles and responsibilities.
2. Define the scope: Decide together what’s in and out of scope, establish required deliverables, and set timelines.
3. Clarify support pathways: Set up check-ins with your VPDS working group or attend office hours (internal only) for additional support.

Set up: Configure your environment

Follow the guidelines for the libraries you’ll be working in to ensure your coding environment is correctly configured.

• HTML/CSS
• Angular
• React
• Flutter

When developing your code, remember to:

• Build using the latest version of Nova and your preferred code library.
• Use and adhere to Visa’s secure coding tools, guidelines, and practices.
• Avoid unnecessary dependencies in your code.

Build: Create and refine

1. Develop the code: Write code to address the issue according to the agreed acceptance criteria.
2. Run automated tests: Verify that all components pass aXe automated accessibility tests. These tests are included in the code libraries.
3. Ensure code coverage: Maintain at least 80% code coverage through testing. Add new tests as needed for your contribution.
4. Add documentation: Document any new classes or properties, and include examples where applicable.
5. Format your code: Use Prettier to maintain consistency and readability. Each web library has its own .prettierrc file at the root, and Prettier is automatically installed as a development dependency.
6. Write standard commit messages: Follow the standard-commit guidelines to format your commit messages clearly and consistently.

Submit: Create a pull request

1. Link the issue: Reference the original issue in your pull request description to close the issue upon merging.
2. Review and feedback: Gather any final feedback and make necessary updates. Note: Not all submissions will be accepted. If not accepted, constructive feedback will be provided.
3. Go live: After submission, your contribution will undergo rigorous accessibility and QA testing by the VPDS team before it’s published. This process may take some time.

Want to contribute design assets or report a design issue?

Learn how you can contribute design assets or report issues.