{% extends "site/layout/base_workspace.html" %}
{% load com %}
{% load i18n %}

{% block title %}
{% blocktrans %}Help{% endblocktrans %}
{% endblock %}

{% block head %}
{% endblock %}

{% block content %}

<h1>Help</h1>

<h2>General Presentation</h2>

XXX

<h2>Glossary</h2>

<h3>Text edition</h3>

<dl>
  <dt><a name="markdown"></a>Markdown</dt>
    <dd>XXX</dd>
    
</dl>

<h3>Texts</h3>

<dl>
  <dt><a name="version_edit"></a>Edit</dt>
    <dd></dd>
</dl>

<h3>Comments</h3>

<dl>
  <dt><a name="collaboration"></a>Collaboration <em>à remonter</em></dt>
    <dd>For now co-ment chose to allow groups of people to collaborate using an unilateral moderation scheme. A group of users, initially chosen by the creator of the workspace, are given supervisors kind of rôles, that allow them to moderate others' comments. This privileged group of users, having say, a Manager rôle could be singled out to a teacher managing a classroom. The right management scheme allows for temporary delegation and offers the minimum openness and organizational incentives we thought we should expect from community driven softwares.
     
    un peu de feedback  un lien vers contact dans la newsletter
    Give it a try. And remember to tell us about moderation policy you chose.</dd>
    
  <dt><a name="comment_moderation"></a>Moderation</dt>
    <dd><p>Comment moderation is the process of editing/removing comments from a text. Moderator rôle is the collection of permissions required to edit/remove a comment submitted by users of the workspace.</p> 
    <p>Although this is not the default, you can choose that "pending comments require publishing" and what that really means is that comments from users with an Observer or Commentator role won't be visible to their author's peers before a user (with at least Moderator role) actually validate the content.</p> 
    Moderators is the mimimum rôle to publish comments.
  <dt><a name="comment_state"></a>States</dt>
    <dd>co-ment uses states to manage its featured moderation policies. Unapproved comments are only visible to Managers, Editors and Moderators. Approved comments are visible to users with any rôle. Pending comments will be visible if you decide so in the settings tab of the text.</dd>
  <dt><a name="comment_tag"></a>Tags</dt>
    <dd>Here at co-ment.org we think that simple workflow as well as basic classification needs will be satisfied using tags one clever way or another. We find it usefull to use tag for TODOs, peer revisions, and general content follow up.</dd>
    
  <dt><a name="comment_inter_links"></a>Linking to a comment</dt>
    <dd>You may find yourself needing to link to a comment from another one. In such case you can do so by copying your target comment's permalink that shows up when you hover over a comment title.  Please note: Your visitor experience will be different if the comment you are referring to belongs to same text. If it does then the link won't open a new window and getting back to the referrer comment can be a difficult task. (allowing a systematic new window on comment links is still to be implemented as is the even better solution of updating comment referrences between versions <em>BUG link</em> we rely on users feedback <em>link</em>for  proper behaviors on situations like this). If the referrenced comment is in another text then opening a new window is the default behavior.</dd>
    
  <dt><a name="comment_scope"></a>Scope</dt>
    <dd>We call scope of the comment the annotated part of the text the comment is about.</dd>
  <dt><a name="comment_versions"></a>Keeping your comments across versions</dt>
    <dd>When you create a new version of the text, comments are duplicated.  In case the text edition did not change the <a href="#comment_scope">scope</a> of the comment co-ment will retain comment's scope between versions through a simple computation. If the scope has been modified then a decision has to be made regarding the conservation of the comment in the new version. For all such comments you'll be given a choice wether you want them kept in the new version as 'detached' from the text (annotation won't be highlighted in the new version's but comments will still be available when browsing) or entirely removed from the new version.</dd>
    
</dl>

<h3>Roles</h3>
<dl>
  <dt><a name="roles"></a>Roles</dt>
    <dd>Roles are predefined sets of permissions. </dd>
    <dd>Your text will not be available by public vistors before anonymous users are given a role on the text.</dd>
    
  <dt><a name="local_role"></a>Text role</dt>
    <dd>A text role is a role that is set for a specific user on a specific text.  It can be used to override a possibly existing workspace-level role or to give a user a role on a text (and not on every text in the workspace).</dd>

  <dt><a name="role_model"></a>Role model</dt>
    <dd>A role model is a role set useful in a specific use case</dd>

</dl>

<h3>Notification and feeds</h3>

<dl>    
  <dt><a name="email_notifications"></a>Email notification</dt>
    <dd>Email notifications are a way for users to be informed when a new comment is added on a text they follow by receiving emails.</dd>
    
  <dt><a name="feed"></a>Feeds</dt>
    <dd>A <a title="Web feed definition on Wikipedia" href="http://en.wikipedia.org/wiki/Web_feed">(web) feed</a> is a news feed on a specific text or on the whole workspace.</dd>
    
  <dt><a name="public_private_feed"></a>Public and private feeds</dt>
    <dd>The public feed includes all the events publically accessible on the workspace or a specific text.  The private feed includes all events.  Be sure to share this feed with caution.</dd>

  <dt><a name="embed"></a>Text embedding</dt>
    <dd>You can embed your text into a page of your own website. Visitors will be able to add comments from your website depending on anonymous users' roles on the text. For a proper test condition when embedding in your own site, in particular for experiencing links referencing comments in the same or different text, be sure your are not logged into your workspace in another tab of your browser. </dd>
    
</dl>

{% endblock %}