{% extends "base.html" %}

{% block subtitle %}
  About
{% endblock subtitle %}

{% block content %}
  <script>
    /*
      Navigate to the active tab on page load, if one is specified in the
      location hash.
    */
    $(function () {
      var activeTab = $('[href=#' + location.hash.substring(2) + ']');
      activeTab && activeTab.tab('show');
    });
  </script>
  <div class="container">
    <div class="row">
      <div class="col-lg-8 col-md-8 col-sm-8">
        <div class="tabbable">
          <ul class="nav nav-tabs about-tabs">
            <li class="active"><a href="#how-to-use" data-toggle="tab">How to use Oppia</a></li>
            <li><a href="#publish-and-release-criteria" data-toggle="tab">Exploration publishing criteria</a></li>
            <li><a href="#publication-policies" data-toggle="tab">Publication Policies</a></li>
          </ul>

          <div class="tab-content">
            <div class="tab-pane active" id="how-to-use">
              <div class="oppia-about">
                <h1>Using Oppia</h1>
                <p>
                  The main units of learning in Oppia are called explorations. These are multi-stage interactive activities that attempt to engage readers in a learning conversation and provide formative feedback along the way.
                </p>
                <p>
                  Any user of Oppia, logged-in or otherwise, can play through, browse, and search for any <a href="/learn">public explorations</a>. To create or edit explorations, a user will need to be logged-in and to author his/her work under a stable username.
                </p>
                <p>
                  Responses submitted to explorations are stored anonymously. The anonymized responses are shown to exploration creators and editors, so that the explorations can be improved over time.
                </p>

                <h2 id="community">Community Guidelines</h2>
                <ol>
                  <li style="line-height: 25px;">
                    Ownership of explorations is temporary and eventually reverts to the Oppia community (see <a href="#lifecycle" target="_self">Lifecycle of an Exploration</a> for more details). The idea is to make it easy for the explorations on this site to improve continuously.
                  </li>
                  <li style="line-height: 25px;">
                    Please exercise judgement before publishing an exploration. Every exploration on this site should have significant educational value, and should not contain advertising, spam, vandalism or abuse.
                  </li>
                  <li style="line-height: 25px;">
                    Creating multiple usernames, using explorations to trick users, or circumventing site features that are meant to encourage the improvement of explorations are examples of antisocial behavior that may result in account suspension.
                  </li>
                  <li style="line-height: 25px;">
                    For contentious topics and clarifications on guidelines, please use the Oppia discussion forum.
                  </li>
                  <li style="line-height: 25px;">
                    The governance model for Oppia comprises site admins and moderators. Site admins manage and have overall responsibility for the site; they are the final arbitrators on any dispute. Moderators suggest and review major edits for explorations, and enforce the behavioral norms described within these community guidelines.
                  </li>
                </ol>
                <br>

                <h2 id="lifecycle">Lifecycle of an Exploration</h2>
                <p>
                  All explorations hosted on the site should ultimately be improved to the point where they are effective, enjoyable learning experiences. More specifically, an exploration goes through three stages as it becomes ready for learners to use:
                  <ul>
                    <li style="line-height: 25px;">
                      Each exploration starts out as <strong>private</strong>: only the creator of the exploration, any editors they assign, invited playtesters, and the site moderators can see it.
                    </li>
                    <li style="line-height: 25px;">
                      Once the creators of the exploration are ready for it to be publicly playtested, they can publish the exploration, at which point its status changes to <strong>beta</strong>. The exploration becomes viewable in the gallery (in the Beta category), and community members can see and play the exploration, and leave feedback and suggestions.
                    </li>
                    <li style="line-height: 25px;">
                      Once the exploration satisfies the <a href="site_guidelines/#publish-and-release-criteria">release criteria</a>, the exploration is officially <strong>released</strong> and is shown in the default view of the <a href="/gallery">gallery</a>.
                    </li>
                  </ul>
                </p>
                <p>
                  The editors of an exploration can retain exclusive editing rights as long as they continue to maintain the exploration and respond to feedback and change suggestions in a timely manner. Otherwise, the exploration will be considered 'orphaned' and ownership of it will revert to the community, who will then be able to collectively improve the exploration over time. The owner(s) of an exploration may also choose to release ownership to the community at any time.
                </p>
              </div>
            </div>

            <div class="tab-pane" id="publish-and-release-criteria">
              <div class="oppia-about">
                <h1>Exploration publishing criteria</h1>
                <p>
                  In order to ensure that Oppia is filled with high-quality explorations that do a good job of helping people learn something new, there are some minimal criteria for publishing an exploration to the "beta" stage and later moving it to the "released" stage. These are described below:
                </p>

                <h2>"Beta" criteria</h2>
                <p>
                  The following criteria for publishing an exploration to "beta" stage are meant to ensure that playtesters can test beta explorations meaningfully and leave helpful feedback, and that it is possible to continue developing and refining these explorations to move towards the Released stage. These criteria are intended to be objective and precise, so that it is easy for anyone to determine whether a particular exploration fits the criteria.
                </p>

                <p>
                  <ul>
                    <li style="line-height: 25px;">
                      <strong>It teaches something.</strong> The exploration should present information that is new to the target audience, and not just test knowledge that its target audience is already assumed to have.
                    </li>
                    <li style="line-height: 25px;">
                      <strong>It teaches more than a single factoid.</strong> The information presented should be either "deep" - an involved and tricky concept that has nuances and depth to it, or "broad" - a collection of related interesting facts that the learner can understand and remember better after playing through the exploration.
                    </li>
                    <li style="line-height: 25px;">
                      <strong>It provides informative feedback.</strong> The feedback that it provides to the players should be more than just "Correct" or "Incorrect"; it should provide (or guide players toward) the reasoning about why something is right or wrong, and how to correct it if necessary. An exploration should be more than just a quiz!
                    </li>
                    <li style="line-height: 25px;">
                      <strong>It doesn't duplicate an existing Beta or Released exploration</strong>. It's fine to teach the same thing using a significantly different way of teaching, but if a new exploration teaches the exact same things as an existing one, in the same way, then the effort would be better spent submitting feedback to, and improving, the existing one.
                    </li>
                  </ul>
                </p>

                <h2>"Released" criteria</h2>
                <p>
                  The criteria for releasing an exploration are meant to ensure that released explorations are educational, interesting to our learners, and make appropriate use of the interactive, discovery-based learning style that the Oppia tool enables. The <a href="https://code.google.com/p/oppia/wiki/DesignTips">Design Tips</a> wiki page has some constructive advice on how to create explorations that fit these criteria, especially how to design useful, formative feedback.
                </p>

                <p>
                  <ul>
                    <li style="line-height: 25px;">
                      <strong>Understanding, not memorization.</strong> Does the exploration attempt to teach some interesting concept, or does it merely provide facts for the student to memorize?
                    </li>
                    <li style="line-height: 25px;">
                      <strong>Learning, not assessment.</strong> Does the exploration present new concepts to the learners, or does it simply quiz them on some set of topics? (Even if a quiz later gives out the right answers, this does not necessarily help a learner master the new concepts effectively.)
                    </li>
                    <li style="line-height: 25px;">
                      <strong>Learn by doing.</strong> How is the new information presented to the learner? Does he have a chance to reason about the concepts himself, try out using them, and receive feedback on what he did?
                    </li>
                    <li style="line-height: 25px;">
                      <strong>Formative feedback.</strong> Does the feedback that you provide to the learner give him new useful insights into the problem? Does it find a good middle ground between simply telling the user he's wrong (or right), and giving the entire answer away? Do the feedback rules cover a wide range of possible answers and misconceptions? Is there a catch-all default rule that nevertheless tries to guide the learner toward a good solution?
                    </li>
                    <li style="line-height: 25px;">
                      <strong>Complete and polished.</strong> Is the exploration free of typos, factual errors and bugs? Is the text well-written and easy to read? Does the exploration deliver all the content it has promised to the learner, either within the exploration or as stated the learning objective?
                    </li>
                  </ul>
                </p>
              </div>
            </div>

            <div class="tab-pane" id="publication-policies">
              <div class="oppia-about">
                <h1>Publication policies</h1>
                <p>
                  The following policies help Oppia moderators enforce the publication and release criteria, and keep explorations moving on the path to Released status. All explorations hosted on {{SITE_NAME}} should ultimately be improved to the point where they satisfy these criteria.
                </p>
                <h2>Publishing to Beta</h2>
                <p>
                  Any owner of a private exploration can make the decision to publish an exploration to Beta at any time. However, if the published exploration does not fit the Beta <a href="site_guidelines/#publish-and-release-criteria">criteria</a>, the site moderators may unpublish or delete it, at their discretion. (The norm is to unpublish; deletion is only likely to happen in egregious cases, such as outright spam.)
                </p>
                <h2>Beta explorations</h2>
                <p>
                  Explorations should not linger in the Beta state forever; they are meant to be polished and developed until they are ready for release. A Beta exploration that has not been edited for a prolonged period may be considered "orphaned", and ownership of it may revert to the community at large (at moderator discretion), so that {{SITE_NAME}} community members can move it towards release.
                </p>
                <p>
                  Note that when you embed a particular version of your exploration in your site, this embedded version will not change unless the original exploration on {{SITE_NAME}} is unpublished or deleted. In particular, even if you or other community members make further additions or changes to the exploration on {{SITE_NAME}}, the version embedded on your website will remain the same.
                </p>

                <h2>Releasing an exploration</h2>
                <p>
                  Currently, the process of releasing an exploration is moderator-driven, though we hope to make it more community-driven in the future. When an owner of the exploration - or anybody else involved in the process - thinks the exploration is ready for release, they can post to the <a href="{{MODERATOR_REQUEST_FORUM_URL}}" target="_blank">Moderator Requests forum</a> with a request for moderator review. A moderator will play through the exploration, look at its structure, and decide whether it fits the Release <a href="site_guidelines/#publish-and-release-criteria">criteria</a>. If it does, then the exploration will be released. If it does not, the moderator will make a series of specific suggestions on how to make the exploration conform to the criteria, and work with the creator(s) in that forum thread to get it polished and ready for release.
                </p>
              </div>
            </div>

          </div>
        </div>
      </div>
    </div>
  </div>

{% endblock %}