replaces seesparkbox links

README.md

@@ -39,4 +39,4 @@ How we dance.
 _Inspired by [Thoughtbot's Playbook][inspiration]_
 
 [inspiration]: https://playbook.thoughtbot.com
-[sparkbox]: http://seesparkbox.com
+[sparkbox]: http://sparkbox.com

accessibility/introduction/README.md

@@ -4,12 +4,12 @@
 
 ### Build Right, Build Better, Build Accessibly
 
-For a long time, Sparkbox has had the goal to build right and to build a better web. In the past couple of years, we have invested in and focused on web accessibility as part of these goals: leveling up our developers with [certifications](https://www.accessibilityassociation.org/certification), bringing in people to do usability testing in person, and having a [Maker Series](https://seesparkbox.com/foundry/derek_featherstone_web_accessibility_and_inclusive_design) dedicated to the topic. We believe that all websites should be built accessibly and that accessibility should be a part of our whole process rather than a task we do at the end of a project. By prioritizing accessibility, we build websites that enable a wider audience to access the web while also providing a useful and enjoyable user experience.
+For a long time, Sparkbox has had the goal to build right and to build a better web. In the past couple of years, we have invested in and focused on web accessibility as part of these goals: leveling up our developers with [certifications](https://www.accessibilityassociation.org/certification), bringing in people to do usability testing in person, and having a [Maker Series](https://sparkbox.com/foundry/derek_featherstone_web_accessibility_and_inclusive_design) dedicated to the topic. We believe that all websites should be built accessibly and that accessibility should be a part of our whole process rather than a task we do at the end of a project. By prioritizing accessibility, we build websites that enable a wider audience to access the web while also providing a useful and enjoyable user experience.
 
 
 ### WCAG 2.1 AA Principles Compliance
 
-Sparkbox aims to fulfill the principles of WCAG 2.1 AA, with an especial focus on the experiences of people with physical, hearing, and sight limitations who employ the use of screen readers or keyboard-only technology (the W3C [does not recommend](https://www.w3.org/TR/WCAG21/#cc1) requiring AAA compliance as it can be impossible to attain for certain types of content). Secondarily, we work to create good experiences for people who encounter color contrast issues and for users with cognitive disabilities. However, our user base focus may differ depending on the most common browsers or technologies utilized on our clients’ sites. 
+Sparkbox aims to fulfill the principles of WCAG 2.1 AA, with an especial focus on the experiences of people with physical, hearing, and sight limitations who employ the use of screen readers or keyboard-only technology (the W3C [does not recommend](https://www.w3.org/TR/WCAG21/#cc1) requiring AAA compliance as it can be impossible to attain for certain types of content). Secondarily, we work to create good experiences for people who encounter color contrast issues and for users with cognitive disabilities. However, our user base focus may differ depending on the most common browsers or technologies utilized on our clients’ sites.
 
 We emphasize the **principles** of WCAG over the success criteria because even if someone builds a website that meets every single WCAG AAA success criterion, they may not actually create an accessible experience as a whole. Highlighting principles allows us to focus on the entire experience of the user as they browse a web page, and in this way, we can create a better and more accessible experience than just trying to “check off” boxes on an accessibility task list.
 
@@ -46,7 +46,7 @@ These statistics demonstrate that people with disabilities consist of a huge por
 
 Everyone should be able to access the web. If this weren’t reason enough for us to build accessibly, we also see the following other benefits:
 
-* A potential 27% increase of the consumer base of our websites 
+* A potential 27% increase of the consumer base of our websites
 * Decreased legal risk from ADA lawsuits
 * Mobile and bandwidth-friendly websites
 * Improved SEO and site-searchability rankings

build_process/drops.md

@@ -41,4 +41,4 @@ Also included is a link to view the differences between the previous Release Tag
 [github-flow]: https://guides.github.com/introduction/flow/index.html
 [sparkbox-git-style]: https://github.com/sparkbox/how_to/tree/master/style/git
 [sparkbox-code-reviews]: https://github.com/sparkbox/how_to/tree/master/style/code_reviews
-[sparkbox-content-priority]: https://seesparkbox.com/foundry/content_priority_guide
+[sparkbox-content-priority]: https://sparkbox.com/foundry/content_priority_guide

career/tech-lead-role.md

@@ -3,10 +3,10 @@
 
 ## Overview
 
-*   At Sparkbox, the tech lead is the **right hand to the Project Manager**. 
-*   The success of a tech lead is **measured by the success of the team and the project**. 
+*   At Sparkbox, the tech lead is the **right hand to the Project Manager**.
+*   The success of a tech lead is **measured by the success of the team and the project**.
 *   To be successful, a tech lead needs to be able to **step out of the immediate coding needs of a project** to **understand**, **prepare**, and **regularly articulate the vision** of the project.
-*   Tech lead models [how we work together](https://github.com/sparkbox/standard/blob/master/how-we-work-together.md). 
+*   Tech lead models [how we work together](https://github.com/sparkbox/standard/blob/master/how-we-work-together.md).
 *   A tech lead **empowers and unlocks the team** through communication, leadership, technical skills, and impact.
 
 
@@ -83,7 +83,7 @@
 
 
 
-*   [Making the Leap to Tech Lead (Article, Cromwell)](https://seesparkbox.com/foundry/making_the_leap_to_tech_lead)
+*   [Making the Leap to Tech Lead (Article, Cromwell)](https://sparkbox.com/foundry/making_the_leap_to_tech_lead)
 *   [Making the Leap to Tech Lead (Video, Cromwell)](https://www.youtube.com/watch?v=Lx8BepRpfvg&feature=youtu.be&list=PL6De8qQmbLARL4YgjgJqa3cP83EcXRIrI)
 *   Build Right: Sustainable Software
     *   [Full Day Slides](https://drive.google.com/open?id=1RAdv_2EtRcZEZri-zUaaFXi8supTduC__Cr97UEj4fE)

code-style/code_reviews/README.md

@@ -16,5 +16,5 @@ Don't be a one person wolf pack. If for some reason we have a project with only
 
 ## Additional Reading
 
-- [Code Review](https://seesparkbox.com/foundry/code_review)
-- [Stop Giving Depressing Code Reviews](https://seesparkbox.com/foundry/stop_giving_depressing_code_reviews)
+- [Code Review](https://sparkbox.com/foundry/code_review)
+- [Stop Giving Depressing Code Reviews](https://sparkbox.com/foundry/stop_giving_depressing_code_reviews)

code-style/git/PULL_REQUEST_TEMPLATE.md

@@ -14,7 +14,7 @@ See Story: [ISSUE_NUMBER](ISSUE_URL)
 * [ ] This PR has code changes, and our linters still pass.
 * [ ] This PR affects production code, so it was browser tested (see below).
 * [ ] This PR has new code, so new tests were added or updated, and they pass.
-* [ ] This PR has new SCSS functions, mixins, or variables, so [Sass Tests](https://seesparkbox.com/foundry/how_and_why_we_unit_test_our_sass) were added or updated, and they pass.
+* [ ] This PR has new SCSS functions, mixins, or variables, so [Sass Tests](https://sparkbox.com/foundry/how_and_why_we_unit_test_our_sass) were added or updated, and they pass.
 * [ ] This PR has copy changes, so copy was proofread and approved.
 * [ ] The content of this PR requires documentation, so we added a detailed description of the component's purpose, requirements, quirks, and instructions for use by designers and developers. Along with accessibility information if pertinent.
 

code-style/git/README.md

@@ -319,27 +319,27 @@ Voila! You're done. You've successfully rebased a branch onto the master branch!
 
 ## Additional Resources
 
-- [GitHub Pull Requests for Everyone](https://seesparkbox.com/foundry/github_pull_requests_for_everyone) by Catherine Meade
-- [Give Better Pull Requests With Screencasts](https://seesparkbox.com/foundry/give_better_pull_requests_with_screencasts) by Ethan Muller
-- [Stop Giving Depressing Code Reviews](https://seesparkbox.com/foundry/stop_giving_depressing_code_reviews) by Bryan Braun
-- [Git is a SHA Management Tool](https://seesparkbox.com/foundry/use_git_commands_git_reset_git_log_git_reflog_git_cherry-pick_to_manage_shas) by Melissa Thompson
-- [I Screwed Up Git; How Do I Fix It?](https://seesparkbox.com/foundry/solutions_to_github_issues_with_git_merges_and_commits) by Catherine Meade
-- [Better Pull Requests & Merge Requests With Templates](https://seesparkbox.com/foundry/better_pull_requests_merge_requests_with_templates) by Patrick Fulton
-- [To Squash or Not to Squash?](https://seesparkbox.com/foundry/to_squash_or_not_to_squash) by Divya Sasidharan
-- [How to Not Dread Rebases When Managing Long-Lived Feature Branches](https://seesparkbox.com/foundry/how_to_not_dread_rebases_when_managing_long_lived_feature_branches) by Adam Simpson
+- [GitHub Pull Requests for Everyone](https://sparkbox.com/foundry/github_pull_requests_for_everyone) by Catherine Meade
+- [Give Better Pull Requests With Screencasts](https://sparkbox.com/foundry/give_better_pull_requests_with_screencasts) by Ethan Muller
+- [Stop Giving Depressing Code Reviews](https://sparkbox.com/foundry/stop_giving_depressing_code_reviews) by Bryan Braun
+- [Git is a SHA Management Tool](https://sparkbox.com/foundry/use_git_commands_git_reset_git_log_git_reflog_git_cherry-pick_to_manage_shas) by Melissa Thompson
+- [I Screwed Up Git; How Do I Fix It?](https://sparkbox.com/foundry/solutions_to_github_issues_with_git_merges_and_commits) by Catherine Meade
+- [Better Pull Requests & Merge Requests With Templates](https://sparkbox.com/foundry/better_pull_requests_merge_requests_with_templates) by Patrick Fulton
+- [To Squash or Not to Squash?](https://sparkbox.com/foundry/to_squash_or_not_to_squash) by Divya Sasidharan
+- [How to Not Dread Rebases When Managing Long-Lived Feature Branches](https://sparkbox.com/foundry/how_to_not_dread_rebases_when_managing_long_lived_feature_branches) by Adam Simpson
 
 [angularc]: https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#
 [karmac]: http://karma-runner.github.io/0.8/dev/git-commit-msg.html
 [365]: http://365git.tumblr.com/post/3308646748/writing-git-commit-messages
 [tpope]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
 [Draft PR]: https://github.blog/2019-02-14-introducing-draft-pull-requests/
 [pull request]: https://help.github.com/articles/using-pull-requests
-[Sparkbox]: http://seesparkbox.com
-[pull request template]: https://seesparkbox.com/foundry/better_pull_requests_merge_requests_with_templates
+[Sparkbox]: http://sparkbox.com
+[pull request template]: https://sparkbox.com/foundry/better_pull_requests_merge_requests_with_templates
 [example PR template]: ./PULL_REQUEST_TEMPLATE.md
 [example issue template]: ./ISSUE_TEMPLATE.md
 [Create a branch]: #naming-branches
 [curate your commit history]: #curating-your-commit-history
 [Conventional Commits]: https://www.conventionalcommits.org/en/v1.0.0/
-[Taking Control of your Commit History]: https://seesparkbox.com/foundry/take_control_of_your_commit_history
+[Taking Control of your Commit History]: https://sparkbox.com/foundry/take_control_of_your_commit_history
 [foundry_curated_commits]: https://sparkbox.com/foundry/interactive_rebasing_curates_commits_to_speed_up_pull_request_review_process

code-style/pattern_libraries/README.md

@@ -1,6 +1,6 @@
 # Pattern Libraries
 
-What do we consider a "[pattern library](https://seesparkbox.com/foundry/building_pattern_libraries_in_react_with_storybook)" to be, exactly? At Sparkbox, our pattern libraries typically consist of all of the "components" that make up a project. We usually combine those components into larger pieces or entire "pages" so that we have some kind of static representation of how the components are used.
+What do we consider a "[pattern library](https://sparkbox.com/foundry/building_pattern_libraries_in_react_with_storybook)" to be, exactly? At Sparkbox, our pattern libraries typically consist of all of the "components" that make up a project. We usually combine those components into larger pieces or entire "pages" so that we have some kind of static representation of how the components are used.
 
 Ultimately, what we end up with is a guide for those who are implementing those static components and pages into larger systems, and those who will use our components to build off of in the future.
 

code-style/scss/README.md

@@ -263,5 +263,5 @@ Future developers will be able to learn a lot about this piece of code by the cl
 
 - [ITCSS: Scalable and Maintainable CSS Architecture](https://www.xfive.co/blog/itcss-scalable-maintainable-css-architecture/)
 - [BEM Website](http://getbem.com)
-- [BEM by Example](https://seesparkbox.com/foundry/bem_by_example)
-- [Thoughtful CSS Architecture](https://seesparkbox.com/foundry/thoughtful_css_architecture)
+- [BEM by Example](https://sparkbox.com/foundry/bem_by_example)
+- [Thoughtful CSS Architecture](https://sparkbox.com/foundry/thoughtful_css_architecture)

culture/remote/README.md

@@ -53,6 +53,6 @@ Here are some links to articles and videos we love.
 [State Of Remote Work 2019]: https://buffer.com/state-of-remote-work-2019
 [The 5 Ways We Build Trust on a Fully Remote Team and Why It’s So Valuable]: https://open.buffer.com/trust-remote-team/
 [Why do remote meetings suck so much?]: https://chelseatroy.com/2018/03/29/why-do-remote-meetings-suck-so-much/
-[Effective Collaboration in Remote Project Management]: https://seesparkbox.com/foundry/effective_collaboration_in_remote_project_management
+[Effective Collaboration in Remote Project Management]: https://sparkbox.com/foundry/effective_collaboration_in_remote_project_management
 [The Ultimate Guide to Remote Meetings 2019]: https://slackhq.com/ultimate-guide-remote-meetings
 [All Remote]: https://about.gitlab.com/company/culture/all-remote/

development_process/README.md

@@ -50,4 +50,4 @@ The release phase is when we begin sending our built artifacts to production.
 We don’t believe in a “big bang” release structure, as this presents too much risk and not enough flexibility to ensure we’re building the right thing early on. We believe in releasing the smallest parts of our application as early as possible. This makes the flexibility required in our improve phase possible.
 
 ### Release Often
-Through the use of [feature flags](https://seesparkbox.com/foundry/feature_flags_continuous_deployment), we can ensure that we can track our changes and roll them back quickly without a separate deploy. This mitigates a lot of the risk in deploying new features.
+Through the use of [feature flags](https://sparkbox.com/foundry/feature_flags_continuous_deployment), we can ensure that we can track our changes and roll them back quickly without a separate deploy. This mitigates a lot of the risk in deploying new features.