1 Overview of the PARA system

This workflow is designed around discrete units of work called projects and utilizes Tiago Forte’s PARA file structure and organization. The PARA system (Projects, Areas, Resources, and Archive) is an excellent place to start for organizing your files - if you don’t have strong feelings about how your work files are organized on your computer, I highly suggest starting with this. If you do have strong feelings, you can always adapt the system to something that works for you. Utilizing this system doesn’t necessarily commit you to going back and re-organizing all of your work files on your computer. Just start now, and build as you go and work on new projects. As you have time in the future, you can always go back and fit your previous work into this structure. However - see my notes on things to watch for when you go back to “refactor” your files and folder structure.

The most important thing is to start now; start today, with the project you are working on.

The second most important thing is to use the same structure across apps, platforms, and languages, which will allow deep integration and ensure you always know where everything is. You will spend less time trying to find for example, a small test R script you wrote last year or that interesting thing you read 18 months (or 2 months!) ago that was related to this project. The PARA system also explicitly focuses attention on those units of work (i.e. Projects) that are the most critical (in an R1 institution these would be manuscripts and proposals - even for us teaching faculty!).

1.1 The PARA system in practice

Tiago Forte’s PARA acronym stands for: Projects, Areas, Resources, and Archive. This system is not strictly hierarchical, but each category from front to back in PARA is given precedence over the last. That is because the underlying philosophy is that projects should produce end outputs or deliverables. Things that are not yet projects, or are larger than a single project are more nebulous, but not any less valuable.

Using the PARA system requires you to set up high level folders (I would suggest in the Documents directory of your computer) for each of the PARA categories: Projects, Areas, Resources, and Archive. Then, all of your professional work, and eventually some of your personal work and interests will nest under these.

Deciding what is a “Project” vs an “Area” vs a “Resource” vs an “Archive” is probably the most important part of this workflow and drives everything else, so I will start there. One simple way to think about this is that when you need to consider where something should go in this system start at the beginning - if its doesn’t fit into the definition of a “Project”, then move down and see if it fits into the definition of an “Area”. If it is not an “Area”, then it will likely be a “Resource” unless it is something completed or inactive, in which case it goes in the “Archive”.

1.2 What is a Project? How should I name my Projects?

1.2.1 Defining Projects - How to Determine if Something is a Project

This seems like a trivial question but defining project boundaries in research can be difficult. Where does one project end and another begin? Does a project include multiple sub projects?

A project is something you are involved in that has a discrete, definable end state or product. Note that our definition of projects here means they are flat. There should not be multiple projects nested under other projects. Each project is a discrete entity - this aligns with GitHub repository organization (as we will see in future chapters), which allows deep integration. In our line of work, examples would be:

A thesis chapter; see below for why a thesis or dissertation itself is actually larger than a Project - it is an Area
A manuscript
A proposal
Conference presentations and invited lectures (one-time - not recurring teaching responsibilities)
Reports to stakeholders on unpublished data. NOTE: grant reports (as addressed below) are not projects, but belong in areas with grants.
NOTE: A grant is best defined as an Area (because these days all grants are collaborative) with multiple projects underneath. Also, because most grants actually have multiple end products such as reports and manuscripts.

1.2.2 Naming Projects

This is a general style guide for naming projects (in the context of files or folder structures). Projects may have very long actual names (or you may not even know what, exactly the name of your project or project idea will eventually be). This doesn’t matter for the purposes of project setup. For now, we just need a two to four word abbreviated title for the project that we will use in our folder structure.

1.2.2.1 Naming Manuscripts - standardized with unique IDs as these will become GitHub repos

All manuscripts (following project setup) will eventually have a GitHub repo which is built from the jelinski-lab-pedology-MXXX-project-template repo, and therefore coordinated and standardized naming is essential. Here is a style guide for naming your projects:

Use all lowercase letters and short dashes instead of spaces.
Manuscripts should be designated as M (for manuscript, including thesis chapters, which should each be a publishable unit).
Projects should then be given a three digit number (with two leading zeros for any project numbers under 100) - these are just given in sequence as we create projects - the order doesn’t matter. **If you are in my lab group*, please obtain a new project ID number by adding your project as a new row to (jelinski-lab-project-registry?). Simply add a row with the next number in sequence (i.e. if the last registered project is M059-jelinski-permafrost-table-id, then your project should be M060-).
Project numbers are followed by the last name of the project lead.
Then all projects should have a 2-4 word descriptive title (note - spend at least a bit of time thinking about this as this is what will be used on all other platforms (your personal computer, GitHub, GoogleDrive, etc…) as your project name.

Your final project name is a combination of components 2 to 5 as follows: Lets say I wanted to create a project structure for the “Techniques for Field Identification of the Permafrost Table” manuscript I am working on, and lets say it is the 59th project in the registry.

My project name is then TypeNumber-Word1-Word2-Word3. So, the project name for my manuscript would be:

M059-jelinski-permafrost-table-ID

1.2.2.2 Naming Proposals

All lab-wide proposals (following project setup) will eventually have a GitHub repo which is built from the jelinski-lab-pedology-MXXX-project-template repo, and therefore coordinated and standardized naming is essential. Here is a style guide for naming your projects:

Proposals should be designated PL or PI (for proposal lab or proposal individual (see below)) and numbered by year. If the proposal is awarded then the entire proposal folder is copied to a grants folder in Areas (see below) with the same number. Group-wide grants (i.e. that Nic writes) start with the big PL label. Individual grants (student grants or personal applications) get a PI label so they do not conflict. Basically Nic is the only one who creates group proposal projects that are registered on the (jelinski-lab-project-registry?). Your proposals (which should start with PI) can have your own numbers, starting with 01).

Proposal names begin with PL or PI, then add the two digit year, and a unique two digit proposal ID. For numbers less than 10, pad to the left with a zero. Then, add your name, the name of the funder, and a short two to four word descriptive title.

Examples: - PL23-05-jelinski-maelc-soil-texture - PI23-01-ainuddin-cogs-travel-grant

1.2.2.3 Naming Conference Presentations and Lectures

Conference presentations and invited lectures do not need to be named and coordinated across all lab members, so ID numbers do not need to be unique. Many conference presentations may eventually end up in manuscript repos if a published manuscript presents the data.

Conference presentations or invited lectures begin with C or L, followed by the two digit year, person giving the presentation, conference or meeting name, and two to four word descriptive name.

Examples: - C22-03-jelinski-sssa-cryoturbation-review - L23-01-jelinski-waterresources-soil-landscape-health

1.3 What is an Area? How should I name my Areas?

1.3.1 Defining Areas - How to Determine if Something is an Area

Areas are larger and more nebulous to define than projects, and they are also often recurring and don’t necessarily have an endpoint (although they might have milestones or deliverables nested within them or an end date). The following are examples of Areas:

Teaching a course or invited lectures.
Grants (including grant reports). Although grants do have a definable end date, they should still be areas because they are highly collaborative and typically have multiple projects under them. Grants typically end with a whimper and not a bang so are best defined as areas. Projects end with a bang!
Service
Employment related items such as annual reviews or summaries

1.3.2 Naming Areas

Area names can be a bit more general than project names and (with the exception of grants) they are more personal so do not need to be registered or have a GitHub repository (although they certainly can if it makes sense).

1.3.2.1 Naming Grants

All lab-wide proposals (following project setup) which are funded become grants. The contents of the proposal folder are copied into Areas and the name remains the same except the PL or PI is removed and replaced with G. Grants should also eventually have a GitHub repo which is built from the jelinski-lab-pedology-MXXX-project-template repo, and therefore coordinated and standardized naming is essential. Here is a style guide for naming your projects: NOTE - need to create project folder/repo template for grants

1.3.2.2 Naming Teaching Folders/Repositories

Teaching folder should start with a T and then the two digit year followed by the course number and semester. Teaching folders may or may not have an associated GitHub repo - they should definitely have a Google Drive folder/archive of the same name. NOTE - need to create project folder template for teaching?

Examples: - T23-soil2125-spring

1.3.2.3 Naming Service Folders/Repositories

Service obligations are personal and therefore do not need to be coordinated across lab members. As service obligations can stretch across many years, these are not labelled by year - simply sequentially.

Examples: - S07-cfans-uprc

1.4 What is a Resource? How should I name my Resources?

1.4.1 Defining Resources - How to Determine if Something is a Resource

Resources are things you actively, continuously refer to but that fall outside of projects and areas. Resources examples are:

A note that contains all accounting codes
A folder of templates for email responses to common inquiries
An actively maintained or growing list of books to read
Your CV

1.4.2 Naming Resources

Resource names can also be quite general and can also be numbered. They should start with “R”. An example would be “R01-accounting”, which could include a note that had all of the EFS strings you use, etc. Resource folder should be best thought of as tags perhaps? NOTE: how to deal with shared resources on Google Drive or GitHub? Need to have a resource registry to parallel the project registry? YES

1.5 What is the Archive?

The archive is for anything that doesn’t fit into the first three categories. This could be individual files such as unmaintained or inactive lists, or completed projects and areas that are no longer relevant to the work you are doing. Whole folders can be moved from the previous three categories into Archive.

1.6 Example folder structure

Here is an example folder structure on my computer

./Documents
- /00-projects
  - /01-manuscripts
    - /M003-jelinski-nayabeda-P
    - /M004-jelinski-pb-distributions
    - /M005-jelinski-platy-e-horizons
    - /M020-jelinski-cold-soils-chapter
    - /M059-jelinski-permafrost-table-id
  - /02-proposals
    - /PL23-01-jelinski-nrcs-urban-soil-mapping
    - /PL23-03-jelinski-transtlantic-permafrost-thaw
  - /03-conferences
    - /C22-04-jelinski-sssa-cryoturbation-review
- /01-areas
  - /01-grants
    - /G23-03-jelinski-nrcs-urban-soil-mapping
    - /G23-08-jelinski-maelc-soil-texture
  - /02-teaching
    - /T23-soil2125-spring
    - /T23-laas5101-spring
  - /03-personnel
    - /undergraduate-students
      - jones-ben
    - /graduate-students
      - lohese-al
    - /staff
      - labine-kat
  - /04-service
    - /S12-editing-ppp
    - /S23-cfans-uprc
  - /05-general-accounting
- /02-resources
  - /R01-personal
  - /R02-literature-notes
  - /R03-email-responses
- /03-archive
  - /M001-jelinski-crb-gelisols
  - /M002-jelinski-us-eroded-soils

1.7 Why do this?

At this point you might be thinking this seems overly complicated. Why should I bother doing this, and why set up an unneccessarily strange and “computer” looking folder structure when I can just have folders named like “My Soil Project 2018”? I know what that is and I only have one project right now anyway…

If you are early in your career, this may seem unneccessary. But I can promise you this is actually the perfect time to start. This folder structure allows you to do five things:

create a publicly available repository out of any one of your project directories at anytime with little to no work
share your folder with anyone in our lab group (or anyone who reads this workflow document) who with little further direction will be able to understand your files and where to locate things
maintain an increasingly complex and growing list of projects and areas as you move forward in your career with little to no headache
spend little to no time finding exactly what you are looking for. As you grow this system, the numbers associated with particular projects will become secondhand nature - “oh that manuscript is M007”.
as you complete projects or certain areas are no longer relevant to your job, you can move whole folders into the archive without compromising your ability to find things. Note, in the example above, how two manuscript folders (M01 and M02) have been moved to the archive. They retain the numbers I associated with them when I was working on them.