How to run a community: your quick start guide

[cheny0]

• Create getting-started-for-community-owners.md
• Update
• First draft rebase develop
• Ready for review rebase develop
• Minor fixes
• Fix merge conflicts

[jorge-campo]

Hello, @cheny0 – Thanks for your content.

Here are my review comments; they don't fundamentally change your document.

• Change the topic's title to 'How to run a Status Community: your quick start guide'. I made the changes in the different links, you still need to update the Markdown filename.

• 'A Status Community is a ...' -> Link to the 'About Status Communities' topic here.

• '... productive interaction'. I would use a different adjective here. Above all, a Status Community must be fun to use. 'Productivity' is not commonly associated with something fun but with work. You can use something like '...that fosters engagement and enjoyable interactions.'

• '... create your community' -> Link to 'Create a Status Community'. I know this is already linked in the tab text, but it's good to link to this content in the H2 intro.

• About titles. One small thing I've seen in other documents: in headers, you mix the ones that address the reader ('Administer your members and membership') with the ones that don't address anyone ('Token and token-based permissions'). Try to address the user. It's only sometimes possible and only sometimes works well, but usually, it does and is more direct. For example, write 'Use tokens and set up token-based permissions'. In titles, it's better to err on the side of longer titles (within a limit) than too short.

• You use two different H2s to speak about tokens and community administration. In reality, tokens are the main way of administering the community. I would update these titles:

  • 'Tokens and token-based permissions' -> 'Administer your community using tokens'
  • 'Administer your community' -> 'Ensure your community's operation'

• 'Administer your members and membership'

  • Screenshots go after the explanation, following our style guide. This is not true for tabs, but tabs are a different thing. So, whenever you write a concept, remember this order: header, explanation, screenshot (if any), and admonition. If you have more than one admonition, it's OK to intercalate them with the content.
  • In the final version, the order of things would be B, then C, and then A.

  

  • One paragraph == one idea. Split the 'After you create ... To increase your...' paragraph into two.
  • Restrict access -> Let's use something that sounds positive. What do you think of 'Control how members join your community'. (I realized I also used 'restrict' at the source.)
  • There are [two factors][about-the-different-types-of-status-communities] under your control to restrict access to your community' -> I would remove under your control because it makes me think there are other factors not under my control (and there aren't).

• Token and token-based permission -> Use tokens and set up token-based permissions

  • 'The different roles have unique permissions that allow them to perform...' This is 'software-centric' and not 'user-centric'. Let's explain what users can do with the roles and not what the roles allow users to do (tip: whenever you write allow you/them to, it's a sentence you may need to change). What do you think of "With these roles, users can perform different tasks in your community".

• '... could create and distribute exclusive virtual items exclusively to those...' what about '... could create and distribute exclusive virtual items only to those...' so we avoid repeating 'exclusive'

• 'Administer your community' -> 'Ensure your community's operation'

  • 'With the control node, you can carry out the tasks discussed earlier, such...' -> I would remove 'earlier'. These references don't work well in documentation because readers don't sequentially digest the information but jump through the content (think about how you read the information on a blog post or news site). This only makes sense when you use 'following' or 'below' to refer to a piece of information right below (like a table).
  • 'Turning off the CHS ...' If you want to use the acronym, you need to use the abbreviation and the name at least once. In your case, this will be the sentence '... maintain historical messages via the Community History Service (CHS).'

[cheny0]

Thank you, @jorge-campo , I have applied your comments :)