# Let two contributors help without creating two competing final versions

Manual worksheet; invented situation, no automatic product import.

## Owned work

- Define the contribution boundaries — Coordinating lead — Procedure sections and examples have distinct contributor responsibilities.
- Own the assembled result — Integration owner — One review version resolves conflicting exception wording.
- Check coherence before receiving review — Contributors — Examples agree with the procedure and both contributors inspect the assembled guide.

## Workflow questions

### Does this require just one contributor?

No. Parallel contribution can help when the integration responsibility is explicit.

### Who decides a shared terminology conflict?

Use the agreed integration/receiving route rather than whichever draft arrived first.

### How should we track it in TeamBoost?

Use distinct owned tasks for contributions and a separate integration task or clearly recorded integration responsibility. Confirm the task relationships available in your account.

## Job to be done

When two people change the same artifact independently, I want clear contribution boundaries and one integration owner so the receiver gets one coherent result.

Two writers improve an operating guide. Their exception wording conflicts because both assume they own the final procedure.

### Recognizable symptoms

- Both contributors produce a final version.
- Shared terminology changes without an integration decision.
- The receiver must resolve conflicts that the team should have settled.

### Shortcut that fails

Adding both names as owners does not explain who merges the result or decides which conflicting wording governs.

### Before

Both writers own the guide. Send whichever version looks finished first.

### After — invented worked answer

Contribution agreement: one writer owns procedure sections; the other owns examples. The integration owner reconciles exception wording and terminology into one review version. Both contributors inspect the assembled guide before the receiving owner reviews it. Neither draft independently becomes the final operating instruction.

### Conditional next moves

- If Contributions are separable: Assign distinct output boundaries. Parallel work can proceed without duplicate final ownership.
- If Contributions change shared meaning: Set the integration decision first. Conflicting definitions cannot be reconciled by arrival time.
- If The assembled output is incoherent: Keep receiving review pending. Completion of separate tasks does not prove a coherent deliverable.

### TeamBoost route — confirm account availability

- Separate contribution work: Assign procedure and example tasks to their contributors. Your check: Each assignment has an agreed output boundary.
- Preserve integration decisions: Record the exception wording choice and one review version. Your check: A human resolves the conflicting meanings.
- Report the coherent delivery stage: Describe contribution progress separately from assembled-guide readiness. Your check: The receiver reviews the coherent result, not two incompatible drafts.

### Success check

The receiver gets one agreed review version and can identify who resolves conflicts between contributions.

### Editable draft facts

- First contribution [parta]: Procedure sections — Name a bounded contribution.
- Second contribution [partb]: Examples matching the procedure — Make the overlap or dependency explicit.
- Integration owner [integrator]: Guide coordinator — Who owns the assembled result?
- Shared decision to resolve [conflict]: Exception terminology — Name the issue drafts disagree on.
- Assembly check [check]: Both writers inspect one version before receiving review — Use a coherence check, not a file count.

### Draft pattern — replace every placeholder

```text
Parallel-work agreement
Contribution A: {parta}.
Contribution B: {partb}.
Integration owner: {integrator}.
Shared decision: {conflict}.
Before receiving review: {check}.
Only the agreed assembled version is the receiving artifact.
```

### Limits

The example does not implement merging or native multi-owner approval. Task relationships and receiving checks need account/process confirmation.

Local text preparation only; no workspace read, task creation, send or approval. Source interfaces do not establish account availability or live feature completion.