How Can I Contribute My Work?

Prerequisites

You will need a GitHub account that is linked to the Microsoft GitHub Organization to start.
To create a GitHub account, navigate to https://github.com https://github.com and follow the instructions to sign-up. (The GitHub account is your personal account and remains your account even after you stop working for Microsoft.
Once you have a GitHub account, instructions to link your GitHub and Microsoft account can be found here: https://repos.opensource.microsoft.com/
Linking will give you access to the Microsoft Organization on GitHub. (This is were all the IP is located.)

​​​​​​​​​​​​​​Workflow To Create A New Accelerator

    If you have great IP that can be packaged as a delivery ​​​​​​​accelerator, reach out to discuss your IP and see if it qualifies for funding. If your IP qualifies, you will get the following:
  • An internal project assignment, so you can log the time you spend curating your code. (funded with NBUE)
  • Help to create your own GitHub Opensource repository (Private or Public) to store your code and build your own portfolio of evidence, to show the world what you have done.
  • Marketing of your accelerator to sellers, delivery teams and Industry teams.
  • Help, from others who have already published and reviewed code for solution accelerators that have been adopted in the Data Science Toolkit.
  • Community recognition, we have won awards, you could be next.

Workflow For Contributing To Existing Accelerators

This section will describe how to contribute using the git workflow (from now on called the SST Flow) used for the different delivery accelerators in the Data Science Toolkit. The flow is an extension of the Github flow first described by Scott Chacon.

If you are new to git or feel like a brush-up, it is highly recommended to read Git in Practice by Mike McQuaid.

The workflow is simple because it essentially involves only two types of branches: the default master branch and feature branches. A feature branch is one that is used only for development of a single feature (or sometimes bug fix) and then deleted after being merged into another branch.

SST Flow

    In GitHub Flow
  • All commits are made on feature branches.
  • Feature branches are merged to the master branch after review in a pull request.
  • All commits to master are considered stable.

    • The SST Flow is essentially GitHub Flow with a couple of extra elements:
  • Branches can be (and should be) rebased, rewritten, and squashed where appropriate (to make history cleaner, but not if the branch is being used by multiple people).
  • Stable releases can be tagged on the master branch.
  • Release branches are branched off from master and can be committed to directly, cherry-picked, or merged to from feature branches.
  • Unlike feature branches, release branches are newer rewritten.
  • Tags are created on feature branches rather than master.
Figure 1
Figure 1: SST Flow

Figure 2
Figure 2: Key

    Figure 1 shows SST Flow from top (the oldest commit) to bottom (the newest commit):
  1. The initial commit to a repository is on the master branch and made with git add and git commit. Consider using git commit --allow-empty -m “Initial commit” as this enables you to rewrite the history of the repository before you publish it to GitHub.
  2. A feature is being developed, so it’s branched off the master branch with git checkout -b.
  3. A release branch for the v1.x release series is branched off the master branch with git checkout -b.
  4. A commit is made to the feature branch with git commit. It’s pushed with git push.
  5. A feature branch is submitted for review in a pull request. If any changes are needed due to comments in the pull request, they’re committed. The pull request is automatically updated after new commits have been pushed to the remote branch. When the branch is ready, it’s merged to master with git merge and deleted locally with git branch --delete and remotely with git push --delete.
  6. Commits are made to the release branches with git commit for changes or fixes specific to a release but not applicable to other application development. For example, such a commit may be changing a version number displayed in the application.
  7. Another feature or fix is developed, so a new feature branch is branched off the master branch with git checkout -- b.
  8. A feature branch is ready and merged to both master and release branch for the v1.x release series with git merge and deleted locally with git branch --delete and remotely with git push --delete. The new master branch is tagged v1.1 with git tag and pushed with git push and git push --tags. The release branch is not deleted but kept around indefinitely in case any more stable releases are needed from it.
  9. Another feature is developed, so a new feature branch is branched off the master branch with git checkout -b.
  10. A fix is needed for the v2.x release series, so a new feature branch is branched off the v2.x release branch with git checkout -b.
  11. The feature branch fix is ready and merged to the v2.x release series branch with git merge and deleted locally with git branch --delete and remotely with git push --delete. The new master branch is tagged v2.1 with git tag and pushed with git push and git push- -tags.
  12. The remaining feature branch needs to use changes in master and to rewrite commits, so it’s rebased and squashed on top of master with git rebase --interactive. The may be to use work from master in the branch, to resolve conflicts in the feature branch before they’re merged into master, or to clean up commit by rewriting them.
  13. The remaining feature branch is submitted for review, merged, and deleted.