Built site for gh-pages

.nojekyll

@@ -1 +1 @@
-58530976
+013ea0f9

CONTRIBUTING.html

@@ -274,9 +274,10 @@ <h3 class="anchored" data-anchor-id="pull-requests">Pull requests</h3>
 </section>
 <section id="deployment" class="level3">
 <h3 class="anchored" data-anchor-id="deployment">Deployment</h3>
-<p>While you are working on changes you can render the site locally using <code>quarto render</code> and if you want to preview it you can use <code>quarto render</code>.</p>
+<p>While you are working on changes you can render the site locally using <code>quarto render</code> and if you want to preview it you can use <code>quarto preview</code>.</p>
 <p>The website itself is deployed through github actions and is the reason that we will use pull requests as a way to not only act as a checkpoint as to what content is added to the website but also as a means to test that any changes that are made to the files will not break the deployment workflow.</p>
-<p>This is all automated and you do not need to manually activate these deployments however, if they fail you will not be able to merge your pull request and it is at this point that you will need to work out what has caused the build to fail. You can refer to the build logs on Github but it might be easier to run <code>quarto render</code> locally and see what the error messages are from there.</p>
+<p>This is all automated and you <em>should</em> not need to manually activate these deployments however, if they fail you will not be able to merge your pull request and it is at this point that you will need to work out what has caused the build to fail. You can refer to the build logs on Github but it might be easier to run <code>quarto render</code> locally and see what the error messages are from there.</p>
+<p>The only time that you will need to first render the site locally before publishing is if you modify any code-based content. This is because we use the freeze functionality that allows us to store partial builds of the website nad makes remote rendering mush more efficient. Currently this will only apply to changes made to the collaborators map in <code>people.yml</code>.</p>
 
 
 </section>

research.html

@@ -187,7 +187,7 @@
 <p>Blah blah blah about research projects/axes</p>
 <div id="listing-research" class="quarto-listing quarto-listing-container-grid">
 <div class="list grid quarto-listing-cols-3">
-<div class="g-col-1" data-index="0" data-listing-file-modified-sort="1736319852023" data-listing-reading-time-sort="1" data-listing-word-count-sort="22">
+<div class="g-col-1" data-index="0" data-listing-file-modified-sort="1736321759098" data-listing-reading-time-sort="1" data-listing-word-count-sort="22">
 <a href="./research/populations/index.html" class="quarto-grid-link">
 <div class="quarto-grid-item card h-100 card-left">
 <p class="card-img-top">
@@ -207,7 +207,7 @@ <h5 class="no-anchor card-title listing-title">
 </div>
 </div></a>
 </div>
-<div class="g-col-1" data-index="1" data-listing-file-modified-sort="1736319851983" data-listing-reading-time-sort="1" data-listing-word-count-sort="157">
+<div class="g-col-1" data-index="1" data-listing-file-modified-sort="1736321759059" data-listing-reading-time-sort="1" data-listing-word-count-sort="157">
 <a href="./research/foodwebs/index.html" class="quarto-grid-link">
 <div class="quarto-grid-item card h-100 card-left">
 <p class="card-img-top">
@@ -227,7 +227,7 @@ <h5 class="no-anchor card-title listing-title">
 </div>
 </div></a>
 </div>
-<div class="g-col-1" data-index="2" data-listing-file-modified-sort="1736319851963" data-listing-reading-time-sort="1" data-listing-word-count-sort="164">
+<div class="g-col-1" data-index="2" data-listing-file-modified-sort="1736321759039" data-listing-reading-time-sort="1" data-listing-word-count-sort="164">
 <a href="./research/conservation/index.html" class="quarto-grid-link">
 <div class="quarto-grid-item card h-100 card-left">
 <p class="card-img-top">

search.json

@@ -116,7 +116,7 @@
     "href": "CONTRIBUTING.html",
     "title": "Welcome!",
     "section": "",
-    "text": "report an issue or suggest new content – open an issue on GitHub\nimprove the documentation – suggest changes in the various READMEs if instructions are unclear\n\n\n\n\nHave a look at the current Julia documentation.\n\n\n\nPlease use emojis, this helps visually sorting through the commits (and makes for a fun time). Inspiration taken from sciencegitmojis\n\n\n\n\n\n\n\n\nIf the commit is about…\n…then use\nExample\n\n\n\n\nWork in progress\n:construction:\n:construction: new output structure\n\n\nBug fix\n:bug:\n:bug: mean fails if NA\n\n\nFixing typos\n:pencil2:\n:pencil2: README\n\n\nCode maintenance\n:wrench:\n:wrench: fix variable names\n\n\nNew test\n:clapper:\n:clapper: wget JSON resource\n\n\nPlot figures\n:bar_chart:\n:bar_chart: example boundaries\n\n\nNew data\n:cd:\n:cd: example pollination network\n\n\nNew feature\n:sparkles:\n:sparkles: (insert achievement)\n\n\nDocumentation\n:books:\n:books: lattice function\n\n\nPerformance improvement\n:racehorse:\n:racehorse: parallelizes models by default\n\n\nUpcoming release\n:package:\n:package: v1.0.6\n\n\nUgly but working code\n:dragon:\n:dragon: added lattice function\n\n\nWorking on code that doesn’t work but I want to go home\n:neutral_face:\n:neutral_face: for triangulation\n\n\nI forgot to save everything before committing\n:sandwich:\n:sandwich: what is saving\n\n\nJettisoned something\n:boom:\n:boom: manifest\n\n\n\n\n\n\nThis section describes the general steps to make sure that your contribution is integrated rapidly. Note that the main branch is protected and you will be unable to make any changes directly but rather through pull requests. The general workflow is as follows:\n\nCreate an issue that outlines proposed content or fixes\nFork the repository (see Branches, etc. below)\nCreate an explicitly named branch from main\nCreate a pull request as soon as you make the first commit and link this to the relevant issue\nBe as explicit as possible on your goals\nDo not squash / rebase commits while you work – we will do so when merging\n\n\n\nCreating a pull request before you push any code will signal that you are interested in contributing to the project. Once this is done, push often, and be explicit about what the commits do (see commits, below). This gives the opportunity for feedback during your work, and allow for tweaks in what you are doing.\nA good pull request (in addition to satisfying to all of the criteria below) is:\n\nSingle purpose - it should do one thing, and one thing only\nShort - it should ideally involve less than 250 lines of code\nLimited in scope - it should ideally not span more than a handful of files\nWell tested and well documented\nWritten in a style similar to the rest of the codebase\n\nThis will ensure that your contribution is rapidly reviewed and evaluated.\n\n\n\nWhile you are working on changes you can render the site locally using quarto render and if you want to preview it you can use quarto render.\nThe website itself is deployed through github actions and is the reason that we will use pull requests as a way to not only act as a checkpoint as to what content is added to the website but also as a means to test that any changes that are made to the files will not break the deployment workflow.\nThis is all automated and you do not need to manually activate these deployments however, if they fail you will not be able to merge your pull request and it is at this point that you will need to work out what has caused the build to fail. You can refer to the build logs on Github but it might be easier to run quarto render locally and see what the error messages are from there."
+    "text": "report an issue or suggest new content – open an issue on GitHub\nimprove the documentation – suggest changes in the various READMEs if instructions are unclear\n\n\n\n\nHave a look at the current Julia documentation.\n\n\n\nPlease use emojis, this helps visually sorting through the commits (and makes for a fun time). Inspiration taken from sciencegitmojis\n\n\n\n\n\n\n\n\nIf the commit is about…\n…then use\nExample\n\n\n\n\nWork in progress\n:construction:\n:construction: new output structure\n\n\nBug fix\n:bug:\n:bug: mean fails if NA\n\n\nFixing typos\n:pencil2:\n:pencil2: README\n\n\nCode maintenance\n:wrench:\n:wrench: fix variable names\n\n\nNew test\n:clapper:\n:clapper: wget JSON resource\n\n\nPlot figures\n:bar_chart:\n:bar_chart: example boundaries\n\n\nNew data\n:cd:\n:cd: example pollination network\n\n\nNew feature\n:sparkles:\n:sparkles: (insert achievement)\n\n\nDocumentation\n:books:\n:books: lattice function\n\n\nPerformance improvement\n:racehorse:\n:racehorse: parallelizes models by default\n\n\nUpcoming release\n:package:\n:package: v1.0.6\n\n\nUgly but working code\n:dragon:\n:dragon: added lattice function\n\n\nWorking on code that doesn’t work but I want to go home\n:neutral_face:\n:neutral_face: for triangulation\n\n\nI forgot to save everything before committing\n:sandwich:\n:sandwich: what is saving\n\n\nJettisoned something\n:boom:\n:boom: manifest\n\n\n\n\n\n\nThis section describes the general steps to make sure that your contribution is integrated rapidly. Note that the main branch is protected and you will be unable to make any changes directly but rather through pull requests. The general workflow is as follows:\n\nCreate an issue that outlines proposed content or fixes\nFork the repository (see Branches, etc. below)\nCreate an explicitly named branch from main\nCreate a pull request as soon as you make the first commit and link this to the relevant issue\nBe as explicit as possible on your goals\nDo not squash / rebase commits while you work – we will do so when merging\n\n\n\nCreating a pull request before you push any code will signal that you are interested in contributing to the project. Once this is done, push often, and be explicit about what the commits do (see commits, below). This gives the opportunity for feedback during your work, and allow for tweaks in what you are doing.\nA good pull request (in addition to satisfying to all of the criteria below) is:\n\nSingle purpose - it should do one thing, and one thing only\nShort - it should ideally involve less than 250 lines of code\nLimited in scope - it should ideally not span more than a handful of files\nWell tested and well documented\nWritten in a style similar to the rest of the codebase\n\nThis will ensure that your contribution is rapidly reviewed and evaluated.\n\n\n\nWhile you are working on changes you can render the site locally using quarto render and if you want to preview it you can use quarto preview.\nThe website itself is deployed through github actions and is the reason that we will use pull requests as a way to not only act as a checkpoint as to what content is added to the website but also as a means to test that any changes that are made to the files will not break the deployment workflow.\nThis is all automated and you should not need to manually activate these deployments however, if they fail you will not be able to merge your pull request and it is at this point that you will need to work out what has caused the build to fail. You can refer to the build logs on Github but it might be easier to run quarto render locally and see what the error messages are from there.\nThe only time that you will need to first render the site locally before publishing is if you modify any code-based content. This is because we use the freeze functionality that allows us to store partial builds of the website nad makes remote rendering mush more efficient. Currently this will only apply to changes made to the collaborators map in people.yml."
   },
   {
     "objectID": "CONTRIBUTING.html#dont-know-where-to-start",
@@ -144,7 +144,7 @@
     "href": "CONTRIBUTING.html#workflow",
     "title": "Welcome!",
     "section": "",
-    "text": "This section describes the general steps to make sure that your contribution is integrated rapidly. Note that the main branch is protected and you will be unable to make any changes directly but rather through pull requests. The general workflow is as follows:\n\nCreate an issue that outlines proposed content or fixes\nFork the repository (see Branches, etc. below)\nCreate an explicitly named branch from main\nCreate a pull request as soon as you make the first commit and link this to the relevant issue\nBe as explicit as possible on your goals\nDo not squash / rebase commits while you work – we will do so when merging\n\n\n\nCreating a pull request before you push any code will signal that you are interested in contributing to the project. Once this is done, push often, and be explicit about what the commits do (see commits, below). This gives the opportunity for feedback during your work, and allow for tweaks in what you are doing.\nA good pull request (in addition to satisfying to all of the criteria below) is:\n\nSingle purpose - it should do one thing, and one thing only\nShort - it should ideally involve less than 250 lines of code\nLimited in scope - it should ideally not span more than a handful of files\nWell tested and well documented\nWritten in a style similar to the rest of the codebase\n\nThis will ensure that your contribution is rapidly reviewed and evaluated.\n\n\n\nWhile you are working on changes you can render the site locally using quarto render and if you want to preview it you can use quarto render.\nThe website itself is deployed through github actions and is the reason that we will use pull requests as a way to not only act as a checkpoint as to what content is added to the website but also as a means to test that any changes that are made to the files will not break the deployment workflow.\nThis is all automated and you do not need to manually activate these deployments however, if they fail you will not be able to merge your pull request and it is at this point that you will need to work out what has caused the build to fail. You can refer to the build logs on Github but it might be easier to run quarto render locally and see what the error messages are from there."
+    "text": "This section describes the general steps to make sure that your contribution is integrated rapidly. Note that the main branch is protected and you will be unable to make any changes directly but rather through pull requests. The general workflow is as follows:\n\nCreate an issue that outlines proposed content or fixes\nFork the repository (see Branches, etc. below)\nCreate an explicitly named branch from main\nCreate a pull request as soon as you make the first commit and link this to the relevant issue\nBe as explicit as possible on your goals\nDo not squash / rebase commits while you work – we will do so when merging\n\n\n\nCreating a pull request before you push any code will signal that you are interested in contributing to the project. Once this is done, push often, and be explicit about what the commits do (see commits, below). This gives the opportunity for feedback during your work, and allow for tweaks in what you are doing.\nA good pull request (in addition to satisfying to all of the criteria below) is:\n\nSingle purpose - it should do one thing, and one thing only\nShort - it should ideally involve less than 250 lines of code\nLimited in scope - it should ideally not span more than a handful of files\nWell tested and well documented\nWritten in a style similar to the rest of the codebase\n\nThis will ensure that your contribution is rapidly reviewed and evaluated.\n\n\n\nWhile you are working on changes you can render the site locally using quarto render and if you want to preview it you can use quarto preview.\nThe website itself is deployed through github actions and is the reason that we will use pull requests as a way to not only act as a checkpoint as to what content is added to the website but also as a means to test that any changes that are made to the files will not break the deployment workflow.\nThis is all automated and you should not need to manually activate these deployments however, if they fail you will not be able to merge your pull request and it is at this point that you will need to work out what has caused the build to fail. You can refer to the build logs on Github but it might be easier to run quarto render locally and see what the error messages are from there.\nThe only time that you will need to first render the site locally before publishing is if you modify any code-based content. This is because we use the freeze functionality that allows us to store partial builds of the website nad makes remote rendering mush more efficient. Currently this will only apply to changes made to the collaborators map in people.yml."
   },
   {
     "objectID": "join.html",

sitemap.xml

@@ -2,42 +2,42 @@
 <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
   <url>
     <loc>https://BecksLab.github.io/website/values.html</loc>
-    <lastmod>2025-01-08T07:04:12.023Z</lastmod>
+    <lastmod>2025-01-08T07:35:59.098Z</lastmod>
   </url>
   <url>
     <loc>https://BecksLab.github.io/website/research/conservation/index.html</loc>
-    <lastmod>2025-01-08T07:04:11.963Z</lastmod>
+    <lastmod>2025-01-08T07:35:59.039Z</lastmod>
   </url>
   <url>
     <loc>https://BecksLab.github.io/website/index.html</loc>
-    <lastmod>2025-01-08T07:04:11.914Z</lastmod>
+    <lastmod>2025-01-08T07:35:58.990Z</lastmod>
   </url>
   <url>
     <loc>https://BecksLab.github.io/website/research.html</loc>
-    <lastmod>2025-01-08T07:04:11.940Z</lastmod>
+    <lastmod>2025-01-08T07:35:59.015Z</lastmod>
   </url>
   <url>
     <loc>https://BecksLab.github.io/website/resources.html</loc>
-    <lastmod>2025-01-08T07:04:12.023Z</lastmod>
+    <lastmod>2025-01-08T07:35:59.098Z</lastmod>
   </url>
   <url>
     <loc>https://BecksLab.github.io/website/people.html</loc>
-    <lastmod>2025-01-08T07:04:11.914Z</lastmod>
+    <lastmod>2025-01-08T07:35:58.990Z</lastmod>
   </url>
   <url>
     <loc>https://BecksLab.github.io/website/CONTRIBUTING.html</loc>
-    <lastmod>2025-01-08T07:04:11.879Z</lastmod>
+    <lastmod>2025-01-08T07:35:58.954Z</lastmod>
   </url>
   <url>
     <loc>https://BecksLab.github.io/website/join.html</loc>
-    <lastmod>2025-01-08T07:04:11.914Z</lastmod>
+    <lastmod>2025-01-08T07:35:58.990Z</lastmod>
   </url>
   <url>
     <loc>https://BecksLab.github.io/website/research/populations/index.html</loc>
-    <lastmod>2025-01-08T07:04:12.023Z</lastmod>
+    <lastmod>2025-01-08T07:35:59.098Z</lastmod>
   </url>
   <url>
     <loc>https://BecksLab.github.io/website/research/foodwebs/index.html</loc>
-    <lastmod>2025-01-08T07:04:11.983Z</lastmod>
+    <lastmod>2025-01-08T07:35:59.059Z</lastmod>
   </url>
 </urlset>