-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathpractice-protocols.qmd
67 lines (39 loc) · 5.55 KB
/
practice-protocols.qmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
# Practices and Protocols {#sec-protocols}
We deal with disparate technologies, fields, and methodologies. Having clear and available policies, practices, and protocols is absolutely essential.
## Documentation and Manuscripts {#sec-docs-and-mans}
### File Formats {#sec-fileformats}
Along with the \@ref(openness) we strive for when disseminating work via the lab, open formats should also be used when possible.
**Documents**: [markdown](https://www.markdownguide.org/cheat-sheet) ([Rmarkdown](https://uoepsy.github.io/usmr/cheatsheet/rmarkdown-2.0.pdf) and [Quarto](https://quarto.org)) or RTF\
**Audio**: [FLAC - Free Lossless Audio Codec](https://xiph.org/flac/) or [OGG (Ogg Vorbis)](https://www.xiph.org/vorbis/)\
**Images**: [JPEG-2000](https://jpeg.org/jpeg2000/index.html) or [TIFF](https://www.adobe.com/creativecloud/file-types/image/raster/tiff-file.html)\
**Video**: [MP4](https://en.wikipedia.org/wiki/MPEG-4_Part_14) or [MKV](https://en.wikipedia.org/wiki/Matroska) (H.264 or H.265 encoded)
While the University of Arizona provides free access to the entire Adobe Creative Cloud to anyone in its ecosystem, which the lab primarily uses, we also encourage the knowledge and use of free, open source software (FOSS) as an optional alternative:
- [HandBrake: Open Source Video Transcoder](https://handbrake.fr/)
- [GIMP - GNU Image Manipulation Program](https://www.gimp.org/)
- [ardour - the digital audio workstation](https://ardour.org/)
### Documenting and Record Keeping {#sec-documenting}
Projects should be housed in the lab's OSF project but the actual work done in these projects--writing, code, et cetera--should typically go in a GitHub repository within the lab's organization, especially student-driven projects. You may find that faculty-driven content may reside elsewhere but should still be linked within an OSF project. That repository can then be linked to the OSF sub-project.
Having a well-written and organized `README` file in your repository is absolutely essential. To conform with [UA Research Data Repository Policies](https://data.library.arizona.edu/data-management/best-practices/data-documentation-readme-metadata) (and to have a consistent organization), you should at least start with the [README_template.txt](https://osf.io/sj8xv/) they provide. You are also encouraged to maintain a step-by-step process that describes your project environment, how to run any cleaning scripts (if applicable), and how to reproduce the manuscript/slide deck/et cetera. The [2014 Software in Research survey](https://github.com/softwaresaved/software_in_research_survey_2014/blob/1.0/README.md) readme is a good example of this.
Likewise, when describing commits in GitHub or describing updates in OSF, please don't skimp. Commits are cheap and the next person that reads what you left will thank you.[^practice-protocols-1]
Note that you don't just have to be coding applications to use GitHub! Use it for slide decks, papers, websites, and all sorts of things (like this lab manual, for example!).
### Filenames {#sec-filenames}
We believe in standardizing as much as we can in order for consistency and clarity. Filenames should be chosen using the three considerations delimited by [Jenny Bryan's "How to name files"](https://speakerdeck.com/jennybc/how-to-name-files?slide=4). They should have the following qualities:
1. Machine readable
2. Human readable
3. Plays well with default ordering
You'll want to name your files like `YYYY-MM-DD_Project-name_Sub-identifier_Slug.ext` or some such.
## Lab Safety
As virtual reality has a tendency to cause dizziness, motion sickness, and so on, the lab has a variety of health-related safety plans and protocols in place.
### Motion Sickness
Should someone become motion sick when in virtual reality, the following steps should be taken:
1. Immediately stop the experience by standing still and removing the headset.
2. Stare at one location as far away as you can.
3. Take deep breaths.
4. Sit down and rest.
Should someone vomit during VR: (see lab guidance in the room for now)
There is always cold water available in the minifridge in the Sierra Vista lab and suckers are in one of the drawers by the storage cabinet.
## Reserving Lab Equipment
Reserving or checking out lab equipment should be done via our online lab inventory management system, [Bookkit by Clustermarket](https://www.clustermarket.com). This system is invite-only, so let the director know if you don't have access. Everyone needs to make a reservation in the system as a means for tracking what equipment is being used to what extent. Please keep in mind that lab equipment does need to be sterilized and recharged between uses and equipment that *is* checked out should be returned in the same fashion (with the exception of the rechargeable batteries; the lab will take care of those upon receipt).
## Requesting Lab Services
It's possible, also using Bookkit, for lab services to be requested by outside entities. Some services like 3D scanning of a property using a Matterport camera requires a certain amount of training. Other services, like providing assistance with software, can be done by those with the expertise necessary. Remember to let the director know if you have a particular skill that you'd like to offer as a service through the lab. (Know Unity? Perfect. Proficient with Adobe Aero? Awesome. These are great services to offer.)
[^practice-protocols-1]: Use GitHub's `Release` function to keep track of substantive updates to a project by keeping track of release notes and next steps. This will also help spin up a new collaborator should someone join your project.