Built site for gh-pages

.nojekyll

@@ -1 +1 @@
-50b23a28
+b755d935

collab_exchange.html

@@ -214,7 +214,13 @@
 <div id="quarto-sidebar-glass" data-bs-toggle="collapse" data-bs-target="#quarto-sidebar,#quarto-sidebar-glass"></div>
 <!-- margin-sidebar -->
     <div id="quarto-margin-sidebar" class="sidebar margin-sidebar">
-
+        <nav id="TOC" role="doc-toc" class="toc-active">
+    <h2 id="toc-title">On this page</h2>
+
+  <ul>
+  <li><a href="#pull-request-pr" id="toc-pull-request-pr" class="nav-link active" data-scroll-target="#pull-request-pr">Pull Request (PR)</a></li>
+  </ul>
+</nav>
     </div>
 <!-- main -->
 <main class="content" id="quarto-document-content">
@@ -236,7 +242,7 @@ <h1 class="title">Code <del>Review</del> Exchange</h1>
 
 </header>
 
-<p>Code Exchange is an asynchronous activity that takes place when a teammate is finished working on an script (or a part of). This teammate will submit a request to another team memeber to look over the code and provide feedback. It is a great way to:</p>
+<p>Code Exchange is an asynchronous activity that takes place when a teammate is finished working on an script (or a part of). This teammate will submit a request to another team member to look over the code and provide feedback. It is a great way to:</p>
 <ul>
 <li>Have one more pair of eyes looking at your code to detect potential bugs / improvements, including analytical aspects of the code</li>
 <li>Motivate development of good documentation</li>
@@ -245,8 +251,14 @@ <h1 class="title">Code <del>Review</del> Exchange</h1>
 <li>Great way to onboard new team members both in terms of code knowledge but also code styling</li>
 </ul>
 <p>The Reviewer should see this activity as a great way to learn from others through <strong>constructive</strong> feedback… and so should the Submitter!!</p>
+<p>There are different way to conduct a code review. It ranges from asking a colleague to look at your code once you reached a milestone, for example a new analysis is working, to leveraging Pull Request (PR), which is a way to ask to merge your changes with the previous version.</p>
+<section id="pull-request-pr" class="level2">
+<h2 class="anchored" data-anchor-id="pull-request-pr">Pull Request (PR)</h2>
+<p>A big advantage of Pull Request is to document and provide a space to discuss the new code and discuss potential modifications. You can even tag others if you want them to chime in.</p>
+<p>To be able to create a PR, you need to first either create a branch or a fork, which are two ways to encapsulate your changes while you are working on them. Once you are done you can ask to send back and merge those changes to the current version of the main branch of the repository (for now we will only merge back to main).</p>
 
 
+</section>
 
 </main> <!-- /main -->
 <div>

collab_pairprog.html

@@ -251,7 +251,7 @@ <h2 class="anchored" data-anchor-id="basic-principles-practices">Basic principle
 <ul>
 <li><strong>Treat each other with kindness, consideration, and respect</strong> - makes group work more fun and sustainable</li>
 <li><strong>Driver/navigator pair programming adapted to work with the whole team</strong> - “For an idea to go from your head into the computer, it <em>must</em> go through someone else’s hands.” Speak at the highest level of abstraction that the driver (and the rest of the team) is able to digest at the moment</li>
-<li><strong>Timed Rotation</strong> - 20-60 minutes. We don’t require that everyone take the driver role; it is everyone’s choice whether to do so</li>
+<li><strong>Timed Rotation</strong> - 20-40 minutes. We don’t require that everyone take the driver role; it is everyone’s choice whether to do so</li>
 <li><strong>Whole Team</strong> - every contributor to the project is an integral part of the whole team; when we don’t have the skills we need within the team, we find someone who does and invite them to work with us to accomplish the needed work</li>
 <li><strong>Reflect, Tune, and Adjust Frequently</strong> - based on agile principle: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”</li>
 </ul>
@@ -260,10 +260,10 @@ <h2 class="anchored" data-anchor-id="basic-principles-practices">Basic principle
 <h2 class="anchored" data-anchor-id="tips-and-tricks-for-effective-team-programming">Tips and Tricks for Effective Team Programming</h2>
 <p>Adapted from Corey Johannsen: https://blog.newrelic.com/2017/10/31/mob-programming-hurdles/</p>
 <ul>
-<li><strong>Suggest, don’t dictate:</strong> Instead of telling the driver what to type into their editor, we explain what we’re trying to accomplish and then help the driver find the best solution. We’ve found that drivers learn better this way, and they don’t just end up feeling like a stenographer. Whenever possible, we ask questions that lead the driver to discover the answers on their own.</li>
-<li><strong>Stay focused and be present:</strong> Shut your laptop and put your phone away. I’ve struggled with following this guideline—we all have—and I recognize that the distraction almost always affects the rest of the mob. We tell all our mob members to be present, and if you can’t, it’s OK to leave until you can be.</li>
+<li><strong>Suggest, don’t dictate:</strong> Instead of telling the driver what to type into their editor, we explain what we are trying to accomplish and then help the driver find the best solution. We have found that drivers learn better this way, and they don’t just end up feeling like a stenographer. Whenever possible, we ask questions that lead the driver to discover the answers on their own.</li>
+<li><strong>Stay focused and be present:</strong> Shut your laptop and put your phone away. I have struggled with following this guideline—we all have—and I recognize that the distraction almost always affects the rest of the mob. We tell all our mob members to be present, and if you can not, it is OK to leave until you can be.</li>
 <li><strong>Use a timer, but be ready to pause it:</strong> We switch drivers every 20 - 60 minutes. However, we often wander off implementation into design discussions—it’s unavoidable—so this is when we pause the timer. This is another key guideline of our mob: the time you spend driving should be dedicated to writing the code that helps complete the task, not discussing design solutions.</li>
-<li><strong>Set specific tasks for each session:</strong> When our mob gathers for a session, we first agree on and create a checklist of the tasks we are going to complete, and order them by priority on a whiteboard. This ensures we are all focused on the same task and keeps us moving forward. Additionally, this keeps us aligned with Minimal Marketable Feature (MMF) work, which we can communicate with our engineering and product managers to assure them we’re completing tasks that align with developing small, self-contained features that demonstrate immediate customer value.</li>
+<li><strong>Set specific tasks for each session:</strong> When our mob gathers for a session, we first agree on and create a checklist of the tasks we are going to complete, and order them by priority on a whiteboard. This ensures we are all focused on the same task and keeps us moving forward. Additionally, this keeps us aligned with Minimal Marketable Feature (MMF) work, which we can communicate with our engineering and product managers to assure them we are completing tasks that align with developing small, self-contained features that demonstrate immediate customer value.</li>
 </ul>
 </section>
 <section id="aknowledgements" class="level2">

search.json

@@ -32,7 +32,14 @@
     "href": "collab_exchange.html",
     "title": "Code Review Exchange",
     "section": "",
-    "text": "Code Exchange is an asynchronous activity that takes place when a teammate is finished working on an script (or a part of). This teammate will submit a request to another team memeber to look over the code and provide feedback. It is a great way to:\n\nHave one more pair of eyes looking at your code to detect potential bugs / improvements, including analytical aspects of the code\nMotivate development of good documentation\nGenerate conversation about code styling\nHave several team members sharing knowledge\nGreat way to onboard new team members both in terms of code knowledge but also code styling\n\nThe Reviewer should see this activity as a great way to learn from others through constructive feedback… and so should the Submitter!!"
+    "text": "Code Exchange is an asynchronous activity that takes place when a teammate is finished working on an script (or a part of). This teammate will submit a request to another team member to look over the code and provide feedback. It is a great way to:\nThe Reviewer should see this activity as a great way to learn from others through constructive feedback… and so should the Submitter!!\nThere are different way to conduct a code review. It ranges from asking a colleague to look at your code once you reached a milestone, for example a new analysis is working, to leveraging Pull Request (PR), which is a way to ask to merge your changes with the previous version."
+  },
+  {
+    "objectID": "collab_exchange.html#pull-request-pr",
+    "href": "collab_exchange.html#pull-request-pr",
+    "title": "Code Review Exchange",
+    "section": "Pull Request (PR)",
+    "text": "Pull Request (PR)\nA big advantage of Pull Request is to document and provide a space to discuss the new code and discuss potential modifications. You can even tag others if you want them to chime in.\nTo be able to create a PR, you need to first either create a branch or a fork, which are two ways to encapsulate your changes while you are working on them. Once you are done you can ask to send back and merge those changes to the current version of the main branch of the repository (for now we will only merge back to main)."
   },
   {
     "objectID": "coding.html",
@@ -95,14 +102,14 @@
     "href": "collab_pairprog.html#basic-principles-practices",
     "title": "Pair Programming",
     "section": "Basic principles & practices",
-    "text": "Basic principles & practices\nAdapted from Woody Zuill https://www.agileconnection.com/article/getting-started-mob-programming\n\nTreat each other with kindness, consideration, and respect - makes group work more fun and sustainable\nDriver/navigator pair programming adapted to work with the whole team - “For an idea to go from your head into the computer, it must go through someone else’s hands.” Speak at the highest level of abstraction that the driver (and the rest of the team) is able to digest at the moment\nTimed Rotation - 20-60 minutes. We don’t require that everyone take the driver role; it is everyone’s choice whether to do so\nWhole Team - every contributor to the project is an integral part of the whole team; when we don’t have the skills we need within the team, we find someone who does and invite them to work with us to accomplish the needed work\nReflect, Tune, and Adjust Frequently - based on agile principle: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”"
+    "text": "Basic principles & practices\nAdapted from Woody Zuill https://www.agileconnection.com/article/getting-started-mob-programming\n\nTreat each other with kindness, consideration, and respect - makes group work more fun and sustainable\nDriver/navigator pair programming adapted to work with the whole team - “For an idea to go from your head into the computer, it must go through someone else’s hands.” Speak at the highest level of abstraction that the driver (and the rest of the team) is able to digest at the moment\nTimed Rotation - 20-40 minutes. We don’t require that everyone take the driver role; it is everyone’s choice whether to do so\nWhole Team - every contributor to the project is an integral part of the whole team; when we don’t have the skills we need within the team, we find someone who does and invite them to work with us to accomplish the needed work\nReflect, Tune, and Adjust Frequently - based on agile principle: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”"
   },
   {
     "objectID": "collab_pairprog.html#tips-and-tricks-for-effective-team-programming",
     "href": "collab_pairprog.html#tips-and-tricks-for-effective-team-programming",
     "title": "Pair Programming",
     "section": "Tips and Tricks for Effective Team Programming",
-    "text": "Tips and Tricks for Effective Team Programming\nAdapted from Corey Johannsen: https://blog.newrelic.com/2017/10/31/mob-programming-hurdles/\n\nSuggest, don’t dictate: Instead of telling the driver what to type into their editor, we explain what we’re trying to accomplish and then help the driver find the best solution. We’ve found that drivers learn better this way, and they don’t just end up feeling like a stenographer. Whenever possible, we ask questions that lead the driver to discover the answers on their own.\nStay focused and be present: Shut your laptop and put your phone away. I’ve struggled with following this guideline—we all have—and I recognize that the distraction almost always affects the rest of the mob. We tell all our mob members to be present, and if you can’t, it’s OK to leave until you can be.\nUse a timer, but be ready to pause it: We switch drivers every 20 - 60 minutes. However, we often wander off implementation into design discussions—it’s unavoidable—so this is when we pause the timer. This is another key guideline of our mob: the time you spend driving should be dedicated to writing the code that helps complete the task, not discussing design solutions.\nSet specific tasks for each session: When our mob gathers for a session, we first agree on and create a checklist of the tasks we are going to complete, and order them by priority on a whiteboard. This ensures we are all focused on the same task and keeps us moving forward. Additionally, this keeps us aligned with Minimal Marketable Feature (MMF) work, which we can communicate with our engineering and product managers to assure them we’re completing tasks that align with developing small, self-contained features that demonstrate immediate customer value."
+    "text": "Tips and Tricks for Effective Team Programming\nAdapted from Corey Johannsen: https://blog.newrelic.com/2017/10/31/mob-programming-hurdles/\n\nSuggest, don’t dictate: Instead of telling the driver what to type into their editor, we explain what we are trying to accomplish and then help the driver find the best solution. We have found that drivers learn better this way, and they don’t just end up feeling like a stenographer. Whenever possible, we ask questions that lead the driver to discover the answers on their own.\nStay focused and be present: Shut your laptop and put your phone away. I have struggled with following this guideline—we all have—and I recognize that the distraction almost always affects the rest of the mob. We tell all our mob members to be present, and if you can not, it is OK to leave until you can be.\nUse a timer, but be ready to pause it: We switch drivers every 20 - 60 minutes. However, we often wander off implementation into design discussions—it’s unavoidable—so this is when we pause the timer. This is another key guideline of our mob: the time you spend driving should be dedicated to writing the code that helps complete the task, not discussing design solutions.\nSet specific tasks for each session: When our mob gathers for a session, we first agree on and create a checklist of the tasks we are going to complete, and order them by priority on a whiteboard. This ensures we are all focused on the same task and keeps us moving forward. Additionally, this keeps us aligned with Minimal Marketable Feature (MMF) work, which we can communicate with our engineering and product managers to assure them we are completing tasks that align with developing small, self-contained features that demonstrate immediate customer value."
   },
   {
     "objectID": "collab_pairprog.html#aknowledgements",

sitemap.xml

@@ -2,38 +2,38 @@
 <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
   <url>
     <loc>https://github.com/UCSB-Library-Research-Data-Services/reproducible-lab/github_teams.html</loc>
-    <lastmod>2023-11-09T05:22:47.028Z</lastmod>
+    <lastmod>2023-11-09T05:49:56.416Z</lastmod>
   </url>
   <url>
     <loc>https://github.com/UCSB-Library-Research-Data-Services/reproducible-lab/collab_exchange.html</loc>
-    <lastmod>2023-11-09T05:22:46.208Z</lastmod>
+    <lastmod>2023-11-09T05:49:55.856Z</lastmod>
   </url>
   <url>
     <loc>https://github.com/UCSB-Library-Research-Data-Services/reproducible-lab/coding.html</loc>
-    <lastmod>2023-11-09T05:22:45.300Z</lastmod>
+    <lastmod>2023-11-09T05:49:55.252Z</lastmod>
   </url>
   <url>
     <loc>https://github.com/UCSB-Library-Research-Data-Services/reproducible-lab/data_mgmt.html</loc>
-    <lastmod>2023-11-09T05:22:44.452Z</lastmod>
+    <lastmod>2023-11-09T05:49:54.700Z</lastmod>
   </url>
   <url>
     <loc>https://github.com/UCSB-Library-Research-Data-Services/reproducible-lab/github_org.html</loc>
-    <lastmod>2023-11-09T05:22:43.312Z</lastmod>
+    <lastmod>2023-11-09T05:49:53.936Z</lastmod>
   </url>
   <url>
     <loc>https://github.com/UCSB-Library-Research-Data-Services/reproducible-lab/github_template.html</loc>
-    <lastmod>2023-11-09T05:22:44.096Z</lastmod>
+    <lastmod>2023-11-09T05:49:54.456Z</lastmod>
   </url>
   <url>
     <loc>https://github.com/UCSB-Library-Research-Data-Services/reproducible-lab/index.html</loc>
-    <lastmod>2023-11-09T05:22:44.888Z</lastmod>
+    <lastmod>2023-11-09T05:49:54.988Z</lastmod>
   </url>
   <url>
     <loc>https://github.com/UCSB-Library-Research-Data-Services/reproducible-lab/collab_pairprog.html</loc>
-    <lastmod>2023-11-09T05:22:45.820Z</lastmod>
+    <lastmod>2023-11-09T05:49:55.580Z</lastmod>
   </url>
   <url>
     <loc>https://github.com/UCSB-Library-Research-Data-Services/reproducible-lab/github_intro.html</loc>
-    <lastmod>2023-11-09T05:22:46.560Z</lastmod>
+    <lastmod>2023-11-09T05:49:56.084Z</lastmod>
   </url>
 </urlset>