You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@beam.apache.org by da...@apache.org on 2016/11/05 17:12:48 UTC
[45/53] [partial] incubator-beam-site git commit: Move files
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/cc22c462/contribute/contribution-guide.md
----------------------------------------------------------------------
diff --git a/contribute/contribution-guide.md b/contribute/contribution-guide.md
deleted file mode 100644
index 4635e91..0000000
--- a/contribute/contribution-guide.md
+++ /dev/null
@@ -1,400 +0,0 @@
----
-layout: default
-title: "Beam Contribution Guide"
-permalink: /contribute/contribution-guide/
-redirect_from: /contribution-guide/
----
-
-# Apache Beam Contribution Guide
-
-* TOC
-{:toc}
-
-The Apache Beam community welcomes contributions from anyone with a passion for data processing! Beam has many different opportunities for contributions -- write new examples, add new user-facing libraries (new statistical libraries, new IO connectors, etc), work on the core programming model, build specific runners (Apache Flink, Apache Spark, Google Cloud Dataflow, etc), or participate on the documentation effort.
-
-We use a review-then-commit workflow in Beam for all contributions.
-
-![Alt text]({{ "/images/contribution-guide-1.png" | prepend: site.baseurl }} "Workflow image")
-
-**For larger contributions or those that affect multiple components:**
-
-1. **Engage**: We encourage you to work with the Beam community on the [Apache JIRA issue tracker](https://issues.apache.org/jira/browse/BEAM) and [developer\u2019s mailing list]({{ site.baseurl }}/use/mailing-lists/) to identify good areas for contribution.
-1. **Design:** More complicated contributions will likely benefit from some early discussion in order to scope and design them well.
-
-**For all contributions:**
-
-1. **Code:** The best part ;-)
-1. **Review:** Submit a pull request with your contribution to our [GitHub mirror](https://github.com/apache/incubator-beam/). Work with a committer to review and iterate on the code, if needed.
-1. **Commit:** A Beam committer merges the pull request into our [Apache repository](https://git-wip-us.apache.org/repos/asf/incubator-beam.git).
-
-We look forward to working with you!
-
-## Engage
-
-### Mailing list(s)
-We discuss design and implementation issues on dev@beam.incubator.apache.org mailing list, which is archived [here](https://lists.apache.org/list.html?dev@beam.apache.org). Join by emailing [`dev-subscribe@beam.incubator.apache.org`](mailto:dev-subscribe@beam.incubator.apache.org).
-
-If interested, you can also join the other [mailing lists]({{ site.baseurl }}/use/mailing-lists/) too.
-
-### Apache JIRA
-We use [Apache JIRA](https://issues.apache.org/jira/browse/BEAM) as an issue tracking and project management tool, as well as a way to communicate among a very diverse and distributed set of contributors. To be able to gather feedback, avoid frustration, and avoid duplicated efforts all Beam-related work should be tracked there.
-
-If you do not already have an Apache JIRA account, sign up [here](https://issues.apache.org/jira/).
-
-If a quick [search](https://issues.apache.org/jira/issues/?jql=project%3DBEAM%20AND%20text%20~%20%22the%20thing%20I%20want%20to%20contribute%22) doesn\u2019t turn up an existing JIRA issue for the work you want to contribute, create it. Please discuss your idea with a committer or the [component lead](https://issues.apache.org/jira/browse/BEAM/?selectedTab=com.atlassian.jira.jira-projects-plugin:components-panel) in JIRA or, alternatively, on the developer mailing list.
-
-If there\u2019s an existing JIRA issue for your intended contribution, please comment about your intended work. Once the work is understood, a committer will assign the issue to you. (If you don\u2019t have a JIRA role yet, you\u2019ll be added to the \u201ccontributor\u201d role.) If an issue is currently assigned, please check with the current assignee before reassigning.
-
-For moderate or large contributions, you should not start coding or writing a design document unless there is a corresponding JIRA issue assigned to you for that work. Simple changes, like fixing typos, do not require an associated issue.
-
-## Design
-
-To avoid potential frustration during the code review cycle, we encourage you to clearly scope and design non-trivial contributions with the Beam community before you start coding.
-
-Generally, the JIRA issue is the best place to gather relevant design docs, comments, or references. It\u2019s great to explicitly include relevant stakeholders early in the conversation. For designs that may be generally interesting, we also encourage conversations on the developer\u2019s mailing list.
-
-We suggest using [Google Docs](https://docs.google.com/) for sharing designs that may benefit from diagrams or comments. Please remember to make the document world-commentable and add a link to it from the relevant JIRA issue. You may want to start from this [template](https://docs.google.com/document/d/1qYQPGtabN5-E4MjHsecqqC7PXvJtXvZukPfLXQ8rHJs/edit?usp=sharing).
-
-## Code
-To contribute code to Apache Beam, you\u2019ll have to do a few administrative steps once, and then follow a few guidelines for each contribution.
-
-### One-time Setup
-
-#### [Potentially] Submit Contributor License Agreement
-Apache Software Foundation (ASF) desires that all contributors of ideas, code, or documentation to the Apache projects complete, sign, and submit an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.txt) (ICLA). The purpose of this agreement is to clearly define the terms under which intellectual property has been contributed to the ASF and thereby allow us to defend the project should there be a legal dispute regarding the software at some future time.
-
-We require you to have an ICLA on file with the Apache Secretary for larger contributions only. For smaller ones, however, we rely on [clause five](http://www.apache.org/licenses/LICENSE-2.0#contributions) of the Apache License, Version 2.0, describing licensing of intentionally submitted contributions and do not require an ICLA in that case.
-
-#### Obtain a GitHub account
-We use GitHub\u2019s pull request functionality to review proposed code changes.
-
-If you do not already have a personal GitHub account, sign up [here](https://github.com/join).
-
-#### Fork the repository on GitHub
-Go to the [Beam GitHub mirror](https://github.com/apache/incubator-beam/) and fork the repository to your own private account. This will be your private workspace for staging changes.
-
-We recommend enabling Travis-CI continuous integration coverage on your private fork in order to easily test your changes before proposing a pull request. Go to [Travis-CI](https://travis-ci.org), log in with your GitHub account, and enable coverage for your repository.
-
-#### Clone the repository locally
-You are now ready to create the development environment on your local machine. Feel free to repeat these steps on all machines that you want to use for development.
-
-We assume you are using SSH-based authentication with GitHub. If necessary, exchange SSH keys with GitHub by following [their instructions](https://help.github.com/articles/generating-an-ssh-key/).
-
-Clone Beam\u2019s read-only GitHub mirror.
-
- $ git clone https://github.com/apache/incubator-beam.git
- $ cd incubator-beam
-
-Add your forked repository as an additional Git remote, where you\u2019ll push your changes.
-
- $ git remote add <GitHub_user> git@github.com:<GitHub_user>/incubator-beam.git
-
-You are now ready to start developing!
-
-#### [Optional] IDE Setup
-
-Depending on your preferred development environment, you may need to prepare it to develop Beam code.
-
-##### IntelliJ
-
-_This documentation is incomplete. If you are an Intellij user, please contribute instructions!
-See [BEAM-835](https://issues.apache.org/jira/browse/BEAM-835)._
-
-###### Checkstyle
-IntelliJ supports checkstyle within the IDE using the Checkstyle-IDEA plugin.
-
-1. Install the "Checkstyle-IDEA" plugin from the IntelliJ plugin repository.
-1. Configure the plugin by going to Settings -> Other Settings -> Checkstyle.
-1. Set the "Scan Scope" to "Only Java sources (including tests)".
-1. In the "Configuration File" pane, add a new configuration using the plus icon:
- 1. Set the "Description" to "Beam".
- 1. Select "Use a local Checkstyle file", and point it to
- "sdks/java/build-tools/src/main/resources/beam/checkstyle.xml" within
- your repository.
- 1. Check the box for "Store relative to project location", and click
- "Next".
- 1. Configure the "checkstyle.suppressions.file" property value to
- "suppressions.xml", and click "Next", then "Finish".
-1. Select "Beam" as the only active configuration file, and click "Apply" and
- "OK".
-1. Checkstyle will now give warnings in the editor for any Checkstyle
- violations.
-
-You can also scan an entire module by opening the Checkstyle tools window and
-clicking the "Check Module" button. The scan should report no errors.
-
-Note: Selecting "Check Project" may report some errors from the archetype
-modules as they are not configured for Checkstyle validation.
-
-##### Eclipse
-
-Use a recent eclipse version that includes m2e. Currently we recommend Eclipse Neon.
-Start eclipse with a fresh workspace in a separate directory from your checkout.
-
-1. Install m2e-apt: Beam uses apt annotation processing to provide auto generated code. One example is the usage of [google auto value](https://github.com/google/auto/tree/master/value). By default m2e does not support this and you will see compile errors.
-
- Help
- -> Eclipse Marketplace
- -> Search for "m2 apt"
- -> Install m2e-apt 1.2 or higher
-
-1. Activate the apt processing
-
- Window
- -> Preferences
- -> Maven
- -> Annotation processing
- -> Switch to Experimental: Delegate annotation processing ...
- -> Ok
-
-1. Import the beam projects
-
- File
- -> Import...
- -> Existing Maven Projects
- -> Browse to the directory you cloned into and select incubator-beam
- -> make sure all beam projects are selected
- -> Finalize
-
-You now should have all the beam projects imported into eclipse and should see no compile errors.
-
-
-### Create a branch in your fork
-You\u2019ll work on your contribution in a branch in your own (forked) repository. Create a local branch, initialized with the state of the branch you expect your changes to be merged into. Keep in mind that we use several branches, including `master`, feature-specific, and release-specific branches. If you are unsure, initialize with the state of the `master` branch.
-
- $ git fetch --all
- $ git checkout -b <my-branch> origin/master
-
-At this point, you can start making and committing changes to this branch in a standard way.
-
-### Syncing and pushing your branch
-Periodically while you work, and certainly before submitting a pull request, you should update your branch with the most recent changes to the target branch.
-
- $ git pull --rebase
-
-Remember to always use `--rebase` parameter to avoid extraneous merge commits.
-
-To push your local, committed changes to your (forked) repository on GitHub, run:
-
- $ git push <GitHub_user> <my-branch>
-
-### Testing
-All code should have appropriate unit testing coverage. New code should have new tests in the same contribution. Bug fixes should include a regression test to prevent the issue from reoccurring.
-
-For contributions to the Java code, run unit tests locally via Maven. Alternatively, you can use Travis-CI.
-
- $ mvn clean verify
-
-## Review
-Once the initial code is complete and the tests pass, it\u2019s time to start the code review process. We review and discuss all code, no matter who authors it. It\u2019s a great way to build community, since you can learn from other developers, and they become familiar with your contribution. It also builds a strong project by encouraging a high quality bar and keeping code consistent throughout the project.
-
-### Create a pull request
-Organize your commits to make your reviewer\u2019s job easier. Use the following command to re-order, squash, edit, or change description of individual commits.
-
- $ git rebase -i origin/master
-
-Navigate to the [Beam GitHub mirror](https://github.com/apache/incubator-beam) to create a pull request. The title of the pull request should be strictly in the following format:
-
- [BEAM-<JIRA-issue-#>] <Title of the pull request>
-
-Please include a descriptive pull request message to help make the reviewer\u2019s job easier. It\u2019s fine to refer to existing design docs or the contents of the associated JIRA as appropriate.
-
-If you know a good committer to review your pull request, please make a comment like the following. If not, don\u2019t worry -- a committer will pick it up.
-
- Hi @<GitHub-reviewer-username>, can you please take a look?
-
-When choosing a reviewer, think about who is the expert on the relevant code, who the stakeholders are for this change, and who else would benefit from becoming familiar with the code. If you\u2019d appreciate comments from additional folks but already have a main reviewer, you can explicitly cc them using `@<GitHub-reviewer-username>`.
-
-### Code Review and Revision
-During the code review process, don\u2019t rebase your branch or otherwise modify published commits, since this can remove existing comment history and be confusing to the reviewer. When you make a revision, always push it in a new commit.
-
-Our GitHub mirror automatically provides pre-commit testing coverage using Jenkins and Travis-CI. Please make sure those tests pass; the contribution cannot be merged otherwise.
-
-### LGTM
-Once the reviewer is happy with the change, they\u2019ll respond with an LGTM (\u201c*looks good to me!*\u201d). At this point, the committer will take over, possibly make some additional touch ups, and merge your changes into the codebase.
-
-In the case both the author and the reviewer are committers, either can merge the pull request. Just be sure to communicate clearly whose responsibility it is in this particular case.
-
-Thank you for your contribution to Beam!
-
-### Deleting your branch
-Once the pull request is merged into the Beam repository, you can safely delete the branch locally and purge it from your forked repository.
-
-From another local branch, run:
-
- $ git fetch --all
- $ git branch -d <my-branch>
- $ git push <GitHub_user> --delete <my-branch>
-
-## Commit (committers only)
-Once the code has been peer reviewed by a committer, the next step is for the committer to merge it into the [authoritative Apache repository](https://git-wip-us.apache.org/repos/asf/incubator-beam.git), not the read-only GitHub mirror. (In the case that the author is also a committer, it is acceptable for either the author or reviewer to do the merge. Just be explicit about whose job it is!)
-
-Pull requests should not be merged before the review has received an explicit LGTM from another committer. Exceptions to this rule may be made rarely, on a case-by-case basis only, in the committer\u2019s discretion for situations such as build breakages.
-
-Committers should never commit anything without going through a pull request, since that would bypass test coverage and potentially cause the build to fail due to checkstyle, etc. In addition, pull requests ensure that changes are communicated properly and potential flaws or improvements can be spotted. **Always go through the pull request, even if you won\u2019t wait for the code review.** Even then, comments can be provided in the pull requests after it has been merged to work on follow-ups.
-
-Committing is currently a manual process, but we are investigating tools to automate pieces of this process.
-
-### One-time Setup
-Add the Apache Git remote in your local clone, by running:
-
- $ git remote add apache https://git-wip-us.apache.org/repos/asf/incubator-beam.git
-
-We recommend renaming the `origin` remote to `github`, to avoid confusion when dealing with this many remotes.
-
- $ git remote rename origin github
-
-For the `github` remote, add an additional fetch reference, which will cause every pull request to be made available as a remote branch in your workspace.
-
- $ git config --local --add remote.github.fetch \
- '+refs/pull/*/head:refs/remotes/github/pr/*'
-
-You can confirm your configuration by running the following command.
-
- $ git remote -v
- apache https://git-wip-us.apache.org/repos/asf/incubator-beam.git (fetch)
- apache https://git-wip-us.apache.org/repos/asf/incubator-beam.git (push)
- github https://github.com/apache/incubator-beam.git (fetch)
- github https://github.com/apache/incubator-beam.git (push)
- <username> git@github.com:<username>/beam.git (fetch)
- <username> git@github.com:<username>/beam.git (push)
-
-### Contributor License Agreement
-If you are merging a larger contribution, please make sure that the contributor has an ICLA on file with the Apache Secretary. You can view the list of committers [here](http://home.apache.org/phonebook.html?unix=committers), as well as [ICLA-signers who aren\u2019t yet committers](http://home.apache.org/unlistedclas.html).
-
-For smaller contributions, however, this is not required. In this case, we rely on [clause five](http://www.apache.org/licenses/LICENSE-2.0#contributions) of the Apache License, Version 2.0, describing licensing of intentionally submitted contributions.
-
-### Tests
-Before merging, please make sure both Travis-CI and Jenkins tests pass, as visible in the GitHub pull request. Do not merge the pull request otherwise.
-
-### Finishing touches
-At some point in the review process, you should take the pull request over and complete any outstanding work that is either minor, stylistic, or otherwise outside the expertise of the contributor.
-
-Fetch references from all remote repositories, and checkout the specific pull request branch.
-
- $ git fetch --all
- $ git checkout -b finish-pr-<pull-request-#> github/pr/<pull-request-#>
-
-At this point, you can commit any final touches to the pull request. For example, you should:
-
-* Rebase on current state of the target branch.
-* Fix typos.
-* Reorganize commits that are part of the pull request, such as squash them into fewer commits that make sense for a historical perspective.
-
-You will often need the following command, assuming you\u2019ll be merging changes into the `master` branch:
-
- $ git rebase -i apache/master
-
-Please make sure to retain authorship of original commits to give proper credit to the contributor. You are welcome to change their commits slightly (e.g., fix a typo) and squash them, but more substantive changes should be a separate commit and review.
-
-### Merge process
-Once you are ready to merge, fetch all remotes, checkout the destination branch and merge the changes.
-
- $ git fetch --all
- $ git checkout apache/master
- $ git merge --no-ff \
- -m $'[BEAM-<JIRA-issue-#&>;</b>] <Title>\n\nThis closes #<pull-request-#>' \
- finish-pr-<pull-request-#>
-
-Always use `--no-ff` option and the specific commit message "This closes #<pull request #>"" -- it ensures proper marking in the tooling. It would be nice to include additional information in the merge commit message, such as the title and summary of the pull request.
-
-At this point, you want to ensure everything is right. Test it with `mvn verify`. Run `gitk` or `git log --graph,` etc. When you are happy with how it looks, push it. This is the point of no return -- proceed with caution.
-
- $ git push apache HEAD:master
-
-Done. You can delete the local <code>finish-pr-<pull-request-#></code> branch if you like.
-
-## Special Cases
-
-The directions above assume you are submitting code to the `incubator-beam` repository's `master` branch. In addition, there are a few other locations where code is maintained. Generally these follow the same *engage*-*design*-**code**-**review**-**commit** process as above, with some minor adjustments to commands.
-
-### Feature Branches
-
-Some larger features are developed on a feature branch before being merged into `master`. In particular, this is often used for initial development of new components like SDKs or runners.
-
-#### Developing
-
-To contribute code on a feature branch, use the same process as above, but replace `master` with the [name of the branch]({{ site.baseurl }}/contribute/work-in-progress/#feature-branches).
-
-Since feature branches are often used for new components, you may find that
-there is no [committer]({{ site.baseurl }}/project/team/) familiar with all the details of the
-new language or runner. In that case, consider asking someone else familiar
-with the technology to do an initial review before looping in a committer for a
-final review and merge.
-
-If you are working on a feature branch, you'll also want to frequently merge in
-changes from `master` in order to prevent life on the branch from deviating too
-far from reality. Like all changes, this should be done via pull request. It
-is permitted for a committer to self-merge such a pull request if there are no
-conflicts or test failures. If there are any conflicts of tests that need
-fixing, then those should get a full review from another committer.
-
-#### Merging into Master
-
-In order for a feature branch to be merged into `master`, new components and major features should aim to meet the following guidelines.
-
-1. Have at least 2 contributors interested in maintaining it, and 1 committer interested in supporting it
-1. Provide both end-user and developer-facing documentation
-1. Have at least a basic level of unit test coverage
-1. Run all existing applicable integration tests with other Beam components and create additional tests as appropriate
-
-Additionally, ...
-
-A new runner should:
-
-1. Be able to handle a subset of the model that address a significant set of use cases (aka. \u2018traditional batch\u2019 or \u2018processing time streaming\u2019)
-1. Update the capability matrix with the current status
-1. Add a webpage under `learn/runners`
-
-A new SDK should:
-
-1. Provide the ability to construct graphs with all the basic building blocks of the model (ParDo, GroupByKey, Window, Trigger, etc)
-1. Begin fleshing out the common composite transforms (Count, Join, etc) and IO connectors (Text, Kafka, etc)
-1. Have at least one runner that can execute the complete model (may be a direct runner)
-1. Provide integration tests for executing against current and future runners
-1. Add a webpage under `learn/sdks`
-
-
-### Website
-
-The Beam website is in the [Beam Site GitHub mirror](https://github.com/apache/incubator-beam-site) repository in the `asf-site` branch (_not_ `master`).
-
-Issues are tracked in the [website](https://issues.apache.org/jira/browse/BEAM/component/12328906) component in JIRA.
-
-#### One-time Setup
-
-The [README file](https://github.com/apache/incubator-beam-site/blob/asf-site/README.md) in the website repository has more information on how to set up the required dependencies for your development environment.
-
-The general guidelines for cloning a repository can be adjusted to use the `asf-site` branch of `incubator-beam-site`:
-
- $ git clone -b asf-site https://github.com/apache/incubator-beam-site.git
- $ cd incubator-beam-site
- $ git remote add <GitHub_user> git@github.com:<GitHub_user>/incubator-beam-site.git
- $ git fetch --all
- $ git checkout -b <my-branch> origin/asf-site
-
-#### Working on your change
-
-While you are working on your pull request, you can test and develop live by running the following command in the root folder of the website:
-
- $ bundle exec jekyll serve
-
-Jekyll will start a webserver on port 4000. As you make changes to the content, Jekyll will rebuild it automatically.
-
-In addition, you can run the tests to valid your links using:
-
- $ bundle exec rake test
-
-Both of these commands will cause the `content/` directory to be generated. Merging autogenerated content can get tricky, so please leave this directory out of your commits and pull request by doing:
-
- $ git checkout -- content
-
-When you are ready, submit a pull request using the [Beam Site GitHub mirror](https://github.com/apache/incubator-beam-site), including the JIRA issue as usual.
-
-During review, committers will patch in your PR, generate the static `content/`, and review the changes.
-
-#### Committing website changes
-
-Follow the same committer process as above, but using `incubator-beam-site` and `asf-site`.
-
-In addition, the committer is responsible for doing the final `jekyll build` to generate the static content, so follow the instructions above to install jekyll.
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/cc22c462/contribute/design-principles.md
----------------------------------------------------------------------
diff --git a/contribute/design-principles.md b/contribute/design-principles.md
deleted file mode 100644
index 87ddd24..0000000
--- a/contribute/design-principles.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-layout: default
-title: 'Design Principles in Beam'
-permalink: /contribute/design-principles/
----
-
-# Design Principles in the Apache Beam Project
-
-Joshua Bloch\u2019s [API Design Bumper Stickers](https://www.infoq.com/articles/API-Design-Joshua-Bloch) are a great list of what makes for good API design. In addition, we have specific design principles we follow in Beam.
-
-* TOC
-{:toc}
-
-## Use cases
-
-### Unify the model
-Provide one model that works over both bounded (aka. batch) and unbounded (aka. streaming) datasets. Pay special attention to windows / triggers / state / timers, which often trip up folks used to a batch world. Provide users with the right abstractions to adjust latency and completeness guarantees to cover both traditional batch and streaming use cases.
-
-### Separate data shapes and runtime requirements
-The model should focus on letting users describe their data and processing, without exposing any details of a specific runtime system. For example, bounded and unbounded describe the shape of data, but batch and streaming describe the behavior of specific runtime systems. Good test cases are to imagine a mythical micro-batching runner that sits somewhere between batch and streaming or a engine that dynamically switches between streaming and batch depending on the backlog.
-
-### Make efficient things easy, rather than make easy things efficient
-Don\u2019t prevent efficiency for ease of use. Design APIs that provide the information necessary for efficiently executing at scale. Provide class hierarchies and wrappers to make the common cases simpler.
-
-## Usability
-
-### Validate Early
-Validate constraints on graph shape, runner requirements, etc as early in the compile time - construction time - submission time - execution time spectrum as reasonably possible in order to provide a smoother user experience.
-
-### Public APIs, like diamonds, are forever (at least until the next major version)
-Backwards incompatible changes can only be made in the next major version. Because of the burden major versions place on users (code has to be modified, conflicting dependency nightmares, etc), we aim to do this infrequently. Clearly mark APIs that are considered experimental (may change at any point) and deprecated (will be removed in the next major version). Consider what APIs are more amenable to future changes (abstract classes vs. interfaces, etc.)
-
-### Examples should be pedagogical
-Canonical examples help people ingrain the principles. Design examples that teach complex concepts in modular chunks. If you can\u2019t explain the concept easily, then the API isn\u2019t right. Examples should withstand random copy-pasting.
-
-## Extensibility
-
-### Use PTransforms for modularity
-Composite transformations (transformations formed by a subgraph of other transformations) are treated as first class objects. They can be named and applied directly in any pipeline to nicely encapsulate concepts. This removes the artificial separation between those built into PCollection and those provided by users. In addition, PTransforms can be used as a clear concept in graphical monitoring and provide a way to scope metadata like aggregators, logging, and resources. Use these when building pipelines.
-
-### Keep Beam SDKs consistent
-Beam SDKs should expose the complete set of concepts in the programming model. They should all use the same set of abstractions and be able to share conceptual documentation.
-
-### When in ~~Rome~~ Python, do as the ~~Romans~~ Pythonians do
-Each SDK must feel right to those who live and breath that language. Adapt the general Beam concepts into language-dependent styles when the benefits clearly outweigh the drawbacks.
-
-### Encourage DSLs
-Many use cases or user communities can be served by provided \u2018wrapper\u2019 SDKs that provide a simpler or domain-specific set of abstractions that then build on a Beam SDK and take advantage of Beam Runners.
-
-### Design for the model, not specific runners
-
-The Beam APIs should serve all runners. Behind every runner-specific hook, there is a general principle in the model. Design APIs that generalize across multiple runners.
-
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/cc22c462/contribute/index.md
----------------------------------------------------------------------
diff --git a/contribute/index.md b/contribute/index.md
deleted file mode 100644
index 9bfda4a..0000000
--- a/contribute/index.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-layout: default
-title: 'Contribute to Beam'
-redirect_from: '/docs/contribute'
----
-
-# Contribute to the Apache Beam Project
-
-Learn how you can contribute to Beam:
-
-#### [Contribution Guide]({{ site.baseurl }}/contribute/contribution-guide/)
-Learn how to contribute to the Beam project.
-
-#### [Technical Vision](https://goo.gl/nk5OM0)
-Learn about the technical vision for Beam, including the designs for SDKs and runners, and the development process.
-
-
-#### Resources
-Resources for contributing to Beam, including mailing lists, the main GitHub repo, and the issues tracker.
-
-* [Mailing Lists]({{ site.baseurl }}/use/mailing-lists/)
-* [Source Repository]({{ site.baseurl }}/contribute/source-repository)
-* [Issue Tracking]({{ site.baseurl }}/use/issue-tracking/)
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/cc22c462/contribute/logos.md
----------------------------------------------------------------------
diff --git a/contribute/logos.md b/contribute/logos.md
deleted file mode 100644
index 0aeccdd..0000000
--- a/contribute/logos.md
+++ /dev/null
@@ -1,65 +0,0 @@
----
-layout: default
-title: "Beam Logos"
-permalink: /contribute/logos/
-redirect_from:
- - /project/logos/
- - /material/
----
-
-# Apache Beam Logos
-
-This page contains project material for the Apache Beam project.
-
-## Project logos
-You can download [this archive]({{ site.baseurl }}/{{ site.downloads }}/{{ site.data.logos.archive-file }})
-containing all of the logos or download the logos individually.
-
-### Scalable Vector Graphics (SVG)
-These [SVG files](https://en.wikipedia.org/wiki/Scalable_Vector_Graphics) can
-be resized easily and are suitable for print or web use. Click on the logo to
-download it.
-
-{% for color in site.data.logos.colors %}
-#### {{ color[1] }}
-<div class="row">
-<div class="col-md-2">
-</div>
-{% for type in site.data.logos.types %}
-<div class="col-md-2">
-<div class="row">
-<a href="{{ site.baseurl }}{{ site.data.logos.logo-location }}/{{ color[0] }}/{{ type }}/beam-logo-{{ color[0] }}-{{ type }}.svg" role="button"><img style="height: 60px" src="{{ site.baseurl }}{{ site.data.logos.logo-location }}/{{ color[0] }}/{{ type }}/beam-logo-{{ color[0] }}-{{ type }}.svg" alt="beam-logo-{{ color[0] }}-{{ type }}.svg"></a>
-</div><br>
-</div>
-{% endfor %}
-</div>
-{% endfor %}
-
-
-### Portable Network Graphics (PNG)
-These [PNG files](https://en.wikipedia.org/wiki/Portable_Network_Graphics) are
-available in a number of fixed sizes and are optimized for web use.
-
-{% for color in site.data.logos.colors %}
-#### {{ color[1] }}
-<div class="row">
-<div class="col-md-2">
-</div>
-{% for type in site.data.logos.types %}
-<div class="col-md-2">
-<div class="row">
-<img style="height: 60px" src="{{ site.baseurl }}{{ site.data.logos.logo-location }}/{{ color[0] }}/{{ type }}/beam-logo-{{ color[0] }}-{{ type }}.svg" alt="beam-logo-{{ color[0] }}-{{ type }}">
-</div><br>
-<div class="row">
-{% for size in site.data.logos.sizes %}
-<a href="{{ site.baseurl }}{{ site.data.logos.logo-location }}/{{ color[0] }}/{{ type }}/beam-logo-{{ color[0] }}-{{ type }}-{{ size }}.png">{{ size }}x{{ size }}</a>
-{% unless forloop.last %},{% endunless %}
-{% endfor %}
-</div>
-</div>
-{% endfor %}
-</div>
-{% endfor %}
-
-## Colors and fonts
-The Apache Beam project uses predefined colors and fonts. [This document]({{ site.baseurl }}/{{ site.downloads }}/palette.pdf) has more information.
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/cc22c462/contribute/presentation-materials.md
----------------------------------------------------------------------
diff --git a/contribute/presentation-materials.md b/contribute/presentation-materials.md
deleted file mode 100644
index aa86391..0000000
--- a/contribute/presentation-materials.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-layout: default
-title: "Beam Presentation Materials"
-permalink: /contribute/presentation-materials/
-redirect_from: /learn/presentation-materials/
----
-
-# Apache Beam Presentation Materials
-
-Are you interested in learning more about Apache Beam or giving a talk about Apache Beam? Excellent! The Apache Beam community has created this collection of materials to help you get started. The community periodically reviews these materials to ensure they are accurate and up-to-date.
-
-<div class="panel panel-default">
- <div class="panel-body">
- <iframe src="https://drive.google.com/embeddedfolderview?id=0B-IhJZh9Ab52a3JLVXFWMDltcHM#list" width="700" height="300" frameborder="0"></iframe>
- </div>
-</div>
-
-## Using these materials
-These materials can be used by anyone. If you do use these materials, please remember to give credit to the authors cited in each presentation. These materials include speaker notes and you can view them by clicking **`View`** and selecting **`Show speaker notes`**. Some presentations have `[Long]` or `[Short]` in their name, such as the *Apache Beam Model*, which means there are two different presentations (a long and short version) depending on your needs and time constraints.
-
-If you have any questions about the these materials, please ask on the [`user@beam.incubator.apache.org`](mailto:user@beam.incubator.apache.org) mailing list.
-
-The Apache Beam community is looking for feedback on these materials to improve them over time. If you deliver a presentation based on these materials, we'd love to hear from you on the [`user@beam.incubator.apache.org`](mailto:user@beam.incubator.apache.org) mailing list. Please share your thoughts, questions you were asked, and (if available and appropriate) a link to the recording of your talk so the rest of the Apache Beam community can benefit from it.
-
-## Contributing new content
-The Apache Beam community is always looking for new core content and contributions!
-
-If you are interested in contributing new content, we recommend you first search the [Apache Beam JIRA](https://issues.apache.org/jira/browse/BEAM) to see if your idea currently has an open JIRA item. If it does not, send an email to the [`user@beam.incubator.apache.org`](mailto:user@beam.incubator.apache.org) mailing list or open a new issue in the [Apache Beam JIRA](https://issues.apache.org/jira/browse/BEAM) using the [website](https://issues.apache.org/jira/browse/BEAM/component/12328906/?selectedTab=com.atlassian.jira.jira-projects-plugin:component-summary-panel) component. Based on community submissions or contributions, the Beam community collaboratively reviews or creates new content and then adds it to this shared space for everyone to use.
-
-## Corrections and updates
-If you encounter missing, incorrect, or out of date material, please make a comment in the presentation or send an email to the [`user@beam.incubator.apache.org`](mailto:user@beam.incubator.apache.org) mailing list.
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/cc22c462/contribute/release-guide.md
----------------------------------------------------------------------
diff --git a/contribute/release-guide.md b/contribute/release-guide.md
deleted file mode 100644
index b0d4dca..0000000
--- a/contribute/release-guide.md
+++ /dev/null
@@ -1,500 +0,0 @@
----
-layout: default
-title: "Beam Release Guide"
-permalink: /contribute/release-guide/
----
-
-# Apache Beam Release Guide
-
-* TOC
-{:toc}
-
-## Introduction
-
-The Apache Beam project periodically declares and publishes releases. A release is one or more packages of the project artifact(s) that are approved for general public distribution and use. They may come with various degrees of caveat regarding their perceived quality and potential for change, such as \u201calpha\u201d, \u201cbeta\u201d, \u201cincubating\u201d, \u201cstable\u201d, etc.
-
-The Beam community treats releases with great importance. They are a public face of the project and most users interact with the project only through the releases. Releases are signed off by the entire Beam community in a public vote.
-
-Each release is executed by a *Release Manager*, who is selected among the [Beam committers]({{ site.baseurl }}/project/team). This document describes the process that the Release Manager follows to perform a release. Any changes to this process should be discussed and adopted on the [dev@ mailing list]({{ site.baseurl }}/use/mailing-lists).
-
-Please remember that publishing software has legal consequences. This guide complements the foundation-wide [Product Release Policy](http://www.apache.org/dev/release.html) and [Release Distribution Policy](http://www.apache.org/dev/release-distribution).
-
-## Overview
-
-![Alt text]({{ "/images/release-guide-1.png" | prepend: site.baseurl }} "Release Process"){:width="100%"}
-
-The release process consists of several steps:
-
-1. Decide to release
-1. Prepare for the release
-1. Build a release candidate
-1. Vote on the release candidate
-1. If necessary, fix any issues and go back to step 3.
-1. Finalize the release
-1. Promote the release
-
-**********
-
-## Decide to release
-
-Deciding to release and selecting a Release Manager is the first step of the release process. This is a consensus-based decision of the entire community.
-
-Anybody can propose a release on the dev@ mailing list, giving a solid argument and nominating a committer as the Release Manager (including themselves). There\u2019s no formal process, no vote requirements, and no timing requirements. Any objections should be resolved by consensus before starting the release.
-
-In general, the community prefers to have a rotating set of 3-5 Release Managers. Keeping a small core set of managers allows enough people to build expertise in this area and improve processes over time, without Release Managers needing to re-learn the processes for each release. That said, if you are a committer interested in serving the community in this way, please reach out to the community on the dev@ mailing list.
-
-### Checklist to proceed to the next step
-
-1. Community agrees to release
-1. Community selects a Release Manager
-
-**********
-
-## Prepare for the release
-
-Before your first release, you should perform one-time configuration steps. This will set up your security keys for signing the release and access to various release repositories.
-
-To prepare for each release, you should audit the project status in the JIRA issue tracker, and do necessary bookkeeping. Finally, you should create a release branch from which individual release candidates will be built.
-
-### One-time setup instructions
-
-#### GPG Key
-
-You need to have a GPG key to sign the release artifacts. Please be aware of the ASF-wide [release signing guidelines](https://www.apache.org/dev/release-signing.html). If you don\u2019t have a GPG key associated with your Apache account, please create one according to the guidelines.
-
-Determine your Apache GPG Key and Key ID, as follows:
-
- gpg --list-keys
-
-This will list your GPG keys. One of these should reflect your Apache account, for example:
-
- --------------------------------------------------
- pub 2048R/845E6689 2016-02-23
- uid Nomen Nescio <an...@apache.org>
- sub 2048R/BA4D50BE 2016-02-23
-
-Here, the key ID is the 8-digit hex string in the `pub` line: `845E6689`.
-
-Now, add your Apache GPG key to the Beam\u2019s `KEYS` file both in [`dev`](https://dist.apache.org/repos/dist/dev/incubator/beam/KEYS) and [`release`](https://dist.apache.org/repos/dist/release/incubator/beam/KEYS) repositories at `dist.apache.org`. Follow the instructions listed at the top of these files.
-
-Configure `git` to use this key when signing code by giving it your key ID, as follows:
-
- git config --global user.signingkey 845E6689
-
-You may drop the `--global` option if you\u2019d prefer to use this key for the current repository only.
-
-#### Access to Apache Nexus repository
-
-Configure access to the [Apache Nexus repository](http://repository.apache.org/), which enables final deployment of releases to the Maven Central Repository.
-
-1. You log in with your Apache account.
-1. Confirm you have appropriate access by finding `org.apache.beam` under `Staging Profiles`.
-1. Navigate to your `Profile` (top right dropdown menu of the page).
-1. Choose `User Token` from the dropdown, then click `Access User Token`. Copy a snippet of the Maven XML configuration block.
-1. Insert this snippet twice into your global Maven `settings.xml` file, typically `${HOME}/.m2/settings.xml`. The end result should look like this, where `TOKEN_NAME` and `TOKEN_PASSWORD` are your secret tokens:
-
- <settings>
- <servers>
- <server>
- <id>apache.releases.https</id>
- <username>TOKEN_NAME</username>
- <password>TOKEN_PASSWORD</password>
- </server>
- <server>
- <id>apache.snapshots.https</id>
- <username>TOKEN_NAME</username>
- <password>TOKEN_PASSWORD</password>
- </server>
- </servers>
- </settings>
-
-#### Website development setup
-
-Get ready for updating the Beam website by following the [website development instructions]({{ site.baseurl }}/contribute/contribution-guide/#website).
-
-### Create a new version in JIRA
-
-When contributors resolve an issue in JIRA, they are tagging it with a release that will contain their changes. With the release currently underway, new issues should be resolved against a subsequent future release. Therefore, you should create a release item for this subsequent release, as follows:
-
-1. In JIRA, navigate to the [`Beam > Administration > Versions`](https://issues.apache.org/jira/plugins/servlet/project-config/BEAM/versions).
-1. Add a new release: choose the next minor version number compared to the one currently underway, select today\u2019s date as the `Start Date`, and choose `Add`.
-
-### Triage release-blocking issues in JIRA
-
-There could be outstanding release-blocking issues, which should be triaged before proceeding to build a release candidate. We track them by assigning a specific `Fix version` field even before the issue resolved.
-
-The list of release-blocking issues is available at the [version status page](https://issues.apache.org/jira/browse/BEAM/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel). Triage each unresolved issue with one of the following resolutions:
-
-* If the issue has been resolved and JIRA was not updated, resolve it accordingly.
-* If the issue has not been resolved and it is acceptable to defer this until the next release, update the `Fix Version` field to the new version you just created. Please consider discussing this with stakeholders and the dev@ mailing list, as appropriate.
-* If the issue has not been resolved and it is not acceptable to release until it is fixed, the release cannot proceed. Instead, work with the Beam community to resolve the issue.
-
-### Review Release Notes in JIRA
-
-JIRA automatically generates Release Notes based on the `Fix Version` field applied to issues. Release Notes are intended for Beam users (not Beam committers/contributors). You should ensure that Release Notes are informative and useful.
-
-Open the release notes from the [version status page](https://issues.apache.org/jira/browse/BEAM/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel) by choosing the release underway and clicking Release Notes.
-
-You should verify that the issues listed automatically by JIRA are appropriate to appear in the Release Notes. Specifically, issues should:
-
-* Be appropriately classified as `Bug`, `New Feature`, `Improvement`, etc.
-* Represent noteworthy user-facing changes, such as new functionality, backward-incompatible API changes, or performance improvements.
-* Have occurred since the previous release; an issue that was introduced and fixed between releases should not appear in the Release Notes.
-* Have an issue title that makes sense when read on its own.
-
-Adjust any of the above properties to the improve clarity and presentation of the Release Notes.
-
-### Create a release branch
-
-Release candidates are built from a release branch. As a final step in preparation for the release, you should create the release branch, push it to the code repository, and update version information on the original branch.
-
-Check out the version of the codebase from which you start the release. For a new minor or major release, this may be `HEAD` of the `master` branch. To build a hotfix/incremental release, instead of the `master` branch, use the release tag of the release being patched. (Please make sure your cloned repository is up-to-date before starting.)
-
- git checkout <master branch OR release tag>
-
-
-Set up a few environment variables to simplify Maven commands that follow. (We use `bash` Unix syntax in this guide.)
-
- VERSION="1.2.3-incubating"
- NEXT_VERSION="1.2.4-incubating"
- BRANCH_NAME="release-${VERSION}"
- DEVELOPMENT_VERSION="${NEXT_VERSION}-SNAPSHOT"
-
-Version represents the release currently underway, while next version specifies the anticipated next version to be released from that branch. Normally, 1.2.0 is followed by 1.3.0, while 1.2.3 is followed by 1.2.4.
-
-Use Maven release plugin to create the release branch and update the current branch to use the new development version. This command applies for the new major or minor version. (Warning: this command automatically pushes changes to the code repository.)
-
- mvn release:branch \
- -DbranchName=${BRANCH_NAME} \
- -DdevelopmentVersion=${DEVELOPMENT_VERSION}
-
-However, if you are doing an incremental/hotfix release, please run the following command after checking out the release tag of the release being patched.
-
- mvn release:branch \
- -DbranchName=${BRANCH_NAME} \
- -DupdateWorkingCopyVersions=false \
- -DupdateBranchVersions=true \
- -DreleaseVersion="${VERSION}-SNAPSHOT"
-
-Check out the release branch.
-
- git checkout ${BRANCH_NAME}
-
-The rest of this guide assumes that commands are run in the root of a repository on `${BRANCH_NAME}` with the above environment variables set.
-
-### Checklist to proceed to the next step
-
-1. Release Manager\u2019s GPG key is published to `dist.apache.org`
-1. Release Manager\u2019s GPG key is configured in `git` configuration
-1. Release Manager has `org.apache.beam` listed under `Staging Profiles` in Nexus
-1. Release Manager\u2019s Nexus User Token is configured in `settings.xml`
-1. JIRA release item for the subsequent release has been created
-1. There are no release blocking JIRA issues
-1. Release Notes in JIRA have been audited and adjusted
-1. Release branch has been created
-1. Originating branch has the version information updated to the new version
-
-**********
-
-## Build a release candidate
-
-The core of the release process is the build-vote-fix cycle. Each cycle produces one release candidate. The Release Manager repeats this cycle until the community approves one release candidate, which is then finalized.
-
-### Build and stage Java artifacts with Maven
-
-Set up a few environment variables to simplify Maven commands that follow. This identifies the release candidate being built. Start with `RC_NUM` equal to `1` and increment it for each candidate.
-
- RC_NUM="1"
- TAG="v${VERSION}-RC${RC_NUM}"
-
-Use Maven release plugin to build the release artifacts, as follows:
-
- mvn release:prepare \
- -Dresume=false \
- -DreleaseVersion=${VERSION} \
- -Dtag=${TAG} \
- -DupdateWorkingCopyVersions=false
-
-Use Maven release plugin to stage these artifacts on the Apache Nexus repository, as follows:
-
- mvn release:perform
-
-Review all staged artifacts. They should contain all relevant parts for each module, including `pom.xml`, jar, test jar, source, test source, javadoc, etc. Artifact names should follow [the existing format](https://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.apache.beam%22) in which artifact name mirrors directory structure, e.g., `beam-sdks-java-io-kafka`. Carefully review any new artifacts.
-
-Close the staging repository on Apache Nexus. When prompted for a description, enter \u201cApache Beam, version X, release candidate Y\u201d.
-
-### Stage source release on dist.apache.org
-
-Copy the source release to the dev repository of `dist.apache.org`.
-
-1. If you have not already, check out the Beam section of the `dev` repository on `dist.apache.org` via Subversion. In a fresh directory:
-
- svn co https://dist.apache.org/repos/dist/dev/incubator/beam
-
-1. Make a directory for the new release:
-
- mkdir beam/${VERSION}
-
-1. Copy and rename the Beam source distribution, hashes, and GPG signature:
-
- cp ${BEAM_ROOT}/target/beam-parent-${VERSION}-source-release.zip beam/${VERSION}/apache-beam-${VERSION}-source-release.zip
- cp ${BEAM_ROOT}/target/beam-parent-${VERSION}-source-release.zip.asc beam/${VERSION}/apache-beam-${VERSION}-source-release.zip.asc
- cp ${BEAM_ROOT}/target/beam-parent-${VERSION}-source-release.zip.md5 beam/${VERSION}/apache-beam-${VERSION}-source-release.zip.md5
- cp ${BEAM_ROOT}/target/beam-parent-${VERSION}-source-release.zip.sha1 beam/${VERSION}/apache-beam-${VERSION}-source-release.zip.sha1
-
-1. Add and commit all the files.
-
- svn add beam/${VERSION}
- svn commit
-
-1. Verify that files are [present](https://dist.apache.org/repos/dist/dev/incubator/beam).
-
-### Build the API reference
-
-Beam publishes API reference manual for each release on the website. For Java SDK, that\u2019s Javadoc.
-
-Check out release candidate, as follows:
-
- git checkout ${TAG}
-
-Use Maven Javadoc plugin to generate the new Java reference manual, as follows:
-
- mvn -DskipTests clean package javadoc:aggregate \
- -Ddoctitle="Apache Beam SDK for Java, version ${VERSION}" \
- -Dwindowtitle="Apache Beam SDK for Java, version ${VERSION}" \
- -Dmaven.javadoc.failOnError=false \
- -DexcludePackageNames="org.apache.beam.examples,org.apache.beam.runners.dataflow.internal,org.apache.beam.runners.flink.examples,org.apache.beam.runners.flink.translation,org.apache.beam.runners.spark.examples,org.apache.beam.runners.spark.translation"
-
-By default, the Javadoc will be generated in `target/site/apidocs/`. Let `${JAVADOC_ROOT}` be the absolute path to `apidocs`. ([Pull request #1015](https://github.com/apache/incubator-beam/pull/1015) will hopefully simplify this process.)
-
-Please carefully review the generated Javadoc. Check for completeness and presence of all relevant packages and `package-info.java`; consider adding less relevant packages to the `excludePackageNames` configuration. The index page is generated at `${JAVADOC_ROOT}/index.html`.
-
-### Propose a pull request for website updates
-
-The final step of building the candidate is to propose a website pull request.
-
-Add the new release to the [Apache Beam Releases]({{ site.baseurl }}/use/releases/) page, as follows:
-
-* Update the `<version>` tags in the sample `pom.xml` snippet to the new release.
-* Add the new version to the `Release Notes` section below, along with links to the source code download and the Release Notes in JIRA.
-
-Add the new Javadoc to [SDK API Reference page]({{ site.baseurl }}/learn/sdks/javadoc/) page, as follows:
-
-* Copy the generated Javadoc into the website repository: `cp -r ${JAVADOC_ROOT} learn/sdks/javadoc/${VERSION}`.
-* Update the Javadoc link on this page to point to the new version.
-
-Finally, propose a pull request with these changes. (Don\u2019t merge before finalizing the release.)
-
-### Checklist to proceed to the next step
-
-1. Maven artifacts deployed to the staging repository of [repository.apache.org](https://repository.apache.org/content/repositories/)
-1. Source distribution deployed to the dev repository of [dist.apache.org](https://dist.apache.org/repos/dist/dev/incubator/beam/)
-1. Website pull request proposed to list the [release]({{ site.baseurl }}/use/releases/) and publish the [API reference manual]({{ site.baseurl }}/learn/sdks/javadoc/)
-
-**********
-
-## Vote on the release candidate
-
-Once you have built and individually reviewed the release candidate, please share it for the community-wide review. Please review foundation-wide [voting guidelines](http://www.apache.org/foundation/voting.html) for more information.
-
-Start the review-and-vote thread on the dev@ mailing list. Here\u2019s an email template; please adjust as you see fit.
-
- From: Release Manager
- To: dev@beam.incubator.apache.org
- Subject: [VOTE] Release 1.2.3, release candidate #3
-
- Hi everyone,
- Please review and vote on the release candidate #3 for the version 1.2.3, as follows:
- [ ] +1, Approve the release
- [ ] -1, Do not approve the release (please provide specific comments)
-
-
- The complete staging area is available for your review, which includes:
- * JIRA release notes [1],
- * the official Apache source release to be deployed to dist.apache.org [2],
- * all artifacts to be deployed to the Maven Central Repository [3],
- * source code tag "v1.2.3-RC3" [4],
- * website pull request listing the release and publishing the API reference manual [5].
-
- The vote will be open for at least 72 hours. It is adopted by majority approval, with at least 3 PPMC affirmative votes.
-
- Thanks,
- Release Manager
-
- [1] link
- [2] link
- [3] link
- [4] link
- [5] link
-
-If there are any issues found in the release candidate, reply on the vote thread to cancel the vote. There\u2019s no need to wait 72 hours. Proceed to the `Fix Issues` step below and address the problem. However, some issues don\u2019t require cancellation. For example, if an issue is found in the website pull request, just correct it on the spot and the vote can continue as-is.
-
-If there are no issues, reply on the vote thread to close the voting. Then, tally the votes in a separate email. Here\u2019s an email template; please adjust as you see fit.
-
- From: Release Manager
- To: dev@beam.incubator.apache.org
- Subject: [RESULT] [VOTE] Release 1.2.3, release candidate #3
-
- I'm happy to announce that we have unanimously approved this release.
-
- There are XXX approving votes, XXX of which are binding:
- * approver 1
- * approver 2
- * approver 3
- * approver 4
-
- There are no disapproving votes.
-
- Thanks everyone!
-
-While in incubation, the Apache Incubator PMC must also vote on each release, using the same process as above. Start the review and vote thread on the `general@incubator.apache.org` list.
-
- From: Release Manager
- To: general@incubator.apache.org
- Cc: dev@beam.incubator.apache.org
- Subject: [VOTE] Apache Beam release 1.2.3-incubating
-
- Hi everyone,
- Please review and vote on the release candidate #3 for the Apache Beam version 1.2.30-incubating, as follows:
- [ ] +1, Approve the release
- [ ] -1, Do not approve the release (please provide specific comments)
-
-
- The complete staging area is available for your review, which includes:
- * JIRA release notes [1],
- * the official Apache source release to be deployed to dist.apache.org [2],
- * all artifacts to be deployed to the Maven Central Repository [3],
- * source code tag "v1.2.3-RC3" [4],
- * website pull request listing the release and publishing the API reference manual [5].
-
- The Apache Beam community has unanimously approved this release [6].
-
- As customary, the vote will be open for at least 72 hours. It is adopted by
- a majority approval with at least three PMC affirmative votes. If approved,
- we will proceed with the release.
-
- Thanks!
-
- [1] link
- [2] link
- [3] link
- [4] link
- [5] link
- [6] lists.apache.org permalink to the vote result thread, e.g., https://lists.apache.org/thread.html/32c991987e0abf2a09cd8afad472cf02e482af02ac35418ee8731940@%3Cdev.beam.apache.org%3E
-
-If passed, close the voting and summarize the results.
-
- From: Release Manager
- To: general@incubator.apache.org
- Cc: dev@beam.incubator.apache.org
- Subject: [RESULT] [VOTE] Apache Beam release 1.2.3-incubating
-
- There are XXX approving votes, all of which are binding:
- * approver 1
- * approver 2
- * approver 3
- * approver 4
-
- There are no disapproving votes.
-
- We'll proceed with this release as staged.
-
- Thanks everyone!
-
-### Checklist to proceed to the finalization step
-
-1. Community votes to release the proposed candidate
-1. While in incubation, Apache Incubator PMC votes to release the proposed candidate
-
-**********
-
-## Fix any issues
-
-Any issues identified during the community review and vote should be fixed in this step.
-
-Code changes should be proposed as standard pull requests to the `master` branch and reviewed using the normal contributing process. Then, relevant changes should be cherry-picked into the release branch. The cherry-pick commits should then be proposed as the pull requests against the release branch, again reviewed and merged using the normal contributing process.
-
-Once all issues have been resolved, you should go back and build a new release candidate with these changes.
-
-### Checklist to proceed to the next step
-
-1. Issues identified during vote have been resolved, with fixes committed to the release branch.
-
-**********
-
-## Finalize the release
-
-Once the release candidate has been reviewed and approved by the community, the release should be finalized. This involves the final deployment of the release candidate to the release repositories, merging of the website changes, etc.
-
-### Deploy artifacts to Maven Central Repository
-
-Use the Apache Nexus repository to release the staged binary artifacts to the Maven Central repository. In the `Staging Repositories` section, find the relevant release candidate `orgapachebeam-XXX` entry and click `Release`. Drop all other release candidates that are not being released.
-
-#### Deploy source release to dist.apache.org
-
-Copy the source release from the `dev` repository to the `release` repository at `dist.apache.org` using Subversion.
-
-### Git tag
-
-Create a new Git tag for the released version by copying the tag for the final release candidate, as follows:
-
- git tag -s \u201cv${VERSION}\u201d ${TAG}
-
-### Merge website pull request
-
-Merge the website pull request to [list the release]({{ site.baseurl }}/use/releases/) and publish the [API reference manual]({{ site.baseurl }}/learn/sdks/javadoc/) created earlier.
-
-### Mark the version as released in JIRA
-
-In JIRA, inside [version management](https://issues.apache.org/jira/plugins/servlet/project-config/BEAM/versions), hover over the current release and a settings menu will appear. Click `Release`, and select today\u2019s date.
-
-### Checklist to proceed to the next step
-
-* Maven artifacts released and indexed in the [Maven Central Repository](https://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.apache.beam%22)
-* Source distribution available in the release repository of [dist.apache.org](https://dist.apache.org/repos/dist/release/incubator/beam/)
-* Website pull request to [list the release]({{ site.baseurl }}/use/releases/) and publish the [API reference manual]({{ site.baseurl }}/learn/sdks/javadoc/) merged
-* Release tagged in the source code repository
-* Release version finalized in JIRA
-
-**********
-
-## Promote the release
-
-Once the release has been finalized, the last step of the process is to promote the release within the project and beyond.
-
-### Apache mailing lists
-
-Announce on the dev@ mailing list that the release has been finished.
-
-Announce on the release on the user@ mailing list, listing major improvements and contributions.
-
-While in incubation, announce the release on the Incubator\u2019s general@ mailing list.
-
-### ASF press release
-
-After incubation, use reporter.apache.org to promote the release.
-
-### Beam blog
-
-Major or otherwise important releases should have a blog post. Write one if needed for this particular release. Minor releases that don\u2019t introduce new major functionality don\u2019t necessarily need to be blogged.
-
-### Social media
-
-Tweet, post on Facebook, LinkedIn, and other platforms. Ask other contributors to do the same.
-
-### Checklist to declare the process completed
-
-1. Release announced on the user@ mailing list.
-1. While in incubation, release announced on the Incubator\u2019s general@ mailing list.
-1. Blog post published, if applicable.
-1. After incubation, Apache Software Foundation press release published.
-1. Release announced on social media.
-1. Completion declared on the dev@ mailing list.
-
-**********
-
-## Improve the process
-
-It is important that we improve the release processes over time. Once you\u2019ve finished the release, please take a step back and look what areas of this process and be improved. Perhaps some part of the process can be simplified. Perhaps parts of this guide can be clarified.
-
-If we have specific ideas, please start a discussion on the dev@ mailing list and/or propose a pull request to update this guide. Thanks!
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/cc22c462/contribute/source-repository.md
----------------------------------------------------------------------
diff --git a/contribute/source-repository.md b/contribute/source-repository.md
deleted file mode 100644
index 2670a4e..0000000
--- a/contribute/source-repository.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-layout: default
-title: "Beam Source Repository"
-permalink: /contribute/source-repository/
-redirect_from: /source_repository/
----
-
-# Apache Beam Source Repository
-
-This project uses [Git](http://git-scm.com) to manage its source code.
-
-## Web Browser Access
-The following is a link to a browsable version of the source repository:
-
- https://git-wip-us.apache.org/repos/asf/incubator-beam.git
-
-## Anonymous Access
-The source can be checked out anonymously from Git with this command (See http://git-scm.com/docs/git-clone):
-
- $ git clone https://git-wip-us.apache.org/repos/asf/incubator-beam.git
-
-## Developer Access
-Only project developers can access the Git tree via this method (See http://git-scm.com/docs/git-clone).
-
- $ git clone https://git-wip-us.apache.org/repos/asf/incubator-beam.git
-
-## Access from Behind a Firewall
-Refer to the documentation of the SCM used for more information about access behind a firewall.
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/cc22c462/contribute/team.md
----------------------------------------------------------------------
diff --git a/contribute/team.md b/contribute/team.md
deleted file mode 100644
index 311a30a..0000000
--- a/contribute/team.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-layout: default
-title: "Beam Team"
-permalink: /contribute/team/
-redirect_from:
- - /project/team/
- - /team/
----
-
-# Apache Beam Team
-
-A successful project requires many people to play many roles. Some members write code or documentation, while others are valuable as testers, submitting patches and suggestions.
-
-The team is comprised of Members and Contributors. Members have direct access to the source of a project and actively evolve the code-base. Contributors improve the project through submission of patches and suggestions to the Members. The number of Contributors to the project is unbounded. Get involved today. All contributions to the project are greatly appreciated.
-
-{% for team in site.beam_team %}
- <h2>{{ team.group }}</h2>
- <p>{{ team.description }}</p>
- <table class="table table-hover">
- <thead>
- <tr>
- <th>Name</th>
- <th>Apache ID</th>
- <th>Email</th>
- <th>Organization</th>
- <th>Roles</th>
- <th>Time Zone</th>
- </tr>
- </thead>
- <tbody>
- {% for member in team.members %}
- <tr>
- <th scope="row">{{ member.name }}</th>
- <td scope="row">{{ member.apache_id }}</td>
- <td scope="row">{{ member.email }}</td>
- <td scope="row">{{ member.organization }}</td>
- <td scope="row">{{ member.roles }}</td>
- <td scope="row">{{ member.time_zone }}</td>
- </tr>
- {% endfor %}
- </tbody>
- </table>
-{% endfor %}
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/cc22c462/contribute/testing.md
----------------------------------------------------------------------
diff --git a/contribute/testing.md b/contribute/testing.md
deleted file mode 100644
index 3743df3..0000000
--- a/contribute/testing.md
+++ /dev/null
@@ -1,374 +0,0 @@
----
-layout: default
-title: 'Beam Testing Guide'
-permalink: /contribute/testing/
----
-
-# Beam Testing Documentation
-
-* TOC
-{:toc}
-
-## Overview
-
-Apache Beam (incubating) is a rapidly-maturing software project with a strong
-commitment to testing. Consequently, it has many testing-related needs. It
-requires precommit tests to ensure code going into the repository meets a
-certain quality bar and it requires ongoing postcommit tests to make sure that
-more subtle changes which escape precommit are nonetheless caught. This document
-outlines how to write tests, which tests are appropriate where, and when tests
-are run, with some additional information about the testing systems at the
-bottom.
-
-If you\u2019re writing tests, take a look at the testing matrix first, find what you
-want to test, then look into the \u201cScenarios\u201d and \u201cTypes\u201d sections below for more
-details on those testing types.
-
-## Testing Matrix
-
-### Java SDK
-
-<table>
- <tr>
- <td><strong>Component to Test</strong>
- </td>
- <td><strong>Test Scenario</strong>
- </td>
- <td><strong>Tool to Use</strong>
- </td>
- <td><strong>Link to Example</strong>
- </td>
- <td><strong>Type</strong>
- </td>
- <td><strong>Runs In</strong>
- </td>
- </tr>
- <tr>
- <td>DoFn
- </td>
- <td>Correctness on one/few bundles
- </td>
- <td>DoFnTester
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/master/sdks/java/io/google-cloud-platform/src/test/java/org/apache/beam/sdk/io/gcp/bigquery/BigQueryIOTest.java#L1325">BigQueryIOTest</a>
- </td>
- <td>Unit
- </td>
- <td>Precommit, Postcommit
- </td>
- </tr>
- <tr>
- <td>BoundedSource
- </td>
- <td>Correctly Reads Input
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/master/sdks/java/core/src/main/java/org/apache/beam/sdk/testing/SourceTestUtils.java#L128">SourceTestUtils.readFromSource</a>
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/84a0dd1714028370befa80dea16f720edce05252/sdks/java/core/src/test/java/org/apache/beam/sdk/io/TextIOTest.java#L972">TextIOTest</a>
- </td>
- <td>Unit
- </td>
- <td>Precommit, Postcommit
- </td>
- </tr>
- <tr>
- <td>
- </td>
- <td>Correct Initial Splitting
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/master/sdks/java/core/src/main/java/org/apache/beam/sdk/testing/SourceTestUtils.java#L201">SourceTestUtils.assertSourcesEqualReferenceSource</a>
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/8b1e64a668489297e11926124c4eee6c8f69a3a7/sdks/java/io/google-cloud-platform/src/test/java/org/apache/beam/sdk/io/gcp/bigtable/BigtableIOTest.java#L339">BigtableTest</a>
- </td>
- <td>Unit
- </td>
- <td>Precommit, Postcommit
- </td>
- </tr>
- <tr>
- <td>
- </td>
- <td>Correct Dynamic Splitting
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/master/sdks/java/core/src/main/java/org/apache/beam/sdk/testing/SourceTestUtils.java#L541">SourceTestUtils. assertSplitAtFractionExhaustive</a>
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/84a0dd1714028370befa80dea16f720edce05252/sdks/java/core/src/test/java/org/apache/beam/sdk/io/TextIOTest.java#L1021">TextIOTest</a>
- </td>
- <td>Unit
- </td>
- <td>Precommit, Postcommit
- </td>
- </tr>
- <tr>
- <td>Transform
- </td>
- <td>Correctness
- </td>
- <td>@NeedsRunner Test
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/master/sdks/java/core/src/test/java/org/apache/beam/sdk/transforms/ParDoTest.java#L1199">ParDoTest</a>
- </td>
- <td>@NeedsRunner
- </td>
- <td>
- </td>
- </tr>
- <tr>
- <td>Example Pipeline
- </td>
- <td>Verify Behavior on Each Runner
- </td>
- <td>E2E Test
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/master/examples/java/src/test/java/org/apache/beam/examples/WordCountIT.java#L76">WordCountIT</a>
- </td>
- <td>E2E
- </td>
- <td>Postcommit (Except WordCountIT)
- </td>
- </tr>
- <tr>
- <td>Source/Sink with external resource
- </td>
- <td>External Resource Faked
- </td>
- <td>Unit / @NeedsRunner Test
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/84a0dd1714028370befa80dea16f720edce05252/sdks/java/io/google-cloud-platform/src/test/java/org/apache/beam/sdk/io/gcp/bigtable/BigtableIOTest.java#L646">FakeBigtableService in BigtableTest</a>
- </td>
- <td>Unit / @NeedsRunner
- </td>
- <td>Precommit / Postcommit
- </td>
- </tr>
- <tr>
- <td>
- </td>
- <td>Real Interactions With External Resource
- </td>
- <td>E2E Test
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/84a0dd1714028370befa80dea16f720edce05252/sdks/java/io/google-cloud-platform/src/test/java/org/apache/beam/sdk/io/gcp/bigtable/BigtableReadIT.java#L40">BigtableReadIT</a>
- </td>
- <td>E2E
- </td>
- <td>Postcommit
- </td>
- </tr>
- <tr>
- <td>Runner
- </td>
- <td>Correctness
- </td>
- <td>E2E Test, <a href="https://github.com/apache/incubator-beam/blob/master/runners/pom.xml#L47">@RunnableonService</a>
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/master/examples/java/src/test/java/org/apache/beam/examples/WordCountIT.java#L78">WordCountIT</a>, <a href="https://github.com/apache/incubator-beam/blob/master/sdks/java/core/src/test/java/org/apache/beam/sdk/transforms/ParDoTest.java">ParDoTest</a>
- </td>
- <td>E2E, @RunnableonService
- </td>
- <td>Postcommit
- </td>
- </tr>
- <tr>
- <td>Coders
- </td>
- <td>Encoding/decoding elements
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/master/sdks/java/core/src/main/java/org/apache/beam/sdk/testing/CoderProperties.java">CoderProperties</a>
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/master/sdks/java/core/src/test/java/org/apache/beam/sdk/coders/NullableCoderTest.java">NullableCoderTest</a>
- </td>
- <td>Unit
- </td>
- <td>Precommit / Postcommit
- </td>
- </tr>
- <tr>
- <td>
- </td>
- <td>Serialization/deserialization of Coder
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/master/sdks/java/core/src/main/java/org/apache/beam/sdk/testing/CoderProperties.java">CoderProperties</a>
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/master/sdks/java/core/src/test/java/org/apache/beam/sdk/coders/NullableCoderTest.java">NullableCoderTest</a>
- </td>
- <td>Unit
- </td>
- <td>Precommit / Postcommit
- </td>
- </tr>
- <tr>
- <td>
- </td>
- <td>Sizing of elements
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/master/sdks/java/core/src/main/java/org/apache/beam/sdk/testing/CoderProperties.java">CoderProperties</a>
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/master/sdks/java/core/src/test/java/org/apache/beam/sdk/coders/NullableCoderTest.java">NullableCoderTest</a>
- </td>
- <td>Unit
- </td>
- <td>Precommit / Postcommit
- </td>
- </tr>
- <tr>
- <td>
- </td>
- <td>Deterministic
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/master/sdks/java/core/src/main/java/org/apache/beam/sdk/testing/CoderProperties.java">CoderProperties</a>
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/master/sdks/java/core/src/test/java/org/apache/beam/sdk/coders/NullableCoderTest.java">NullableCoderTest</a>
- </td>
- <td>Unit
- </td>
- <td>Precommit / Postcommit
- </td>
- </tr>
- <tr>
- <td>
- </td>
- <td>Structural value equality
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/master/sdks/java/core/src/main/java/org/apache/beam/sdk/testing/CoderProperties.java">CoderProperties</a>
- </td>
- <td><a href="https://github.com/apache/incubator-beam/blob/master/sdks/java/core/src/test/java/org/apache/beam/sdk/coders/NullableCoderTest.java">NullableCoderTest</a>
- </td>
- <td>Unit
- </td>
- <td>Precommit / Postcommit
- </td>
- </tr>
-</table>
-
-### Python SDK
-
-The Python SDK is currently under development on a feature branch. We have initial
-postcommit tests by a Jenkins build; precommit testing and a full testing
-matrix will be coming soon.
-
-## Testing Scenarios
-
-With the tools at our disposal, we have a good set of utilities which we can use
-to verify Beam correctness. To ensure an ongoing high quality of code, we use
-precommit and postcommit testing.
-
-### Precommit
-
-For precommit testing, Beam uses
-[Jenkins](https://builds.apache.org/view/Beam/),
-[Travis](http://travis-ci.org/apache/incubator-beam), and a code coverage tool
-called [Coveralls](https://coveralls.io/github/apache/incubator-beam), hooked up
-to [Github](https://github.com/apache/incubator-beam), to ensure that pull
-requests meet a certain quality bar. These precommits verify correctness via two
-of the below testing tools: unit tests (with coverage monitored by Coveralls)
-and E2E tests. We run the full slate of unit tests in precommit, ensuring
-correctness at a basic level, and then run the WordCount E2E test in both batch
-and streaming (coming soon!) against each supported SDK / runner combination as
-a smoke test, to verify that a basic level of functionality exists. We think
-that this hits the appropriate tradeoff between a desire for short (ideally
-\<30m) precommit times and a desire to verify that pull requests going into Beam
-function in the way in which they are intended.
-
-Precommit tests are kicked off when a user makes a Pull Request against the
-apache/incubator-beam repository and the Travis, Jenkins, and Coveralls statuses
-are displayed at the bottom of the pull request page. Clicking on \u201cDetails\u201d will
-open the status page in the selected tool; there, test status and output can be
-viewed.
-
-### Postcommit
-
-Running in postcommit removes as stringent of a time constraint, which gives us
-the ability to do some more comprehensive testing. In postcommit we have a test
-suite running the RunnableOnService tests against each supported runner, and
-another for running the full set of E2E tests against each runner.
-Currently-supported runners are Dataflow, Flink, Spark, and Gearpump, with
-others soon to follow. Work is ongoing to enable Flink, Spark, and Gearpump in
-the E2E framework, with full support targeted for end of August 2016. Postcommit
-tests run periodically, with timing defined in their Jenkins configurations.
-
-Adding new postcommit E2E tests is generally as easy as adding a \*IT.java file
-to the repository - Failsafe will notice it and run it - but if you want to do
-more interesting things, take a look at
-[WordCountIT.java](https://github.com/apache/incubator-beam/blob/master/examples/java/src/test/java/org/apache/beam/examples/WordCountIT.java).
-
-Postcommit test results can be found in
-[Jenkins](https://builds.apache.org/view/Beam/).
-
-## Testing Types
-
-### Unit
-
-Unit tests are, in Beam as everywhere else, the first line of defense in
-ensuring software correctness. As all of the contributors to Beam understand the
-importance of testing, Beam has a robust set of unit tests, as well as testing
-coverage measurement tools, which protect the codebase from simple to moderate
-breakages. Beam Java unit tests are written in JUnit.
-
-### RunnableOnService (Working Title)
-
-RunnableOnService tests contain components of both component and end-to-end
-tests. They fulfill the typical purpose of a component test - they are meant to
-test a well-scoped piece of Beam functionality or the interactions between two
-such pieces and can be run in a component-test-type fashion against the
-DirectRunner. Additionally, they are built with the ability to run in an
-end-to-end fashion against a runner, allowing them to verify not only core Beam
-functionality, but runner functionality as well. They are more lightweight than
-a traditional end-to-end test and, because of their well-scoped nature, provide
-good signal as to what exactly is working or broken against a particular runner.
-
-The name \u201cRunnableOnService\u201d is an artifact of when Beam was still the Google
-Cloud Dataflow SDK and [will be
-changing](https://issues.apache.org/jira/browse/BEAM-655) to something more
-indicative of its use in the coming months.
-
-### E2E
-
-End-to-End tests are meant to verify at the very highest level that the Beam
-codebase is working as intended. Because they are implemented as a thin wrapper
-around existing pipelines, they can be used to prove that the core Beam
-functionality is available. They will be used to verify runner correctness, but
-they can also be used for IO connectors and other core functionality.
-
-## Testing Systems
-
-### E2E Testing Framework
-
-The Beam end-to-end testing framework is a framework designed in a
-runner-agnostic fashion to exercise the entire lifecycle of a Beam pipeline. We
-run a pipeline as a user would and allow it to run to completion in the same
-way, verifying after completion that it behaved how we expected. Using pipelines
-from the Beam examples, or custom-built pipelines, the framework will provide
-hooks during several pipeline lifecycle events, e.g., pipeline creation,
-pipeline success, and pipeline failure, to allow verification of pipeline state.
-
-The E2E testing framework is currently built to hook into the [Maven Failsafe
-Integration Test
-plugin](http://maven.apache.org/surefire/maven-failsafe-plugin/), which means it
-is tightly integrated with the overall build process. Once it is determined how
-Python and other future languages will integrate into the overall build/test
-system (via Maven or otherwise) we will adjust this. The framework provides a
-wrapper around actual Beam pipelines, enabling those pipelines to be run in an
-environment which facilitates verification of pipeline results and details.
-
-Verifiers include:
-
-* Output verification. Output verifiers ensure that the pipeline has produced
- the expected output. Current verifiers check text-based output, but future
- verifiers could support other output such as BigQuery and Datastore.
-* Aggregator verification. Aggregator verifiers ensure that the user-defined
- aggregators present in the pipelines under test finish in the expected
- state.
-
-The E2E framework will support running on various different configurations of
-environments. We currently provide the ability to run against the DirectRunner,
-against a local Spark instance, a local Flink instance, and against the Google
-Cloud Dataflow service.
-
-### RunnableOnService Tests
-
-RunnableOnService tests are tests built to use the Beam TestPipeline class,
-which enables test authors to write simple functionality verification. They are
-meant to use some of the built-in utilities of the SDK, namely PAssert, to
-verify that the simple pipelines they run end in the correct state.
-
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/cc22c462/contribute/work-in-progress.md
----------------------------------------------------------------------
diff --git a/contribute/work-in-progress.md b/contribute/work-in-progress.md
deleted file mode 100644
index 2017d57..0000000
--- a/contribute/work-in-progress.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-layout: default
-title: 'In Progress Work in Beam'
-permalink: /contribute/work-in-progress/
----
-
-# Work In Progress in the Apache Beam Project
-
-As mentioned in the [Contribution Guide]({{ site.baseurl }}/contribute/contribution-guide/), all work in Beam is tracked in our [Apache JIRA](https://issues.apache.org/jira/browse/BEAM). In addition, the following types of work may be of particular interest to the Beam community.
-
-* TOC
-{:toc}
-
-
-## Starter Tasks
-
-The community regular tags good getting started tasks with the label `starter`. Use a quick [JIRA search](https://issues.apache.org/jira/issues?jql=project%20%3D%20BEAM%20AND%20status%20%3D%20Open%20AND%20labels%20%3D%20starter) to identify ways you can get started [contributing]({{ site.baseurl }}/contribute/contribution-guide/) to Beam.
-
-## Feature Branches
-
-Larger features with multiple active developers may be developed on a [feature branch]({{ site.baseurl }}/contribute/contribution-guide/#feature-branches) before being merged in the master branch. In particular, this is often used for initial development of new components like SDKs or runners.
-
-Current branches include:
-
-| Feature | Branch | JIRA Component | More Info |
-| ---- | ---- | ---- | ---- |
-| Apache Apex Runner | [apex-runner](https://github.com/apache/incubator-beam/tree/apex-runner) | [runner-apex](https://issues.apache.org/jira/browse/BEAM/component/12331007) | - |
-| Apache Gearpump Runner | [gearpump-runner](https://github.com/apache/incubator-beam/tree/gearpump-runner) | [runner-gearpump](https://issues.apache.org/jira/browse/BEAM/component/12330829) | [README](https://github.com/apache/incubator-beam/blob/gearpump-runner/runners/gearpump/README.md) |
-| Python SDK | [python-sdk](https://github.com/apache/incubator-beam/tree/python-sdk) | [sdk-py](https://issues.apache.org/jira/browse/BEAM/component/12328910) | [README](https://github.com/apache/incubator-beam/blob/python-sdk/sdks/python/README.md) |
-| Apache Spark 2.0 Runner | [runners-spark2](https://github.com/apache/incubator-beam/tree/runners-spark2) | - | [thread](https://lists.apache.org/thread.html/e38ac4e4914a6cb1b865b1f32a6ca06c2be28ea4aa0f6b18393de66f@%3Cdev.beam.apache.org%3E) |
-{:.table}
-
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/cc22c462/css/main.scss
----------------------------------------------------------------------
diff --git a/css/main.scss b/css/main.scss
deleted file mode 100644
index f2e566e..0000000
--- a/css/main.scss
+++ /dev/null
@@ -1,53 +0,0 @@
----
-# Only the main Sass file needs front matter (the dashes are enough)
----
-@charset "utf-8";
-
-
-
-// Our variables
-$base-font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
-$base-font-size: 16px;
-$base-font-weight: 400;
-$small-font-size: $base-font-size * 0.875;
-$base-line-height: 1.5;
-
-$spacing-unit: 30px;
-
-$text-color: #111;
-$background-color: #fdfdfd;
-$brand-color: #2a7ae2;
-
-$grey-color: #828282;
-$grey-color-light: lighten($grey-color, 40%);
-$grey-color-dark: darken($grey-color, 25%);
-
-// Width of the content area
-$content-width: 800px;
-
-$on-palm: 600px;
-$on-laptop: 800px;
-
-
-
-// Use media queries like this:
-// @include media-query($on-palm) {
-// .wrapper {
-// padding-right: $spacing-unit / 2;
-// padding-left: $spacing-unit / 2;
-// }
-// }
-@mixin media-query($device) {
- @media screen and (max-width: $device) {
- @content;
- }
-}
-
-
-
-// Import partials from `sass_dir` (defaults to `_sass`)
-@import
- "base",
- "layout",
- "syntax-highlighting"
-;
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/cc22c462/css/theme.css
----------------------------------------------------------------------
diff --git a/css/theme.css b/css/theme.css
deleted file mode 100644
index c0dd5a4..0000000
--- a/css/theme.css
+++ /dev/null
@@ -1,21 +0,0 @@
-body {
- padding-top: 70px;
- padding-bottom: 30px;
- font-family: 'Roboto', sans-serif;
-}
-
-.theme-dropdown .dropdown-menu {
- position: static;
- display: block;
- margin-bottom: 20px;
-}
-
-.theme-showcase > p > .btn {
- margin: 5px 0;
-}
-
-.theme-showcase .navbar .container {
- width: auto;
-}
-
-@import url(https://fonts.googleapis.com/css?family=Roboto:400,300);
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/cc22c462/documentation/index.md
----------------------------------------------------------------------
diff --git a/documentation/index.md b/documentation/index.md
deleted file mode 100644
index 6bd6be8..0000000
--- a/documentation/index.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-layout: default
-title: "Learn about Beam"
-permalink: /documentation/
-redirect_from:
- - /learn/
- - /docs/learn/
----
-
-# Learn about the Apache Beam Model
-
-Get in-depth conceptual information and reference material for the Beam Model, SDKs and Runners:
-
-#### [Beam Programming Guide]({{ site.baseurl }}/learn/programming-guide/)
-Learn about the Beam Programming Model and the concepts common to all Beam SDKs and Runners.
-
-#### Beam SDKs
-Find status and reference information on all of the available Beam SDKs.
-
-* [Java SDK]({{ site.baseurl }}/learn/sdks/java/)
-
-#### Runners
-Learn about the [Capability Matrix]({{ site.baseurl }}/learn/runners/capability-matrix/) and find status and reference information on all of the available Beam Runners:
-
-* [Direct Runner]({{ site.baseurl }}/learn/runners/direct/)
-* [Apache Flink]({{ site.baseurl }}/learn/runners/flink/)
-* [Apache Spark]({{ site.baseurl }}/learn/runners/spark/)
-* [Cloud Dataflow]({{ site.baseurl }}/learn/runners/dataflow/)
-
-#### [Additional Resources]({{ site.baseurl }}/learn/resources/)
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/cc22c462/documentation/pipelines/create-your-pipeline.md
----------------------------------------------------------------------
diff --git a/documentation/pipelines/create-your-pipeline.md b/documentation/pipelines/create-your-pipeline.md
deleted file mode 100644
index b99628f..0000000
--- a/documentation/pipelines/create-your-pipeline.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-layout: default
-title: "Create Your Pipeline"
-permalink: /documentation/pipelines/create-your-pipeline/
----
-# Create Your Pipeline
-
-> **Note:** There is an open JIRA issue to create this guide ([BEAM-901](https://issues.apache.org/jira/browse/BEAM-901)).
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/cc22c462/documentation/pipelines/design-your-pipeline.md
----------------------------------------------------------------------
diff --git a/documentation/pipelines/design-your-pipeline.md b/documentation/pipelines/design-your-pipeline.md
deleted file mode 100644
index 8a76704..0000000
--- a/documentation/pipelines/design-your-pipeline.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-layout: default
-title: "Design Your Pipeline"
-permalink: /documentation/pipelines/design-your-pipeline/
----
-# Design Your Pipeline
-
-> **Note:** There is an open JIRA issue to create this guide ([BEAM-901](https://issues.apache.org/jira/browse/BEAM-901)).
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/cc22c462/documentation/pipelines/test-your-pipeline.md
----------------------------------------------------------------------
diff --git a/documentation/pipelines/test-your-pipeline.md b/documentation/pipelines/test-your-pipeline.md
deleted file mode 100644
index 0a75bb5..0000000
--- a/documentation/pipelines/test-your-pipeline.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-layout: default
-title: "Test Your Pipeline"
-permalink: /documentation/pipelines/test-your-pipeline/
----
-# Test Your Pipeline
-
-> **Note:** There is an open JIRA issue to create this guide ([BEAM-901](https://issues.apache.org/jira/browse/BEAM-901)).