Merge pull request #27 from github-community-projects/update-docs

(docs): Initial outline of user doc

docs/using-the-app.md

@@ -0,0 +1,31 @@
+## How to get started working with Internal Contribution Forks
+
+1. Set up an organization to host your open source work. Many enterprises use a primary organization which mainly contains private repos or company-wide projects owned by the enterprise. Creating a separate organization which hosts your open-source efforts - both forks of upstream projects in use for this app, as well as open projects that expect a lot of external collaborators - makes for cleaner administrative/security boundaries.
+
+2. Install the app into that organization. Currently you'll need to self-host the application, following the [instructions in the project's README](../README.md). In this early phase of the project, if self-hosting is a blocker for your adoption of the app, please [file an issue](https://github.com/github-community-projects/internal-contribution-forks/issues/new) so we can understand your use case and work towards a solution.
+
+3. Fork an upstream project into the organization's namespace. This will create your **public fork**. A decision point for administrators is whether to permit any user to fork new projects into the organizations, or restrict the ability to fork. These permissions are managed by [the organization's forking policy](https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-organization-settings/managing-the-forking-policy-for-your-organization). A more permissive posture can lower the barrier to contribution, but shouldn't circumvent company policy on approving upstream work.
+
+4. Go the app's URL and authenticate to it. You'll see a list of your organizations that the app is managing. Click on your org's name and you'll see a list of all the public forks in the organization. _What about access control to app/forks inside?_
+
+![List of public forks inside the organization](images/public-forks-inside-org.png)
+
+5. Click on the name of the public fork you just created. Click **Create mirror** and give it an unambiguous name, then click **Confirm**. This will create a **private mirror** of the repo. The app syncs commits on the private mirror's default branch to a new branch on the public fork. The public fork's branch will be named after the private mirror, so the default branch of a private mirror named `silverteam-website` will be synced to a branch named `silverteam-website` on the public fork. So it's a good idea to be verbose in your name and describe how this fork will be used. ICF's workflow supports multiple private mirrors per public fork, to enable different individuals or teams to work on the default branches of their respective mirrors without interefering with each other.
+
+![Dialog showing creation of new private mriror](images/create-new-mirror.png)
+
+6. As the app creates the private mirror, it also adds some basic branch protection rules to require approvals before merge, but you'll likely want to customize these with additional checks to meet your internal requirements for compliance or IP review. Go to the newly-created mirror's **Settings** page and add or modify the rules under **Branches**.
+
+![Branch protection rules in the private mirror's settings](images/branch-protection.png)
+
+The mirror should now be ready for PRs!
+
+## PR workflow once a mirror is active
+
+1. Create a pull request against the private mirror repo
+
+2. Review and merge the PR - at this step, if issues come up that require the deletion of code in the PR, you should "squash history" in the PR so the merge commit does not contain traces of the unwanted code.
+
+3. Once it's merged, the app will automatically sync the private mirror to your public fork, updating a branch whose name matches the name of the private mirror (`silverteam-website`, in this example).
+
+4. You can then use that branch of the public fork as the base to open a PR to the upstream repository.