Skip to content

Dev_Developer Guidelines

Jump to bottom
Eric Carmichael edited this page Sep 5, 2017 · 10 revisions

Basic Requirements

Before working on CodaLab, you should be able to successfully build and run the project. Remember to follow basic Git hygiene. CodaLab is built using Python and Django, so you should be familiar with these technologies.

Branches

In the CodaLab Github Repo there may be many branches. We want to be very careful about two specific branches to ensure the quality of the codebase stays high.

  1. master - This is the stable version that is in production at any given time. It should be well tested and deployable.

  2. develop - This is the development branch. This is the branch that has all of the work that is thought to have been completed but has not yet undergone final testing before deployment to production. The develop branch is where automated builds and QA happens.

Get the Source Code

Follow these instructions to create a local clone of the CodaLab source code.

  1. Fork the CodaLab repo from GitHub.

  2. Clone the fork to your local computer.

    git clone https://github.com/<username>/codalab.git

Pull Requests

When the code in your GitHub fork is ready to make its way into the master branch of the CodaLab GitHub account, you should submit a pull request. Be detailed in your description of the changes.

When you submit a pull request, GitHub will let you know if the request cannot be merged automatically. This GitHub page explains how to merge a pull request.

Other assumptions:

  • Committers will review pull requests and fold them into the master branch of the CodaLab account.
  • Developers should ask for code reviews of their code when they feel like it's getting ready to pull into master. This is easily done by adding github id's to the message on the pull request (mentioning them sends a notification).
  • If a change is going to affect the user experience, it should include code reviews/discussions (again through pull requests mentions) because this is a broad platform, intended for use by many diverse communities.
  • Merges to master and deployment to production will be done by the project QA/Release Engineer.
  • Secure data is being stored in a shared dropbox location.

Best practices

  • DO read and follow the process for managing tasks and bugs.
  • DO associate your commit with the issue that you are fixing. The mechanism for doing so is explained in this GitHub Blog entry and in this StackOverflow question.
  • DO ensure that the development environment runs on Windows and Linux. We want contributions from many developers irrespective of their favorite development platform.
  • DO add tests as appropriate
  • DO run flake8 against your code to make sure we're following the same style guidelines

Additional Resources

Finally, here is some recommended reading for participating in an open source project:

Clone this wiki locally