Working in Teams

Installing a Team Parts Library

Why a Shared Parts Library Matters

When multiple engineers are designing PCBs for the same vehicle or system, consistency in the parts library becomes a practical safety concern. If one person creates a footprint for a particular connector and another creates a different footprint for the same part, the board files are incompatible. Worse, a footprint error made once gets silently replicated across every design that uses it.

A shared team parts library is the single verified source of truth. Every symbol, footprint, and 3D model in it has been checked and approved before anyone uses it in a design. Engineers pull from the same library, so a footprint that works in one design works in all of them. When someone invests the time to source a high-quality 3D model or verify a land pattern against a production board, that work benefits the whole team immediately.

The team library typically contains: symbols and footprints for heavily reused parts (regulators, connectors, microcontrollers), team branding blocks (title block graphics, logo symbols), and any standardized subcircuits the team has agreed on as repeatable building blocks.

The Library Lives in a Git Repository

A parts library is a collection of files — .kicad_sym, .kicad_mod, .step — and like any other engineering file it needs version control. Storing the team library in a Git repository means:

• Every change is tracked with a timestamp and author
• Previous versions are recoverable if a footprint change introduces a bug
• The library can be cloned by new team members in a single command
• Changes go through a review process before they affect anyone else's work

Team members clone the library repository to their local machine and register it with KiCad as a global library, so it is available in every project without needing a local copy per design. When the team updates the library, members pull the changes and the update is live immediately.

Installing the Team Library

Clone the team library repository to a stable location on your machine — somewhere it will not be moved or deleted. Then register it with KiCad:

• Symbols: go to Preferences → Manage Symbol Libraries, select the Global tab, and add the .kicad_sym file from the cloned repository using an absolute path.
• Footprints: go to Preferences → Manage Footprint Libraries, select the Global tab, and add the .pretty footprint directory from the repository.

Using the Global library table rather than the Project table means you do not need to reconfigure anything for each new KiCad project. The 3D models, if the repository includes .step files, should be stored in the same directory as the footprints so the relative path reference in each .kicad_mod file resolves correctly wherever the repository is cloned.

Modifying a Team Parts Library

Adding a New Part: Branch, Commit, Pull Request

Editing the team library directly on the main branch is the wrong approach. If your footprint has an error, it immediately affects everyone who pulls. The correct workflow uses Git branches to isolate changes until they are reviewed.

The process for adding a new part:

• Branch first. Create a new branch off main before making any changes. Name it something descriptive: add-MCP2551-CAN-transceiver. This keeps your work isolated from the stable main branch.
• Add the symbol. Open the Symbol Editor pointed at the library file in your cloned repository. Create the new symbol with correct pin numbers and pre-assign the footprint field.
• Add the footprint. Open the Footprint Editor and create the footprint in the team's .pretty directory. Verify it against the datasheet land pattern recommendation.
• Associate the 3D model. If a .step file is available (from the manufacturer or SnapEDA), add it to the repository directory and link it in the footprint properties using a relative path.
• Commit your changes. Stage the new or modified library files and commit with a clear message describing what was added and why. One part per commit is a clean practice.
• Open a pull request. Push the branch and open a PR against main. Describe the part, its MPN, and note which datasheet version you used. The reviewer can check your pin assignments, courtyard dimensions, and 3D model orientation before the part enters the shared library.

This workflow may feel heavyweight for a student team, but the overhead of one review is far less than the cost of discovering a footprint error after boards have been assembled. A PR is also a record: six months later, when someone asks why pad 1 is oriented a particular way, the answer is in the PR comments.

Design Decision Review (DDR)

Design Decision Review (DDR)

A Design Decision Review is a structured peer review of a schematic and PCB layout, conducted before the design is sent to the fabrication house. The goal is to catch errors while they are still cheap to fix. Rerouting a trace in KiCad takes minutes; reflowing a misassembled board or respinning a batch of PCBs takes days and costs money.

A DDR involves at least two people: the designer who owns the circuit, and at least one independent reviewer. The reviewer brings fresh eyes and is more likely to spot things the designer has stopped seeing after a week on the same schematic.

A DDR typically works through a structured checklist before moving into open exploration. Common checklist items include:

• ERC passes with no errors — the Electrical Rules Check is the first gate. Unconnected pins and driven-by-multiple-sources nets should be resolved, not suppressed without justification.
• Title block is complete — designer name, board name, revision, team name. A schematic without a revision number cannot be traced back to a specific board revision after the fact.
• Schematic is readable — subcircuits are grouped and labeled, signal flow reads left-to-right where possible, wire crossings are minimized. A neat schematic is not vanity; it is the primary document another engineer will use to debug the board in the field.
• Net names are unambiguous — power nets use global labels, signal nets are consistently named across hierarchical sheets.
• DRC passes with no errors — copper clearances, pad-to-pad spacing, courtyard overlaps, unconnected ratsnest.
• Component values are correct — resistor and capacitor values are as designed; no copy-paste errors have left the wrong value on a footprint that looks correct on the schematic.
• All parts are orderable — check that the MPNs in the BOM are currently in stock. If a part is on allocation, find the substitute before fabrication, not after.

After the checklist, the reviewer should browse the schematic freely, looking for anything unusual: a non-standard component value that suggests a calculation, a net name that implies a specific voltage but is not labeled, a passive that might be wrong polarity. Frame these observations as questions, not criticisms. "Why is R3 19.5 k rather than 20 k?" is a legitimate question that might reveal an intentional voltage divider calculation, or it might reveal a typo.

Giving and Receiving Feedback

The technical quality of a DDR depends as much on how feedback is exchanged as on the checklist itself. A schematic is the product of engineering decisions made over hours or days. A reviewer who opens it and immediately declares it wrong will get a defensive response and a less productive session.

As a reviewer, approach the schematic with curiosity. Ask questions. If you see something you do not understand, say so. This is often where the most useful conversations happen: either the designer explains something you did not know, or your question exposes an assumption the designer had not tested. The review is a knowledge transfer in both directions.

As the designer receiving feedback, the goal is to get the board right, not to defend every decision. A reviewer who asks why a particular value was chosen is doing their job. Be willing to recalculate in the session if a value is questioned.

Teams that review before they order spend less on board spins and learn faster. Teams that skip reviews spend more, learn slower, and tend to lose confidence in their own designs because they do not know which decisions were actually correct.