Assigning and reviewing articles

Assigning an article gives it an owner and a due date. That combination is what turns intentions into published articles.

Assigning an article gives it an owner and a due date. That combination is what turns intentions into published articles.

Assign one

1. Open the article in Knowledge.
2. Set an assignee.
3. Set a due date.
4. Save. The assignee sees it in their own list.

Both fields or neither

An assignee with no date is a wish. A date with no assignee is a date nobody is going to meet. Together they are a commitment somebody made, and that is the only version that produces articles.

Assign to a person, always

Not to a team, not to a shared account. Work assigned to everybody belongs to nobody, which is exactly the state a workflow exists to prevent.

Use it for reviews too

The same mechanism handles the second half of the job: assign an existing article to somebody with a date, and you have scheduled a review rather than hoped for one.

This is what makes a knowledge base maintainable at scale. Writing articles is a project; reviewing them is a habit, and the habit needs a queue.

Make the queue visible

Look at the list of assigned articles in your regular team meeting. Ten minutes on what is overdue does more than any amount of agreement that documentation matters.

Keep dates honest

A due date that has passed for three months has stopped meaning anything, and a list full of them trains people to ignore the list. Either move the date deliberately or drop the article.

See also

• What Team Publishing is
• Submitting an article for review
• Article verification: what it is and how to set it up