[15/22] incubator-tinkerpop git commit: Made subdirectories for various "books" in the docs.

[sp...@apache.org]

Made subdirectories for various "books" in the docs.

At this point you can generate docs with --dryRun, but the pre/post processors don't know what to do as the paths don't all point at the root of doc generation anymore.  That's the next step.


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

Branch: refs/heads/master
Commit: bc46d64982ba6e517b47baccf88a410f4d407dcc
Parents: 79b0556
Author: Stephen Mallette <sp...@genoprime.com>
Authored: Fri Nov 20 06:53:39 2015 -0500
Committer: Stephen Mallette <sp...@genoprime.com>
Committed: Fri Nov 20 06:53:39 2015 -0500

----------------------------------------------------------------------
 bin/process-docs.sh                             |    2 +-
 docs/src/acknowledgements.asciidoc              |   40 -
 docs/src/conclusion.asciidoc                    |   26 -
 docs/src/dev/developer/administration.asciidoc  |   91 +
 docs/src/dev/developer/contributing.asciidoc    |  362 +++
 docs/src/dev/developer/index.asciidoc           |   33 +
 docs/src/dev/developer/meetings.asciidoc        |   64 +
 docs/src/dev/developer/release.asciidoc         |  184 ++
 docs/src/developer-administration.asciidoc      |   91 -
 docs/src/developer-contributing.asciidoc        |  362 ---
 docs/src/developer-meetings.asciidoc            |   64 -
 docs/src/developer-release.asciidoc             |  184 --
 docs/src/developer.asciidoc                     |   33 -
 docs/src/gremlin-applications.asciidoc          | 1760 -------------
 docs/src/implementations.asciidoc               | 1764 -------------
 docs/src/index.asciidoc                         |   39 -
 docs/src/intro.asciidoc                         |  397 ---
 docs/src/preface.asciidoc                       |   97 -
 docs/src/reference/acknowledgements.asciidoc    |   40 +
 docs/src/reference/conclusion.asciidoc          |   26 +
 .../src/reference/gremlin-applications.asciidoc | 1760 +++++++++++++
 docs/src/reference/implementations.asciidoc     | 1764 +++++++++++++
 docs/src/reference/index.asciidoc               |   39 +
 docs/src/reference/intro.asciidoc               |  397 +++
 docs/src/reference/preface.asciidoc             |   97 +
 docs/src/reference/the-graph.asciidoc           |  771 ++++++
 docs/src/reference/the-graphcomputer.asciidoc   |  475 ++++
 docs/src/reference/the-traversal.asciidoc       | 2378 ++++++++++++++++++
 docs/src/the-graph.asciidoc                     |  771 ------
 docs/src/the-graphcomputer.asciidoc             |  475 ----
 docs/src/the-traversal.asciidoc                 | 2378 ------------------
 docs/src/tutorials-getting-started.asciidoc     |  571 -----
 .../tutorials/getting-started/index.asciidoc    |  571 +++++
 .../upgrade-release-3.0.x-incubating.asciidoc   |  180 --
 .../upgrade-release-3.1.x-incubating.asciidoc   |  322 ---
 docs/src/upgrade.asciidoc                       |   39 -
 docs/src/upgrade/index.asciidoc                 |   39 +
 .../upgrade/release-3.0.x-incubating.asciidoc   |  180 ++
 .../upgrade/release-3.1.x-incubating.asciidoc   |  322 +++
 pom.xml                                         |   38 +-
 40 files changed, 9609 insertions(+), 9617 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/bc46d649/bin/process-docs.sh
----------------------------------------------------------------------
diff --git a/bin/process-docs.sh b/bin/process-docs.sh
index 4710317..dd1dc2a 100755
--- a/bin/process-docs.sh
+++ b/bin/process-docs.sh
@@ -24,7 +24,7 @@ if [ "$1" == "--dryRun" ]; then
 
   mkdir -p target/postprocess-asciidoc/tmp
   cp -R docs/{static,stylesheets} target/postprocess-asciidoc/
-  cp docs/src/*.asciidoc target/postprocess-asciidoc/
+  cp -R docs/src/. target/postprocess-asciidoc/
   ec=$?
 
 else

http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/bc46d649/docs/src/acknowledgements.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/acknowledgements.asciidoc b/docs/src/acknowledgements.asciidoc
deleted file mode 100644
index 76cddec..0000000
--- a/docs/src/acknowledgements.asciidoc
+++ /dev/null
@@ -1,40 +0,0 @@
-////
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements.  See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License.  You may obtain a copy of the License at
-
-  http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
-////
-[[acknowledgements]]
-Acknowledgements
-================
-
-image:yourkit-logo.png[width=200,float=left] YourKit supports the TinkerPop open source project with its full-featured
-Java Profiler. YourKit, LLC is the creator of innovative and intelligent tools for profiling Java and .NET
-applications. YourKit's leading software products: link:http://www.yourkit.com/java/profiler/index.jsp[YourKit Java Profiler]
-and link:http://www.yourkit.com/.net/profiler/index.jsp[YourKit .NET Profiler]
-
-image:egg-logo.png[width=200,float=left] link:http://incubator.apache.org/projects/tinkerpop.html[Apache TinkerPop] is
-an effort undergoing incubation at link:http://apache.org[The Apache Software Foundation] (ASF), sponsored by the
-Apache Incubator. Incubation is required of all newly accepted projects until a further review indicates that the
-infrastructure, communications, and decision making process have stabilized in a manner consistent with other
-successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of
-the code, it does indicate that the project has yet to be fully endorsed by the ASF. Apache TinkerPop is distributed
-under the Apache License v2.0.
-
-image:ketrina-tinkerpop3.png[width=150,float=right] link:http://ketrinayim.tumblr.com[Ketrina Yim] -- Designing
-Gremlin and his friends for TinkerPop was one of my first major projects as a freelancer, and it's delightful to
-see them on the Web and all over the documentation! Drawing and tweaking the characters over time is like watching
-them grow up. They've gone from sketches on paper to full-color logos, and from logos to living characters that
-cheerfully greet visitors to the TinkerPop website. And it's been a great time all throughout!
-
-...in the beginning. 

http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/bc46d649/docs/src/conclusion.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/conclusion.asciidoc b/docs/src/conclusion.asciidoc
deleted file mode 100644
index c5eecf3..0000000
--- a/docs/src/conclusion.asciidoc
+++ /dev/null
@@ -1,26 +0,0 @@
-////
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements.  See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License.  You may obtain a copy of the License at
-
-  http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
-////
-[[conclusion]]
-Conclusion
-==========
-
-image:tinkerpop-character.png[width=100,float=left] The world that we know, you and me, is but a subset of the world
-that Gremlin has weaved within The TinkerPop. Gremlin has constructed a fully connected graph and only the subset that
-makes logical sense to our traversing thoughts is the fragment we have come to know and have come to see one another
-within. But there are many more out there, within other webs of logics unfathomed. From any thought, every other
-thought, we come to realize that which is -- The TinkerPop.
-

http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/bc46d649/docs/src/dev/developer/administration.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/dev/developer/administration.asciidoc b/docs/src/dev/developer/administration.asciidoc
new file mode 100644
index 0000000..fea3749
--- /dev/null
+++ b/docs/src/dev/developer/administration.asciidoc
@@ -0,0 +1,91 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+////
+Administration
+==============
+
+New Committers
+--------------
+
+When a candidate is identified by a PPMC member as someone who might be a good official committer to TinkerPop, the
+PPMC member should open a DISCUSS thread on the private TinkerPop mailing list.  The thread should provide some
+background and reasoning for why that member believes the candidate would be a good committer.  Given enough time for
+feedback on the candidate and presuming there is still positive interest in doing so, a VOTE thread on the private
+TinkerPop mailing list is started to get the official stance.  As per usual, the VOTE will be made open for no less
+than 72 hours.
+
+If the VOTE closes with a successful positive vote to make the candidate a committer, then send the following email
+to the candidate and copy the private TinkerPop mailing list:
+
+[source,text]
+----
+SUBJECT: Invitation to become TinkerPop committer: [candidate name]
+
+Hello,
+
+The TinkerPop Podling Project Management Committee (PPMC)  hereby offers you committer privileges to the project.
+These privileges are offered on the understanding that you'll use them reasonably and with common sense. We like to
+work on trust rather than unnecessary constraints.
+
+Being a committer enables you to more easily make changes without needing to go through the patch submission process.
+
+Being a committer does not require you to participate any more than you already do. It does tend to make one even more
+committed.  You will probably find that you spend more time here.
+
+Of course, you can decline and instead remain as a contributor, participating as you do now.
+
+A. This personal invitation is a chance for you to accept or decline in private.  Either way, please let us know in
+reply to the private@tinkerpop.incubator.apache.org address only.
+
+B. If you are accepting, the next step is to register an iCLA with the Apache Software Foundation:
+    1. Details of the iCLA and the forms are found through this link: http://www.apache.org/licenses/#clas.
+
+    2. The form (text or PDF version) provides instructions for its completion and return to the Secretary of the ASF.
+
+    3. When you transmit the completed iCLA, request to notify the Apache TinkerPop and choose a unique Apache id.
+       Look to see if your preferred id is already taken at http://people.apache.org/committer-index.html   This will
+       allow the Secretary to notify the PMC when your iCLA has been recorded.
+
+When recording of your iCLA is noticed, you will receive a follow-up message with the next steps for establishing you
+as a committer.
+----
+
+Assuming the individual accepts, the next step is to get their account created.  As we are in incubation, we will
+need to contact a mentor for help with this step.
+
+Upon confirming with the new committer that their account is established, send an announcement email to the
+developer and user mailing lists:
+
+[source,text]
+----
+SUBJECT: New Committer: [committer name]
+
+The Podling Project Management Committee (PPMC) for Apache TinkerPop has asked [committer name] to become a committer
+and we are pleased to announce that he has accepted.
+
+[describe the nature of the committers work in the community]
+
+Being a committer enables easier contribution to the project since there is no need to work via the patch submission
+process. This should enable better productivity.
+----
+
+Finally, update the TinkerPop incubator project status page by:
+
+. Adding to the "News" section
+. Adding to the "Committers" section
+
+
+

http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/bc46d649/docs/src/dev/developer/contributing.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/dev/developer/contributing.asciidoc b/docs/src/dev/developer/contributing.asciidoc
new file mode 100644
index 0000000..38da30d
--- /dev/null
+++ b/docs/src/dev/developer/contributing.asciidoc
@@ -0,0 +1,362 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+////
+Contributing
+============
+
+Contributions via GitHub pull requests are gladly accepted from their original author. By submitting any copyrighted
+material via pull request, email, or other means you agree to license the material under the project's open source
+license and warrant that you have the legal authority to do so.
+
+Getting Started
+---------------
+
+New contributors can start development with TinkerPop by first link:https://help.github.com/articles/fork-a-repo/[forking
+then cloning] the Apache TinkerPop link:https://github.com/apache/incubator-tinkerpop[GitHub repository]. Generally
+speaking it is best to tie any work done to an issue in link:https://issues.apache.org/jira/browse/TINKERPOP3[JIRA].
+Either scan through JIRA for an existing open issue to work on or create a new one.
+
+NOTE: For those who are trying to find a place to start to contribute, consider looking at unresolved issues that
+have the "trivial" priority as these issues are specifically set aside as
+link:https://issues.apache.org/jira/issues/?jql=project%20%3D%20TINKERPOP3%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Trivial%20ORDER%20BY%20key%20DESC[low-hanging fruit]
+for newcomers.
+
+After making changes, submit a link:https://help.github.com/articles/using-pull-requests/[pull request] through
+GitHub, where the name of the pull request is prefixed with the JIRA issue number.  In this way, the pull request
+and its comments get tied back to the JIRA issue it references.
+
+Before issuing your pull request, please be sure of the following:
+
+. `mvn clean install` works successfully.
+. If the change requires modification to the documentation, which can be found in `docs/src`, please be sure to try to
+generate the docs.  If the changes are minimal and do not include code examples, it might be sufficient to test
+generate the docs to validate formatting by just doing `bin/process-docs.sh --dryRun`.  If there are code examples,
+please be sure to have Zookeeper and Hadoop running when doing a `bin/process-docs.sh`.  The documentation is
+generated to `/target/docs/htmlsingle`.
+. If necessary, run the integration tests.  For example, if the changes affect serialization or Gremlin Server/Driver
+operations then running the integration tests assures in addition to unit tests will definitely be necessary. After
+a successful `mvn clean install`, do `mvn verify -DskipIntegrationTests=false -pl gremlin-server`.
+
+Once a pull request is submitted it must go through <<rtc,review>> and will be merged once three TinkerPop committers
+offer positive vote and achieve Apache consensus.
+
+Building and Testing
+--------------------
+
+TinkerPop requires `Java 1.8.0_40+` for proper building and proper operations.
+
+* Build Project: `mvn clean install`
+** Specify specific tests in a TinkerPop Suite to run with the `GREMLIN_TESTS` environment variable, along with the
+Maven project list argument, e.g.:
++
+----
+export GREMLIN_TESTS='org.apache.tinkerpop.gremlin.process.traversal.step.map.PathTest$Traversals,org.apache.tinkerpop.gremlin.process.traversal.PathTest'
+mvn -Dmaven.javadoc.skip=true --projects tinkergraph-gremlin test
+----
+** Clean the `.groovy/grapes/org.apache.tinkerpop` directory on build: `mvn clean install -DcleanGrapes`
+** Turn off "heavy" logging in the "process" tests: `mvn clean install -DargLine="-DmuteTestLogs=true"`
+** The test suite for `neo4j-gremlin` is disabled by default - to turn it on: `mvn clean install -DincludeNeo4j`
+* Regenerate test data (only necessary given changes to IO classes): `mvn clean install -Dio` from `tinkergraph-gremlin` directory
+** If there are changes to the Gryo format, it may be necessary to generate the Grateful Dead dataset from GraphSON (see `IoDataGenerationTest.shouldWriteGratefulDead`)
+* Check license headers are present: `mvn apache-rat:check`
+* Build AsciiDocs (Hadoop and ZooKeeper must be running): `bin/process-docs.sh`
+** Build AsciiDocs (but don't evaluate code blocks): `bin/process-docs.sh --dryRun`
+** Process a single AsciiDoc file: +pass:[docs/preprocessor/preprocess-file.sh `pwd`/gremlin-console/target/apache-gremlin-console-*-standalone `pwd`/docs/src/xyz.asciidoc]+
+* Build JavaDocs: `mvn process-resources -Djavadoc`
+* Check for Apache License headers: `mvn apache-rat:check`
+* Check for newer dependencies: `mvn versions:display-dependency-updates` or `mvn versions:display-plugin-updates`
+* Deploy JavaDocs/AsciiDocs: `bin/publish-docs.sh svn-username`
+* Integration Tests: `mvn verify -DskipIntegrationTests=false`
+** Execute with the `-DincludeNeo4j` option to include transactional tests.
+** Execute with the `-DuseEpoll` option to try to use Netty native transport (works on Linux, but will fallback to Java NIO on other OS).
+* Performance Tests: `mvn verify -DskipPerformanceTests=false`
+
+IDE Setup with Intellij
+-----------------------
+
+This section refers specifically to setup within Intellij.  TinkerPop has a module called `gremlin-shaded` which
+contains shaded dependencies for some libraries that are widely used and tend to introduce conflicts.  To ensure
+that Intellij properly interprets this module after importing the Maven `pom.xml` perform the following steps:
+
+. Build `gremlin-shaded` from the command line with `mvn clean install`.
+. Right-click on the `gremlin-shaded` module in the project viewer of Intellij and select "Remove module".
+. In the "Maven Projects" Tool window and click the tool button for "Reimport All Maven projects" (go to
+`View | Tool Windows | Maven Projects` on the main menu if this panel is not activated).
+. At this point it should be possible to compile and run the tests within Intellij, but in the worst case, use
+`File | Invalidate Caches/Restart` to ensure that indices properly rebuild.
+
+Note that it maybe be necessary to re-execute these steps if the `gremlin-shaded` `pom.xml` is ever updated.
+
+Developers working on the `neo4j-gremlin` module should enabled the `include-neo4j` Maven profile in Intellij.
+This will ensure that tests will properly execute within the IDE.
+
+If Intellij complains about "duplicate sources" for the Groovy files when attempting to compile/run tests, then
+install the link:http://plugins.jetbrains.com/plugin/7442?pr=idea[GMavenPlus Intellij plugin].
+
+For Committers
+--------------
+
+The guidelines that follow apply to those with commit access to the main repository:
+
+Communication
+~~~~~~~~~~~~~
+
+TinkerPop has a link:http://groups.google.com/group/gremlin-users[user mailing list] and a
+link:http://mail-archives.apache.org/mod_mbox/incubator-tinkerpop-dev/[developer mailing list].  As a committer,
+it is a good idea to join both.
+
+It would also be helpful to join the public link:https://s.apache.org/tinkerpop[TinkerPop HipChat room] for developer
+discussion.  This helps contributors to communicate in a more real-time way.  Anyone can join as a guest, but for
+regular contributors it may be best to request that an Apache HipChat account be created.
+
+Release Notes
+~~~~~~~~~~~~~
+
+There is a two-pronged approach to maintaining the change log and preparing the release notes.
+
+1. For work that is documented in JIRA, run the release notes report to include all of
+the tickets targeted for a specific release.  This report can be included in the
+release announcement.
+
+2. The manual change log (`CHANGELOG.asciidoc`) can be used to highlight large
+changes, describe themes (e.g. "We focused on performance improvements") or to
+give voice to undocumented changes.
+
+Given the dependence on the JIRA report for generating additions to the `CHANGELOG.asciidoc`,
+which uses the title of the issue as the line presented in the release note report, titles should
+be edited prior to release to be useful in that context.  In other words, an issue title should
+be understandable as a change in the fewest words possible while still conveying the gist of the
+change.
+
+Changes that break the public APIs should be marked with a "breaking" label and should be
+distinguished from other changes in the release notes.
+
+Branches
+~~~~~~~~
+
+The "master" branch is used for the main line of development and release branches are constructed as needed
+for ongoing maintenance work. If new to the project or are returning to it after some time away, it may be good
+to send an email to the developer mailing list (or ask on HipChat) to find out what the current operating branches
+are.
+
+Other branches may be created for collaborating on features or for RFC's that other developers may want to inspect.
+It is suggested that the JIRA issue ID be used as the prefix, since that triggers certain automation, and it provides a
+way to account for the branch lifecycle, i.e. "Who's branch is this, and can I delete it?"
+
+For branches that are NOT associated with JIRA issues, developers should utilize their Apache ID as
+a branch name prefix.  This provides a unique namespace, and also a way to account for the branch lifecycle.
+
+Developers should remove their own branches when they are no longer needed.
+
+Tags
+~~~~
+
+Tags are used for milestones, release candidates, and approved releases.  Please refrain from creating arbitrary
+tags, as they produce permanent clutter.
+
+Issue Tracker Conventions
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+TinkerPop uses Apache JIRA as its link:https://issues.apache.org/jira/browse/TINKERPOP3[issue tracker].  JIRA is a
+very robust piece of software with many options and configurations.  To simplify usage and ensure consistency across
+issues, the following conventions should be adhered to:
+
+* An issue's "status" should generally be in one of two states: `open` or `closed` (`reopened` is equivalent to `open`
+for our purposes).
+** An `open` issue is newly created, under consideration or otherwise in progress.
+** A `closed` issue is completed for purposes of release (i.e. code, testing, and documentation complete).
+** Issues in a `resolved` state should immediately be evaluated for movement to `closed` - issue become `resolved`
+by those who don't have the permissions to `close`.
+* An issue's "type" should be one of two options: `bug` or `improvement`.
+** A `bug` has a very specific meaning, referring to an error that prevents usage of TinkerPop AND does not have a
+reasonable workaround.  Given that definition, a `bug` should generally have very high priority for a fix.
+** Everything else is an `improvement` in the sense that any other work is an enhancement to the current codebase.
+* The "component" should be representative of the primary area of code that it applies to and all issues should have
+this property set.
+* Issues are not assigned "labels" with two exceptions:
+** The "breaking" label which marks an issue as one that is representative of a change in the API that might
+affect users or vendors.  This label is important when organizing release notes.
+** The "deprecation" label which is assigned to an issue that is about removing a deprecated portion of the API.
+* The "affects/fix version(s)" fields should be appropriately set, where the "fix version" implies the version on
+which that particular issue will completed.
+* The "priority" field can be arbitrarily applied with one exception.  The "trivial" option should be reserved for
+tasks that are "easy" for a potential new contributor to jump into and do not have significant impact to urgently
+required improvements.
+
+Code Style
+~~~~~~~~~~
+
+Contributors should examine the current code base to determine what the code style patterns are and should match their
+style to what is already present. Of specific note however, TinkerPop does not use "import wildcards" - IDEs should
+be adjusted accordingly to not auto-wildcard the imports.
+
+Deprecation
+~~~~~~~~~~~
+
+When possible, committers should avoid direct "breaking" change (e.g. removing a method from a class) and favor
+deprecation.  Deprecation should come with sufficient documentation and notice especially when the change involves
+public APIs that might be utilized by users or implemented by vendors:
+
+* Mark the code with the `@Deprecated` annotation.
+* Use javadoc to further document the change with the following content:
+** `@deprecated As of release x.y.z, replaced by {@link SomeOtherClass#someNewMethod()}` - if the method is not
+replaced then the comment can simply read "not replaced".  Additional comments that provide more context are
+encouraged.
+** `@see <a href="https://issues.apache.org/jira/browse/TINKERPOP3-XXX">TINKERPOP3-XXX</a>` - supply a link to the
+JIRA issue for reference.
+* All deprecation should typically be tied to a JIRA issue with a "breaking" label - the issue itself does not need to
+specifically or solely be about "deprecation" but it should be documented very clearly in the comments what was
+deprecated and what the path forward should be.
+* Be sure that deprecated methods are still under test - consider using javadoc/comments in the tests themselves to
+call out this fact.
+* Create a new JIRA issue to track removal of the deprecation for future evaluation - this issue should have the
+"breaking" label as well as a "deprecation" label.
+* Update the "upgrade documentation" to reflect the API change and how the reader should resolve it.
+
+The JIRA issues that track removal of deprecated methods should be periodically evaluated to determine if it is
+prudent to schedule them into a release.
+
+Gremlin Language Test Cases
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When writing a test case for a Gremlin step, be sure to use the following conventions.
+
+* The name of the traversal generator should start with `get`, use `X` for brackets, `_` for space, and the Gremlin-Groovy sugar syntax.
+** `get_g_V_hasLabelXpersonX_groupXaX_byXageX_byXsumX_name()`
+* When creating a test for a step that has both a barrier and sideEffect form (e.g. `group()`, `groupCount()`, etc.), test both representations.
+** `get_g_V_groupCount_byXnameX()`
+** `get_g_V_groupCountXaX_byXnameX_capXaX()`
+* The name of the actual test case should be the name of the traversal generator minus the `get_` prefix.
+* The Gremlin-Groovy version of the test should use the sugar syntax in order to test sugar (as Gremlin-Java8 tests test standard syntax).
+** `g.V.age.sum`
+* Avoid using lambdas in the test case unless that is explicitly what is being tested as OLAP systems will typically not be able to execute those tests.
+* `AbstractGremlinProcessTest` has various static methods to make writing a test case easy.
+** `checkResults(Arrays.asList("marko","josh"), traversal)`
+** `checkMap(new HashMap<String,Long>() {{ put("marko",1l); }}, traversal.next())`
+
+[[rtc]]
+Review then Commit
+~~~~~~~~~~~~~~~~~~
+
+Code modifications must go through a link:http://www.apache.org/foundation/glossary.html#ReviewThenCommit[review-then-committ] (RTC)
+process before being merged into a release branch. All committers should follow the pattern below, where "you" refers to the
+committer wanting to put code into a release branch.
+
+* Make a JIRA ticket for the software problem you want to solve (i.e. a fix).
+* Fork the release branch that the fix will be put into.
+** The branch name should be the JIRA issue identifier (e.g. `TINKERPOP3-XXX`).
+* Develop your fix in your branch.
+* When your fix is complete and ready to merge, issue a link:https://git-scm.com/docs/git-request-pull[pull request].
+** Be certain that the test suite is passing.
+** If you updated documentation, be sure that the `process-docs.sh` is building the documentation correctly.
+* Before you can merge your branch into the release branch, you must have at least 3 +1 link:http://www.apache.org/foundation/glossary.html#ConsensusApproval[consensus votes].
+** Please see the Apache Software Foundations regulations regarding link:http://www.apache.org/foundation/voting.html#votes-on-code-modification[Voting on Code Modifications].
+* Votes are issued by TinkerPop committers as comments to the pull request.
+* Once 3 +1 votes are received, you are responsible for merging to the release branch and handling any merge conflicts.
+** If there is a higher version release branch that requires your fix (e.g. `3.y-1.z` fix going to a `3.y.z` release), be sure to merge to that release branch as well.
+* Be conscious of deleting your branch if it is no longer going to be used so stale branches don't pollute the repository.
+
+NOTE: These steps also generally apply to external pull requests from those who are not official Apache committers. In
+this case, the person responsible for the merge after voting is typically the first person available
+who is knowledgeable in the area that the pull request affects. Any additional coordination on merging can be handled
+via the pull request comment system.
+
+The following exceptions to the RTC (review-then-commit) model presented above are itemized below. It is up to the
+committer to self-regulate as the itemization below is not complete and only hints at the types of commits that do not
+require a review.
+
+* You are responsible for a release and need to manipulate files accordingly for the release.
+** `Gremlin.version()`, CHANGELOG dates, `pom.xml` version bumps, etc.
+* You are doing an minor change and it is obvious that an RTC is not required (would be a pointless burden to the community).
+** The fix is under the link:http://www.apache.org/foundation/glossary.html#CommitThenReview[commit-then-review] (CTR) policy and lazy consensus is sufficient, where a single -1 vote requires you to revert your changes.
+** Adding a test case, fixing spelling/grammar mistakes in the documentation, fixing LICENSE/NOTICE/etc. files, fixing a minor issue in an already merged branch.
+
+When the committer chooses CTR, it is considered good form to include something in the commit message that explains
+that CTR was invoked and the reason for doing so.  For example, "Invoking CTR as this change encompasses minor
+adjustments to text formatting."
+
+Pull Request Format
+^^^^^^^^^^^^^^^^^^^
+
+When you submit a pull request, be sure it uses the following style.
+
+* The title of the pull request is the JIRA ticket number + "colon" + the title of the JIRA ticket.
+* The first line of the pull request message should contain a link to the JIRA ticket.
+* Discuss what you did to solve the problem articulated in the JIRA ticket.
+* Discuss any "extra" work done that go beyond the assumed requirements of the JIRA ticket.
+* Be sure to explain what you did to prove that the issue is resolved.
+** Test cases written.
+** Integration tests run (if required for the work accomplished).
+** Documentation building (if required for the work accomplished).
+** Any manual testing (though this should be embodied in a test case).
+* Notes about what you will do when you merge to the respective release branch (e.g. update CHANGELOG).
+** These types of "on merge tweaks" are typically done to extremely dynamic files to combat and merge conflicts.
+* If you are a TinkerPop committer, you can VOTE on your own pull request, so please do so.
+
+[[dependencies]]
+Dependencies
+~~~~~~~~~~~~
+
+There are many dependencies on other open source libraries in TinkerPop modules. When adding dependencies or
+altering the version of a dependency, developers must consider the implications that may apply to the TinkerPop
+LICENSE and NOTICE files. There are two implications to consider:
+
+. Does the dependency fit an Apache _approved_ license?
+. Given the addition or modification to a dependency, does it mean any change for TinkerPop LICENSE and NOTICE files?
+
+Understanding these implications is important for insuring that  TinkerPop stays compliant with the Apache 2 license
+that it releases under.
+
+Regarding the first item, refer to the Apache Legal for a list of link:http://www.apache.org/legal/resolved.html[approved licenses]
+that are compatible with the Apache 2 license.
+
+The second item requires a bit more effort to follow. The Apache website offers a
+link:http://www.apache.org/dev/licensing-howto.html[how-to guide] on the approach to maintaining appropriate LICENSE
+and NOTICE files, but this guide is designed to offer some more specific guidance as it pertains to TinkerPop
+and its distribution.
+
+To get started, TinkerPop has both "source" and "binary" LICENSE/NOTICE files:
+
+* Source LICENSE/NOTICE relate to files packaged with the released source code distribution:
+link:https://github.com/apache/incubator-tinkerpop/blob/master/LICENSE[LICENSE] / link:https://github.com/apache/incubator-tinkerpop/blob/master/NOTICE[NOTICE]
+* Binary LICENSE/NOTICE relate to files packaged with the released binary distributions:
+** Gremlin Console link:https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-console/src/main/LICENSE[LICENSE]
+/ link:https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-console/src/main/NOTICE[NOTICE]
+** Gremlin Server link:https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-server/src/main/LICENSE[LICENSE]
+/ link:https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-server/src/main/NOTICE[NOTICE]
+
+As we don't usually include any dependencies in the source distribution (i.e. the source zip distribution), there is
+typically no need to edit source LICENSE/NOTICE when editing a TinkerPop `pom.xml`. These files only need to be edited
+if the distribution has a file added to it.  Such a situation may arise from several scenarios, but it would most
+likely come from the addition of a source file from another library. In that case, edit LICENSE to include this file
+following the pattern already present there. Refer to the
+link:http://www.apache.org/dev/licensing-howto.html#mod-notice[Modifications to Notice] section from the Apache
+"how-to" to determine if changes are necessary there.
+
+The binary LICENSE/NOTICE is perhaps most impacted by changes to the various `pom.xml` files. After altering the
+`pom.xml` file of any module, build both Gremlin Console and Gremlin Server and examine the contents of both binary
+distributions, either:
+
+* target/apache-gremlin-console-x.y.z-distribution.zip
+* target/apache-gremlin-server-x.y.z-distribution.zip
+
+There is a _near_ one-to-one mapping between the jar files in those distributions and their respective LICENSE files.
+It is described as "near" because the distributions include TinkerPop jars which don't need to be represented there
+and there are entries in LICENSE that refer to libraries that are present, but shaded in the gremlin-shaded module.
+Everything else should be listed and present under the appropriate license section.
+
+There is also a good chance that the TinkerPop binary NOTICE should be updated. Check if the newly added dependency
+contains a NOTICE of its own. If so, include that NOTICE in the TinkerPop NOTICE.

http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/bc46d649/docs/src/dev/developer/index.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/dev/developer/index.asciidoc b/docs/src/dev/developer/index.asciidoc
new file mode 100644
index 0000000..a9e3a94
--- /dev/null
+++ b/docs/src/dev/developer/index.asciidoc
@@ -0,0 +1,33 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+////
+image::apache-tinkerpop-logo.png[width=500]
+
+:toc-position: left
+
+Developer Documentation
+=======================
+
+This document contains information for TinkerPop developers, contributors, and community members. It focuses on
+technical information and other internal processes related to the project.
+
+include::contributing.asciidoc[]
+
+include::release.asciidoc[]
+
+include::administration.asciidoc[]
+
+include::meetings.asciidoc[]
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/bc46d649/docs/src/dev/developer/meetings.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/dev/developer/meetings.asciidoc b/docs/src/dev/developer/meetings.asciidoc
new file mode 100644
index 0000000..e381707
--- /dev/null
+++ b/docs/src/dev/developer/meetings.asciidoc
@@ -0,0 +1,64 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+////
+Meetings
+========
+
+October 29, 2015
+----------------
+
+The meeting was scheduled for 1:00pm EST, started on time and was held via Google Hangout hosted by Stephen Mallette.
+Meeting adjourned at 1:45pm EST.
+
+*Committers/PPMC Members*
+
+* Stephen Mallette
+* Marko Rodriguez
+* Daniel Kuppitz
+
+*Guests*
+
+_None_
+
+*Minutes*
+
+* Reviewed the scope of 3.1.0-incubating in JIRA in the context of the upcoming release date on November 16, 2015.
+* It was noted that with the new one week code freeze policy that the real cut-off date for work is November 9, 2015.
+* There was general consensus on the call that work should be accomplished in such a way that the code review process
+not drag into the code freeze time period.  In other words, pull requests to the release branch should be completed
+well ahead of the 9th.
+
+Upon review of the tickets in JIRA assigned to 3.1.0-incubating, the following were removed from the 3.1.0-incubating
+roadmap:
+
+[width="100%",cols="2,5,5",options="header"]
+|=========================================================
+|ID |Description |Removal Reasoning
+|TINKERPOP3-891 |Re-examine Sandboxing Abstractions |Low priority and time limitations.
+|TINKERPOP3-890 |Remove the concept of branch/ package. |Awaiting step library definition in 3.2.0-incubating.
+|TINKERPOP3-873 |FoldStep should default to using BulkSet for efficiency. |Awaiting step library definition in 3.2.0-incubating.
+|TINKERPOP3-864 |Operator.mean would be nice. |Awaiting step library definition in 3.2.0-incubating.
+|TINKERPOP3-862 |Add a TraversalSourceStrategy that provides "locked" values. |Low priority and time limitations.
+|TINKERPOP3-854 |Remove PropertyMapStep in favor of multi-instruction construction. |Non-trivial given time limitations.
+|TINKERPOP3-789 |Choose then Enforce Semantics for Graph.close() |Non-trivial given time limitations.
+|TINKERPOP3-768 |MatchStep in OLAP should be smart about current vertex. |Non-trivial given time limitations.
+|TINKERPOP3-705 |Make use of a MemoryRDD instead of Accumulators in SparkGraphComputer? |Non-trivial given time limitations.
+|TINKERPOP3-659 |GraphConfiguration Class |Non-trivial given time limitations.
+|TINKERPOP3-623 |More output for OLAP jobs |Not clearly defined given time limitations.
+|TINKERPOP3-620 |Commutative Step Marker interface |Awaiting step library definition in 3.2.0-incubating
+|TINKERPOP3-550 |Gremlin IO needs to support both OLTP and OLAP naturally. |Not clearly defined given time limitations.
+|TINKERPOP3-479 |Consider Providing "getOrCreate" Functionality |Not clearly defined given time limitations.
+|=========================================================
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/bc46d649/docs/src/dev/developer/release.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/dev/developer/release.asciidoc b/docs/src/dev/developer/release.asciidoc
new file mode 100644
index 0000000..a5ddcc8
--- /dev/null
+++ b/docs/src/dev/developer/release.asciidoc
@@ -0,0 +1,184 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+////
+Release Process
+===============
+
+This document describes the steps required to release a version of TinkerPop.  The release is handled by a "release
+manager" (a committer fulfills this role), who ensures that the steps in this document are executed. The process is
+multi-phased and can therefore take several weeks to complete given the time needed for Apache voting and community
+feedback.  Once a release point has been identified, the following phases represent the flow of "release":
+
+* Pre-flight check.
+* Optionally, produce a release candidate for community feedback.
+* Submit the official release for PMC vote.
+* Submit the official release for Incubator vote.
+* Release and promote.
+
+NOTE: It might be helpful to use this document as generated from the currently release as opposed to one generate
+from a previous version or from recent `SNAPSHOT`. When using one generated for release, all the "versions" in the
+commands end up being set to the version that is being released, making cut and paste of those commands less labor
+intensive and error prone.
+
+Pre-flight Check
+----------------
+
+The "pre-flight check" is a list of things performed by the release manager during the weeks leading up to a scheduled
+day to release.  These checks will help to ensure that that release day goes smoothly by identifying problems up early
+and communicating with other members of the community.
+
+. Fourteen days before release, issue an email to the dev mailing list to remind the community of the pending release.
+.. Note any important issues open in JIRA in that post.
+.. Request review and update of the "upgrade documentation" and CHANGELOG.
+. Seven days before release, announce the code freeze on the dev mailing list to remind the community that the branch
+under release is protected. Tweaks to documentation and other odds and ends related to release are still allowed
+during this period.
+. At some point during the week:
+.. Run the full integration test suite: `mvn clean install -DskipIntegrationTests=false -DincludeNeo4j`
+.. Deploy a final SNAPSHOT to the snapshot repository.
+.. Review LICENSE and NOTICE files to make sure that no <<dependencies,changes are needed>>.
+.. Review javadoc filters on the "Core API" docs to be sure nothing needs to change.
+.. Review JIRA tickets in the release and ensure that:
+... All tickets categorized by having a "Component" assigned.
+... All tickets are either of type "Bug" or "Enhancement".
+. When all documentation changes are in place, use `bin/publish-docs.sh` to deploy a final `SNAPSHOT` representation
+of the docs and thus validate that there are no issues with the documentation generation process. Request review
+of the published documentation on the dev mailing list.
+
+Release Candidate
+-----------------
+
+A release candidate is an unofficial release that is represented by a tagged version in the Git repository.  It is
+offered in cases where there is significant change in a particular version and the potential for upgrades and problems
+might be high.
+
+. `mvn clean install -DincludeNeo4j`
+.. `mvn verify -DskipIntegrationTests=false -DincludeNeo4j`
+.. `mvn verify -DskipPerformanceTests=false`
+. `bin/publish-docs.sh <username>` - note that under a release candidate the documentation is published as SNAPSHOT
+. `mvn versions:set -DnewVersion=x.y.z -DgenerateBackupPoms=false` to update the project files to reference a non-SNAPSHOT version
+. `git diff` and review the updated files (expect all `pom.xml` files and this README)
+. `git commit -a -m "TinkerPop x.y.z release"` and `git push`
+. `git tag -a -m "TinkerPop x.y.z release" x.y.z` and `git push --tags`
+. `mvn clean install -Dmaven.test.skip=true`
+. `mvn versions:set -DnewVersion=x.y.z-SNAPSHOT -DgenerateBackupPoms=false` to go back to SNAPSHOT
+. `git commit -a -m "Returned to x.y.z-SNAPSHOT"` and `git push`
+. Announce the release candidate to `dev` mailing list and await feedback
+. Repeat as required or proceed to the next phase
+
+PMC Vote
+--------
+
+A positive vote for a particular release from the TinkerPop PMC is required to move to the following phase.
+
+. By this point, the testing performed during the code freeze should have validated the release.  If however there
+are additional tests to perform that the release manager feels are relevant, they should be performed now. In other
+words, there is no need to rebuild the `SNAPSHOT` yet another time unless there are circumstances that would call its
+validity into question.
+. Update `CHANGELOG.asciidoc`:
+.. Update the release date
+.. Generate the JIRA release notes report for the current version and append them to the `CHANGELOG.asciidoc`.
+... Use an "advanced" search to filter out JIRA issues already released on other versions. For example: `fixVersion
+= 3.1.0-incubating AND fixVersion not in (3.0.2-incubating, 3.0.1-incubating`.
+... Consider use of an "Excel" export to organize, sort and prepare the JIRA tickets to be pasted to `CHANGELOG.asciidoc`
+... Be sure to include a link to other versions in the `CHANGELOG.asciidoc` that were previously released while the
+current release was under development as this new release will have those changes included within it. Please see
+3.1.0-incubating for an example.
+.. Organize "breaking" changes to be clearly marked (use JIRA and the "breaking" label to identify those)
+. Update "upgrade documentation":
+.. Update the release date.
+.. Update the link to CHANGELOG.asciidoc
+. `mvn versions:set -DnewVersion=x.y.z -DgenerateBackupPoms=false` to update project files to reference the non-SNAPSHOT version
+. `git diff` and review the updated files (expect all `pom.xml` files and this README)
+. `git commit -a -m "TinkerPop x.y.z release"` and `git push`
+. `mvn clean install -Dmaven.test.skip=true` - need to build first so that the right version of the console is used with `bin/publish-docs.sh`
+. `bin/process-docs.sh` and validate the generated documentation locally
+. `bin/publish-docs.sh <username>` - Note that this step requires no additional processing as the previous step.
+handled document generation and this step now merely needs to upload what was generated.
+. `mvn deploy -Papache-release -DcreateChecksum=true -Dmaven.test.skip=true` - deploy signed artifacts with checksums to link:https://repository.apache.org/[Apache Nexus]. Review (artifacts versions, file sizes, anything that might be out of place - request another committer to review as well) but do NOT close/release the staging repository at this time.
+. Review generated artifacts to be sure they have both javadocs and asciidocs present
+. Upload artifacts to `https://dist.apache.org/repos/dist/dev/incubator/tinkerpop` for `[VOTE]` review.
+.. `svn co --depth empty https://dist.apache.org/repos/dist/dev/incubator/tinkerpop/ dev` and `mkdir dev/x.y.z`
+.. `cp ~/.m2/repository/org/apache/tinkerpop/gremlin-console/x.y.z/gremlin-console-x.y.z-distribution.zip* dev/x.y.z`
+.. `cp ~/.m2/repository/org/apache/tinkerpop/gremlin-server/x.y.z/gremlin-server-x.y.z-distribution.zip* dev/x.y.z`
+.. `cp ~/.m2/repository/org/apache/tinkerpop/tinkerpop/x.y.z/tinkerpop-x.y.z-source-release.zip* dev/x.y.z`
+.. `cd dev/x.y.z`
+.. pass:[<code>ls * | xargs -n1 -I {} echo "mv apache-{} {}" | sed -e 's/distribution/bin/' -e 's/source-release/src/' -e s'/^\(.*\) \(.*\) \(.*\)$/\1 \3 \2/' | /bin/bash</code>]
+.. `cd ..; svn add x.y.z/; svn ci -m "TinkerPop x.y.z release"`
+. Execute `bin/validate-distribution.sh` and any other relevant testing.
+. `git tag -a -m "TinkerPop x.y.z release" x.y.z` and `git push --tags`
+. Perform JIRA administration tasks:
+.. "Release" the current version and set the "release date"
+.. If there is to be a follow on release in the current line of code, create that new version specifying the "start date"
+. Submit for `[VOTE]` at `dev@tinkerpop.incubator.apache.org` (see email template below)
+. *Wait for vote acceptance* (72 hours)
+
+Incubator Vote
+--------------
+
+A positive vote for a particular release from the Apache Incubator is required to move to the following phase.
+
+. Submit for `[VOTE]` at `general@incubator.apache.org` (see email template below)
+.. Include the vote tally: "Apache TinkerPop (http://tinkerpop.incubator.apache.org/) would like to release TinkerPop x.y.z. We had a dev@ VOTE which resulted in a tally of +1 (3), 0 (0), and -1 (0). We now present our artifacts for vote by Incubator."
+. *Wait for vote acceptance* (72 hours)
+
+Release & Promote
+-----------------
+
+. Close the staging repository at link:https://repository.apache.org/[Apache Nexus]) and then release.
+. `svn co --depth empty https://dist.apache.org/repos/dist/dev/incubator/tinkerpop dev; svn up dev/x.y.z`
+. `svn co --depth empty https://dist.apache.org/repos/dist/release/incubator/tinkerpop release; mkdir release/x.y.z`
+. `cd release; svn add x.y.z/; svn ci -m "TinkerPop x.y.z release"`
+. Update homepage with references to latest distribution and to other internal links elsewhere on the page.
+. Wait for Apache Central to sync the jars and src (link:http://repo1.maven.org/maven2/org/apache/tinkerpop/tinkerpop/[http://repo1.maven.org/maven2/org/apache/tinkerpop/tinkerpop/]).
+. Announce release on `dev@`/`gremlin-users@` mailing lists and tweet from `@apachetinkerpop`
+
+Example `[VOTE]` email:
+
+```
+[VOTE] TinkerPop x.y.z Release
+
+Hello,
+
+The release artifacts can be found at this location:
+	https://dist.apache.org/repos/dist/dev/incubator/tinkerpop/x.y.z/
+
+The source distribution is provided by:
+	apache-tinkerpop-x.y.z-src.zip
+
+Two binary distributions are provided for user convenience:
+	apache-gremlin-console-x.y.z-bin.zip
+	apache-gremlin-server-x.y.z-bin.zip
+
+The online docs can be found here:
+	http://tinkerpop.incubator.apache.org/docs/x.y.z/ (user docs)
+	http://tinkerpop.incubator.apache.org/docs/x.y.z/upgrade.html (upgrade docs)
+	http://tinkerpop.incubator.apache.org/javadocs/x.y.z/core/ (core javadoc)
+	http://tinkerpop.incubator.apache.org/javadocs/x.y.z/full/ (full javadoc)
+
+The tag in Apache Git can be found here:
+	https://git-wip-us.apache.org/repos/asf?p=incubator-tinkerpop.git;...
+
+The release notes are available here:
+	https://github.com/apache/incubator-tinkerpop/blob/master/CHANGELOG.asciidoc#...
+
+The [VOTE] will be open for the next 72 hours --- closing <DayOfTheWeek> (<Month> <Day> <Year>) at <Time> <TimeZone>.
+
+My vote is +1.
+
+Thank you very much,
+<TinkerPop Committer Name>
+```
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/bc46d649/docs/src/developer-administration.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/developer-administration.asciidoc b/docs/src/developer-administration.asciidoc
deleted file mode 100644
index fea3749..0000000
--- a/docs/src/developer-administration.asciidoc
+++ /dev/null
@@ -1,91 +0,0 @@
-////
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements.  See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License.  You may obtain a copy of the License at
-
-  http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
-////
-Administration
-==============
-
-New Committers
---------------
-
-When a candidate is identified by a PPMC member as someone who might be a good official committer to TinkerPop, the
-PPMC member should open a DISCUSS thread on the private TinkerPop mailing list.  The thread should provide some
-background and reasoning for why that member believes the candidate would be a good committer.  Given enough time for
-feedback on the candidate and presuming there is still positive interest in doing so, a VOTE thread on the private
-TinkerPop mailing list is started to get the official stance.  As per usual, the VOTE will be made open for no less
-than 72 hours.
-
-If the VOTE closes with a successful positive vote to make the candidate a committer, then send the following email
-to the candidate and copy the private TinkerPop mailing list:
-
-[source,text]
-----
-SUBJECT: Invitation to become TinkerPop committer: [candidate name]
-
-Hello,
-
-The TinkerPop Podling Project Management Committee (PPMC)  hereby offers you committer privileges to the project.
-These privileges are offered on the understanding that you'll use them reasonably and with common sense. We like to
-work on trust rather than unnecessary constraints.
-
-Being a committer enables you to more easily make changes without needing to go through the patch submission process.
-
-Being a committer does not require you to participate any more than you already do. It does tend to make one even more
-committed.  You will probably find that you spend more time here.
-
-Of course, you can decline and instead remain as a contributor, participating as you do now.
-
-A. This personal invitation is a chance for you to accept or decline in private.  Either way, please let us know in
-reply to the private@tinkerpop.incubator.apache.org address only.
-
-B. If you are accepting, the next step is to register an iCLA with the Apache Software Foundation:
-    1. Details of the iCLA and the forms are found through this link: http://www.apache.org/licenses/#clas.
-
-    2. The form (text or PDF version) provides instructions for its completion and return to the Secretary of the ASF.
-
-    3. When you transmit the completed iCLA, request to notify the Apache TinkerPop and choose a unique Apache id.
-       Look to see if your preferred id is already taken at http://people.apache.org/committer-index.html   This will
-       allow the Secretary to notify the PMC when your iCLA has been recorded.
-
-When recording of your iCLA is noticed, you will receive a follow-up message with the next steps for establishing you
-as a committer.
-----
-
-Assuming the individual accepts, the next step is to get their account created.  As we are in incubation, we will
-need to contact a mentor for help with this step.
-
-Upon confirming with the new committer that their account is established, send an announcement email to the
-developer and user mailing lists:
-
-[source,text]
-----
-SUBJECT: New Committer: [committer name]
-
-The Podling Project Management Committee (PPMC) for Apache TinkerPop has asked [committer name] to become a committer
-and we are pleased to announce that he has accepted.
-
-[describe the nature of the committers work in the community]
-
-Being a committer enables easier contribution to the project since there is no need to work via the patch submission
-process. This should enable better productivity.
-----
-
-Finally, update the TinkerPop incubator project status page by:
-
-. Adding to the "News" section
-. Adding to the "Committers" section
-
-
-

http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/bc46d649/docs/src/developer-contributing.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/developer-contributing.asciidoc b/docs/src/developer-contributing.asciidoc
deleted file mode 100644
index 38da30d..0000000
--- a/docs/src/developer-contributing.asciidoc
+++ /dev/null
@@ -1,362 +0,0 @@
-////
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements.  See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License.  You may obtain a copy of the License at
-
-  http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
-////
-Contributing
-============
-
-Contributions via GitHub pull requests are gladly accepted from their original author. By submitting any copyrighted
-material via pull request, email, or other means you agree to license the material under the project's open source
-license and warrant that you have the legal authority to do so.
-
-Getting Started
----------------
-
-New contributors can start development with TinkerPop by first link:https://help.github.com/articles/fork-a-repo/[forking
-then cloning] the Apache TinkerPop link:https://github.com/apache/incubator-tinkerpop[GitHub repository]. Generally
-speaking it is best to tie any work done to an issue in link:https://issues.apache.org/jira/browse/TINKERPOP3[JIRA].
-Either scan through JIRA for an existing open issue to work on or create a new one.
-
-NOTE: For those who are trying to find a place to start to contribute, consider looking at unresolved issues that
-have the "trivial" priority as these issues are specifically set aside as
-link:https://issues.apache.org/jira/issues/?jql=project%20%3D%20TINKERPOP3%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Trivial%20ORDER%20BY%20key%20DESC[low-hanging fruit]
-for newcomers.
-
-After making changes, submit a link:https://help.github.com/articles/using-pull-requests/[pull request] through
-GitHub, where the name of the pull request is prefixed with the JIRA issue number.  In this way, the pull request
-and its comments get tied back to the JIRA issue it references.
-
-Before issuing your pull request, please be sure of the following:
-
-. `mvn clean install` works successfully.
-. If the change requires modification to the documentation, which can be found in `docs/src`, please be sure to try to
-generate the docs.  If the changes are minimal and do not include code examples, it might be sufficient to test
-generate the docs to validate formatting by just doing `bin/process-docs.sh --dryRun`.  If there are code examples,
-please be sure to have Zookeeper and Hadoop running when doing a `bin/process-docs.sh`.  The documentation is
-generated to `/target/docs/htmlsingle`.
-. If necessary, run the integration tests.  For example, if the changes affect serialization or Gremlin Server/Driver
-operations then running the integration tests assures in addition to unit tests will definitely be necessary. After
-a successful `mvn clean install`, do `mvn verify -DskipIntegrationTests=false -pl gremlin-server`.
-
-Once a pull request is submitted it must go through <<rtc,review>> and will be merged once three TinkerPop committers
-offer positive vote and achieve Apache consensus.
-
-Building and Testing
---------------------
-
-TinkerPop requires `Java 1.8.0_40+` for proper building and proper operations.
-
-* Build Project: `mvn clean install`
-** Specify specific tests in a TinkerPop Suite to run with the `GREMLIN_TESTS` environment variable, along with the
-Maven project list argument, e.g.:
-+
-----
-export GREMLIN_TESTS='org.apache.tinkerpop.gremlin.process.traversal.step.map.PathTest$Traversals,org.apache.tinkerpop.gremlin.process.traversal.PathTest'
-mvn -Dmaven.javadoc.skip=true --projects tinkergraph-gremlin test
-----
-** Clean the `.groovy/grapes/org.apache.tinkerpop` directory on build: `mvn clean install -DcleanGrapes`
-** Turn off "heavy" logging in the "process" tests: `mvn clean install -DargLine="-DmuteTestLogs=true"`
-** The test suite for `neo4j-gremlin` is disabled by default - to turn it on: `mvn clean install -DincludeNeo4j`
-* Regenerate test data (only necessary given changes to IO classes): `mvn clean install -Dio` from `tinkergraph-gremlin` directory
-** If there are changes to the Gryo format, it may be necessary to generate the Grateful Dead dataset from GraphSON (see `IoDataGenerationTest.shouldWriteGratefulDead`)
-* Check license headers are present: `mvn apache-rat:check`
-* Build AsciiDocs (Hadoop and ZooKeeper must be running): `bin/process-docs.sh`
-** Build AsciiDocs (but don't evaluate code blocks): `bin/process-docs.sh --dryRun`
-** Process a single AsciiDoc file: +pass:[docs/preprocessor/preprocess-file.sh `pwd`/gremlin-console/target/apache-gremlin-console-*-standalone `pwd`/docs/src/xyz.asciidoc]+
-* Build JavaDocs: `mvn process-resources -Djavadoc`
-* Check for Apache License headers: `mvn apache-rat:check`
-* Check for newer dependencies: `mvn versions:display-dependency-updates` or `mvn versions:display-plugin-updates`
-* Deploy JavaDocs/AsciiDocs: `bin/publish-docs.sh svn-username`
-* Integration Tests: `mvn verify -DskipIntegrationTests=false`
-** Execute with the `-DincludeNeo4j` option to include transactional tests.
-** Execute with the `-DuseEpoll` option to try to use Netty native transport (works on Linux, but will fallback to Java NIO on other OS).
-* Performance Tests: `mvn verify -DskipPerformanceTests=false`
-
-IDE Setup with Intellij
------------------------
-
-This section refers specifically to setup within Intellij.  TinkerPop has a module called `gremlin-shaded` which
-contains shaded dependencies for some libraries that are widely used and tend to introduce conflicts.  To ensure
-that Intellij properly interprets this module after importing the Maven `pom.xml` perform the following steps:
-
-. Build `gremlin-shaded` from the command line with `mvn clean install`.
-. Right-click on the `gremlin-shaded` module in the project viewer of Intellij and select "Remove module".
-. In the "Maven Projects" Tool window and click the tool button for "Reimport All Maven projects" (go to
-`View | Tool Windows | Maven Projects` on the main menu if this panel is not activated).
-. At this point it should be possible to compile and run the tests within Intellij, but in the worst case, use
-`File | Invalidate Caches/Restart` to ensure that indices properly rebuild.
-
-Note that it maybe be necessary to re-execute these steps if the `gremlin-shaded` `pom.xml` is ever updated.
-
-Developers working on the `neo4j-gremlin` module should enabled the `include-neo4j` Maven profile in Intellij.
-This will ensure that tests will properly execute within the IDE.
-
-If Intellij complains about "duplicate sources" for the Groovy files when attempting to compile/run tests, then
-install the link:http://plugins.jetbrains.com/plugin/7442?pr=idea[GMavenPlus Intellij plugin].
-
-For Committers
---------------
-
-The guidelines that follow apply to those with commit access to the main repository:
-
-Communication
-~~~~~~~~~~~~~
-
-TinkerPop has a link:http://groups.google.com/group/gremlin-users[user mailing list] and a
-link:http://mail-archives.apache.org/mod_mbox/incubator-tinkerpop-dev/[developer mailing list].  As a committer,
-it is a good idea to join both.
-
-It would also be helpful to join the public link:https://s.apache.org/tinkerpop[TinkerPop HipChat room] for developer
-discussion.  This helps contributors to communicate in a more real-time way.  Anyone can join as a guest, but for
-regular contributors it may be best to request that an Apache HipChat account be created.
-
-Release Notes
-~~~~~~~~~~~~~
-
-There is a two-pronged approach to maintaining the change log and preparing the release notes.
-
-1. For work that is documented in JIRA, run the release notes report to include all of
-the tickets targeted for a specific release.  This report can be included in the
-release announcement.
-
-2. The manual change log (`CHANGELOG.asciidoc`) can be used to highlight large
-changes, describe themes (e.g. "We focused on performance improvements") or to
-give voice to undocumented changes.
-
-Given the dependence on the JIRA report for generating additions to the `CHANGELOG.asciidoc`,
-which uses the title of the issue as the line presented in the release note report, titles should
-be edited prior to release to be useful in that context.  In other words, an issue title should
-be understandable as a change in the fewest words possible while still conveying the gist of the
-change.
-
-Changes that break the public APIs should be marked with a "breaking" label and should be
-distinguished from other changes in the release notes.
-
-Branches
-~~~~~~~~
-
-The "master" branch is used for the main line of development and release branches are constructed as needed
-for ongoing maintenance work. If new to the project or are returning to it after some time away, it may be good
-to send an email to the developer mailing list (or ask on HipChat) to find out what the current operating branches
-are.
-
-Other branches may be created for collaborating on features or for RFC's that other developers may want to inspect.
-It is suggested that the JIRA issue ID be used as the prefix, since that triggers certain automation, and it provides a
-way to account for the branch lifecycle, i.e. "Who's branch is this, and can I delete it?"
-
-For branches that are NOT associated with JIRA issues, developers should utilize their Apache ID as
-a branch name prefix.  This provides a unique namespace, and also a way to account for the branch lifecycle.
-
-Developers should remove their own branches when they are no longer needed.
-
-Tags
-~~~~
-
-Tags are used for milestones, release candidates, and approved releases.  Please refrain from creating arbitrary
-tags, as they produce permanent clutter.
-
-Issue Tracker Conventions
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-TinkerPop uses Apache JIRA as its link:https://issues.apache.org/jira/browse/TINKERPOP3[issue tracker].  JIRA is a
-very robust piece of software with many options and configurations.  To simplify usage and ensure consistency across
-issues, the following conventions should be adhered to:
-
-* An issue's "status" should generally be in one of two states: `open` or `closed` (`reopened` is equivalent to `open`
-for our purposes).
-** An `open` issue is newly created, under consideration or otherwise in progress.
-** A `closed` issue is completed for purposes of release (i.e. code, testing, and documentation complete).
-** Issues in a `resolved` state should immediately be evaluated for movement to `closed` - issue become `resolved`
-by those who don't have the permissions to `close`.
-* An issue's "type" should be one of two options: `bug` or `improvement`.
-** A `bug` has a very specific meaning, referring to an error that prevents usage of TinkerPop AND does not have a
-reasonable workaround.  Given that definition, a `bug` should generally have very high priority for a fix.
-** Everything else is an `improvement` in the sense that any other work is an enhancement to the current codebase.
-* The "component" should be representative of the primary area of code that it applies to and all issues should have
-this property set.
-* Issues are not assigned "labels" with two exceptions:
-** The "breaking" label which marks an issue as one that is representative of a change in the API that might
-affect users or vendors.  This label is important when organizing release notes.
-** The "deprecation" label which is assigned to an issue that is about removing a deprecated portion of the API.
-* The "affects/fix version(s)" fields should be appropriately set, where the "fix version" implies the version on
-which that particular issue will completed.
-* The "priority" field can be arbitrarily applied with one exception.  The "trivial" option should be reserved for
-tasks that are "easy" for a potential new contributor to jump into and do not have significant impact to urgently
-required improvements.
-
-Code Style
-~~~~~~~~~~
-
-Contributors should examine the current code base to determine what the code style patterns are and should match their
-style to what is already present. Of specific note however, TinkerPop does not use "import wildcards" - IDEs should
-be adjusted accordingly to not auto-wildcard the imports.
-
-Deprecation
-~~~~~~~~~~~
-
-When possible, committers should avoid direct "breaking" change (e.g. removing a method from a class) and favor
-deprecation.  Deprecation should come with sufficient documentation and notice especially when the change involves
-public APIs that might be utilized by users or implemented by vendors:
-
-* Mark the code with the `@Deprecated` annotation.
-* Use javadoc to further document the change with the following content:
-** `@deprecated As of release x.y.z, replaced by {@link SomeOtherClass#someNewMethod()}` - if the method is not
-replaced then the comment can simply read "not replaced".  Additional comments that provide more context are
-encouraged.
-** `@see <a href="https://issues.apache.org/jira/browse/TINKERPOP3-XXX">TINKERPOP3-XXX</a>` - supply a link to the
-JIRA issue for reference.
-* All deprecation should typically be tied to a JIRA issue with a "breaking" label - the issue itself does not need to
-specifically or solely be about "deprecation" but it should be documented very clearly in the comments what was
-deprecated and what the path forward should be.
-* Be sure that deprecated methods are still under test - consider using javadoc/comments in the tests themselves to
-call out this fact.
-* Create a new JIRA issue to track removal of the deprecation for future evaluation - this issue should have the
-"breaking" label as well as a "deprecation" label.
-* Update the "upgrade documentation" to reflect the API change and how the reader should resolve it.
-
-The JIRA issues that track removal of deprecated methods should be periodically evaluated to determine if it is
-prudent to schedule them into a release.
-
-Gremlin Language Test Cases
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-When writing a test case for a Gremlin step, be sure to use the following conventions.
-
-* The name of the traversal generator should start with `get`, use `X` for brackets, `_` for space, and the Gremlin-Groovy sugar syntax.
-** `get_g_V_hasLabelXpersonX_groupXaX_byXageX_byXsumX_name()`
-* When creating a test for a step that has both a barrier and sideEffect form (e.g. `group()`, `groupCount()`, etc.), test both representations.
-** `get_g_V_groupCount_byXnameX()`
-** `get_g_V_groupCountXaX_byXnameX_capXaX()`
-* The name of the actual test case should be the name of the traversal generator minus the `get_` prefix.
-* The Gremlin-Groovy version of the test should use the sugar syntax in order to test sugar (as Gremlin-Java8 tests test standard syntax).
-** `g.V.age.sum`
-* Avoid using lambdas in the test case unless that is explicitly what is being tested as OLAP systems will typically not be able to execute those tests.
-* `AbstractGremlinProcessTest` has various static methods to make writing a test case easy.
-** `checkResults(Arrays.asList("marko","josh"), traversal)`
-** `checkMap(new HashMap<String,Long>() {{ put("marko",1l); }}, traversal.next())`
-
-[[rtc]]
-Review then Commit
-~~~~~~~~~~~~~~~~~~
-
-Code modifications must go through a link:http://www.apache.org/foundation/glossary.html#ReviewThenCommit[review-then-committ] (RTC)
-process before being merged into a release branch. All committers should follow the pattern below, where "you" refers to the
-committer wanting to put code into a release branch.
-
-* Make a JIRA ticket for the software problem you want to solve (i.e. a fix).
-* Fork the release branch that the fix will be put into.
-** The branch name should be the JIRA issue identifier (e.g. `TINKERPOP3-XXX`).
-* Develop your fix in your branch.
-* When your fix is complete and ready to merge, issue a link:https://git-scm.com/docs/git-request-pull[pull request].
-** Be certain that the test suite is passing.
-** If you updated documentation, be sure that the `process-docs.sh` is building the documentation correctly.
-* Before you can merge your branch into the release branch, you must have at least 3 +1 link:http://www.apache.org/foundation/glossary.html#ConsensusApproval[consensus votes].
-** Please see the Apache Software Foundations regulations regarding link:http://www.apache.org/foundation/voting.html#votes-on-code-modification[Voting on Code Modifications].
-* Votes are issued by TinkerPop committers as comments to the pull request.
-* Once 3 +1 votes are received, you are responsible for merging to the release branch and handling any merge conflicts.
-** If there is a higher version release branch that requires your fix (e.g. `3.y-1.z` fix going to a `3.y.z` release), be sure to merge to that release branch as well.
-* Be conscious of deleting your branch if it is no longer going to be used so stale branches don't pollute the repository.
-
-NOTE: These steps also generally apply to external pull requests from those who are not official Apache committers. In
-this case, the person responsible for the merge after voting is typically the first person available
-who is knowledgeable in the area that the pull request affects. Any additional coordination on merging can be handled
-via the pull request comment system.
-
-The following exceptions to the RTC (review-then-commit) model presented above are itemized below. It is up to the
-committer to self-regulate as the itemization below is not complete and only hints at the types of commits that do not
-require a review.
-
-* You are responsible for a release and need to manipulate files accordingly for the release.
-** `Gremlin.version()`, CHANGELOG dates, `pom.xml` version bumps, etc.
-* You are doing an minor change and it is obvious that an RTC is not required (would be a pointless burden to the community).
-** The fix is under the link:http://www.apache.org/foundation/glossary.html#CommitThenReview[commit-then-review] (CTR) policy and lazy consensus is sufficient, where a single -1 vote requires you to revert your changes.
-** Adding a test case, fixing spelling/grammar mistakes in the documentation, fixing LICENSE/NOTICE/etc. files, fixing a minor issue in an already merged branch.
-
-When the committer chooses CTR, it is considered good form to include something in the commit message that explains
-that CTR was invoked and the reason for doing so.  For example, "Invoking CTR as this change encompasses minor
-adjustments to text formatting."
-
-Pull Request Format
-^^^^^^^^^^^^^^^^^^^
-
-When you submit a pull request, be sure it uses the following style.
-
-* The title of the pull request is the JIRA ticket number + "colon" + the title of the JIRA ticket.
-* The first line of the pull request message should contain a link to the JIRA ticket.
-* Discuss what you did to solve the problem articulated in the JIRA ticket.
-* Discuss any "extra" work done that go beyond the assumed requirements of the JIRA ticket.
-* Be sure to explain what you did to prove that the issue is resolved.
-** Test cases written.
-** Integration tests run (if required for the work accomplished).
-** Documentation building (if required for the work accomplished).
-** Any manual testing (though this should be embodied in a test case).
-* Notes about what you will do when you merge to the respective release branch (e.g. update CHANGELOG).
-** These types of "on merge tweaks" are typically done to extremely dynamic files to combat and merge conflicts.
-* If you are a TinkerPop committer, you can VOTE on your own pull request, so please do so.
-
-[[dependencies]]
-Dependencies
-~~~~~~~~~~~~
-
-There are many dependencies on other open source libraries in TinkerPop modules. When adding dependencies or
-altering the version of a dependency, developers must consider the implications that may apply to the TinkerPop
-LICENSE and NOTICE files. There are two implications to consider:
-
-. Does the dependency fit an Apache _approved_ license?
-. Given the addition or modification to a dependency, does it mean any change for TinkerPop LICENSE and NOTICE files?
-
-Understanding these implications is important for insuring that  TinkerPop stays compliant with the Apache 2 license
-that it releases under.
-
-Regarding the first item, refer to the Apache Legal for a list of link:http://www.apache.org/legal/resolved.html[approved licenses]
-that are compatible with the Apache 2 license.
-
-The second item requires a bit more effort to follow. The Apache website offers a
-link:http://www.apache.org/dev/licensing-howto.html[how-to guide] on the approach to maintaining appropriate LICENSE
-and NOTICE files, but this guide is designed to offer some more specific guidance as it pertains to TinkerPop
-and its distribution.
-
-To get started, TinkerPop has both "source" and "binary" LICENSE/NOTICE files:
-
-* Source LICENSE/NOTICE relate to files packaged with the released source code distribution:
-link:https://github.com/apache/incubator-tinkerpop/blob/master/LICENSE[LICENSE] / link:https://github.com/apache/incubator-tinkerpop/blob/master/NOTICE[NOTICE]
-* Binary LICENSE/NOTICE relate to files packaged with the released binary distributions:
-** Gremlin Console link:https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-console/src/main/LICENSE[LICENSE]
-/ link:https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-console/src/main/NOTICE[NOTICE]
-** Gremlin Server link:https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-server/src/main/LICENSE[LICENSE]
-/ link:https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-server/src/main/NOTICE[NOTICE]
-
-As we don't usually include any dependencies in the source distribution (i.e. the source zip distribution), there is
-typically no need to edit source LICENSE/NOTICE when editing a TinkerPop `pom.xml`. These files only need to be edited
-if the distribution has a file added to it.  Such a situation may arise from several scenarios, but it would most
-likely come from the addition of a source file from another library. In that case, edit LICENSE to include this file
-following the pattern already present there. Refer to the
-link:http://www.apache.org/dev/licensing-howto.html#mod-notice[Modifications to Notice] section from the Apache
-"how-to" to determine if changes are necessary there.
-
-The binary LICENSE/NOTICE is perhaps most impacted by changes to the various `pom.xml` files. After altering the
-`pom.xml` file of any module, build both Gremlin Console and Gremlin Server and examine the contents of both binary
-distributions, either:
-
-* target/apache-gremlin-console-x.y.z-distribution.zip
-* target/apache-gremlin-server-x.y.z-distribution.zip
-
-There is a _near_ one-to-one mapping between the jar files in those distributions and their respective LICENSE files.
-It is described as "near" because the distributions include TinkerPop jars which don't need to be represented there
-and there are entries in LICENSE that refer to libraries that are present, but shaded in the gremlin-shaded module.
-Everything else should be listed and present under the appropriate license section.
-
-There is also a good chance that the TinkerPop binary NOTICE should be updated. Check if the newly added dependency
-contains a NOTICE of its own. If so, include that NOTICE in the TinkerPop NOTICE.

http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/bc46d649/docs/src/developer-meetings.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/developer-meetings.asciidoc b/docs/src/developer-meetings.asciidoc
deleted file mode 100644
index e381707..0000000
--- a/docs/src/developer-meetings.asciidoc
+++ /dev/null
@@ -1,64 +0,0 @@
-////
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements.  See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License.  You may obtain a copy of the License at
-
-  http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
-////
-Meetings
-========
-
-October 29, 2015
-----------------
-
-The meeting was scheduled for 1:00pm EST, started on time and was held via Google Hangout hosted by Stephen Mallette.
-Meeting adjourned at 1:45pm EST.
-
-*Committers/PPMC Members*
-
-* Stephen Mallette
-* Marko Rodriguez
-* Daniel Kuppitz
-
-*Guests*
-
-_None_
-
-*Minutes*
-
-* Reviewed the scope of 3.1.0-incubating in JIRA in the context of the upcoming release date on November 16, 2015.
-* It was noted that with the new one week code freeze policy that the real cut-off date for work is November 9, 2015.
-* There was general consensus on the call that work should be accomplished in such a way that the code review process
-not drag into the code freeze time period.  In other words, pull requests to the release branch should be completed
-well ahead of the 9th.
-
-Upon review of the tickets in JIRA assigned to 3.1.0-incubating, the following were removed from the 3.1.0-incubating
-roadmap:
-
-[width="100%",cols="2,5,5",options="header"]
-|=========================================================
-|ID |Description |Removal Reasoning
-|TINKERPOP3-891 |Re-examine Sandboxing Abstractions |Low priority and time limitations.
-|TINKERPOP3-890 |Remove the concept of branch/ package. |Awaiting step library definition in 3.2.0-incubating.
-|TINKERPOP3-873 |FoldStep should default to using BulkSet for efficiency. |Awaiting step library definition in 3.2.0-incubating.
-|TINKERPOP3-864 |Operator.mean would be nice. |Awaiting step library definition in 3.2.0-incubating.
-|TINKERPOP3-862 |Add a TraversalSourceStrategy that provides "locked" values. |Low priority and time limitations.
-|TINKERPOP3-854 |Remove PropertyMapStep in favor of multi-instruction construction. |Non-trivial given time limitations.
-|TINKERPOP3-789 |Choose then Enforce Semantics for Graph.close() |Non-trivial given time limitations.
-|TINKERPOP3-768 |MatchStep in OLAP should be smart about current vertex. |Non-trivial given time limitations.
-|TINKERPOP3-705 |Make use of a MemoryRDD instead of Accumulators in SparkGraphComputer? |Non-trivial given time limitations.
-|TINKERPOP3-659 |GraphConfiguration Class |Non-trivial given time limitations.
-|TINKERPOP3-623 |More output for OLAP jobs |Not clearly defined given time limitations.
-|TINKERPOP3-620 |Commutative Step Marker interface |Awaiting step library definition in 3.2.0-incubating
-|TINKERPOP3-550 |Gremlin IO needs to support both OLTP and OLAP naturally. |Not clearly defined given time limitations.
-|TINKERPOP3-479 |Consider Providing "getOrCreate" Functionality |Not clearly defined given time limitations.
-|=========================================================
\ No newline at end of file