Click here for more detailed documentation (work-in-progress).
This repository is for collective design of an iGEM DNA distribution. The processes used in this repository are intended to support:
Table of Contents
Although we are sending the distribution to teams this year, the repository and our process for modifying the distribution are still in beta, therefore although we are open to contributions (see Issues for what we're currently focussed on), we aren't allowing contributions from iGEM teams for the time being. Please watch this space for updates!
For more information on contributing, see CONTRIBUTING.md.
Each directory contains one "package" of parts, where a "package" is a coherent collection of basic or composite parts and devices. Packages should be large enough to contain a full "tool kit", but small enough to be readily understood, reviewed, and discussed. Some examples of reasonable packages:
It's OK for a part to appear in multiple packages. Multiple usages will be detected and only one copy will appear in the actual distribution.
The directory for a package should contain the following:
package template.xlsx
. This is the central file of the package and defines all of its contents. The format must not be altered, or else it cannot be processed correctly.views
subdirectory, which contains exported versions of package data. These files should not be edited by hand. Views to expect are:
Package directories should not have any other subdirectories.
The package spreadsheet allows a collection of related parts to be specified compactly.
The Parts and Devices
tab list of all the parts that are to be used, along with notes about them as needed.
In this context, "Part" or "Device" just means any contiguous DNA sequence that you don't need to subdivide, and can include multiple sequence features. For example J04450, which encodes a complete functional unit, could be entered as a single part/device on this sheet (subpart relationships will be detected later in the process, via sequence information).
DNA sequence information can be specified in three ways:
The Libraries and Composite Parts
tab contains "build plans" for how parts/devices will be combined.
Three different types of combinations can be indicated here:
The "final product" column indicates which of these are intended to be the actual plasmids in the distribution, as opposed to intermediates in the build plan.
_Example: a line on this tab can indicate that we want all 20 Anderson promoters to be put into the pOpenv4 and pSB1C3 backbones, as a final product
Columns in blue are optional; columns in black are required.
Some of the columns have constrained data values. You can add organisms to the organism columns by adding entries on the "Organism Terms" tab. Do not modify the other tabs; they are used for configuring spreadsheet's automation.
To organize collective editing and review, this repository uses the GitFlow workflow. The key points for contributors to know are:
main
branch is only for releases, and the develop
branch only for approved and validated pre-release material. main
should have very few commits, mostly just release tags.develop
.
small-molecule-inducers
or IP-free-fluorescence
.add-missing-sensors
branch off of develop
. You edit the package Excel file to add the sensors, commit, and push. GitHub automatically creates CSV exports in the views
directory for the package. Satisfied with what you see, you create a pull request and ask a colleague to review and merge.develop
and request review from other contributors.
CRISPR-repressors
branch, and you want suggest new composite constructs using their repressors. First, you make a new composite-CRISPR-repressors
branch from their branch. You add your changes on that branch, then set up a pull request from composite-CRISPR-repressors
into CRISPR-repressors
and ask them to review your pull request.