Writing high-quality SDK documentation requires a specific vocabulary — from providing code samples to marking deprecated methods. This exercise covers the collocations used by developer relations teams, technical writers, and engineers when creating and reviewing developer documentation.
0 / 5 completed
1 / 5
The developer relations team needs to ___ code samples for every endpoint in the SDK.
Provide code samples is the standard documentation collocation — it emphasises that the documentation gives the reader something useful. 'Write' focuses on authorship; 'add' and 'include' are more mechanical and less idiomatic in a documentation quality discussion.
2 / 5
We should ___ the authentication flow in the getting-started guide before the SDK launch.
Document the authentication flow is the natural collocation — it implies creating formal, structured written record. 'Describe' and 'explain' are verbs used within documentation but not when talking about the act of creating it. 'Cover' is informal.
3 / 5
Developers frequently ___ the changelog to understand what changed between SDK versions.
Consult the changelog is the professional collocation — it implies actively seeking guidance from a reference document. 'Read' is fine but less specific to purpose-driven use; 'check' is informal; 'refer to' is also correct but more verbose.
4 / 5
The team agreed to ___ all deprecated methods clearly in the API reference.
Mark deprecated methods is the standard documentation collocation — most style guides and tools use 'mark as deprecated'. 'Flag' also works in conversation; 'label' and 'note' are less idiomatic in SDK documentation contexts.
5 / 5
Before releasing the SDK, we should ___ the documentation for accuracy and completeness.
Review the documentation is the natural collocation for a quality gate before release — it implies structured evaluation by a reviewer. 'Proofread' is specifically about text errors; 'validate' is more technical; 'check' is informal and implies a quick glance.