diff --git a/app/views/pages/what.html.erb b/app/views/pages/what.html.erb
index a1e8d21d3..8eed140a5 100644
--- a/app/views/pages/what.html.erb
+++ b/app/views/pages/what.html.erb
@@ -39,7 +39,7 @@
     The creator of CodeTriage, <a href="https://www.schneems.com/">Richard Schneeman</a>, was surprised to learn one day that the Ruby on Rails core team (of about 7 or so people) were responsible for handling ALL the issues opened on the Rails GitHub repo. At the time, there were about 700 or so issues. These maintainers are hugely valuable to the project due to their depth of knowledge, however keeping up with issues was taking a huge amount of time. Would you rather these highly specialized maintainers spend their time developing new features and actually fix bugs, or would you want them to spend their days responding to hundreds of issues? Asking for simple questions like "what version of Rails are you using?", and "can you provide an <a href="/example_app">example app</a>?", and "is this fixed on master?”.
   </p>
   <p>
-    While asking these questions might only take 5 or 10 minutes of time, the sheer volume of issues per maintainer was unreasonable. This was highlighted by the herculean efforts of another developer <a href="https://twitter.com/steveklabnik">Steve Klabnik</a>, who went through every single issue and responded to all of them in a marathon session spanning multiple days. The effort got him accolades and commit access to the Rails repo. While he deserves the praise, the efforts were ultimately unsustainable.
+    While asking these questions might only take 5 or 10 minutes of time, the sheer volume of issues per maintainer was unreasonable. This was highlighted by the herculean efforts of another developer <a href="https://steveklabnik.com/">Steve Klabnik</a>, who went through every single issue and responded to all of them in a marathon session spanning multiple days. The effort got him accolades and commit access to the Rails repo. While he deserves the praise, the efforts were ultimately unsustainable.
   </p>
   <p>
     Instead of one developer responding to hundreds of issues, it makes more sense to democratize the process and spread the load around. What if we could have hundreds of developers each only reviewing a handful of issues. That's why CodeTriage was created.
@@ -82,7 +82,7 @@
     CodeTriage is all about helping people get started and get more involved in Open Source. The service is a volunteer (and Open Source) effort. A huge thank you to <a href="https://github.com/codetriage/codetriage/graphs/contributors">all our contributors!</a>. If you have ideas for tools that can help people make impactful contributions to open source please let us know with an <a href="https://github.com/codetriage/codetriage/issues">issue</a>.
   </p>
   <p>
-    If you're not a <%= link_to "CodeTriage member already", user_github_omniauth_authorize_path, method: :post %>, what are you waiting for? <%= link_to "Discover how to make your Open Source journey approachable and sustainable", user_github_omniauth_authorize_path %>. Get started!
+    If you're not a <%= link_to "CodeTriage member already", user_github_omniauth_authorize_path, method: :post %>, what are you waiting for? <%= link_to "Discover how to make your Open Source journey approachable and sustainable", user_github_omniauth_authorize_path, method: :post %>. Get started!
   </p>
   <br />
   <center>
diff --git a/app/views/university/picking_a_repo.md.erb b/app/views/university/picking_a_repo.md.erb
index 90bb92a63..f7fdca265 100644
--- a/app/views/university/picking_a_repo.md.erb
+++ b/app/views/university/picking_a_repo.md.erb
@@ -27,7 +27,7 @@ The best people to write features and documentation for a piece of software are
 
 ## How many Repos should I subscribe to?
 
-When you're getting started contributing to open source, many developers have a goal. For example, they want a commit in a large library or framework. For instance, many Ruby developers want to contribute to [rails/rails](). If your open-source goal includes a specific repo, then definitely subscribe to that one right away.
+When you're getting started contributing to open source, many developers have a goal. For example, they want a commit in a large library or framework. For instance, many Ruby developers want to contribute to [rails/rails](https://github.com/rails/rails). If your open-source goal includes a specific repo, then definitely subscribe to that one right away.
 
 In addition to a famous repository, we also suggest that you subscribe to a smaller repo. Why? One person can make a significant impact on a smaller project. Also, smaller projects are generally easier to fit into your brain. You'll pick up different complementary skillsets when you work with projects of various sizes.