Welcome
Welcome to the UBC iGEM 2023-2024 Internal Wiki. Read these pages before you start adding to our wiki!
If you have any questions regarding documenting your progress and work, please send a message in the documentation-wiki channel.
What should this internal wiki contain?
This wiki contains everything that lets other members know how other subteams get things running, what other subteams are researching, and the current state of a subteam.
What differentiates this internal wiki from the master todo list? On the master todo list, you can see a task someone in dry lab is working on, while in this internal wiki you can read about the progress, current state, and future plans that member (or subteam) has regarding this task.
On the sidebar you can see all the different categories for each subteam. These folders were put here for a reason; they are a one to one correspondence with the required wiki pages for the iGEM competition. Create files within these folders when adding your content. This internal wiki serves as documentation for every subteam. Any content that is related to any of these topics on the sidebar should be here.
NOTE: We are not writing the final wiki pages here. Later on when we start writing our final content for the iGEM Wiki, use this website as a way to quickly and efficiently absorb and understand material from all our different subteams. The final wiki document is NOT HERE. When you start wiki writing, you will be DIRECTLY committing to the iGEM provisioned Wiki repository on GitLab.
What doesn't this internal wiki contain?
Subteam meeting notes, administrative documents, sponsorship documents, finance. Anything sub-related to our project. Message the documentation channel to verify what goes on the internal wiki if you are unsure. Documentation officially starts when we are finished with pitching and have chosen a project.
Goals
Subteam transparency
Commits to this internal wiki hub are public. This means members can see who is contributing to our documentation and who isn't. The goal is for everyone to be an engaged and active member and contributing to our documentation in a consistent manner is one way to do so. This includes recording down setbacks, progress, blockers, wins and more.
One notable requirement of iGEM is to demonstrate we have used the Engineering Cycle in our project. This means we must demonstrate that we are iterating on the design of our project which is only possible if we record down what went wrong in our processes and how we plan to fix it.
Additionally, iGEM also requires a notebook (from wet lab, but dry lab should also have individual notebooks). Anyone should be able to freely access these notebooks to inquire about what subteams are up to.
We are also using software practices when adding content to our internal wiki. This includes all members making a personal branch to pull updates and push their own, making PRs to merge their content into the main branch, using issues, and more. If you are confused by this, wait until our Git, GitHub and Documentation workshop; if you're still confused send a message in the documentation channel.
Knowledge Transfer
Encourage creativity; the more knowledge sharing we have, the better all our different subteams can collaborate. The more integrated each subteam is the better we will perform at iGEM.
iGEM is a holistic competition. Having a strong dry lab will get you no better than silver if other subteams are struggling. Everyone is expected to have an educated and in depth knowledge of the project from every angle; dry lab, wet lab and HP. This is not possible without documentation from each subteam.
Additionally, teams must integrate each other's work into their own work. This is only possible if knowledge is being shared between all members of the team.
Track Progress: Concrete, small steps (with deliverables) towards our goal
The iGEM project involves many moving parts from all our subteams. In order to ensure everyone is aware of what is going on and to comply with subteam transparency, we must break our project down into a few overarching goals, and then these goals into concrete, small steps. Leads should create goals based on their subteams and larger tasks for these goals, while subteam members should take these larger tasks and break them down into smaller tasks for themselves. This should all be recorded on the internal wiki. Not on Slack channels, not in private DMs or Google Docs. New folders and files should be created to aid this process.
Now you're asking, what does it mean to create a concrete, small step?
Concrete (with a meaningful deliverable)
When defining a next course of action, either for your subteam members or yourself, make sure there is a clear reason for doing this task that contributes to an overarching goal. Each task should also have deliverable that indicates that this step has been successfully completed. For instance, if you are a lead and have given your subteam members a task to understand Golden Gate Assembly, there are two things you should think about. One, why should they learn this procedure? In the context of synthetic biology, you should let your members know that Golden Gate Assembly is an "extremely powerful modular assembly technique in synthetic biology that allows for the efficient and precise assembly of multiple DNA fragments into a single construct." and that we are planning to use this technique in our experiments. Even if you believe the reasoning behind a task is obvious, this is not the case for every member. Be explicit in this reasoning.
Two, how can your subteam members can explicitly demonstrate this understanding in a way that if possible, benefits all members? For instance, ask every member to upload their notes to this internal wiki; then members from other subteams can read what they have written and understand the Golden Gate Assembly as well. This not only allows your members to consolidate their understanding of Golden Gate Assembly, but also to allow knowledge sharing to other subteams.
Small
Tasks should be defined such that they can be completed within a certain time period and contribute to an overarching goal. Time periods that make sense include weekly (to present at our weekly generals) or biweekly; anything more than a month indicates the task may too large or vaguely. If a task you are defining is taking longer than a week or two, then that task can be broken down into smaller tasks. This includes documentation; this documentation should be updated at least once a week from each subteam.
Based on weekly tasks leads give their subteam members, each member should create daily tasks for themselves, that are recorded on this internal wiki. Smaller tasks allow leads to check in on their members to see how they are progressing within the larger weekly task.
Wiki Transfer
Everyone is expected to write on the wiki. Having your progress, results and knowledge here will make wiki writing easier for everyone. The workflow for wiki writing should be as follows:
- You are assigned a page to contribute to.
- You come to this internal wiki to check out related pages.
- If you need more information about a page, you know exactly who to ask by looking at the commit history.
- If your page requires writing about the entire process and not just end results, you can find all of the progress here.
- You start writing the final wiki page in the GitLab repository with this website open.
Questions
Why mdBook?
This documentation format was created by the Rust Language to document their programming language and other Rust projects.
Why aren't we using Notion?
An ideal platform is Notion, however, Canadian schools are not able to get free access to Notion, and our student accounts have limits that cannot accommodate our team of 20 people. Using Notion would cost us $1920.
Why are we using GitHub and Git?
Practice for the final wiki.
Is it okay if I have everything locally?
Brainstorming is okay to keep local, all fleshed out ideas must be on the internal wiki.
Why are we using software/agile practices?
Good way to maintain transparency, and proven to work.