accumulo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mwa...@apache.org
Subject [03/16] accumulo git commit: Reorganized website menu
Date Mon, 21 Nov 2016 16:24:37 GMT
Reorganized website menu

* Links to User Manual, Javadocs & Examples go to latest release
  in 'Documentation' menu
* Added 'Documentation Archive' for historical reference
* All release notes also have links to documentation for that release
* Added github and twitter buttons next to where download button is.
* Removed old release notes archive as it is now automatically
  generated.
* Moved links in 'Development' menu to new 'Contributor Guide' which
  now lives in 'Community' menu
* Moved content in 'Thanks' page to organizations on 'People' page
* Moved 'Screenshots' to 'Features' page


Project: http://git-wip-us.apache.org/repos/asf/accumulo/repo
Commit: http://git-wip-us.apache.org/repos/asf/accumulo/commit/a71ede83
Tree: http://git-wip-us.apache.org/repos/asf/accumulo/tree/a71ede83
Diff: http://git-wip-us.apache.org/repos/asf/accumulo/diff/a71ede83

Branch: refs/heads/gh-pages
Commit: a71ede8300ce414d51e8de2c8ec90c87e7306ecd
Parents: dca73a8
Author: Mike Walch <mwalch@apache.org>
Authored: Thu Nov 17 10:22:45 2016 -0500
Committer: Mike Walch <mwalch@apache.org>
Committed: Mon Nov 21 11:04:06 2016 -0500

----------------------------------------------------------------------
 _includes/nav.html                          |  33 +-
 _posts/release/2014-03-06-accumulo-1.5.1.md |   7 +
 _posts/release/2014-05-02-accumulo-1.6.0.md |   8 +-
 _posts/release/2014-09-25-accumulo-1.6.1.md |  14 +-
 _posts/release/2015-02-16-accumulo-1.6.2.md |   6 +
 _posts/release/2015-05-18-accumulo-1.7.0.md |   6 +
 _posts/release/2015-06-25-accumulo-1.5.3.md |   6 +
 _posts/release/2015-07-04-accumulo-1.6.3.md |   6 +
 _posts/release/2015-09-19-accumulo-1.5.2.md |   7 +
 _posts/release/2015-09-21-accumulo-1.5.4.md |   6 +
 _posts/release/2015-10-03-accumulo-1.6.4.md |   6 +
 _posts/release/2016-02-17-accumulo-1.6.5.md |   6 +
 _posts/release/2016-02-26-accumulo-1.7.1.md |   6 +
 contrib.md                                  |  90 -----
 contributor/contrib-projects.md             |  91 +++++
 contributor/git.md                          | 453 +++++++++++++++++++++
 contributor/index.md                        |  29 ++
 contributor/rb.md                           | 108 +++++
 contributor/releasing.md                    | 146 +++++++
 contributor/source.md                       | 235 +++++++++++
 contributor/verifying_releases.md           |  92 +++++
 contributor/versioning.md                   |  70 ++++
 css/accumulo.scss                           |   4 +-
 get_involved.md                             |   9 +-
 git.md                                      | 452 ---------------------
 glossary.md                                 | 123 ------
 index.md                                    |   4 +-
 notable_features.md                         | 440 --------------------
 pages/docs-archive.md                       |  29 ++
 pages/examples.md                           |  10 -
 pages/features.md                           | 488 +++++++++++++++++++++++
 pages/glossary.md                           | 123 ++++++
 pages/javadocs.md                           |  10 -
 pages/old_archive.md                        |  57 ---
 pages/user-manual.md                        |  11 -
 people.md                                   |  16 +-
 rb.md                                       | 108 -----
 releasing.md                                | 145 -------
 screenshots.md                              |  47 ---
 source.md                                   | 234 -----------
 thanks.md                                   |  18 -
 verifying_releases.md                       |  91 -----
 versioning.md                               |  69 ----
 43 files changed, 1974 insertions(+), 1945 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/_includes/nav.html
----------------------------------------------------------------------
diff --git a/_includes/nav.html b/_includes/nav.html
index 25290c9..c2a6eb2 100644
--- a/_includes/nav.html
+++ b/_includes/nav.html
@@ -24,13 +24,13 @@
         <li class="dropdown">
         <a class="dropdown-toggle" data-toggle="dropdown" href="#">Documentation<span class="caret"></span></a>
         <ul class="dropdown-menu">
-          <li><a href="{{ site.baseurl }}/user-manual/">User Manuals</a></li>
-          <li><a href="{{ site.baseurl }}/javadocs/">Javadocs</a></li>
-          <li><a href="{{ site.baseurl }}/examples/">Examples</a></li>
-          <li><a href="{{ site.baseurl }}/notable_features">Features</a></li>
-          <li><a href="{{ site.baseurl }}/screenshots">Screenshots</a></li>
+          <li><a href="{{ site.baseurl }}/{{ site.latest_minor_release }}/accumulo_user_manual.html">User Manual ({{ site.latest_minor_release }})</a></li>
+          <li><a href="{{ site.baseurl }}/{{ site.latest_minor_release }}/apidocs">Javadocs ({{ site.latest_minor_release }})</a></li>
+          <li><a href="{{ site.baseurl }}/{{ site.latest_minor_release }}/examples">Examples ({{ site.latest_minor_release }})</a></li>
+          <li><a href="{{ site.baseurl }}/features">Features</a></li>
           <li><a href="{{ site.baseurl }}/papers">Papers &amp; Presentations</a></li>
           <li><a href="{{ site.baseurl }}/glossary">Glossary</a></li>
+          <li><a href="{{ site.baseurl }}/docs-archive/">Archive</a></li>
         </ul>
         </li>
         <li class="dropdown">
@@ -39,30 +39,11 @@
           <li><a href="{{ site.baseurl }}/get_involved">Get Involved</a></li>
           <li><a href="{{ site.baseurl }}/mailing_list">Mailing Lists</a></li>
           <li><a href="{{ site.baseurl }}/people">People</a></li>
-          <li><a href="{{ site.baseurl }}/news">News Archive</a></li>
-          <li><a href="{{ site.baseurl }}/projects">Community Projects</a></li>
-          <li><a href="{{ site.baseurl }}/thanks">Thanks</a></li>
+          <li><a href="{{ site.baseurl }}/projects">Related Projects</a></li>
+          <li><a href="{{ site.baseurl }}/contributor/">Contributor Guide</a></li>
           <li><a href="{{ site.baseurl }}/governance/">Governance</a></li>
         </ul>
         </li>
-        <li class="dropdown">
-        <a class="dropdown-toggle" data-toggle="dropdown" href="#">Development<span class="caret"></span></a>
-        <ul class="dropdown-menu">
-          <li><a href="https://issues.apache.org/jira/browse/ACCUMULO">Issue Tracker <i class="fa fa-external-link"></i></a></li>
-          <li><a href="https://github.com/apache/accumulo/pulls">Pull Requests <i class="fa fa-external-link"></i></a></li>
-          <li><a href="https://builds.apache.org/view/A/view/Accumulo">Jenkins Builds <i class="fa fa-external-link"></i></a></li>
-          <li><a href="https://travis-ci.org/apache/accumulo">TravisCI Builds <i class="fa fa-external-link"></i></a></li>
-          <li class="divider"></li>
-          <li class="dropdown-header">Guides</li>
-          <li><a href="{{ site.baseurl }}/source">Source &amp; Guide</a></li>
-          <li><a href="{{ site.baseurl }}/git">Git Workflow</a></li>
-          <li><a href="{{ site.baseurl }}/versioning">Versioning</a></li>
-          <li><a href="{{ site.baseurl }}/contrib">Contrib Projects</a></li>
-          <li><a href="{{ site.baseurl }}/rb">Review Board</a></li>
-          <li><a href="{{ site.baseurl }}/releasing">Making Releases</a></li>
-          <li><a href="{{ site.baseurl }}/verifying_releases">Verifying Releases</a></li>
-        </ul>
-        </li>
       </ul>
       <ul class="nav navbar-nav navbar-right">
         <li class="dropdown">

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/_posts/release/2014-03-06-accumulo-1.5.1.md
----------------------------------------------------------------------
diff --git a/_posts/release/2014-03-06-accumulo-1.5.1.md b/_posts/release/2014-03-06-accumulo-1.5.1.md
index 71ca1a7..780129b 100644
--- a/_posts/release/2014-03-06-accumulo-1.5.1.md
+++ b/_posts/release/2014-03-06-accumulo-1.5.1.md
@@ -7,6 +7,13 @@ Apache Accumulo 1.5.1 is a maintenance release on the 1.5 version branch.
 This release contains changes from over 200 issues, comprised of bug fixes
 (client side and server side), new test cases, and updated Hadoop support
 contributed by over 30 different contributors and committers.
+
+Below are resources for this release:
+
+* [User Manual](/1.5/accumulo_user_manual.html)
+* [Javadocs](/1.5/apidocs)
+* [Examples](/1.5/examples)
+
 As this is a maintenance release, Apache Accumulo 1.5.1 has no client API 
 incompatibilities over Apache Accumulo 1.5.0 and requires no manual upgrade 
 process. Users of 1.5.0 are strongly encouraged to update as soon as possible 

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/_posts/release/2014-05-02-accumulo-1.6.0.md
----------------------------------------------------------------------
diff --git a/_posts/release/2014-05-02-accumulo-1.6.0.md b/_posts/release/2014-05-02-accumulo-1.6.0.md
index b6529a8..916c0c9 100644
--- a/_posts/release/2014-05-02-accumulo-1.6.0.md
+++ b/_posts/release/2014-05-02-accumulo-1.6.0.md
@@ -3,7 +3,13 @@ title: Apache Accumulo 1.6.0
 redirect_from: /release_notes/1.6.0.html
 ---
 
-Apache Accumulo 1.6.0 adds some major new features and fixes many bugs.  This release contains changes from 609 issues contributed by 36 contributors and committers.  
+Apache Accumulo 1.6.0 adds some major new features and fixes many bugs.  This release contains changes from 609 issues contributed by 36 contributors and committers.
+
+Below are resources for this release:
+
+* [User Manual](/1.6/accumulo_user_manual.html)
+* [Javadocs](/1.6/apidocs)
+* [Examples](/1.6/examples)
 
 Accumulo 1.6.0 runs on Hadoop 1, however Hadoop 2 with HA namenode is recommended for production systems.  In addition to HA, Hadoop 2 also offers better data durability guarantees, in the case when nodes lose power, than Hadoop 1.
 

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/_posts/release/2014-09-25-accumulo-1.6.1.md
----------------------------------------------------------------------
diff --git a/_posts/release/2014-09-25-accumulo-1.6.1.md b/_posts/release/2014-09-25-accumulo-1.6.1.md
index 45ead5e..46c3a45 100644
--- a/_posts/release/2014-09-25-accumulo-1.6.1.md
+++ b/_posts/release/2014-09-25-accumulo-1.6.1.md
@@ -5,9 +5,17 @@ redirect_from: /release_notes/1.6.1.html
 
 Apache Accumulo 1.6.1 is a maintenance release on the 1.6 version branch.
 This release contains changes from over 175 issues, comprised of bug-fixes, performance
-improvements and better test cases. As this is a maintenance release, Apache Accumulo
-1.6.1 has no client API  incompatibilities over Apache Accumulo 1.6.0. Users of 1.6.0
-are strongly encouraged to update as soon as possible to benefit from the improvements.
+improvements and better test cases. 
+
+Below are resources for this release:
+
+* [User Manual](/1.6/accumulo_user_manual.html)
+* [Javadocs](/1.6/apidocs)
+* [Examples](/1.6/examples)
+
+As this is a maintenance release, Apache Accumulo 1.6.1 has no client API incompatibilities
+over Apache Accumulo 1.6.0. Users of 1.6.0 are strongly encouraged to update as soon as
+possible to benefit from the improvements.
 
 New users are encouraged to use this release over 1.6.0 or any other older releases. For
 information about improvements since Accumulo 1.5, see the [1.6.0 release notes][32].

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/_posts/release/2015-02-16-accumulo-1.6.2.md
----------------------------------------------------------------------
diff --git a/_posts/release/2015-02-16-accumulo-1.6.2.md b/_posts/release/2015-02-16-accumulo-1.6.2.md
index 57b07b2..9232e90 100644
--- a/_posts/release/2015-02-16-accumulo-1.6.2.md
+++ b/_posts/release/2015-02-16-accumulo-1.6.2.md
@@ -10,6 +10,12 @@ community has adopted [Semantic Versioning][1] which means that all changes to t
 are guaranteed to be made without adding to or removing from the public API. This ensures
 that client code that runs against 1.6.1 is guaranteed to run against 1.6.2 and vice versa.
 
+Below are resources for this release:
+
+* [User Manual](/1.6/accumulo_user_manual.html)
+* [Javadocs](/1.6/apidocs)
+* [Examples](/1.6/examples)
+
 Users of 1.6.0 or 1.6.1 are strongly encouraged to update as soon as possible to benefit from
 the improvements with very little concern in change of underlying functionality. Users of 1.4 or 1.6
 are seeking to upgrade to 1.6 should consider 1.6.2 the starting point over 1.6.0 or 1.6.1. For

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/_posts/release/2015-05-18-accumulo-1.7.0.md
----------------------------------------------------------------------
diff --git a/_posts/release/2015-05-18-accumulo-1.7.0.md b/_posts/release/2015-05-18-accumulo-1.7.0.md
index 040ac37..144ec1a 100644
--- a/_posts/release/2015-05-18-accumulo-1.7.0.md
+++ b/_posts/release/2015-05-18-accumulo-1.7.0.md
@@ -9,6 +9,12 @@ features related to security, availability, and extensibility. Nearly 700 JIRA
 issues were resolved in this version. Approximately two-thirds were bugs and
 one-third were improvements.
 
+Below are resources for this release:
+
+* [User Manual](/1.7/accumulo_user_manual.html)
+* [Javadocs](/1.7/apidocs)
+* [Examples](/1.7/examples)
+
 In the context of Accumulo's [Semantic Versioning][semver] [guidelines][api],
 this is a "minor version". This means that new APIs have been created, some
 deprecations may have been added, but no deprecated APIs have been removed.

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/_posts/release/2015-06-25-accumulo-1.5.3.md
----------------------------------------------------------------------
diff --git a/_posts/release/2015-06-25-accumulo-1.5.3.md b/_posts/release/2015-06-25-accumulo-1.5.3.md
index ab12740..0a802ec 100644
--- a/_posts/release/2015-06-25-accumulo-1.5.3.md
+++ b/_posts/release/2015-06-25-accumulo-1.5.3.md
@@ -7,6 +7,12 @@ Apache Accumulo 1.5.3 is a bug-fix release for the 1.5 series. It is likely to b
 1.5 release, with development shifting towards newer release lines. We recommend upgrading
 to a newer version to continue to get bug fixes and new features.
 
+Below are resources for this release:
+
+* [User Manual](/1.5/accumulo_user_manual.html)
+* [Javadocs](/1.5/apidocs)
+* [Examples](/1.5/examples)
+
 In the context of Accumulo's [Semantic Versioning][semver] [guidelines][api],
 this is a "patch version". This means that there should be no public API changes. Any
 changes which were made were done in a backwards-compatible manner. Code that

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/_posts/release/2015-07-04-accumulo-1.6.3.md
----------------------------------------------------------------------
diff --git a/_posts/release/2015-07-04-accumulo-1.6.3.md b/_posts/release/2015-07-04-accumulo-1.6.3.md
index 2de1679..e210a9b 100644
--- a/_posts/release/2015-07-04-accumulo-1.6.3.md
+++ b/_posts/release/2015-07-04-accumulo-1.6.3.md
@@ -8,6 +8,12 @@ This release contains changes from over 63 issues, comprised of bug-fixes,
 performance improvements and better test cases. See [JIRA][JIRA_163] for a
 complete list.
 
+Below are resources for this release:
+
+* [User Manual](/1.6/accumulo_user_manual.html)
+* [Javadocs](/1.6/apidocs)
+* [Examples](/1.6/examples)
+
 Users of 1.6.0, 1.6.1, and 1.6.2 are strongly encouraged to update as soon as
 possible to benefit from the improvements with very little concern in change
 of underlying functionality. Users of 1.4 or 1.5 that are seeking to upgrade

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/_posts/release/2015-09-19-accumulo-1.5.2.md
----------------------------------------------------------------------
diff --git a/_posts/release/2015-09-19-accumulo-1.5.2.md b/_posts/release/2015-09-19-accumulo-1.5.2.md
index d876840..9569f6b 100644
--- a/_posts/release/2015-09-19-accumulo-1.5.2.md
+++ b/_posts/release/2015-09-19-accumulo-1.5.2.md
@@ -7,6 +7,13 @@ Apache Accumulo 1.5.2 is a maintenance release on the 1.5 version branch.
 This release contains changes from over 100 issues, comprised of bug fixes
 (client side and server side), new test cases, and updated Hadoop support
 contributed by over 30 different contributors and committers.
+
+Below are resources for this release:
+
+* [User Manual](/1.5/accumulo_user_manual.html)
+* [Javadocs](/1.5/apidocs)
+* [Examples](/1.5/examples)
+
 As this is a maintenance release, Apache Accumulo 1.5.2 has no client API 
 incompatibilities over Apache Accumulo 1.5.0 and 1.5.1 and requires no manual upgrade 
 process. Users of 1.5.0 or 1.5.1 are strongly encouraged to update as soon as possible 

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/_posts/release/2015-09-21-accumulo-1.5.4.md
----------------------------------------------------------------------
diff --git a/_posts/release/2015-09-21-accumulo-1.5.4.md b/_posts/release/2015-09-21-accumulo-1.5.4.md
index 336ca06..09ef319 100644
--- a/_posts/release/2015-09-21-accumulo-1.5.4.md
+++ b/_posts/release/2015-09-21-accumulo-1.5.4.md
@@ -6,6 +6,12 @@ redirect_from: /release_notes/1.5.4.html
 Apache Accumulo 1.5.4 is one more bug-fix release for the 1.5 series. Like 1.5.3 before it, this release contains a
 very small changeset when considering the normal size of changes in a release.
 
+Below are resources for this release:
+
+* [User Manual](/1.5/accumulo_user_manual.html)
+* [Javadocs](/1.5/apidocs)
+* [Examples](/1.5/examples)
+
 This release contains no changes to the [public API][api]. As such, there are no concerns
 for the compatibility of user code running against 1.5.3. All users are encourage to upgrade
 immediately without concern of stability and compatibility.

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/_posts/release/2015-10-03-accumulo-1.6.4.md
----------------------------------------------------------------------
diff --git a/_posts/release/2015-10-03-accumulo-1.6.4.md b/_posts/release/2015-10-03-accumulo-1.6.4.md
index 40dfe3d..b498814 100644
--- a/_posts/release/2015-10-03-accumulo-1.6.4.md
+++ b/_posts/release/2015-10-03-accumulo-1.6.4.md
@@ -8,6 +8,12 @@ This release contains changes from 21 issues, comprised of bug-fixes,
 performance improvements and better test cases. See [JIRA][JIRA_164] for a
 complete list.
 
+Below are resources for this release:
+
+* [User Manual](/1.6/accumulo_user_manual.html)
+* [Javadocs](/1.6/apidocs)
+* [Examples](/1.6/examples)
+
 Users of any previous 1.6.x release are strongly encouraged to update as soon as
 possible to benefit from the improvements with very little concern in change
 of underlying functionality. Users of 1.4 or 1.5 that are seeking to upgrade

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/_posts/release/2016-02-17-accumulo-1.6.5.md
----------------------------------------------------------------------
diff --git a/_posts/release/2016-02-17-accumulo-1.6.5.md b/_posts/release/2016-02-17-accumulo-1.6.5.md
index efc4e98..7f6d616 100644
--- a/_posts/release/2016-02-17-accumulo-1.6.5.md
+++ b/_posts/release/2016-02-17-accumulo-1.6.5.md
@@ -8,6 +8,12 @@ release contains changes from 55 issues, comprised of bug-fixes, performance
 improvements, build quality improvements, and more. See [JIRA][JIRA_165] for a
 complete list.
 
+Below are resources for this release:
+
+* [User Manual](/1.6/accumulo_user_manual.html)
+* [Javadocs](/1.6/apidocs)
+* [Examples](/1.6/examples)
+
 Users of any previous 1.6.x release are strongly encouraged to update as soon as
 possible to benefit from the improvements with very little concern in change of
 underlying functionality. Users of 1.4 or 1.5 that are seeking to upgrade to 1.6

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/_posts/release/2016-02-26-accumulo-1.7.1.md
----------------------------------------------------------------------
diff --git a/_posts/release/2016-02-26-accumulo-1.7.1.md b/_posts/release/2016-02-26-accumulo-1.7.1.md
index ee64607..77ce388 100644
--- a/_posts/release/2016-02-26-accumulo-1.7.1.md
+++ b/_posts/release/2016-02-26-accumulo-1.7.1.md
@@ -8,6 +8,12 @@ release contains changes from more than 150 issues, comprised of bug-fixes,
 performance improvements, build quality improvements, and more. See
 [JIRA][JIRA_171] for a complete list.
 
+Below are resources for this release:
+
+* [User Manual](/1.7/accumulo_user_manual.html)
+* [Javadocs](/1.7/apidocs)
+* [Examples](/1.7/examples)
+
 Users of any previous 1.7.x release are strongly encouraged to update as soon
 as possible to benefit from the improvements with very little concern in change
 of underlying functionality. Users of 1.6 or earlier that are seeking to

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/contrib.md
----------------------------------------------------------------------
diff --git a/contrib.md b/contrib.md
deleted file mode 100644
index e8b3853..0000000
--- a/contrib.md
+++ /dev/null
@@ -1,90 +0,0 @@
----
-title: Contrib Projects
----
-
-Apache Accumulo is a complex distributed system. In order to minimize that
-complexity for both operators and developers the project maintains contrib
-repositories for instructive applications and code that builds interoperability
-between Accumulo and other systems. This helps minimize the set of dependencies
-needed when building or installing Accumulo, keeps the build time down, and
-allows the contrib projects to follow their own release schedule.
-
-## Existing Contrib Projects
-
-Each of the below contrib project handles their own development and release
-cycle. For information on what version(s) of Accumulo they work with, see the
-documentation for the individual project.
-
-### Instamo Archetype
-
-A Maven Archetype that automates the customization of Instamo to quickly spin
-up an Accumulo process in memory.
-
-The Apache Accumulo Instamo Archetype uses [Git][gitbook] version control
-([browse][instamo-browse]|[checkout][instamo-checkout]). It builds with [Apache
-Maven][maven-proj]. See the section [Contributing to Contrib][contrib2] for
-instructions on submitting issues and patches.
-
-### Wikisearch Application
-
-A complex application example that makes use of most of the Accumulo feature
-stack. The Wikisearch application provides an example of indexing and querying
-Wikipedia data within Accumulo. It is a great place to start if you want to get
-familiar with good development practices building on Accumulo. 
-
-For details on setting up the application, see the project&apos;s README. You can
-also read [an overview and some performance numbers][wikisearch].
-
-The Apache Accumulo Wikisearch Example uses [Git][gitbook] version control
-([browse][wikisearch-browse]|[checkout][wikisearch-checkout]). It builds with
-[Apache Maven][maven-proj]. See the section [Contributing to Contrib][contrib2] for
-instructions on submitting issues and patches.
-
-### Hama Integration
-
-An implementation for running [Bulk Synchronous Parallel (BSP)
-algorithms][bsp-alg] implemented via [Apache Hama][hama] on top of data stored
-in Accumulo.
-
-The Apache Accumulo BSP implementation uses [Git][gitbook] version control
-([browse][bsp-browse]|[checkout][bsp-checkout]).  It builds with [Apache
-Maven][maven-proj]. See the section [Contributing to Contrib][contrib2] for
-instructions on submitting issues and patches.
-
-## Contributing to Contrib
-
-All contributions to the various Apache Accumulo contrib projects should follow
-the [same process used in the primary project][git-process]. All contributions
-should have a corresponding issue filed in the [contrib component in the
-Accumulo issue tracker][jira-component].
-
-## Adding a new Contrib Project
-
-Proposals for new contrib projects should be sent to the [Accumulo mailing
-list][mailing-list] for [developers][mail-with-subj]. 
-
-If an example application only makes use of a single Accumulo feature, it is
-probably better off as an Accumulo version-specific example. You can see
-several of these demonstrative applications in the [simple example
-codebase][examples-simple] and the related published documentation for versions
-[1.7][17EXAMPLES] and [1.6][16EXAMPLES].
-
-[gitbook]: http://git-scm.com
-[instamo-browse]: https://git-wip-us.apache.org/repos/asf?p=accumulo-instamo-archetype.git;a=summary
-[instamo-checkout]: https://git-wip-us.apache.org/repos/asf/accumulo-instamo-archetype.git
-[maven-proj]: https://maven.apache.org
-[wikisearch]: example/wikisearch
-[wikisearch-browse]: https://git-wip-us.apache.org/repos/asf?p=accumulo-wikisearch.git;a=summary
-[wikisearch-checkout]: https://git-wip-us.apache.org/repos/asf/accumulo-wikisearch.git
-[bsp-alg]: https://hama.apache.org/hama_bsp_tutorial
-[hama]: https://hama.apache.org
-[bsp-browse]: https://git-wip-us.apache.org/repos/asf?p=accumulo-bsp.git;a=summary
-[bsp-checkout]: https://git-wip-us.apache.org/repos/asf/accumulo-bsp.git
-[git-process]: git#the-implementation
-[jira-component]: https://issues.apache.org/jira/browse/ACCUMULO/component/12316610
-[mailing-list]: mailing_list
-[mail-with-subj]: mailto:dev@accumulo.apache.org?subject=[Accumulo+Contrib+Proposal]
-[examples-simple]: https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=tree;f=examples/simple;
-[16EXAMPLES]: 1.6/examples
-[17EXAMPLES]: 1.7/examples
-[contrib2]: #contributing-to-contrib

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/contributor/contrib-projects.md
----------------------------------------------------------------------
diff --git a/contributor/contrib-projects.md b/contributor/contrib-projects.md
new file mode 100644
index 0000000..360cf0c
--- /dev/null
+++ b/contributor/contrib-projects.md
@@ -0,0 +1,91 @@
+---
+title: Contrib Projects
+redirect_from: /contrib
+---
+
+Apache Accumulo is a complex distributed system. In order to minimize that
+complexity for both operators and developers the project maintains contrib
+repositories for instructive applications and code that builds interoperability
+between Accumulo and other systems. This helps minimize the set of dependencies
+needed when building or installing Accumulo, keeps the build time down, and
+allows the contrib projects to follow their own release schedule.
+
+## Existing Contrib Projects
+
+Each of the below contrib project handles their own development and release
+cycle. For information on what version(s) of Accumulo they work with, see the
+documentation for the individual project.
+
+### Instamo Archetype
+
+A Maven Archetype that automates the customization of Instamo to quickly spin
+up an Accumulo process in memory.
+
+The Apache Accumulo Instamo Archetype uses [Git][gitbook] version control
+([browse][instamo-browse]|[checkout][instamo-checkout]). It builds with [Apache
+Maven][maven-proj]. See the section [Contributing to Contrib][contrib2] for
+instructions on submitting issues and patches.
+
+### Wikisearch Application
+
+A complex application example that makes use of most of the Accumulo feature
+stack. The Wikisearch application provides an example of indexing and querying
+Wikipedia data within Accumulo. It is a great place to start if you want to get
+familiar with good development practices building on Accumulo. 
+
+For details on setting up the application, see the project&apos;s README. You can
+also read [an overview and some performance numbers][wikisearch].
+
+The Apache Accumulo Wikisearch Example uses [Git][gitbook] version control
+([browse][wikisearch-browse]|[checkout][wikisearch-checkout]). It builds with
+[Apache Maven][maven-proj]. See the section [Contributing to Contrib][contrib2] for
+instructions on submitting issues and patches.
+
+### Hama Integration
+
+An implementation for running [Bulk Synchronous Parallel (BSP)
+algorithms][bsp-alg] implemented via [Apache Hama][hama] on top of data stored
+in Accumulo.
+
+The Apache Accumulo BSP implementation uses [Git][gitbook] version control
+([browse][bsp-browse]|[checkout][bsp-checkout]).  It builds with [Apache
+Maven][maven-proj]. See the section [Contributing to Contrib][contrib2] for
+instructions on submitting issues and patches.
+
+## Contributing to Contrib
+
+All contributions to the various Apache Accumulo contrib projects should follow
+the [same process used in the primary project][git-process]. All contributions
+should have a corresponding issue filed in the [contrib component in the
+Accumulo issue tracker][jira-component].
+
+## Adding a new Contrib Project
+
+Proposals for new contrib projects should be sent to the [Accumulo mailing
+list][mailing-list] for [developers][mail-with-subj]. 
+
+If an example application only makes use of a single Accumulo feature, it is
+probably better off as an Accumulo version-specific example. You can see
+several of these demonstrative applications in the [simple example
+codebase][examples-simple] and the related published documentation for versions
+[1.7][17EXAMPLES] and [1.6][16EXAMPLES].
+
+[gitbook]: http://git-scm.com
+[instamo-browse]: https://git-wip-us.apache.org/repos/asf?p=accumulo-instamo-archetype.git;a=summary
+[instamo-checkout]: https://git-wip-us.apache.org/repos/asf/accumulo-instamo-archetype.git
+[maven-proj]: https://maven.apache.org
+[wikisearch]: example/wikisearch
+[wikisearch-browse]: https://git-wip-us.apache.org/repos/asf?p=accumulo-wikisearch.git;a=summary
+[wikisearch-checkout]: https://git-wip-us.apache.org/repos/asf/accumulo-wikisearch.git
+[bsp-alg]: https://hama.apache.org/hama_bsp_tutorial
+[hama]: https://hama.apache.org
+[bsp-browse]: https://git-wip-us.apache.org/repos/asf?p=accumulo-bsp.git;a=summary
+[bsp-checkout]: https://git-wip-us.apache.org/repos/asf/accumulo-bsp.git
+[git-process]: git#the-implementation
+[jira-component]: https://issues.apache.org/jira/browse/ACCUMULO/component/12316610
+[mailing-list]: mailing_list
+[mail-with-subj]: mailto:dev@accumulo.apache.org?subject=[Accumulo+Contrib+Proposal]
+[examples-simple]: https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=tree;f=examples/simple;
+[16EXAMPLES]: 1.6/examples
+[17EXAMPLES]: 1.7/examples
+[contrib2]: #contributing-to-contrib

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/contributor/git.md
----------------------------------------------------------------------
diff --git a/contributor/git.md b/contributor/git.md
new file mode 100644
index 0000000..278ae1d
--- /dev/null
+++ b/contributor/git.md
@@ -0,0 +1,453 @@
+---
+title: Git
+redirect_from: /git
+---
+
+[Git](https://git-scm.com) is an open source, distributed version control system
+which has become very popular in large, complicated software projects due to
+its efficient handling of multiple, simultaneously and independently developed
+branches of source code.\
+
+
+## Workflow Background
+
+Likely the most contested subject matter regarding switching an active team
+from one SCM tool to another is a shift in the development paradigm.
+
+Some background, the common case, as is present with this team, is that
+developers coming from a Subversion history are very light on merging being a
+critical consideration on how to perform development. Because merging in
+Subversion is typically of no consequence to the complete view of history, not
+to mention that Subversion allows "merging" of specific revisions instead of
+sub-trees. As such, a transition to Git typically requires a shift in mindset
+in which a fix is not arbitrarily applied to trunk (whatever the main
+development is called), but the fix should be applied to the earliest, non
+end-of-life (EOL) version of the application.
+
+For example, say there is a hypothetical application which has just released
+version-3 of their software and have shifted their development to a version-4
+WIP. Version-2 is still supported, while version-1 was just EOL'ed. Each
+version still has a branch. A bug was just found which affects all released
+versions of this application. In Subversion, considering the history in the
+repository, it is of no consequence where the change is initially applied,
+because a Subversion merge is capable of merging it to any other version.
+History does not suffer because Subversion doesn't have the capacities to
+accurately track the change across multiple branches. In Git, to maintain a
+non-duplicative history, it is imperative that the developer choose the correct
+branch to fix the bug in. In this case, since version-1 is EOL'ed, version-2,
+version-3 and the WIP version-4 are candidates. The earliest version is
+obviously version-2; so, the change should be applied in version-2, merged to
+version-3 and then the version-4 WIP.
+
+The importance of this example is making a best-attempt to preserve history
+when using Git. While Git does have commands like cherry-pick which allow the
+contents of a commit to be applied from one branch to another which are not
+candidates to merge without conflict (which is typically the case when merging
+a higher version into a lower version), this results in a duplication of that
+commit in history when the two trees are eventually merged together. While Git
+is smart enough to not attempt to re-apply the changes, history still contains
+the blemish.
+
+The purpose of this extravagant example is to outline, in the trivial case, how
+the workflow decided upon for development is very important and has direct
+impact on the efficacy of the advanced commands bundled with Git.
+
+## Proposed Workflow
+
+This is a summary of what has been agreed upon by vocal committers/PMC members
+on [dev@accumulo.apache.org](mailto:dev@accumulo.apache.org). Enumeration of
+every possible situation out of the scope of this document. This document
+intends to lay the ground work to define the correct course of action regardless
+of circumstances. Some concrete examples will be provided to ensure the
+explanation is clear.
+
+1. Active development is performed concurrently over no less than two versions
+   of Apache Accumulo at any one point in time. As such, the workflow must
+   provide guidance on how and where changes should be made which apply to
+   multiple versions and how to ensure that such changes are contained in all
+   applicable versions.
+
+2. Releases are considered extremely onerous and time-consuming so no emphasis
+   is placed on rapid iterations or development-cycles.
+
+3. New features typically have lengthy development cycles in which more than
+   one developer contributes to the creation of the new feature from planning,
+   to implementation, to scale testing. Mechanisms/guidance should be provided
+   for multiple developers to teach contribute to a remote-shared resource.
+
+4. The repository should be the irrefutable, sole source of information
+   regarding the development of Apache Accumulo, and, as such, should have
+   best-efforts given in creating a clean, readable history without any single
+   entity having to control all write access and changes (a proxy). In other
+   words, the developers are the ones responsible for ensuring that previous
+   releases are preserved to meet ASF policy, for not rewriting any public
+   history of code not yet officially released (also ASF policy relevant) and
+   for a best-effort to be given to avoid duplicative commits appearing in
+    history created by the application of multiple revisions which have
+    different identifying attributes but the same contents (git-rebase and
+    git-cherry-pick).
+
+# The implementation 
+
+## Contributors
+
+Use the following steps, original derived from Apache Kafka's [simple
+contributor
+workflow][1].
+
+To be specific, let's consider a contributor wanting to work on a fix for the
+Jira issue ACCUMULO-12345 that affects 1.5.0 release.
+
+1. Ensure you configured Git with your information
+
+    `git config --global user.name 'My Name' && git config --global user.email
+    'myname@mydomain.com'`
+
+2. Clone the Accumulo repository:
+
+    `git clone https://git-wip-us.apache.org/repos/asf/accumulo.git accumulo`
+
+3. or update your local copy:
+
+    `git fetch && git fetch --tags`
+
+4. For the given issue you intend to work on, choose the 'lowest' fixVersion
+   and create a branch for yourself to work in. This example is against the next release of 1.5
+
+    `git checkout -b ACCUMULO-12345-my-work origin/1.5`
+
+5. Make commits as you see fit as you fix the issue, referencing the issue name
+   in the commit message:
+
+    `git commit -av`
+
+    Please include the ticket number at the beginning of the log message, and
+    in the first line, as it's easier to parse quickly. For example:
+
+    `ACCUMULO-2428 throw exception when rename fails after compaction`
+
+    Consider following the git log message format described in
+    [Zach Holman's talk](https://zachholman.com/talk/more-git-and-github-secrets/)
+    (specifically slides 78-98, beginning at 15:20 into the video). Essentially,
+    leave a short descriptive message in the first line, skip a line, and write
+    more detailed stuff there, if you need to. For example:
+
+    `ACCUMULO-2194 Add delay for randomwalk Security teardown`
+
+    `If two Security randomwalk tests run back-to-back, the second test may see that the
+    table user still exists even though it was removed when the first test was torn down.
+    This can happen if the user drop does not propagate through Zookeeper quickly enough.
+    This commit adds a delay to the end of the Security test to give ZK some time.`
+
+6. Assuming others are developing against the version you also are, as you
+   work, or before you create your patch, rebase your branch against the remote
+   to lift your changes to the top of your branch. The branch specified here should be the same one you used in step 4.
+
+    `git pull --rebase origin 1.5`
+
+7. At this point, you can create a patch file from the upstream branch to
+   attach to the ACCUMULO-12345 Jira issue. The branch specified here should be teh same one you used in step 4.
+
+    `git format-patch --stdout origin/1.5 > ACCUMULO-12345.patch`
+
+An alternative to creating a patch is submitting a request to pull your changes
+from some repository, e.g. Github. Please include the repository and branch
+name merge in the notice to the Jira issue, e.g.
+
+    repo=git://github.com/<username>/accumulo.git branch=ACCUMULO-12345
+
+A second alternative is to use Github's "Pull Requests" feature against the
+[Apache Accumulo account](https://github.com/apache/accumulo). Notifications of
+new pull-requests from Github should automatically be sent to
+[dev@accumulo.apache.org](mailto:dev@accumulo.apache.org).
+
+Ignoring specifics, contributors should be sure to make their changes against
+the earlier version in which the fix is intended, `git-rebase`'ing their
+changes against the upstream branch so as to keep their changes co-located and
+free of unnecessary merges.
+
+## Developers
+
+### Primary Development
+
+Primary development should take place in `master` which is to contain the most
+recent, un-released version of Apache Accumulo. Branches exist for minor releases
+for each previously released major version. 
+
+Using long-lived branches that track a major release line simplifies management and
+release practices. Developers are encouraged to make branches for their own purposes,
+for large features, release candidates or whatever else is deemed useful.
+
+### Reviewing contributor changes
+
+It is always the responsibility of committers to determine that a patch is
+intended and able to be contributed.  From the
+[new committer's guide](https://www.apache.org/dev/new-committers-guide#cla):
+"Please take care to ensure that patches are original works which have been
+clearly contributed to the ASF in public. In the case of any doubt (or when a
+contribution with a more complex history is presented) please consult your
+project PMC before committing it."
+
+Extra diligence may be necessary when code is contributed via a pull request.
+Committers should verify that the contributor intended to submit the code as a 
+Contribution under the [Apache License](https://www.apache.org/licenses/LICENSE-2.0.txt).
+When pulling the code, committers should also verify that the commits pulled match the 
+list of commits sent to the Accumulo dev list in the pull request.
+
+#### Patches
+
+Developers should use the following steps to apply patches from
+contributors:
+
+1. Checkout the branch for the major version which the patch is intended:
+
+    `git checkout 1.5`
+
+2. Verify the changes introduced by the patch:
+
+    `git apply --stat ACCUMULO-12345.patch`
+
+3. Verify that the patch applies cleanly:
+
+    `git apply --check ACCUMULO-12345.patch`
+
+4. If all is well, apply the patch:
+
+    `git am --signoff < ACCUMULO-12345.patch`
+
+5. When finished, push the changes:
+
+    `git push origin 1.5`
+
+6. Merge where appropriate:
+
+    `git checkout master && git merge 1.5`
+
+#### Github Pull-Requests
+
+If the contributor submits a repository and branch to pull
+from, the steps are even easier:
+
+1. Add their repository as a remote to your repository
+
+    `git remote add some_name ${repository}`
+
+2. Fetch the refs from the given repository
+
+    `git fetch ${repository}`
+
+3. Merge in the given branch to your local branch
+
+    `git merge some_name/${branch}`
+
+4. Delete the remote:
+
+    `git remote remove some_name`
+
+If the branch doesn't fast-forward merge, you likely want to inform the
+contributor to update their branch to avoid the conflict resolution and merge
+commit. See the [Git
+manual](https://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging)
+for more information on merging. When merging a pull-request, it's best to **not**
+include a signoff on the commit(s) as it changes the final commit ID in the
+Accumulo repository. This also has the negative of not automatically closing
+the Pull-Request when the changes are made public.
+
+### Feature Branches
+
+Ease in creating and using feature branches is a desirable merit which Git
+provides with little work. Feature branches are a great way in which developers
+to work on multiple, long-running features concurrently, without worry of
+mixing code ready for public-review and code needing more internal work.
+Additionally, this creates an easily consumable series of commits in which
+other developers can track changes, and see how the feature itself evolved.
+
+To prevent developers' feature branches from colliding with one another, it was
+suggested to impose a "hierarchy" in which shared feature branches are prefixed
+with `<apache_id>/ACCUMULO-<issue#>[-description]`.
+
+1. Create a branch off of `master`.
+
+    `git checkout <apache_id>/ACCUMULO-<issue#> master`
+
+2. Create the feature, commiting early and often to appropriately outline the
+"story" behind the feature and it's implementation.
+
+3. As long as you have not collaborating with others, `git-rebase` your feature
+branch against upstream changes in `master`
+
+    `git fetch && git rebase origin/master`
+
+4. If you are actively collaborating with others, you should be nice and not
+change their history. Use `git-merge` instead.
+
+    `git fetch && git merge origin/master`
+
+5. Continue steps 2 through 4 until the feature is complete.
+
+6. Depending on the nature, duration and history of the changes in your feature
+branch, you can choose to:
+
+    * **'Simple' Merge**: 
+
+        `git checkout master && git merge <apache_id>/ACCUMULO-<issue#>`
+
+    * **Rebase and merge** -- keeps all feature-branch commits
+      co-located: 
+
+        `git fetch && git rebase origin/master && git checkout master && git merge <apache_id>/ACCUMULO-<issue#>`
+
+    * **Merge with squash** -- feature branch history is a mess, just make one commit
+      with the lump-sum of your feature branch changes: 
+
+        `git checkout master && git merge --squash <apache_id>/ACCUMULO-<issue#>`
+
+### Changes which affect multiple versions (a.k.a. merging)
+
+Merging can be a very confusing topic for users switching to Git, but it can be
+summarized fairly easily.
+
+0. **Precondition**: choose the right branch to start! (lowest, applicable version
+   for the change)
+
+1. Get your changes fixed for that earliest version.
+
+2. Switch to the next highest version which future minor versions will be
+   released (non-EOL major release series).
+
+3. `git-merge` the branch from #1 into the current.
+
+4. In the face of conflicts, use options from `git-merge` to help you.
+
+    * `git checkout new-version && git merge --stat old-version`
+    * `git checkout new-version && git merge --no-commit old-version`
+
+5. Treat your current branch as the branch from #2, and repeat from #2.
+
+When merging changes across major releases, there is always the possibility of
+changes which are applicable/necessary in one release, but not in any future
+releases, changes which are different in implementation due to API changes, or
+any number of other cases. Whatever the actual case is, the developer who made
+the first set of changes (you) is the one responsible for performing the merge
+through the rest of the active versions. Even when the merge may results in a
+zero-length change in content, this is incredibly important to record as you
+are the one who knows that this zero-length change in content is correct!
+
+## Release Management
+
+Releases, although not a day to day task, have their own unique steps which are
+to be followed. Releases can be categorized in to minor and major releases.
+
+### A minor release
+
+A minor release is some set of changes `z'` on top of a version `x.y.z`.
+Typically, `z'` is simply `z + 1`, e.g. given a release named '1.6.0', and the
+next minor release is '1.6.1'. These changes for `z'` should not break any
+client code which works against `z` and should absolutely not change the public
+API.
+
+By convention, the branch containing the changes `z'` should be named
+`x.y` (where the changes for `z'` are commits since `x.y.z`. The steps to take are as follows:
+
+1. Prepare the release candidate. [Release
+   Guide]({{ site.baseurl }}/governance/releasing), [Maven
+   Instructions]({{ site.baseurl }}/releasing)
+2. Create a branch for the release candidate from the `x.y` branch,
+   named something like `x.y.z'-RCN`.
+3. Test and Vote
+4. Create a GPG-signed tag with the correct final name: `x.y.z'`
+5. Push a delete of the remote branch `x.y.z'-RCN`
+
+This process is not firm and should not be viewed as requirements for making a release.
+The release manager is encouraged to make use branches/tags in whichever way is best.
+
+### A major release
+
+A major release is a release in which multiple new features are introduced
+and/or the public API are modified. The major release `y'`, even when the
+client API is not modified, will typically contain many new features and
+functionality above the last release series `y`. A major release also resets
+the `z` value back to `0`.
+
+The steps to create a new major release are very similar to a minor release:
+
+1. Prepare the release candidate. _reference release instructions_
+2. Create a tag of the release candidate from the `x.y` branch,
+   named something like `x.y.0-RCN`.
+3. Test and Vote
+4. Create a GPG-signed tag with the correct final name: `x.y.0`
+5. Push a delete of the remote branch `x.y.0-RCN`
+
+# The infrastructure
+
+This section deals with the changes that must be requested through INFRA. As
+with any substantial INFRA request, the VOTE and result from the mailing should
+be referenced so INFRA knows that the request has been acknowledged. Likely, a
+PMC member should be the one to submit the request.
+
+## Repositories
+
+I believe that we will need multiple repositories to best align ourselves with
+how we currently track "Accumulo" projects. The repositories follow:
+
+1. The main source tree. This will track the standard trunk, branches, tags
+   structure from Subversion for Apache Accumulo.
+
+2. One repository for every project in
+   [contrib](https://svn.apache.org/repos/asf/accumulo/contrib): Accumulo-BSP,
+   Instamo Archetype, and the Wikisearch project. Each of these
+   are considered disjoint from one another, and the main source tree, so they
+   each deserve their own repository.
+
+Given the list of repositories that currently exist on the [ASF
+site](https://git-wip-us.apache.org/repos/asf) and a brief search over INFRA
+tickets, multiple repositories for a single Apache project is not an issue.
+Having this list when making the initial ticket will likely reduce the amount
+of work necessary in opening multiple INFRA tickets.
+
+## Mirroring
+
+It should be noted in the INFRA requst that each repository will also need to
+be configured to properly mirror to the [ASF Github](https://github.com/apache)
+account to provide the same functionality with current have via the git+svn
+mirror. This should be noted in the INFRA request. Same change needs to be
+applied for the [Apache hosted](https://git.apache.org) mirror'ing.
+
+## Mailing lists
+
+It should be noted in the INFRA request that commit messages should be sent to
+[commits@accumulo.apache.org](mailto:commits@accumulo.apache.org). The subject
+can be decided on using the [provided
+variables](https://git-wip-us.apache.org/docs/switching-to-git#contents).
+
+# Examples
+
+For the sake of clarity, some examples of common situations are included below.
+
+## Releasing 1.6.0
+
+1. Branch from `master` to `1.6`
+
+    `git checkout master && git branch 1.6`
+
+2. Tag `1.6.0-RC1` from the just created `1.6` branch
+
+    `git tag 1.6.0-RC1 1.6`
+
+3. Test, vote, etc. and tag from 1.6.0-RC1
+
+    `git -s tag 1.6.0 1.6.0-RC1`
+
+4. Delete the RC tag, if desired.
+
+    `git tag -d 1.6.0-RC1 && git push --delete origin 1.6.0-RC1`
+
+5. Ensure `master` contains all features and fixes from `1.6.0`
+
+    `git checkout master && git merge 1.6`
+
+6. Update the project version in `master` to 1.7.0-SNAPSHOT
+
+
+[1]: https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review#Patchsubmissionandreview-Simplecontributorworkflow
+

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/contributor/index.md
----------------------------------------------------------------------
diff --git a/contributor/index.md b/contributor/index.md
new file mode 100644
index 0000000..3902a17
--- /dev/null
+++ b/contributor/index.md
@@ -0,0 +1,29 @@
+---
+title: Contributor Guide
+---
+
+This page contains resources and documentation for Accumulo contributors.
+
+Any documentation that is helpful to Accumulo users should be placed in the [user manual][manual].
+
+* [JIRA] - Accumulo's Issue Tracker
+* [GitHub] - Pull requests can be made on GitHub
+* [Jenkins] & [TravisCI] - Accumulo build servers
+* [Source Guide]({{ "/contributor/source" | relative_url }})
+* [Git Workflow]({{ "/contributor/git" | relative_url }})
+* [Versioning]({{ "/contributor/versioning" | relative_url }})
+* [Contrib Projects]({{ "/contributor/contrib-projects" | relative_url }})
+* [Review Board]({{ "/contributor/rb" | relative_url }})
+
+Below are resources for Accumulo committers which may also be helpful to contributors.
+
+* [Making Releases][making]
+* [Verifying Releases][verifying]
+
+[manual]: {{ site.baseurl }}/{{ site.latest_minor_release }}/accumulo_user_manual.html
+[JIRA]: https://issues.apache.org/jira/browse/ACCUMULO
+[GitHub]: https://github.com/apache/accumulo/pulls
+[Jenkins]: https://builds.apache.org/view/A/view/Accumulo
+[TravisCI]: https://travis-ci.org/apache/accumulo
+[making]: {{ "/contributor/releasing" | relative_url }}
+[verifying]: {{ "/contributor/verifying_releases" | relative_url }}

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/contributor/rb.md
----------------------------------------------------------------------
diff --git a/contributor/rb.md b/contributor/rb.md
new file mode 100644
index 0000000..dccbb40
--- /dev/null
+++ b/contributor/rb.md
@@ -0,0 +1,108 @@
+---
+title: Using Review Board
+---
+
+The Apache Software Foundation provides an [instance][rbinstance] of
+[Review Board][rb] (RB) for projects to use in code reviews. Here is how RB can
+be used to support development in the context of the
+[Apache Accumulo bylaws][bylaws].
+
+Contributors to Accumulo are encouraged to use RB for non-trivial patches and
+any time feedback is desired. No one is required to use RB, but its ready
+availability and better interface for feedback can help with reviews. Committers
+seeking review prior to pushing changes can also benefit similarly.
+
+## Roles for Review Board
+
+### Optional Pre-Commit Review
+
+Accumulo operates under the [Commit-Then-Review][ctr] (CtR) policy, so code
+review does not need to occur prior to commit. However, a committer may opt to
+hold a code review before commit for changes that, in their opinion, would
+benefit from additional attention. RB can be used to conduct such code reviews.
+
+### Consensus Approval after a Code Change Veto
+
+Code changes are approved by lazy approval, with consensus approval following
+a veto (see the [Actions][actions] section of the bylaws). RB can be used
+to coordinate a consensus approval vote by providing a convenient view of the
+code change under consideration. The vote itself must still be held on the
+developer mailing list.
+
+## Guidelines for Posting a Review
+
+* It is best to post a git-generated patch as the basis for a review. RB does
+  not support patches containing multiple commits, so either squash commits
+  first, or submit a diff spanning the changeset. The `rbt` and `post-review`
+  tools generate diffs.
+* Strive to make your changes small. Reviewers are less likely to want to
+  trudge through a review with lots of changes, and are more likely to miss
+  problems.
+* Begin the summary of the review with a JIRA issue number. A review must
+  always be associated with a JIRA issue. The issue number should also be
+  entered in the "Bugs" field of the review, providing a link to JIRA.
+* The "Branch" field should contain the name of the branch that the code change
+  is based on (e.g., the base of your git feature branch).
+* Include the "accumulo" user group as reviewers. Also include specific people
+  as individual reviewers, even if they are in the "accumulo" group, if you
+  deem them of primary importance for the review (e.g., you have been working
+  out problems with the review with them, they are expert in the area).
+* Use the description to summarize the change under review. Include helpful
+  instructions to the reviewers here.
+* Describe any testing done on the change. It is not expected that reviewers
+  will do their own testing, and they may reject the review if you have not
+  done sufficient testing yourself.
+* Avoid submitting generated code for review if it can be reproduced by a
+  reviewer.
+
+After the review is published, set the status of the associated JIRA issue to
+"Patch Available" as a signal to reviewers. Also, link to the review from the
+issue (More -> Link -> Web Link) to help viewers of the issue find the review
+and assess its progress.
+
+## Guidelines for Reviewing Code
+
+* Try to associate comments with relevant lines of code in the review.
+* By default, each comment opens a review issue. If a comment pertains to
+  something that should not block the review from completing successfully, then
+  clear the "Open an issue" checkbox before saving your feedback. Examples that
+  might qualify as non-issues: minor formatting/whitespace issues, spelling
+  mistakes, general background questions.
+* If a review looks good, be sure to "Ship It" by either using the "Ship It!"
+  button or by submitting a general review with the "Ship It" checkbox checked.
+
+## Guidelines for Completing a Review
+
+These guidelines do not apply to consensus approval votes, since the vote
+completion depends on the votes registered in the developer mailing list.
+
+* Use your judgement for the number of "Ship It"s you want to receive to
+  consider a review passed. Usually, getting one "Ship It" is enough to proceed
+  with a commit. It is recommended that the "Ship It" be from a committer who
+  is a neutral party not involved in the change under review.
+* Use your judgement for the minimum time length you set for the review. Simple
+  changes can be up for just a day, while complex ones should take up to seven.
+* Review time should be extended in the face of problems discovered in the
+  review. Update the review with improved code instead of discarding (i.e.,
+  closing unsuccessfully) it and beginning a new one.
+* A review should not be "submitted" (i.e., closed successfully) unless there
+  are no outstanding issues. Check with reviewers to ensure that their issues
+  are resolved satisfactorily.
+* A review should be "discarded" if the code requires major rework or it
+  becomes obvious it should never be committed (due to design changes,
+  becoming overcome by events, being back-burnered, etc.).
+* Don't leave a review open indefinitely. Once you have received sufficient
+  feedback to submit or discard it, do so. If there has been no activity for
+  some time, discard the review. A new one can always be created later.
+
+Once you've closed a review as submitted, if you are unable to commit your
+changes yourself, attach the final version of them to the relevant JIRA issue.
+They should be in the form of a patch containing a single commit,
+[per the final steps of the contribution process][contributor].
+
+[rbinstance]: https://reviews.apache.org
+[rb]: https://www.reviewboard.org
+[bylaws]: {{ "/governance/bylaws" | relative_url }}
+[ctr]: https://www.apache.org/foundation/glossary#CommitThenReview
+[actions]: {{ "/governance/bylaws#actions" | relative_url }}
+[contributor]: {{ "/contributor/git#contributors" | relative_url }}

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/contributor/releasing.md
----------------------------------------------------------------------
diff --git a/contributor/releasing.md b/contributor/releasing.md
new file mode 100644
index 0000000..39be39a
--- /dev/null
+++ b/contributor/releasing.md
@@ -0,0 +1,146 @@
+---
+title: Making a Release
+redirect_from: /releasing
+---
+
+This is a guide for the creation of a release of Apache Accumulo. 
+
+## Setup
+
+There are number of things that are required before attempting to build a release.
+
+1. Use gpg-agent, and be sure to increase the gpg-agent cache timeout (via .gnupg/gpg-agent.conf) to ensure that the agent doesn't require re-authentication mid-build, as it will cause things to fail. For example, you can add `default-cache-ttl 6000` to increase the timeout from the default of 10 minutes to over an hour. If you do not have a GPG key, reference the very thorough [ASF release signing documentation][1].
+2. Ensure that you're using the correct major release of Java (check javadoc too).
+3. Ensure that you're building Apache Accumulo with a username that has the same name as your Apache ID (this is due to
+   the maven-release-plugin and staging the release candidate).
+4. Update the CHANGES file so that it's in sync with Jira (manual process).
+5. Ensure that you have a texlive distribution installed so you are able to build the documentation.
+6. Have a clean workspace before starting.
+
+Given all of this, it's recommended that you only attempt making a release from a GNU/Linux machine.
+
+## Create the candidate
+
+**TL;DR**
+
+* `./assemble/build.sh --create-release-candidate` to make the release candidate
+* `git tag $version $version-rcN` to create an RC tag from the actual tag
+* `git tag -d $version` make sure you don't accidentally push a "release" tag
+* `git push origin $version-rcN` push the RC tag
+* `git checkout -b $version-rcN-branch` save off the branch from the Maven release plugin
+* **VOTE**
+* *If vote fails*, fix the original branch and start over.
+* *If vote passes*, `git merge $version-rcN-branch` back into the original branch you released from.
+* `git tag -s $version-rcN $version` make a GPG-signed tag
+* `git push origin $version` push the signed tag.
+
+**Long-winded explanation**
+
+You should use the provided script assemble/build.sh to create the release candidate. This script is
+desirable as it activates all necessary maven profiles in addition to verifying that certain preconditions
+are met, like RPM signing availablilty and the ability to sign files using GPG. The --test option can 
+be used as a dry run for creating a release candidate. The --create-release-candidate option should be 
+used to create the actual release candidate.
+
+When invoking build.sh with the --create-release-candidate option, the majority of the work will be performed
+by the maven-release-plugin, invoking *release:clean*, *release:prepare*, and *release:perform*. These will
+guide you through choosing the correct versions. The default options provided should be what you choose.
+It is highly recommended that an 'RC' suffix is *not* appended to the release version the plugin prompts
+you for, as that will result in that version string being placed into the poms, which then would require 
+voting to occur on artifacts that cannot be directly promoted. After the build.sh script finishes (this will 
+likely take at least 15 minutes, even on recent hardware), your current branch will be on the "next" version 
+that you provided to the release plugin.
+
+One unwanted side-effect of this approach is that after creating this branch, but *before invoking release:perform*,
+you must edit the release.properties to add the _-rcN_ suffix to the value of scm.tag. Otherwise, the release
+plugin will complain that it cannot find the branch for the release. With a successful invocation of *mvn release:perform*,
+a staging repository will be made for you on the [ASF Nexus server][2] which you can log into with your ASF 
+credentials.
+
+After you log into Nexus, click on _Staging Repositories_ in the _Build Promotion_ toolbar on the left side of
+the screen. Assuming your build went according to plan, you should have a new staging repository made for
+you. At this point, you should inspect the artifacts that were staged to ensure that they are as you expect
+them to be. When you're ready to present those artifacts for voting, you need to close that repository which
+will make it publicly available for other members to inspect.
+
+## Vote
+
+At this point, you should have a closed repository that's ready to vote on. Send a message to [the dev
+list](mailto:dev@accumulo.apache.org) and get the ball rolling. If the vote ultimately fails, you delete
+the staged repository, clean up the branch you created (or wait until the release ultimately passes if you
+choose), and fix what needs fixing.
+
+If the vote passes, huzzah, you're almost done.
+
+## Promote the artifacts 
+
+Promote that staged repository using Nexus which you can do with the click of a button. This will trigger
+a process to get the release out to all of the mirrors.
+
+## Create the final Git tag
+
+The Git repository should also contain a tag which refers to the final commit which made up a release. This tag
+should also be signed with your GPG key. To ensure proper retention on release (stemming from ASF policy
+requirements), This final tag *must* being with "rel/". For example, a release of 1.7.0 should have a corresponding
+tag name of "rel/1.7.0".
+
+
+## Copy artifacts to dist.apache.org
+
+An SVN server is running at https://dist.apache.org/repos/dist/release/accumulo. You need to upload the release
+tarballs, the GPG signatures and checksum files to the correct directory (based on the release number). If you
+are releasing a bug-fix release, be sure to delete the previous release in the same line (e.g. if you release
+1.6.2, remove 1.6.1). The old tarballs removed from dist.apache.org will still be preserved in archive.apache.org
+automatically.
+
+## Update projects.apache.org
+
+Fill out the [add release][addrelease] form to update the projects website.
+
+## Update the Website
+
+After a successful vote, this website needs to be updated with the new artifacts.
+
+  * Copy Accumulo User Manual (HTML version exists in >=1.7.0)
+  * Update downloads page
+  * Create release notes (ensure notes contain link to JIRA changes for that version)
+  * Remove previous bug-fix release (if applicable)
+  * Update examples README files
+  * Update doap_Accumulo.rdf
+
+### Javadocs
+
+Javadocs are easy to update. Using the latest JDK7 or later (at least JDK 7u21
+to avoid known [vulnerabilities][7]), follow these steps:
+
+1. Unpack the source release tarball and change to its root directory, or checkout the SCM tag for the release
+2. Build the javadocs with `mvn clean package javadoc:aggregate -DskipTests -Paggregate-javadocs`
+3. Take note that the javadocs you will need to copy are the entire contents of `./target/site/apidocs/`
+4. Checkout the `gh-pages` branch (you may need to move the contents of `./target/site/apidocs` outside your git workspace to switch branches)
+5. Remove any existing apidocs from the appropriate version folder (e.g. 1.6/apidocs for a 1.6.x release)
+6. Copy the entire contents of the new apidocs directory (identified in step 3) to the destination (e.g. to 1.6/apidocs)
+7. Continue updating the site content, as needed
+8. Commit the changes
+9. Update the site using jekyll with `./_devtools/git-hooks/post-commit` (if you don't have the commit hook already configured)
+10. Don't forget to push both the `gh-pages` and `asf-site` branches
+11. Verify that javadocs have been updated on the production site (e.g. https://accumulo.apache.org/1.6/apidocs/)
+
+## References
+
+Some good references that explain a few things:
+
+- [Christopher talks about making releases][3]
+- [Publishing Maven Artifacts][4]
+- [Publishing Releases][5]
+- [Accumulo Release Guide][6]
+
+
+[1]: https://www.apache.org/dev/release-signing
+[2]: https://repository.apache.org
+[3]: https://mail-archives.apache.org/mod_mbox/accumulo-dev/201305.mbox/raw/%3CCAL5zq9bH8y0FyjXmmfXhWPj8axosn9dZ7%2Bu-R1DK4Y-WM1YoWg%40mail.gmail.com%3E
+[4]: https://www.apache.org/dev/publishing-maven-artifacts
+[5]: https://www.apache.org/dev/release-publishing
+[6]: {{ site.baseurl }}/governance/releasing
+[7]: https://www.kb.cert.org/vuls/id/225657
+[8]: https://www.apache.org/dev/cmsref#extpaths
+[addrelease]: https://reporter.apache.org/addrelease?accumulo

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/contributor/source.md
----------------------------------------------------------------------
diff --git a/contributor/source.md b/contributor/source.md
new file mode 100644
index 0000000..e8de7ff
--- /dev/null
+++ b/contributor/source.md
@@ -0,0 +1,235 @@
+---
+title: Source Code and Developers Guide
+skiph1fortitle: true
+redirect_from: /source
+---
+
+<div class="panel panel-default pull-right">
+<div class="panel-heading">Quick Links</div>
+<div class="list-group">
+<a href="https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=summary" class="list-group-item"><i class="fa fa-external-link"></i> Accumulo source</a>
+<a href="https://builds.apache.org/job/Accumulo-Master" class="list-group-item"><i class="fa fa-external-link"></i> Master build on Jenkins</a>
+<a href="https://issues.apache.org/jira/browse/ACCUMULO" class="list-group-item"><i class="fa fa-external-link"></i> Accumulo JIRA</a>
+</div>
+</div>
+
+## Source Code
+
+### Apache Accumulo
+
+Apache Accumulo&trade; source code is maintained using [Git][git] version control 
+([browse][cgit]|[checkout][anongit]).  It builds with [Apache Maven][maven].
+
+Instructions for configuring git are [here][git-instr].
+
+### Contrib Projects
+
+Accumulo has a number of [contrib projects][contrib] that maintain their own code repositories and release schedules.
+
+### Website
+
+Accumulo's web site is developed using [Jekyll][jekyll]. Development is
+performed by editing the contents of the [gh-pages][gh-pages] branch, either
+directly by a committer, with a pull request to [GitHub][github], or a patch
+submitted to [JIRA][jiraloc]. The rendered site can be previewed locally or on
+[GitHub][site-mirror], and the rendered site (in the `_site` directory) will be
+merged into the `asf-site` branch to update our [official/canonical
+site][site-canon] after being built.
+
+To manage any Gem dependencies, it is highly recommended to use [Bundler](https://bundler.io).
+To start using Bundler, install it and then the dependencies for the website:
+
+    gem install bundler
+    bundle install
+
+To get help with jekyll:
+
+    jekyll help
+
+To test the site locally (usually on http://localhost:4000):
+
+    jekyll serve --safe
+
+To do the same with Bundler:
+
+    bundle exec jekyll serve --safe
+
+To build for updating the `asf-site` branch:
+
+    jekyll build --safe
+
+To do the same with Bundler:
+
+    bundle exec jekyll build --safe
+
+For preview convenience and consistent builds and testing, build using a
+version which looks the same locally and on GitHub.
+
+A [post-commit hook][hook] is available for you to automatically create a
+commit in the `asf-site` branch locally each time you commit to the `gh-pages`
+branch. You can also run this command manually:
+
+    ./_devtools/git-hooks/post-commit
+
+To automatically run this post-commit hook in your local repository, copy
+the given file into your `.git/hook` directory:
+
+    cp ./_devtools/git-hooks/post-commit .git/hooks/
+
+## Developer's Guide
+
+### Building
+
+#### Installing Apache Thrift
+
+If you activate the 'thrift' Maven profile, the build of some modules will attempt to run the Apache Thrift command line to regenerate
+stubs. If you activate this profile and don't have Apache Thrift installed and in your path, you will see a warning and
+your build will fail. For Accumulo 1.5.0 and greater, install Thrift 0.9 and make sure that the 'thrift' command is in your path. 
+Watch out for THRIFT-1367; you may need to configure Thrift with --without-ruby. Most developers do not
+need to install or modify the Thrift definitions as a part of developing against Apache Accumulo.
+
+#### Checking out from Git
+
+To check out the code:
+
+    git clone https://git-wip-us.apache.org/repos/asf/accumulo.git
+
+#### Running a Build
+
+Accumulo uses  [Apache Maven][maven] to handle source building, testing, and packaging. To build Accumulo you will need to use Maven version 3.0.5 or later.
+
+You should familiarize yourself with the [Maven Build Lifecycle][lifecycle], as well as the various plugins we use in our [POM][pom], in order to understand how Maven works and how to use the various build options while building Accumulo.
+
+To build from source (for example, to deploy):
+
+    mvn package -Passemble
+
+This will create a file accumulo-*-SNAPSHOT-dist.tar.gz in the assemble/target directory. Optionally, append `-DskipTests` if you want to skip the build tests.
+
+To build your branch before submitting a pull request, you'll probably want to run some basic "sunny-day" integration tests to ensure you haven't made any grave errors, as well as `checkstyle` and `findbugs`:
+
+    mvn verify -Psunny
+
+To run specific unit tests, you can run:
+
+    mvn package -Dtest=MyTest -DfailIfNoTests=false
+
+Or to run the specific integration tests MyIT and YourIT (and skip all unit tests), you can run:
+
+    mvn verify -Dtest=NoSuchTestExists -Dit.test=MyIT,YourIT -DfailIfNoTests=false
+
+There are plenty of other options. For example, you can skip findbugs with `mvn verify -Dfindbugs.skip` or checkstyle `-Dcheckstyle.skip`, or control the number of forks to use while executing tests, `-DforkCount=4`, etc. You should check with specific plugins to see which command-line options are available to control their behavior. Note that not all options will result in a stable build, and options may change over time.
+
+If you regularly switch between major development branches, you may receive errors about improperly licensed files from the [RAT plugin][1]. This is caused by modules that exist in one branch and not the other leaving Maven build files that the RAT plugin no longer understands how to ignore.
+
+The easiest fix is to ensure all of your current changes are stored in git and then cleaning your workspace.
+
+    $> git add path/to/file/that/has/changed
+    $> git add path/to/other/file
+    $> git clean -df
+
+Note that this git clean command will delete any files unknown to git in a way that is irreversible. You should check that no important files will be included by first looking at the "untracked files" section in a ```git status``` command.
+
+    $> git status
+    # On branch master
+    nothing to commit (working directory clean)
+    $> mvn package
+    { maven output elided }
+    $> git checkout 1.6.1-SNAPSHOT
+    Switched to branch '1.6.1-SNAPSHOT'
+    $> git status
+    # On branch 1.6.1-SNAPSHOT
+    # Untracked files:
+    #   (use "git add <file>..." to include in what will be committed)
+    #
+    # mapreduce/
+    # shell/
+    nothing added to commit but untracked files present (use "git add" to track)
+    $> git clean -df
+    Removing mapreduce/
+    Removing shell/
+    $> git status
+    # On branch 1.6.1-SNAPSHOT
+    nothing to commit (working directory clean)
+
+### Continuous Integration
+
+Accumulo uses [Jenkins][jenkins] for automatic builds.
+
+<img src="https://builds.apache.org/job/Accumulo-Master/lastBuild/buildStatus" style="height: 1.1em"> [Master][masterbuild]
+
+<img src="https://builds.apache.org/job/Accumulo-1.7/lastBuild/buildStatus" style="height: 1.1em"> [1.7 Branch][17build]
+
+<img src="https://builds.apache.org/job/Accumulo-1.6/lastBuild/buildStatus" style="height: 1.1em"> [1.6 Branch][16build]
+
+### Issue Tracking
+
+Accumulo [tracks issues][jiraloc] with [JIRA][jira].  Every commit should reference a JIRA ticket of the form ACCUMULO-#.
+
+### Merging Practices
+
+Changes should be merged from earlier branches of Accumulo to later branches.  Ask the [dev list][devlist] for instructions.
+
+### Public API
+
+Refer to the README in the release you are using to see what packages are in the public API.
+
+Changes to non-private members of those classes are subject to additional scrutiny to minimize compatibility problems across Accumulo versions.
+
+### Coding Practices
+
+{: .table}
+| **License Header**              | Always add the current ASF license header as described in [ASF Source Header][srcheaders].            |
+| **Trailing Whitespaces**        | Remove all trailing whitespaces. Eclipse users can use Source&rarr;Cleanup option to accomplish this. |
+| **Indentation**                 | Use 2 space indents and never use tabs!                                                               |
+| **Line Wrapping**               | Use 160-column line width for Java code and Javadoc.                                                  |
+| **Control Structure New Lines** | Use a new line with single statement if/else blocks.                                                  |
+| **Author Tags**                 | Do not use Author Tags. The code is developed and owned by the community.                             |
+
+### Code Review
+
+Accumulo has [guidelines for using Review Board][rb] to support code reviews.
+
+### IDE Configuration Tips
+
+#### Eclipse
+
+* Download Eclipse [formatting and style guides for Accumulo][styles].
+* Import Formatter: Preferences > Java > Code Style >  Formatter and import the Eclipse-Accumulo-Codestyle.xml downloaded in the previous step. 
+* Import Template: Preferences > Java > Code Style > Code Templates and import the Eclipse-Accumulo-Template.xml. Make sure to check the "Automatically add comments" box. This template adds the ASF header and so on for new code.
+
+#### IntelliJ
+
+ * Formatter [plugin][intellij-formatter] that uses eclipse code style xml.
+
+### Release Guide
+
+Accumulo's release guide can be found [here][release].
+
+[16build]: https://builds.apache.org/job/Accumulo-1.6
+[17build]: https://builds.apache.org/job/Accumulo-1.7
+[1]: https://creadur.apache.org/rat/apache-rat-plugin
+[anongit]: git://git.apache.org/accumulo.git
+[cgit]: https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=summary
+[contrib]: {{ "/contributor/contrib-projects" | relative_url }}
+[devlist]: mailto:dev@accumulo.apache.org
+[gh-pages]: https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=tree;h=gh-pages
+[git-instr]: https://git-wip-us.apache.org
+[git]: https://git-scm.com
+[github]: https://github.com/apache/accumulo
+[hook]: https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob_plain;f=_devtools/git-hooks/post-commit;hb=gh-pages
+[intellij-formatter]: https://code.google.com/p/eclipse-code-formatter-intellij-plugin
+[jekyll]: https://jekyllrb.com
+[jenkins]: https://jenkins.io
+[jira]: https://www.atlassian.com/software/jira
+[jiraloc]: https://issues.apache.org/jira/browse/ACCUMULO
+[lifecycle]: https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle
+[masterbuild]: https://builds.apache.org/job/Accumulo-Master
+[maven]: https://maven.apache.org
+[pom]: https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob_plain;f=pom.xml;hb=HEAD
+[rb]: {{ "/contributor/rb" | relative_url }}
+[release]: {{ "/governance/releasing" | relative_url }}
+[site-canon]: https://accumulo.apache.org
+[site-mirror]: http://apache.github.io/accumulo
+[srcheaders]: https://www.apache.org/legal/src-headers
+[styles]: https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=tree;f=contrib;hb=HEAD

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/contributor/verifying_releases.md
----------------------------------------------------------------------
diff --git a/contributor/verifying_releases.md b/contributor/verifying_releases.md
new file mode 100644
index 0000000..f36ef49
--- /dev/null
+++ b/contributor/verifying_releases.md
@@ -0,0 +1,92 @@
+---
+title: Verifying a Release
+redirect_from: /verifying_releases
+---
+
+This is a guide for the verification of a release candidate of Apache Accumulo. These steps are meant to encapsulate
+the requirements of the PMC set forth by the Foundation itself.
+
+The information here is meant to be an application of Foundation policy. When in doubt or conflict, any Foundation-level
+trumps anything written here.
+
+Verification of a release candidate can be broken down into three categories.
+
+## Accumulo Correctness ##
+
+Testing a distributed database is, arguably, the easiest of these requirements.
+
+Accumulo contains unit and integration tests which can be automatically run via Maven. These tests can be invoked
+by issues the following commands:
+
+    $ mvn verify
+
+Additionally, Accumulo contains multiple distributed tests, most notably the RandomWalk and ContinuousIngest tests.
+Information on these tests can be found in their respective directories, `test/system/randomwalk` and
+ `test/system/continuous`, which include instructions on how to run the tests. These tests are intended to be run
+for days on end while injecting faults into the system. These are the tests that truly verify the correctness of
+Accumulo on real systems.
+
+More information on these tests, and the requirements in running them for a given release, can be found on the
+[governance page on releasing][1]
+
+## Foundation Level Requirements ##
+
+The ASF requires that all artifacts in a release are cryptographically signed and distributed with hashes.
+
+OpenPGP is an asymmetric encryption scheme which lends itself well to the globally distributed nature of Apache.
+Verification of a release artifact can be done using the signature and the release-maker's public key. Hashes
+can be verified using the appropriate command (e.g. `sha1sum`, `md5sum`).
+
+An Apache release must contain a source-only artifact. This is the official release artifact. While a release of
+an Apache project can contain other artifacts that do contain binary files. These non-source artifacts are for
+user convenience only, but still must adhere to the same licensing rules.
+
+PMC members should take steps to verify that the source-only artifact does not contain any binary files. There is
+some leeway in this rule. For example, test-only binary artifacts (such as test files or jars) are acceptable as long
+as they are only used for testing the software and not running it.
+
+The following are the aforementioned Foundation-level documents provided for reference:
+
+* [Applying the Apache Software License][2]
+* [Legal's license application guidelines][3]
+* [Common legal-discuss mailing list questions/resolutions][4]
+* [ASF Legal Affairs Page][5]
+
+## Apache Software License Application ##
+
+Application of the Apache Software License v2 consists of the following steps on each artifact in a release. It's
+important to remember that for artifacts that contain other artifacts (e.g. a tarball that contains JAR files or
+an RPM which contains JAR files), both the tarball, RPM and JAR files are subject to the following roles.
+
+The difficulty in verifying each artifact is that, often times, each artifact requires a different LICENSE and NOTICE
+file. For example, the Accumulo binary tarball must contain appropriate LICENSE and NOTICE files considering the bundled
+jar files in `lib/`. The Accumulo source tarball would not contain these same contents in the LICENSE and NOTICE files
+as it does not contain those same JARs.
+
+### LICENSE file ###
+
+The LICENSE file should be present at the top-level of the artifact. This file should be explicitly named `LICENSE`,
+however `LICENSE.txt` is acceptable but not preferred. This file contains the text of the Apache Software License 
+at the top of the file. At the bottom of the file, all other open source licenses _contained in the given
+artifact_ must be listed at the bottom of the LICENSE file. Contained components that are licensed with the ASL themselves
+do not need to be included in this file. It is common to see inclusions in file such as the MIT License of 3-clause
+BSD License.
+
+### NOTICE file ###
+
+The NOTICE file should be present at the top-level of the artifact beside the LICENSE file. This file should be explicitly
+name `NOTICE`, while `NOTICE.txt` is also acceptable but not preferred. This file contains the copyright notice for
+the artifact being released. As a reminder, the copyright is held by the Apache Software Foundation, not the individual
+project.
+
+The second purpose this file serves is to distribute third-party notices from dependent software. Specifically, other code
+which is licensed with the ASLv2 may also contain a NOTICE file. If such an artifact which contains a NOTICE file is
+contained in artifact being verified for releases, the contents of the contained artifact's NOTICE file should be appended
+to this artifact's NOTICE file. For example, Accumulo bundles the Apache Thrift libthrift JAR file which also have its
+own NOTICE file. The contents of the Apache Thrift NOTICE file should be included within Accumulo's NOTICE file.
+
+[1]: {{ site.baseurl }}/governance/releasing#testing
+[2]: https://www.apache.org/dev/apply-license
+[3]: https://www.apache.org/legal/src-headers
+[4]: https://www.apache.org/legal/resolved
+[5]: https://www.apache.org/legal

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/contributor/versioning.md
----------------------------------------------------------------------
diff --git a/contributor/versioning.md b/contributor/versioning.md
new file mode 100644
index 0000000..cb136e5
--- /dev/null
+++ b/contributor/versioning.md
@@ -0,0 +1,70 @@
+---
+title: Versioning
+redirect_from: /versioning
+---
+
+The Apache Accumulo PMC closed a vote on 2014/12/12 which adopted [Semantic Versioning 2.0.0][1] as
+the reference document on the meaning and requirements of the versions of Apache Accumulo. Semantic
+versioning requires a definition of a public API: this definition is unchanged over previous releases and
+can be found in section 9 of the [README][2]. A copy of the specification is included here, licensed under
+[Creative Commons - CC BY 3.0][3]:
+
+## Specification
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
+in this document are to be interpreted as described in RFC 2119.
+
+1. Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist
+strictly in documentation. However it is done, it should be precise and comprehensive.
+
+2. A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain
+leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase
+numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.
+
+3. Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST
+be released as a new version.
+
+4. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be
+considered stable.
+
+5. Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent
+on this public API and how it changes.
+
+6. Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix
+is defined as an internal change that fixes incorrect behavior.
+
+7. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the
+public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if
+substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes.
+Patch version MUST be reset to 0 when minor version is incremented.
+
+8. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public
+API. It MAY include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented.
+
+9. A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following
+the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty.
+Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal
+version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements
+as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
+
+10. Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following
+the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST
+NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the
+build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.
+
+11. Precedence refers to how versions are compared to each other when ordered. Precedence MUST be calculated by separating
+the version into major, minor, patch and pre-release identifiers in that order (Build metadata does not figure into precedence).
+Precedence is determined by the first difference when comparing each of these identifiers from left to right as follows: Major,
+minor, and patch versions are always compared numerically. Example: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. When major, minor, and patch
+are equal, a pre-release version has lower precedence than a normal version. Example: 1.0.0-alpha < 1.0.0. Precedence for two
+pre-release versions with the same major, minor, and patch version MUST be determined by comparing each dot separated identifier
+from left to right until a difference is found as follows: identifiers consisting of only digits are compared numerically and
+identifiers with letters or hyphens are compared lexically in ASCII sort order. Numeric identifiers always have lower precedence
+than non-numeric identifiers. A larger set of pre-release fields has a higher precedence than a smaller set, if all of the
+preceding identifiers are equal. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 
+1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.
+
+
+[1]: http://semver.org/spec/v2.0.0
+[2]: https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob;f=README.md;hb=refs/heads/master
+[3]: https://creativecommons.org/licenses/by/3.0

http://git-wip-us.apache.org/repos/asf/accumulo/blob/a71ede83/css/accumulo.scss
----------------------------------------------------------------------
diff --git a/css/accumulo.scss b/css/accumulo.scss
index 8ca49be..bb30adc 100644
--- a/css/accumulo.scss
+++ b/css/accumulo.scss
@@ -167,8 +167,8 @@ h1[id]::before, h2[id]::before, h3[id]::before, h4[id]::before, h5[id]::before,
   visibility: hidden;
 }
 
-/* Makes navbar collapse at larger width (1185px) */
-@media (max-width: 1185px) {
+/* Makes navbar collapse at larger width (1050px) */
+@media (max-width: 975px) {
     .navbar-header {
         float: none;
     }


Mime
View raw message