QA processes

The QA engineer runs through the article like a reader would, usually at least twice. The first time, they run through the full article, following all instructions and checking all technical steps, making sure that they can successfully reproduce whatever is explained in the article as a reader would.

The engineering writer should have already done this process as a 'pre-QA' check. If the QA engineer can't successfully run through the article because instructions are broken or wrong, they should add the 'QA-rejected' label on GitHub and give the article back to the writer, mentioning the first problem they ran into and reminding the writer to do a full clean runthrough before submitting to QA.

Then on a second run through the QA engineer can start to make fixes and changes such as redoing screenshots if needed, checking compatibility with different versions, and fixing or querying any other issues.

TODOs and anything outstanding after QA

Use a top level comment on the draft-PR (the one that is usually from the author with 'no description provided'. If the author already used that then just add a note to the top and leave their stuff at the bottom)

Example repositories

If an article links to an example repository that we have developed, it's usually in our github organization. Customers usually want this example repo in their own organization.

During QA, update any internal links to predict where they will probably live based on what we know about what the customer usually wants.

Add as a top level comment in GitHub

Dependencies:

- This requires that <internal repo> be made available at <link you used>

Often this is just changing the org name in github e.g.

Dependencies:

- This requies that https://github.com/ritza-co/foobar is made available at https://github.com/acme/foobar

But sometimes it might be a different name or structure. Maybe we choose a better name for the customer, or they want all examples to be in a monorepo etc.