Wiki & Documentation
Strategy Guide

1.1 Your role in one sentence

As Wiki Lead, your job is to build and maintain the team wiki so that judges, future iGEM teams, and the entire world can see what UH Houston-TX accomplished — and to tell that story so well that they remember it. Everything else in this guide is in service of that sentence.

1.2 The two wins we're aiming for

1.3 Your three core responsibilities

This is the most important section in the guide. Every past team that won Best Wiki did the same core things. Every team that submitted a mediocre wiki made the same core mistakes. Here is the playbook in plain language, illustrated with real examples from past iGEM winners.

2.1 The three tiers, explained

2.2 Case studies — what past winners actually did

Read these closely. Each one teaches a specific move. When you are building your wiki, you should be able to say "I'm borrowing this approach from [winner] because it solves the same problem we have."

2.3 The mistakes that cost teams the Best Wiki

• Template clone with no customization. Judges know the iGEM starter template. If your wiki looks identical, it signals low effort.
• Broken links, missing images, placeholder text ("TODO") anywhere. Instant credibility killers.
• Inconsistent formatting across pages — different heading styles, different caption formats, different tone.
• Walls of text with no visual breaks. Judges read hundreds of pages in a week. Headings, pull-quotes, figures, and white space matter.
• Mobile-unfriendly layout. Some judges review on tablets during Jamboree sessions.
• No alt text on images. This is an accessibility failure and disqualifies you from Best Wiki consideration.

iGEM requires specific pages at specific URLs. If a page is missing or at the wrong URL, judges cannot evaluate it and the team may not receive credit. This is non-negotiable.

Every page must live at the Standard URL format:

https://2026.igem.wiki/houston-tx/[page-name]

A winning wiki is not a collection of pages — it is a designed experience. Before you write a single word of content, you need to establish the architecture.

4.1 Information architecture (the 3-click rule)

Every piece of content on the wiki should be reachable within 3 clicks from the homepage:

• Level 1 · Homepage. Project overview, visual navigation to all major sections, team identity. This is your storefront.
• Level 2 · Section pages. Description, Engineering, HP, Model, Safety, Team, Notebook, etc.
• Level 3 · Sub-pages. Individual experiments, specific HP interviews, parts detail pages. Use only if needed.

4.2 Design system — establish before building

Lock these decisions in your first two weeks. Everything else builds on them.

This is the hardest part of being Wiki Lead — not the coding, not the design, but getting other people to submit their content on time and at the quality level you need. The workflow below is battle-tested.

5.1 The content request process

• Send a content request to the subteam lead at least 2 weeks before you need the final version.
• Include: what you need (text, figures, data), word count target, format (Google Doc with headings), and deadline.
• First draft due 10 days before Wiki Freeze. This gives you time for 2 rounds of editing.
• If a lead misses their deadline by 3 days, escalate to Dr. Windham. He will follow up. Do not chase people alone.
• Final content goes through your editorial review before it goes on the wiki. No exceptions.

5.2 Content quality standards

Every piece of content on the wiki must meet these standards before you publish:

• Accuracy. All scientific claims are cited. No unverified claims. Austin reviews all technical content.
• Clarity. Written for an educated non-specialist. If a smart undergrad outside your field can't follow it, simplify.
• Originality. No copied text. All content must be CC BY 4.0 compatible. All images must be original or properly licensed.
• Formatting. Follows the design system. Headings are consistent, images are captioned, links work.
• Attribution. Every external contribution is credited on the Attributions page.

5.3 Worked example — how one page gets built

Scientific writing on a wiki is different from writing a lab report or a paper. The audience is broader, the attention span is shorter, and visual communication matters as much as text.

6.1 Voice and tone

• First person plural: "We designed…" "Our results show…" This is a team project.
• Active voice: "We optimized the model" — not "The model was optimized."
• Accessible but not dumbed down: Write for an intelligent reader who is not an expert in your specific field. Define technical terms on first use.
• Confident but honest: "Our model predicts a 3.2-fold increase" — not "We think maybe it might increase." But also: "This result was inconclusive" when appropriate.

6.2 Page structure — every page should follow this

1. Hook. 1–2 sentences that tell the reader why this page matters. What question does it answer?
2. Context. Brief background — what the reader needs to understand what follows.
3. Content. The substance — methods, results, analysis, narrative.
4. So what. What does this mean for the project? What did you learn? Where does it connect to other pages?
5. References. Properly formatted citations at the bottom.

6.3 Three wiki principles that separate Best Wiki from the rest

These are the technical details that separate amateur wikis from professional ones. You don't need to be an expert developer, but you do need to follow these standards.

7.1 Performance

• Image compression. Use TinyPNG or Squoosh. Every image under 200 KB. Use WebP where possible.
• Lazy loading. Images below the fold should lazy-load. This dramatically improves page speed.
• Minify CSS / JS. Before freeze, minify all stylesheets and scripts.
• Test on slow connections. Use Chrome DevTools throttling on 3G. If a page takes >5 s, fix it.

7.2 Accessibility (this wins Best Wiki)

• Alt text. Every image must have descriptive alt text. Not "image1.png" but a concrete description of what the figure shows and why it's on the page.
• Color contrast. Use WebAIM's contrast checker. Minimum 4.5:1 ratio for body text, 3:1 for large text.
• Keyboard navigation. All interactive elements reachable via Tab. Focus states must be visible.
• Screen reader. Test with VoiceOver (Mac) or NVDA (Windows) at least once before freeze.
• Font size. Minimum 16 px body text. Never use font sizes below 14 px.
• Semantic HTML. Proper heading hierarchy (h1 → h2 → h3). Use <nav>, <main>, <article>, <figure>.

7.3 Version control

• Use GitLab. iGEM provides GitLab repos. Commit often with descriptive messages.
• Branch strategy. Main branch = live wiki. Feature branches for new pages. Merge only when tested.
• Backup. Before every major change, tag a release. Before Wiki Freeze, create a full backup.

This section is the operational heart of the guide. Follow the rhythms below and the work will compound. Skip them and you will feel behind by July.

8.1 Daily rhythm (10–15 min)

Every weekday, ideally at the start of your study session:

• Open the Wiki Lead Dashboard. Check the next task due and any notifications from Dr. Windham or Austin.
• Review any content submissions from other leads (check shared Drive folder and group chat).
• Make one small improvement to the wiki: fix a typo, add an image alt tag, compress an image, test a link.
• Log your progress in the dashboard task notes — these feed directly into your weekly check-in agenda.
• Scan for any overdue content from subteam leads — if >3 days late, flag for Dr. Windham.

8.2 Weekly rhythm

8.3 Monthly milestones

9.1 The Wiki Lead Dashboard

Your Wiki Lead Dashboard is your command center. Open it daily. It is the single place where:

• Your current tasks and deadlines live.
• Every resource in this guide is linked (so you don't have to remember file names).
• Weekly check-in agendas auto-generate from your task notes.
• Urgent items can be escalated with a single button — when you mark a task "Urgent," it surfaces on Dr. Windham's Coordinator Dashboard immediately.

9.2 Dr. Windham — mentor & Project Coordinator

Dr. Windham is your first line of support outside the formal structure. Think of him as a senior colleague who has read the entire project context and understands the bigger picture. He will:

• Review your work weekly at the Monday check-in.
• Answer off-cycle questions by email.
• Help you troubleshoot design or code issues.
• Pre-read content before you route it to Austin.
• Back you up when a decision is hard.

9.3 Austin Routt — Project Lead

Austin has final sign-off on any content that involves the science — strain design, metabolic modeling, experimental methods, claims about results. Route technical content through Austin before publishing. For non-technical wiki decisions (design, layout, navigation), you have autonomy — use it.

9.4 Other team leads

• HP Lead (May). Collaborate closely on the Human Practices and Inclusivity pages. She provides content; you integrate it into the wiki design.
• Wet-lab team. Your source for Experiments, Results, Notebook, Engineering, and Parts content.
• Modeling lead. Your source for the Model page. Austin may handle this directly.

10.1 Pre-wiki-freeze checklist (by October 20, 2026)

10.2 Jamboree preparation (Oct 21 – Nov 12)

• Draft a 2-minute "wiki design philosophy" talking track for judges.
• Build a 1-page wiki summary handout (PDF) for the poster session.
• Prepare to explain how the wiki demonstrates engineering iteration, integrated HP, and modeling.
• Practice the walk-through with Dr. Windham and Austin.

10.3 The Jamboree itself (Nov 13–16, Paris)

Show up rested, dressed professionally, and ready to tell the story. Judges will ask: "Walk me through your wiki." You should be able to open the homepage, navigate to any page in under 3 clicks, and explain the design choices that made it work. That 60-second walkthrough is the distilled output of everything in this guide.