Do you have a defined usuage policy for your teams?
Asked by Dave Anderson:

I have been tasked with creating a usuage policy for confluence within or organization. I am curious if anyone else has done this. My fear is that it will become to restrictive and stifle any creativity or collaboration.

Any feedback or examples would be greatly appreciated


Answers:
author: JP _AC Bielefeld Leader_
body: HI Dave,

yes, we did this when we introduced Confluence in 2014. It's more a guideline than a policy.

It targets the main questions users are asking when first introduced to Confluence:

- Where do I create content?

- How to I comment / interact / collaborate? (Differences between commenting, sharing, mentioning, watching, favorizing... you get it?!?)

- How to I create content? Choosing a good page title is important

- Restrictions - Keep it open unless there're really specific needs to hide it from other users.

And most important:

- Where to I store files? Do I keep them on a file server or do I store them inside a space / page in Confluence?

And, yes, Nic is right: Templates are good!

comments: author: Dave Anderson
body: Thank you for the feedback. I appreciate you taking the time to respond


author: Nic Brough -Adaptavist-
body: We don't here, but my lot have quite a lot of Atlassian experts who know how to be clever with Confluence and a high level of trust that we won't get things too badly wrong.

I've worked in places that have varying levels of policies varying from "meh, do what you want" (bad) through to "draconian" (also bad for totally different reasons)

Your usage policy should be driven by what you want Confluence to represent. If you're a law firm, you could well have some strict rules about how things are done in documentation systems. Or you might have requirements if you're trying to achieve certifications of some sort (ISO for example). This should always be the most important driver of a usage policy.

But after that, you are absolutely spot-on. "Meh" is bad because people will quickly create an unformed mess. "Draconian" is bad is people feel restricted and stop using it, do the docs somewhere else, and you lose the creativity and collaboration advantages remarkably fast.

That said, there are some guidelines that hold up well in general. In no particular order:

* Document and publicise the policy
* Encourage the use of templates and blueprints
* Consider delegation of policy - different spaces are used by different people for different things. A policy that works well for technical documentation probably won't work at all for the HR intranet.
* Almost all of your users should start new docs from a template or blueprint
* Make it absolutely clear that a users personal space (if you allow them at all) are to be used for
  * A personal profile for other people to get an idea of who that person is in the organisation
  * Stuff personal to that user only
  * A scratchpad or area for "playing" with Confluence (maybe a bit of wiggle room for drafting - I tend to write stuff I would be ashamed to publish in my personal space, then polish it to the point where I would not be ashamed, then move it to where it should be. This is not good practice, but I am good at the "move it when I'm happy-ish", so no-one complains about it. And we are quite rigorous about the next point)
  * Absolutely **nothing** in a personal space should be considered as useful or correct (apart from the user's profile stuff)
* Templates and blueprints should be used to create almost all new pages
* Come up with a rule about "who owns a page". The most simple option is "the author, and if they've left, the space owners", but a lot of people also add rules such as
  * A mention of the owners as a group or person in the content or page properties
  * The last person who edited (significantly) or moved the page
  * The author's manager
* Be explicit about the rules of acceptable editing for other people. Imagine I wrote a page that I thought was fantastic, and then a load of other people edited it without asking - that could really annoy me and cause problems. A simple, but useful general rule set we had at my last place was:
  * Go ahead and edit someone else's page if you notice things in formatting, non-standard structures, spelling, clarity or grammar. But ask people to be careful not to do grammar/clarity editing that substantially changes the style of writing. (I'm happy when people correct my "its/it's" blind-spot, not too bothered when they shorten or split my sentences, but I really don't like it when they add/change words that I would never use. For example - "leverage" as a verb is always wrong, and should not be used as most English speakers will immediately think "corporate bullshit" and switch off. "Utilise" is pointless typing that adds nothing. Something I write will always have "use". Don't change that if you edit my pages)
  * Edit a page if the data on it is out of date - ideally, update it, but if worried, leave the old stuff in and include a reason you're updating in a comment
  * For any more intrusive edits, ask the owner/author first. In-line comments are a massive help here - you can directly call out something that you think is wrong without affecting the content. Almost all comments like this lead to the author going "thanks, I'll update it" or "yes, you know the new stuff better than me, go for it".
* Get your authors involved with forming the policy - how do they want to do it? What would each space owner want all their authors to do every time? (e.g. always label the page, always work from a space template, always include a certain set of text for specific doc types, and so-on)

So, a bit of an essay, and not really a "policy" example. But hopefully some of it can help you form something that works well for you.

p.s. Templates are good, right?

comments: author: Dave Anderson
body: Templates are fantastic. Thank you for the feedback. I appreciate you taking the time to respond. This is exactly what I was thinking