Contributing

Thanks for helping improve the Forward Deployed Engineer Roadmap, an independent visual field guide to Forward Deployed Engineering.

This project is intentionally small, curated, and provenance-conscious. Contributions should make the guide clearer, more useful, more accurate, or easier to navigate without turning it into an exhaustive link dump.

Good contribution areas

You are welcome to propose changes that:

• fix typos or ambiguous wording;
• improve technical explanations;
• suggest clearer distinctions between FDE and neighboring roles;
• refine the roadmap or depth-track boundaries;
• improve the diagrams;
• add high-quality references that materially improve a section;
• identify claims that need qualification or better attribution.

Editorial principles

1. Treat FDE as a variable role, not a universal standard.
2. Keep core capabilities separate from employer-specific depth.
3. Prefer synthesis over accumulation.
4. Separate source concepts, editorial synthesis, and original presentation.
5. Avoid vendor prescription when a transferable concept is enough.
6. Do not copy large passages or reproduce third-party roadmaps.
7. Do not imply that this repository is official guidance from any company or source.

Provenance requirements

If a contribution changes the conceptual roadmap or adds a new primary reference:

• update docs/sources-and-provenance.md;
• update SOURCES.yml when source metadata changes;
• use an immutable commit SHA for Git repositories when possible;
• record an access date for dynamic web sources;
• verify the source's actual license or reuse boundary instead of assuming public access means open-source reuse.

Proposing a reference

Explain:

• what claim or section the source improves;
• why the source is credible or useful;
• whether it is primary material, practitioner guidance, or secondary commentary;
• what should change in the guide because of it.

A URL by itself is usually not enough.

Proposing a visual change

Visual contributions should:

• preserve the established technical diagram family;
• remain legible at normal GitHub README width;
• keep iconography neutral and purposeful;
• use restrained semantic color rather than decorative color;
• preserve source/provenance footers where appropriate;
• provide the final PNG intended for repository use;
• document meaningful visual or content changes in the pull request;
• avoid implying that AI-assisted artwork is mechanically reproducible from a source file that does not exist.

The contribution policy is tool-neutral. Contributors are not required to use a particular image-generation or graphics tool.

Pull request checklist

• Keep the scope focused.
• Run a spelling/formatting pass.
• Verify local Markdown links and image paths.
• Confirm that borrowed ideas are attributed.
• Avoid brand logos unless necessary to an explanation.
• Update CHANGELOG.md when the change is user-visible.
• Update provenance files when conceptual coverage changes.

Tone

Be direct, constructive, and specific. Disagreement about role definitions is expected because FDE responsibilities vary across organizations.

The goal is not to win a definition. The goal is to make the guide more useful and more defensible.