feat (im): Quarto doc versions of all IM manual pages made and added …

…to site

_quarto.yml

@@ -22,6 +22,28 @@ website:
             href: im/home.qmd
           - text: "New to LTER"
             href: im/new-to-lter.qmd
+          - text: "New to IM"
+            href: im/new-to-im.qmd
+          - text: "EML"
+            href: im/eml.qmd
+          - text: "GitHub Organizations"
+            href: im/github-organization-recs.qmd
+          - text: "Site Identifier"
+            href: im/site-identifier.qmd
+          - text: "Site Personnel"
+            href: im/site-personnel.qmd
+          - text: "Site Publications"
+            href: im/site-publications.qmd
+          - text: "Site Websites"
+            href: im/site-websites.qmd
+          - text: "Bibtex"
+            href: im/bibtex.qmd
+          - text: "Biblio Fields"
+            href: im/biblio-fields.qmd
+          - text: "Getting Help"
+            href: im/getting-help.qmd
+          - text: "Editing IM Docs"
+            href: im/edits.qmd
     right: 
       - icon: github
         href: https://github.com/lter/docs-network

im/biblio-fields.qmd

@@ -0,0 +1,49 @@
+---
+title: "Biblio Fields"
+format: html
+---
+
+NSF uses a fairly narrow set of entry types for annual report and public access repository reporting. In general, it makes sense to align the LTER publication database with those types, but we are allowing a few additional types to accommodate technical reports, gray literature, and a miscellaneous type to accommodate awkward and unanticipated modes of publication, such as maps and software packages. The required fields for each entry type are the same as NSF's and are listed below the entry type.
+
+- article - An article from a journal or magazine. 
+    - Required fields: author, title, journal, year
+    - Optional fields: volume, number, pages, month, note
+- book - A book with an explicit publisher
+    - Required fields: author or editor, title, publisher, year
+    - Optional fields: volume or number, series, address, edition, month, note
+- booklet- A work that is printed and bound, but without a named publisher or sponsoring institution.
+    - Required field: title
+    - Optional fields: author, howpublished, address, month, year, note
+- inbook - A part of a book, which may be a chapter (or section or whatever) and/or a range of pages.
+    - Required fields: author or editor, title, chapter and/or pages, publisher, year
+    - Optional fields: volume or number, series, type, address, edition, month, note
+- incollection - A part of a book having its own title
+    - Required fields: author, title, booktitle, publisher, year
+    - Optional fields: editor, volume or number, series, type, chapter, pages, address, edition, month, note
+- mastersthesis or phdthesis - master's or doctoral thesis
+    - Required fields: author, title, school, year, type (masters, doctoral)
+    - Optional fields: address, month, note
+- proceedings - The proceedings of a conference
+    - Required fields: title, year
+    - Optional fields: editor, volume or number, series, address, month, organization, publisher, note
+- inproceedings - An article in a conference proceedings
+    - Required fields: author, title, booktitle, year
+    - Optional fields: editor, volume or number, series, pages, address, month, organization, publisher, note
+
+### Additional standard BibTex entry types that are acceptable for the LTER Network bibliography
+
+- techreport - A report published by a school or other institution, usually numbered within a series (also appropriate for government reports and gray literature)
+    - Required fields: author, title, institution/organization, year
+    - Optional fields: type, number, address, month, note
+- manual - Technical documentation
+    - Required field: title
+    - Optional fields: author, organization, address, edition, month, year, note
+- misc - Use this type when nothing else fits. (Appropriate for maps, patents, software, etc. Please strive to include as much detail as possible, especially year and howpublished)
+    - Required fields: none.
+    - Optional fields: author, title, howpublished, month, year, note.
+
+### Sources
+
+[Bibtex entry definitions and required fields](https://www.openoffice.org/bibliographic/bibtex-defs.html)
+
+[NSF reporting entry types](https://www.research.gov/common/robohelp/public/WebHelp/Project_Reports.htm#project_reports_htm_how_to_add_p_2803)

im/bibtex.qmd

@@ -0,0 +1,18 @@
+---
+title: "Bibtex"
+format: html
+---
+
+## Exporting Bibtex files for importing to the Network bibliography
+
+LTER sites maintain records of their publications in different systems (Zotero, DEIMS, EndNote, custom databases), but everyone should be able to export a BibTex file. The LNO will accept files exported from non-Zotero systems as bibtex files and will handle de-duplication, aligning with DOI’s, and tagging, so that each publication is listed only once, but all associated sites are tagged.
+
+Please name your file according to the following convention and send it to downs@nceas.ucsb.edu along with the date of the last network bibliography update:
+XXX-pubs-YYYY-MM where XXX=site acronym; YYYY=Year; and MM=numeric month in which the file was exported.
+
+## Identifying LTER Site
+
+Please use the linked entry-types and fields when exporting your BibTex file. In addition to the required fields listed below under each entry type, please ensure that your export includes a keyword identifying your LTER site and one or both of two standard fields for linking to the product:
+
+- LTER site keyword format (or tag in Zotero): LTER-XXX, where XXX=your three-letter site acronym
+- DOI (if available) or URL (if available)

im/edits.qmd

@@ -0,0 +1,10 @@
+---
+title: "Editing IM Documents"
+format: html
+---
+
+We welcome edits to the IM manual. You can make edits in a number of ways as described in [CONTRIBUTING.md](https://github.com/lter/docs-network/blob/main/CONTRIBUTING.md).
+
+If you just want to post a suggestion or comment, the simplest approach is to sign in to GitHub and create an [issue](https://github.com/lter/docs-network/issues). Click the **New issue** button to get started.
+
+You can use plain text to describe your issue, but if you want to take advantage of more advanced features, check out [GitHub's Quickstart guide](https://docs.github.com/en/issues/tracking-your-work-with-issues/quickstart).

im/eml.qmd

@@ -0,0 +1,42 @@
+---
+title: "Ecological Metadata Language (EML)"
+format: html
+---
+
+## Creating EML
+
+The [Ecological Metadata Language (EML)](https://eml.ecoinformatics.org/) is an XML schema for describing ecological datasets.
+EDI maintains [best practices for EML](https://ediorg.github.io/data-package-best-practices/) that you should review when writing your own EML.
+
+There are many one-off solutions for creating EML at LTER sites. Some common ones are listed below, as well as some newer offerings from EDI.
+
+## ezEML
+
+[ezEML](https://ezeml.edirepository.org) is an online form based EML editor.
+ezEML has developed into a very simple approach for generating metadata files at three levels:
+
+* If you're starting from scratch or don't have much experience with metadata.
+* If you need to gather metadata from a researcher or student at your site, you can let them start from a template that you have created.
+* Set ezEML up for your site's metadata management: 
+  + Import EML snippets from other files. This option lets you set up something akin to a metadata database from which to import parts needed for a new EML file. 
+  + Import datapackages (EML and data) from the EDI repository for updates and new versions.
+
+Extensive documentation may be found in the [user guide](https://ezeml.edirepository.org/eml/user_guide) or on [YouTube](https://www.youtube.com/playlist?list=PLi1PZkcSXdAKTtpgyHnd8GjtL6kRMMGFR).
+
+
+## LTER Core Metabase
+
+Some LTER sites manage dataset metadata using a Postgres database schema called [Metabase](https://github.com/lter/LTER-core-metabase).
+It is maintained by LTER IMs, as is the companion R code called [MetaEgress](https://github.com/BLE-LTER/MetaEgress) for generating EML from Metabase.
+The original Metabase was developed at GCE, but the current version (called LTER Core Metabase) is in use at BLE and JRN.
+
+
+## EMLassemblyline
+
+[EMLassemblyline](https://ediorg.github.io/EMLassemblyline/) is an R package for creating EML.
+It is maintained by EDI and is used by several LTER sites such as HBR, JRN, NES, and NTL.
+
+
+## DEIMS
+
+DEIMS used to be a [Drupal](https://www.drupal.org/)-based solution for LTER websites. Drupal is a flexible content management system / programming environment that supports metadata based LTER websites well due to its database backend. It can also be used to generate EML. Recent efforts of upgrading from the original DEIMS to Drupal 8/9 are well documented in this [GitHub repository](https://github.com/lter/Deims7-8-Migration) and modules for extracting and ingesting metadata have been developed.

im/getting-help.qmd

@@ -0,0 +1,16 @@
+---
+title: "Getting IM Help"
+format: html
+---
+
+For general information management (IM) questions, check out the **im** channel in the [LTER Slack workspace](https://lter.slack.com/).
+Post your question, and you'll likely get a response from other IMs active that day.
+
+For general LTER questions, again try [Slack](https://lter.slack.com/), or just [email Marty Downs](mailto:downs@nceas.ucsb.edu), director of the LTER Network Office (LNO).
+If Marty gets tired of the spam, be sure to point her to this page so she can edit it and scold Tim for posting her address.
+
+For help with archiving data at the Environmental Data Initiative, [email EDI](mailto:info@edirepository.org). Or join [EDI's Slack](https://edi-got-data.slack.com).
+They are generally very responsive and helpful.
+
+If you see something at an LTER site and you want to know how they did that, reach out to the IM.  We're a friendly community.
+Some are even eager to share because shared solutions can be more sustainable and it makes the site look good when reviews and renewals come up!

im/github-organization-recs.qmd

@@ -0,0 +1,59 @@
+---
+title: "GitHub Organization Recommendations"
+format: html
+---
+
+## Rationale
+
+[GitHub Organizations](https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/about-organizations) are a great way of centralizing many individual GitHub repositories under a common umbrella. Access to these repositories is easily shared with organization members and limits to this access can be implemented smoothly as desired across groups of users simultaneously. Organizations also "own" repositories which lessens the risk of accidental deletion. Websites created by repositories owned by the same organization have a URL with a shared root which greatly simplifies navigation around the ecosystem of products produced by an organization.
+
+The LTER Network recommends each LTER site create a GitHub organization for itself and then encourage site staff and visiting researchers to house their repositories there rather than in their own profiles. There are many benefits of GitHub Organizations (including those outlined above) and we hope that you share our excitement for this potential new direction!
+
+The LTER Network has followed our own advice and has a GitHub Organization which you can see [here](https://github.com/lter)!
+
+## Naming Convention
+
+We recommend adopting a common organization naming convention so that visitors to one organization can easily find the organization of another LTER site. Six sites currently have organizations and the general naming convention is to use the three letter site abbreviation in all caps followed by a hyphen and "LTER" (e.g., "JRN-LTER").
+
+Note that organization names can be changed as needed without breaking an individual user's code but the link to GitHub-hosted websites/etc. will be changed if the organization name changes.
+
+## Organization Description & README
+
+We also recommend adding a short description of your site to the organization page, so that visitors have a big-picture overview of your site. In addition, the organization page is a great place to link to your site's main website, your [Research Organization Registry (ROR)](https://ror.org/search?query=LTER), data catalog, or other platforms and build your online presence.
+
+We also recommend that you create a README as a landing page for the Organization. To do this, create a public repository named ".github". Add a "profile" folder and put "README.md" in that folder. The content of the README will then appear on your organization's profile and will be the first thing visitors to the GitHub Organization will see.
+
+## Administrators
+
+Members of an organization can be designated "owners" and they will then have access to all possible settings for the organization (including inviting new members, changing the organization name, or deleting the organization among other functions). [GitHub recommends adding more than one owner](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/maintaining-ownership-continuity-for-your-organization) because if only a single person has that power, access to the organization settings is entirely dependent on that person.
+
+We recommend adding the following people as owners of a site organization:
+
+- Site Primary Investigator
+- Site Information Manager
+- At least one representative of the LTER Network Office
+
+Note that these people must all have a GitHub profile to be added as owners. Even if one of the prospective owners has no other need for a GitHub account, we feel it is worthwhile to have them create a GitHub profile for the sole purpose of allowing back-up access to the organization settings if that becomes necessary.
+
+## Organization "Teams"
+
+GitHub organizations control access to repositories in a slightly different way than repositories owned by individual users. In a user-owner repository, other profiles can be granted access and as each person is added, their level of access is decided by the profile that owns the repository. In an organization context however, access is controlled by [Organization Teams](https://docs.github.com/en/organizations/organizing-members-into-teams/about-teams). Instead of people being granted access to repositories, teams are granted access to repositories. Users are then added to team(s) as appropriate and their level of access is dictated by [the access of the team](https://docs.github.com/en/enterprise-server@3.7/organizations/managing-user-access-to-your-organizations-repositories/repository-roles-for-an-organization). Note that only organization owners have the power to create teams or modify the level of access granted to existing teams.
+
+We recommend creating the following teams:
+
+- **"Admin" team** including everyone at the LTER site that should have admin-level access to all repositories (i.e., can change repository-level settings)
+- **"Maintain" team** including all lead researchers who need access to non-destructive actions in repositories (i.e., most repository-level settings)
+- **"Write" team** including everyone who has any need to write any amount of code (i.e., no settings access but able to add/change code in a repository)
+
+You may also want to create additional teams for active research or lab groups that have many repositories where a consistent set of profiles will need access to all of those repositories.
+
+As new repositories are added to the organization, an organization owner will need to add teams to those repositories (so that people in each team have the correct level of access to that repository).
+
+## Example Organization - BLE
+
+The [Beaufort Lagoon Ecosystem GitHub Organization](https://github.com/BLE-LTER) is a phenomenal example of everything we just described above! Check out their organization for a nice example of how one site went about setting up an Organization for themselves.
+
+## GitHub Organization vs. Other Platforms
+
+If you are already using a comparable non-GitHub platform (e.g., [BitBucket](https://bitbucket.org/product), [GitLab](https://about.gitlab.com/), etc.) we still recommend creating a GitHub Organization! At the very least, an organization for your site will give site researchers who do use GitHub a place to store their code and interact with peers who also use GitHub–both at and outside of your site. You can also use the description field of your organization to direct visitors to the link of whichever alternate platform your site decides best fits your needs. Finally, if a majority of sites do create their own organizations, external users will be able to use the standard naming convention to navigate among sites even in cases where each site utilizes the organization at different levels of intensity.
+