diff --git a/src/_about/contributing/add-a-component-or-pattern-once-approved.html b/src/_about/contributing/add-a-component-or-pattern-once-approved.html
index 386954091..625ca22a0 100644
--- a/src/_about/contributing/add-a-component-or-pattern-once-approved.html
+++ b/src/_about/contributing/add-a-component-or-pattern-once-approved.html
@@ -8,25 +8,50 @@
- Create a pull request in GitHub in order to add your component or pattern:
+ If your team has the resources to contribute your component or pattern to the Design System, you can complete much of the work on your own.
+ If your team does not have the resources to contribute your component or pattern to the Design System, the Design System Team will complete the work on your behalf. They will:
+
Your documentation should follow the component or pattern template to the best of your ability. Any sections you have trouble filling out simply leave a "TODO:" note for the Design System Team who will review your submission and make edits or ask you questions, as necessary.
Add the component or pattern
+ Contribute to the Design System yourself
-
+
+
Add file
menuAdd file
menuDocument your component or pattern
+ Contribute to the Design System via the Design System Team
+
+
+
+
+ Document your component or pattern
Artifacts (mockups, wireframes, or prototypes)
+ Artifacts (mockups, wireframes, or prototypes)
Artifacts (mockups, wireframes, or prototypes)
New components will enter at the start of the maturity scale at "Use with caution: Candidate". This signals to others that the candidate exists and be something they could consider using.
@@ -47,7 +72,7 @@If an experimental component or pattern sits in the "Use with caution: Candidate" status for 6 months with no validation research documented, it will be removed by the design system team.
-@@ -70,4 +95,6 @@
Proposing a new component or pattern is appropriate if you have an idea for something that should be included in the design system, or if you receive feedback in the Collaboration Cycle that your work may be useful for other teams. Note that the experimental design process is only necessary when a component or pattern will be useful for other VFS teams. Custom components and patterns that will be used only in your product do not need to go through this process.
+- Be sure to check the design system and ensure your component or pattern does not already exist. If your addition overlaps with a current component or pattern, be sure to call that out when you file your request in step 2. + As you build your component or pattern, check the design system and ensure it does not already exist. If your addition overlaps with a current component or pattern, be sure to call that out when you file your request.
- Check the backlog to see if your idea has already been suggested. If you do not see your idea in the backlog, go to step 2. + Next, check the backlog to see if your idea has already been suggested.
+- If you do see your idea in the backlog, message the contributors to see if they are moving forward or not. If not, and you would like to tackle the problem, move forward with step 2. -
- Fill out an Experimental Design System request issue. This should take no more than 10-15 minutes. In the issue you will need to provide justification for this new component or pattern, and link to any artifacts you want to include. +Fill out an Experimental Design System request issue. This should take no more than 10-15 minutes. In the issue you will need to provide justification for this new component or pattern, and link to any artifacts you want to include.
Request a new addition to the Design System @@ -42,13 +45,19 @@
- After filling out the issue, post in the {{ site.slack_channel_name }} slack channel and tag Carol Wong to alert the team that you have filled out an issue and would like to get on the council's agenda. + Note that you do not need to have anything coded at this point, and in fact, we suggest not having anything coded since ideally ideas would be surfaced to the council before teams put effort into building new components. +
++ Additionally, the artifacts you include do not need to be high fidelity. They only need to be able to illustrate your concept. We do, however, encourage some thoughts on how your component or pattern works on mobile.
+- Note that you do not need to have anything coded at this point, and in fact, we suggest not having anything coded since ideally ideas would be surfaced to the council before teams put effort into building new components. + You must validate the design of your new component or pattern with user research. Learn about conducting research at VA. You may conduct research before presenting your work to the Design System Council, or you may present to the Design System Council and receive feedback before you complete a research study.
- Additionally, the artifacts you include do not need to be high fidelity. They only need to be able to illustrate your concept. We do, however, encourage some thoughts on how your component or pattern works on mobile. + Note that even if the Design System Council approves your component or pattern before you conduct research, you must still validate your work with user research and provide your findings to the Design System Council before it can be included in the design system. After research is complete, attach your findings to your Experimental Design request issue, post in the {{ site.slack_channel_name }} Slack channel and tag Carol Wong to alert the team.
- You will present your work to the Design System Council at an upcoming meeting (unless you have requested an asynchronous review). The Design System Council meets every other Thursday at 11am Eastern. Experimental design requests will always be prioritized in this meeting, and teams can assume generally that they will be able to present the same week of the request. In order to kick off this step: + You will present your work to the Design System Council at an upcoming meeting (unless you have requested an asynchronous review). The Design System Council meets every other Thursday at 11am Eastern. Experimental design requests will always be prioritized in this meeting, and teams can assume generally that they will be able to present the same week of the request. +
++ When you are ready to present, post in the {{ site.slack_channel_name }} Slack channel and tag Carol Wong to alert the team that you have filled out an issue and would like to get on the council's agenda. During the meeting, the Design System Council will evaluate the request and make a decision. +
++ If your component or pattern request is rejected, the council will add notes as to why and what they suggest you do instead in the issue.
+ If you feel like the change is simple and does not need further explanation beyond what you have provided in your issue then you may ask to have asynchronous approval when creating the initial request. +
+- If your component or pattern request is rejected, the council will add notes as to why and what they suggest you do instead in the issue. -
- If you feel like the change is simple and does not need further explanation beyond what you have provided in your issue then you may ask to have asynchronous approval when creating the initial request. -
-If you are suggesting a change to something that already exists in the VA.gov Design System, you should go through the New component or pattern process above.
-- If you are requesting a minor change, a change which you feel would be a minor adjustment to current functionality, then you may request an asynchronous review. To do so, complete steps 1 and 2 above and indicate in your request that you would like an asynchronous review by the Design System Council. -
-- If the change you are requesting is a bug in a component or pattern file an issue. For example, if the behavior of the component does not match our documentation or a component is not behaving as expected. If the Design System Team feels the matter needs to be addressed by the Design System Council, we'll let you know in the issue. -
+