diff --git a/_sources/process/CONTRIBUTING.md.txt b/_sources/process/CONTRIBUTING.md.txt
new file mode 100644
index 0000000..c13fa4b
--- /dev/null
+++ b/_sources/process/CONTRIBUTING.md.txt
@@ -0,0 +1,116 @@
+Contributing to op-build
+========================
+
+op-build is the open source build system for OpenPOWER firmware. It assembles
+many individual components (only a few of which are OpenPOWER specific) into
+a single firmware image. op-build is implemented as a buildroot overlay.
+
+If you haven't already, join us on IRC (#openpower on Freenode) and on
+the mailing list ( openpower-firmware@lists.ozlabs.org - subscribe by
+going to https://lists.ozlabs.org/listinfo/openpower-firmware )
+
+We use GitHub Issues and Pull Requests for tracking contributions. We
+expect participants to adhere to the GitHub Community Guidelines (found
+at https://help.github.com/articles/github-community-guidelines/ ).
+
+If you are unable or unwilling to use GitHub, we can accept contributions
+via the mailing list.
+
+All contributions should have a Developer Certificate of Origin (see below).
+
+Development Philosophy
+----------------------
+
+Our development philosophy is:
+
+1. Don't re-invent the wheel
+2. Upstream first
+
+As such, we don't like to carry patches in op-build, we prefer to interact
+with upstream projects and get patches accepted there. Where we do need
+to patch things locally, we prefer to carry backports from upstream, which
+can be removed when we move to more recent upstream.
+
+Development Environment
+-----------------------
+
+For working on op-build you will need a reasonably recent Linux distribution.
+We aim to have all current major distros be suitable development platforms
+(focused on Ubuntu and Fedora, as that's what most developers currently use).
+
+A host GCC of at least 4.9 is recommended (all modern Linux distributions
+provide this).
+
+You can build on x86-64, ppc64 or ppc64le, op-build will build appropriate
+cross-compilers for you (thanks to the magic of buildroot).
+
+You will need 8-15GB of disk space to do a full build of any one configuration.
+
+Development Process
+-------------------
+
+The main source repository is on GitHub. We use GitHub issues and pull requests
+as well as a mailing list (https://lists.ozlabs.org/listinfo/openpower-firmware).
+
+We tag a new op-build release roughly every 6 weeks.
+
+We use GitHub milestones: https://github.com/open-power/op-build/milestones
+
+Starting with the v1.15 release, active development occurs against the master
+branch. When we're nearing a release, we move the content of the master branch
+over to a 'release' branch, ensuring development can continue while the release
+is prepared.
+
+We accept pull requests on GitHub: https://github.com/open-power/op-build/pulls
+
+Developer Certificate of Origin
+-------------------------------
+
+Contributions to this project should conform to the `Developer Certificate
+of Origin` as defined at http://elinux.org/Developer_Certificate_Of_Origin.
+Commits to this project need to contain the following line to indicate
+the submitter accepts the DCO:
+```
+Signed-off-by: Your Name <your_email@domain.com>
+```
+By contributing in this way, you agree to the terms as follows:
+```
+Developer Certificate of Origin
+Version 1.1
+
+Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
+660 York Street, Suite 102,
+San Francisco, CA 94110 USA
+
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
+
+
+Developer's Certificate of Origin 1.1
+
+By making a contribution to this project, I certify that:
+
+(a) The contribution was created in whole or in part by me and I
+    have the right to submit it under the open source license
+    indicated in the file; or
+
+(b) The contribution is based upon previous work that, to the best
+    of my knowledge, is covered under an appropriate open source
+    license and I have the right under that license to submit that
+    work with modifications, whether created in whole or in part
+    by me, under the same open source license (unless I am
+    permitted to submit under a different license), as indicated
+    in the file; or
+
+(c) The contribution was provided directly to me by some other
+    person who certified (a), (b) or (c) and I have not modified
+    it.
+
+(d) I understand and agree that this project and the contribution
+    are public and that a record of the contribution (including all
+    personal information I submit with it, including my sign-off) is
+    maintained indefinitely and may be redistributed consistent with
+    this project or the open source license(s) involved.
+```
+
+
diff --git a/_sources/process/KernelTree.rst.txt b/_sources/process/KernelTree.rst.txt
new file mode 100644
index 0000000..bdf383d
--- /dev/null
+++ b/_sources/process/KernelTree.rst.txt
@@ -0,0 +1,69 @@
+op-build Linux Kernel
+=====================
+
+The skiroot/Petitboot kernel is currently based on the 5.3 series.
+
+Submitting a patch
+------------------
+
+If you require a patch added to the firmware, follow these steps:
+
+1. Submit your patch upstream. It doesn’t need to be upstream, but it
+   should be on it’s way
+2. Send a pull request or a ``git format-patch`` formatted patch series
+   to openpower-firmware@lists.ozlabs.org, and cc joel@jms.id.au. Be
+   sure to use ``--suppress-cc=sob`` when generating the patches so we
+   don’t spam the community. The current tree is based on 5.1-stable
+   (although we will always move to the latest stable kernel ASAP).
+
+Bug fixes
+---------
+
+Whenever a stable release is tagged in
+https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/,
+we will rebase our patches on top of that and create a new release.
+
+If you are submitting patches upstream that you want to be included,
+then ensure you cc stable as per the
+`rules <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/stable_kernel_rules.txt>`__.
+
+Versioning
+----------
+
+Versions are the upstream version number, followed by ``-openpowerN``,
+where N is the revision that counts up from 1 for the given upstream
+version number. These versions will be present as tags in the git
+repository hosted at https://github.com/open-power/linux.
+
+We aim to follow "the latest upstream release".
+
+For op-build stable trees, we follow the latest stable release of the
+kernel that particular op-build release was made with. Since op-build
+stable releases may outlast how long an upstream kernel is maintain for,
+we will move up the kernel version we use until the next LTS kernel.
+Once on an LTS kernel, an op-build stable release will stick with that
+version.
+
+Tree and patches
+----------------
+
+The kernel tree hosted at https://github.com/open-power/linux contains
+the current release plus a set of patches that we carry. Ideally there
+would be no patches carried, as everything should be upstream.
+
+We take the commits in this tree between the upstream tag and the
+openpower tag and generate a series of patches that are imported into
+the op-build Buildroot overlay, and placed in
+`op-build/openpower/linux <https://github.com/open-power/op-build/tree/master/openpower/linux>`_.
+op-build then fetches the upstream tarball and applies these patches.
+This way we don’t have to clone an entire tree when doing an op-build
+build.
+
+All patches are to head upstream *first*. There is a zero chance that
+op-build will carry kernel patches for any time greater than "until the
+next kernel release", and even then, only in *exceptional* circumstances.
+
+Patches in the tree
+-------------------
+
+-  xhci: Reset controller on xhci shutdown
diff --git a/_sources/process/building-with-ci.rst.txt b/_sources/process/building-with-ci.rst.txt
new file mode 100644
index 0000000..471681d
--- /dev/null
+++ b/_sources/process/building-with-ci.rst.txt
@@ -0,0 +1,11 @@
+Building with ci scripts
+========================
+
+op-build has several build scripts in the ci/ directory aimed at being used to
+help continuous integration environments, as well as specifying build
+dependencies as code.
+
+These use Docker containers for the build environment.
+
+It is recommended you use (or send patches so that you can use them) these over
+rolling your own scripts.
diff --git a/_sources/process/index.rst.txt b/_sources/process/index.rst.txt
new file mode 100644
index 0000000..1d0af3e
--- /dev/null
+++ b/_sources/process/index.rst.txt
@@ -0,0 +1,9 @@
+Development Process
+===================
+
+.. toctree::
+
+   CONTRIBUTING.md
+   KernelTree.rst
+   building-with-ci
+   stable-rules.rst
diff --git a/_sources/process/stable-rules.rst.txt b/_sources/process/stable-rules.rst.txt
new file mode 100644
index 0000000..629e7f5
--- /dev/null
+++ b/_sources/process/stable-rules.rst.txt
@@ -0,0 +1,73 @@
+.. _stable-rules:
+
+=======================================
+op-build stable tree rules and releases
+=======================================
+
+Our stable tree process follows processes similar to other open source projects
+such as the Linux Kernel and Buildroot, as do several OpenPOWER Firmware
+components such as Skiboot and Petitboot.
+
+The purpose of a -stable tree is to give vendors a stable base to create
+firmware releases from and to incorporate into service packs. New stable
+releases contain critical fixes only.
+
+As a general rule, only the most recent op-build release gets a maintained
+-stable tree. If you wish to maintain an older tree, speak up! For example,
+with my IBMer hat on, we'll maintain branches that we ship in products.
+
+What patches are accepted?
+--------------------------
+
+* Patches must be obviously correct and tested
+
+  * A Tested-by signoff is *important*
+* A patch must fix a real bug
+* No trivial patches, such fixups belong in main branch
+* Not fix a purely theoretical problem unless you can prove how
+  it's exploitable
+* The patch, or an equivalent one, must already be in master
+
+  * Submitting to both at the same time is okay, but back-porting is better
+
+HOWTO submit to stable
+----------------------
+
+1. Make a pull request with "[stable op-build-N.N.y]" in subject (where N.N.y
+   is the stable branch to which you are targeting)
+
+   * This targets the patch *ONLY* to the stable branch.
+
+     * Such commits will *NOT* be merged into master.
+   * Use this when:
+
+     a. cherry-picking a fix from master
+     b. fixing something that is only broken in stable
+     c. fix in stable needs to be completely different than in master
+
+     If b or c: explain why.
+   * If cherry-picking, include the following at the top of your
+     commit message (or use the -x option to git-cherry-pick): ::
+
+       commit <sha1> upstream.
+   * If the patch has been modified, explain why in description.
+
+2. Add a comment on the PR indicating that a PR should also go to a stable
+   branch when making a Pull request to master
+
+   * This targets the patch to master and stable.
+   * You can target a patch to a specific stable tree by putting that in the
+     comment
+   * You can ask for prerequisites to be cherry-picked.
+
+Trees
+-----
+
+* https://github.com/open-power/op-build/ (or via ssh at ``git@github.com:open-power/op-build.git`` )
+
+  * (branches are op-build-X.Y.y - e.g. op-build-2.0.y)
+
+* Some stable versions may last longer than others
+
+  * So there may be op-build-2.0.y and op-build-2.4.y actively maintained
+    and op-build-2.0.y could possibly outlast op-build-2.4.y.