Public Lab Wiki documentation

Public Lab welcomes and encourages community contributions to our open source software!

This page is intended to:

1. List software projects that Public Lab has incubated and provide links to source code.
2. Collect software development guidelines and best practices for Public Lab projects.
3. Help newcomers figure out how and where to start contributing!

Getting started

For an excellent overview of contributing to open source projects in general, check out How to contribute to an open source project on Github.

Quick tips for getting involved with the Public Lab codebases:

1. Set up a GitHub account and install git.

   If you're not familiar with git, a popular version control software, you can try it out at https://try.github.io.

   Speaking of GitHub...right now, all of Public Lab's open source code is located on GitHub, a website which hosts git repositories. Setting up a GitHub account is the first step to getting involved with Public Lab's code (and lots of other code).

2. Join the Public Lab developers mailing list

Contribution Guidelines

Public Lab software is written in many languages, and each project may have its own guidelines for contributors. These broad guidelines should serve as general principles to guide your approach to a new Public Lab codebase.

Contributing using git

If this is your first time contributing to open source software, or to Public Lab, see our **Welcome page to take your first step!

Also check out this article on GitHub flow, a routine that works great on all git projects and makes Public Lab development super smooth.

Questions

[questions:software]

Activities

[activities:software]

A sample git workflow

See this activity for a guide to using branches and pull requests on GitHub.

For some additional tips for different scenarios, such as if you've forgotten to make your commits in a named feature branch and need to rewind your master, see below

Public Lab Software

For an overview of Public Lab software projects, see this list on the Developers page

Additional workflows

Rewinding the master branch

Sometimes you forget to make your commits on a named feature branch, and add commits to your master branch. You want to rewind the master branch back so you can pull in the latest changes from others, but you don't want to lose your work! It's all right, though -- you can follow these steps to rewind, update, and rebase your changes on top of the latest commits to Public Lab's master branch (shown here for the plots2 repository):

1. git checkout master - go back to your master branch (your work is saved in the feature branch)
2. git reset --hard 123456 -- rewind your master branch to a state before it diverged from our master (where 123456 is the commit hash just before your commits -- the latest one your history has in common with the publiclab/plots repository's history)
3. git pull https://github.com/publiclab/plots2.git master -- fetch publiclab's latest master
4. git checkout feature-branch-name -- go back to your saved feature branch, named something more descriptive than feature-branch-name
5. git rebase master -- this just detaches your latest changes (minus the deleted one) and reattaches or "replays" them onto the latest master. If you see merge errors, try following this guide to resolve them.
6. git push origin feature-branch-name -- push up your newly re-based changes! (you can use git push -f origin feature-branch-name forces, to overwrite a PR if you've already opened one)
7. Go to https://github.com/publiclab/plots2 to look for the prompt to open a PR if you haven't already.

Public Lab welcomes and encourages community contributions to our open source software!

This page is intended to:

1. List software projects that Public Lab has incubated and provide links to source code.
2. Collect software development guidelines and best practices for Public Lab projects.
3. Help newcomers figure out how and where to start contributing!

Getting started

For an excellent overview of contributing to open source projects in general, check out How to contribute to an open source project on Github.

Quick tips for getting involved with the Public Lab codebases:

1. Set up a GitHub account and install git.

   If you're not familiar with git, a popular version control software, you can try it out at https://try.github.io.

   Speaking of GitHub...right now, all of Public Lab's open source code is located on GitHub, a website which hosts git repositories. Setting up a GitHub account is the first step to getting involved with Public Lab's code (and lots of other code).

2. Join the Public Lab developers mailing list

Contribution Guidelines

Public Lab software is written in many languages, and each project may have its own guidelines for contributors. These broad guidelines should serve as general principles to guide your approach to a new Public Lab codebase.

Contributing using git

Check out this article on GitHub flow, a routine that works great on all git projects and makes Public Lab development super smooth.

A sample git workflow

See this activity for a guide to using branches and pull requests on GitHub.

For some additional tips for different scenarios, such as if you've forgotten to make your commits in a named feature branch and need to rewind your master, see below

Public Lab Software

Additional workflows

Rewinding the master branch

Sometimes you forget to make your commits on a named feature branch, and add commits to your master branch. You want to rewind the master branch back so you can pull in the latest changes from others, but you don't want to lose your work! It's all right, though -- you can follow these steps to rewind, update, and rebase your changes on top of the latest commits to Public Lab's master branch (shown here for the plots2 repository):

1. git checkout master - go back to your master branch (your work is saved in the feature branch)
2. git reset --hard 123456 -- rewind your master branch to a state before it diverged from our master (where 123456 is the commit hash just before your commits -- the latest one your history has in common with the publiclab/plots repository's history)
3. git pull https://github.com/publiclab/plots2.git master -- fetch publiclab's latest master
4. git checkout feature-branch-name -- go back to your saved feature branch, named something more descriptive than feature-branch-name
5. git rebase master -- this just detaches your latest changes (minus the deleted one) and reattaches or "replays" them onto the latest master. If you see merge errors, try following this guide to resolve them.
6. git push origin feature-branch-name -- push up your newly re-based changes! (you can use git push -f origin feature-branch-name forces, to overwrite a PR if you've already opened one)
7. Go to https://github.com/publiclab/plots2 to look for the prompt to open a PR if you haven't already.

Public Lab welcomes and encourages community contributions to our open source software!

This page is intended to:

1. List software projects that Public Lab has incubated and provide links to source code.
2. Collect software development guidelines and best practices for Public Lab projects.
3. Help newcomers figure out how and where to start contributing!

Getting started

For an excellent overview of contributing to open source projects in general, check out How to contribute to an open source project on Github.

Quick tips for getting involved with the Public Lab codebases:

1. Set up a GitHub account and install git.

   If you're not familiar with git, a popular version control software, you can try it out at https://try.github.io.

   Speaking of GitHub...right now, all of Public Lab's open source code is located on GitHub, a website which hosts git repositories. Setting up a GitHub account is the first step to getting involved with Public Lab's code (and lots of other code).

2. Join the Public Lab developers mailing list

Contribution Guidelines

Public Lab software is written in many languages, and each project may have its own guidelines for contributors. These broad guidelines should serve as general principles to guide your approach to a new Public Lab codebase.

Contributing using git

Check out this article on GitHub flow, a routine that works great on all git projects and makes Public Lab development super smooth.

A sample git workflow

See this activity for a guide to *using branches and pull requests on GitHub.

For some additional tips for different scenarios, such as if you've forgotten to make your commits in a named feature branch and need to rewind your master, see below

Public Lab Software

Additional workflows

Rewinding the master branch

Sometimes you forget to make your commits on a named feature branch, and add commits to your master branch. You want to rewind the master branch back so you can pull in the latest changes from others, but you don't want to lose your work! It's all right, though -- you can follow these steps to rewind, update, and rebase your changes on top of the latest commits to Public Lab's master branch (shown here for the plots2 repository):

1. git checkout master - go back to your master branch (your work is saved in the feature branch)
2. git reset --hard 123456 -- rewind your master branch to a state before it diverged from our master (where 123456 is the commit hash just before your commits -- the latest one your history has in common with the publiclab/plots repository's history)
3. git pull https://github.com/publiclab/plots2.git master -- fetch publiclab's latest master
4. git checkout feature-branch-name -- go back to your saved feature branch, named something more descriptive than feature-branch-name
5. git rebase master -- this just detaches your latest changes (minus the deleted one) and reattaches or "replays" them onto the latest master. If you see merge errors, try following this guide to resolve them.
6. git push origin feature-branch-name -- push up your newly re-based changes! (you can use git push -f origin feature-branch-name forces, to overwrite a PR if you've already opened one)
7. Go to https://github.com/publiclab/plots2 to look for the prompt to open a PR if you haven't already.

Public Lab welcomes and encourages community contributions to our open source software!

This page is intended to:

1. List software projects that Public Lab has incubated and provide links to source code.
2. Collect software development guidelines and best practices for Public Lab projects.
3. Help newcomers figure out how and where to start contributing!

Getting started

For an excellent overview of contributing to open source projects in general, check out How to contribute to an open source project on Github.

Quick tips for getting involved with the Public Lab codebases:

1. Set up a GitHub account and install git.

   If you're not familiar with git, a popular version control software, you can try it out at https://try.github.io.

   Speaking of GitHub...right now, all of Public Lab's open source code is located on GitHub, a website which hosts git repositories. Setting up a GitHub account is the first step to getting involved with Public Lab's code (and lots of other code).

2. Join the Public Lab developers mailing list

Contribution Guidelines

Public Lab software is written in many languages, and each project may have its own guidelines for contributors. These broad guidelines should serve as general principles to guide your approach to a new Public Lab codebase.

Contributing using git

Check out this article on GitHub flow, a routine that works great on all git projects and makes Public Lab development super smooth.

A sample git workflow

Let's say that a developer and PublicLab community member named Susan decides that she wants to add a feature to plots2 (PublicLab.org). Here's what Susan's workflow might look like:

1. Susan forks the publiclab/plots2 repo on GitHub.
2. Susan clones the forked repository susan/plots2. This downloads a copy of Susan's version of plots2 to her computer.
3. She creates a branch for the new feature (a feature branch). Let's say that Susan wanted users to be able to tag maps. She might then create and checkout a new branch called add-map-tags with: git checkout -b add-map-tags.
4. Susan develops the new feature in the add-map-tags feature branch, making commits (and running tests) as she goes.
5. When Susan is done developing the new feature, she switches back to the master branch of her own repository: git checkout master, and then pulls the latest version of plots2 down from the publiclab repo with git pull https://github.com/publiclab/plots2.git master.
6. Susan applies her new feature on top of the latest version of plots2: From the add-map-tags branch, she runs git rebase master. This is the great strength of doing development in a feature branch - it allows Susan to merge her changes into the latest public version of plots2 on her own computer and to resolve any conflicts locally.
7. After rebasing, Susan's local feature branch add-map-tags contains the latest version of plots2 with her new feature added on top. The new feature is ready, so Susan pushes her feature branch up to her own remote repository with git push origin add-map-tags and submits a pull request on GitHub from that to publiclab's master branch.
8. Susan discusses her code with others. After any questions or change requests have been resolved, Susan's request is merged in, and her contribution becomes part of PublicLab.org!

A few notes - some git best practices that will make all of our lives easier:

• Remember to pull from master before you start working on a new feature. This helps keep your local repository in sync with the code that everyone else is working on. If you've forgotten to, see below for how to recover without losing your work.
• Always do development in a feature branch (again, see below if you've forgotten). This makes it much easier for project maintainers to merge your contributions into the trunk. The name of your branch is displayed when it is merged in to the main trunk, which means that it serves as built-in documentation for your feature. This works great when you give your feature branches descriptive names! Some example branch names:
  • donation-button-redesign
  • markdown-package-update
  • fix#44 (fixes GitHub issue #44 in this repository)
• Open a pull request early! In fact, feel free to open a pull request as soon as you start working on a new feature or bugfix. GitHub's pull request pages make it easy to see progress that's been made on an issue, and it's a great way to start an open and ongoing discussion with the project's maintainers and other contributors about your work.

For some additional tips for different scenarios, such as if you've forgotten to make your commits in a named feature branch and need to rewind your master, see below

Public Lab Software

Additional workflows

Rewinding the master branch

Sometimes you forget to make your commits on a named feature branch, and add commits to your master branch. You want to rewind the master branch back so you can pull in the latest changes from others, but you don't want to lose your work! It's all right, though -- you can follow these steps to rewind, update, and rebase your changes on top of the latest commits to Public Lab's master branch (shown here for the plots2 repository):

1. git checkout master - go back to your master branch (your work is saved in the feature branch)
2. git reset --hard 123456 -- rewind your master branch to a state before it diverged from our master (where 123456 is the commit hash just before your commits -- the latest one your history has in common with the publiclab/plots repository's history)
3. git pull https://github.com/publiclab/plots2.git master -- fetch publiclab's latest master
4. git checkout feature-branch-name -- go back to your saved feature branch, named something more descriptive than feature-branch-name
5. git rebase master -- this just detaches your latest changes (minus the deleted one) and reattaches or "replays" them onto the latest master. If you see merge errors, try following this guide to resolve them.
6. git push origin feature-branch-name -- push up your newly re-based changes! (you can use git push -f origin feature-branch-name forces, to overwrite a PR if you've already opened one)
7. Go to https://github.com/publiclab/plots2 to look for the prompt to open a PR if you haven't already.

Public Lab welcomes and encourages community contributions to our open source software!

This page is intended to:

1. List software projects that Public Lab has incubated and provide links to source code.
2. Collect software development guidelines and best practices for Public Lab projects.
3. Help newcomers figure out how and where to start contributing!

Getting started

For an excellent overview of contributing to open source projects in general, check out How to contribute to an open source project on Github.

Quick tips for getting involved with the Public Lab codebases:

1. Set up a GitHub account and install git.

   If you're not familiar with git, a popular version control software, you can try it out at https://try.github.io.

   Speaking of GitHub...right now, all of Public Lab's open source code is located on GitHub, a website which hosts git repositories. Setting up a GitHub account is the first step to getting involved with Public Lab's code (and lots of other code).

2. Join the Public Lab developers mailing list

Contribution Guidelines

Public Lab software is written in many languages, and each project may have its own guidelines for contributors. These broad guidelines should serve as general principles to guide your approach to a new Public Lab codebase.

Contributing using git

Check out this article on GitHub flow, a routine that works great on all git projects and makes Public Lab development super smooth.

A sample git workflow

Let's say that a developer and PublicLab community member named Susan decides that she wants to add a feature to plots2 (PublicLab.org). Here's what Susan's workflow might look like:

1. Susan forks the publiclab/plots2 repo on GitHub.
2. Susan clones the forked repository susan/plots2. This downloads a copy of Susan's version of plots2 to her computer.
3. She creates a branch for the new feature (a feature branch). Let's say that Susan wanted users to be able to tag maps. She might then create and checkout a new branch called add-map-tags with: git checkout -b add-map-tags.
4. Susan develops the new feature in the add-map-tags feature branch, making commits (and running tests) as she goes.
5. When Susan is done developing the new feature, she switches back to the master branch of her own repository: git checkout master, and then pulls the latest version of plots2 down from the publiclab repo with git pull https://github.com/publiclab/plots2.git master.
6. Susan applies her new feature on top of the latest version of plots2: From the add-map-tags branch, she runs git rebase master. This is the great strength of doing development in a feature branch - it allows Susan to merge her changes into the latest public version of plots2 on her own computer and to resolve any conflicts locally.
7. After rebasing, Susan's local feature branch add-map-tags contains the latest version of plots2 with her new feature added on top. The new feature is ready, so Susan pushes her feature branch up to her own remote repository with git push origin add-map-tags and submits a pull request on GitHub from that to publiclab's master branch.
8. Susan discusses her code with others. After any questions or change requests have been resolved, Susan's request is merged in, and her contribution becomes part of PublicLab.org!

A few notes - some git best practices that will make all of our lives easier:

• Remember to pull from master before you start working. This helps keep your local repository in sync with the code that everyone else is working on. If you've forgotten to, see below for how to recover without losing your work.
• Always do development in a feature branch (again, see below if you've forgotten). This makes it much easier for project maintainers to merge your contributions into the trunk. The name of your branch is displayed when it is merged in to the main trunk, which means that it serves as built-in documentation for your feature. This works great when you give your feature branches descriptive names! Some example branch names:
  • donation-button-redesign
  • markdown-package-update
  • fix#44 (fixes GitHub issue #44 in this repository)
• Open a pull request early! In fact, feel free to open a pull request as soon as you start working on a new feature or bugfix. GitHub's pull request pages make it easy to see progress that's been made on an issue, and it's a great way to start an open and ongoing discussion with the project's maintainers and other contributors about your work.

For some additional tips for different scenarios, such as if you've forgotten to make your commits in a named feature branch and need to rewind your master, see below

Public Lab Software

Additional workflows

Rewinding the master branch

Sometimes you forget to make your commits on a named feature branch, and add commits to your master branch. You want to rewind the master branch back so you can pull in the latest changes from others, but you don't want to lose your work! It's all right, though -- you can follow these steps to rewind, update, and rebase your changes on top of the latest commits to Public Lab's master branch (shown here for the plots2 repository):

1. git checkout master - go back to your master branch (your work is saved in the feature branch)
2. git reset --hard 123456 -- rewind your master branch to a state before it diverged from our master (where 123456 is the commit hash just before your commits -- the latest one your history has in common with the publiclab/plots repository's history)
3. git pull https://github.com/publiclab/plots2.git master -- fetch publiclab's latest master
4. git checkout feature-branch-name -- go back to your saved feature branch, named something more descriptive than feature-branch-name
5. git rebase master -- this just detaches your latest changes (minus the deleted one) and reattaches or "replays" them onto the latest master. If you see merge errors, try following this guide to resolve them.
6. git push origin feature-branch-name -- push up your newly re-based changes! (you can use git push -f origin feature-branch-name forces, to overwrite a PR if you've already opened one)
7. Go to https://github.com/publiclab/plots2 to look for the prompt to open a PR if you haven't already.

Public Lab welcomes and encourages community contributions to our open source software!

This page is intended to:

1. List software projects that Public Lab has incubated and provide links to source code.
2. Collect software development guidelines and best practices for Public Lab projects.
3. Help newcomers figure out how and where to start contributing!

Getting started

For an excellent overview of contributing to open source projects in general, check out How to contribute to an open source project on Github.

Quick tips for getting involved with the Public Lab codebases:

1. Set up a GitHub account and install git.

   If you're not familiar with git, a popular version control software, you can try it out at https://try.github.io.

   Speaking of GitHub...right now, all of Public Lab's open source code is located on GitHub, a website which hosts git repositories. Setting up a GitHub account is the first step to getting involved with Public Lab's code (and lots of other code).

2. Join the Public Lab developers mailing list

Contribution Guidelines

Public Lab software is written in many languages, and each project may have its own guidelines for contributors. These broad guidelines should serve as general principles to guide your approach to a new Public Lab codebase.

Contributing using git

Check out this article on GitHub flow, a routine that works great on all git projects and makes Public Lab development super smooth.

A sample git workflow

Let's say that a developer and PublicLab community member named Susan decides that she wants to add a feature to plots2 (PublicLab.org). Here's what Susan's workflow might look like:

1. Susan forks the publiclab/plots2 repo on GitHub.
2. Susan clones the forked repository susan/plots2. This downloads a copy of Susan's version of plots2 to her computer.
3. She creates a branch for the new feature (a feature branch). Let's say that Susan wanted users to be able to tag maps. She might then create and checkout a new branch called add-map-tags with: git checkout -b add-map-tags.
4. Susan develops the new feature in the add-map-tags feature branch, making commits (and running tests) as she goes.
5. When Susan is done developing the new feature, she switches back to the master branch of her own repository: git checkout master, and then pulls the latest version of plots2 down from the publiclab repo with git pull https://github.com/publiclab/plots2.git master.
6. Susan applies her new feature on top of the latest version of plots2: From the add-map-tags branch, she runs git rebase master. This is the great strength of doing development in a feature branch - it allows Susan to merge her changes into the latest public version of plots2 on her own computer and to resolve any conflicts locally. Back in master (git checkout master), Susan runs git merge add-map-tags --ff-only to bring her master branch up to date.
7. After rebasing, Susan's local master branch contains the latest version of plots2 with her new feature added on top. The new feature is ready, so Susan submits a pull request on GitHub.
8. Susan discusses her code with others. After any questions or change requests have been resolved, Susan's request is merged in, and her contribution becomes part of PublicLab.org!

A few notes - some git best practices that will make all of our lives easier:

• Remember to pull from master before you start working. This helps keep your local repository in sync with the code that everyone else is working on. If you've forgotten to, see below for how to recover without losing your work.
• Always do development in a feature branch (again, see below if you've forgotten). This makes it much easier for project maintainers to merge your contributions into the trunk. The name of your branch is displayed when it is merged in to the main trunk, which means that it serves as built-in documentation for your feature. This works great when you give your feature branches descriptive names! Some example branch names:
  • donation-button-redesign
  • markdown-package-update
  • fix#44 (fixes GitHub issue #44 in this repository)
• Open a pull request early! In fact, feel free to open a pull request as soon as you start working on a new feature or bugfix. GitHub's pull request pages make it easy to see progress that's been made on an issue, and it's a great way to start an open and ongoing discussion with the project's maintainers and other contributors about your work.

For some additional tips for different scenarios, such as if you've forgotten to make your commits in a named feature branch and need to rewind your master, see below

Public Lab Software

Additional workflows

Rewinding the master branch

Sometimes you forget to make your commits on a named feature branch, and add commits to your master branch. You want to rewind the master branch back so you can pull in the latest changes from others, but you don't want to lose your work! It's all right, though -- you can follow these steps to rewind, update, and rebase your changes on top of the latest commits to Public Lab's master branch (shown here for the plots2 repository):

1. git checkout master - go back to your master branch (your work is saved in the feature branch)
2. git reset --hard 123456 -- rewind your master branch to a state before it diverged from our master (where 123456 is the commit hash just before your commits -- the latest one your history has in common with the publiclab/plots repository's history)
3. git pull https://github.com/publiclab/plots2.git master -- fetch publiclab's latest master
4. git checkout feature-branch-name -- go back to your saved feature branch, named something more descriptive than feature-branch-name
5. git rebase master -- this just detaches your latest changes (minus the deleted one) and reattaches or "replays" them onto the latest master. If you see merge errors, try following this guide to resolve them.
6. git push origin feature-branch-name -- push up your newly re-based changes! (you can use git push -f origin feature-branch-name forces, to overwrite a PR if you've already opened one)
7. Go to https://github.com/publiclab/plots2 to look for the prompt to open a PR if you haven't already.

Public Lab welcomes and encourages community contributions to our open source software!

This page is intended to:

1. List software projects that Public Lab has incubated and provide links to source code.
2. Collect software development guidelines and best practices for Public Lab projects.
3. Help newcomers figure out how and where to start contributing!

Getting started

For an excellent overview of contributing to open source projects in general, check out How to contribute to an open source project on Github.

Quick tips for getting involved with the Public Lab codebases:

1. Set up a GitHub account and install git.

   If you're not familiar with git, a popular version control software, you can try it out at https://try.github.io.

   Speaking of GitHub...right now, all of Public Lab's open source code is located on GitHub, a website which hosts git repositories. Setting up a GitHub account is the first step to getting involved with Public Lab's code (and lots of other code).

2. Join the Public Lab developers mailing list

Contribution Guidelines

Public Lab software is written in many languages, and each project may have its own guidelines for contributors. These broad guidelines should serve as general principles to guide your approach to a new Public Lab codebase.

Contributing using git

Check out this article on GitHub flow, a routine that works great on all git projects and makes Public Lab development super smooth.

A sample git workflow

Let's say that a developer and PublicLab community member named Susan decides that she wants to add a feature to plots2 (PublicLab.org). Here's what Susan's workflow might look like:

1. Susan forks the publiclab/plots2 repo on GitHub.
2. Susan clones the forked repository susan/plots2. This downloads a copy of Susan's version of plots2 to her computer.
3. She creates a branch for the new feature (a feature branch). Let's say that Susan wanted users to be able to tag maps. She might then create and checkout a new branch called add-map-tags with: git checkout -b add-map-tags.
4. Susan develops the new feature in the add-map-tags feature branch, making commits (and running tests) as she goes.
5. When Susan is done developing the new feature, she switches back to the master branch of her own repository: git checkout master, and then pulls the latest version of plots2 down from the publiclab repo with git pull https://github.com/publiclab/plots2.git master.
6. Susan applies her new feature on top of the latest version of plots2: From the add-map-tags branch, she runs git rebase master. This is the great strength of doing development in a feature branch - it allows Susan to merge her changes into the latest public version of plots2 on her own computer and to resolve any conflicts locally. Back in master (git checkout master), Susan runs git merge add-map-tags --ff-only to bring her master branch up to date.
7. After rebasing, Susan's local master branch contains the latest version of plots2 with her new feature added on top. The new feature is ready, so Susan submits a pull request on GitHub.
8. Susan discusses her code with others. After any questions or change requests have been resolved, Susan's request is merged in, and her contribution becomes part of PublicLab.org!

A few notes - some git best practices that will make all of our lives easier:

• Remember to pull from master before you start working. This helps keep your local repository in sync with the code that everyone else is working on. If you've forgotten to, see below for how to recover without losing your work.
• Always do development in a feature branch (again, see below if you've forgotten). This makes it much easier for project maintainers to merge your contributions into the trunk. The name of your branch is displayed when it is merged in to the main trunk, which means that it serves as built-in documentation for your feature. This works great when you give your feature branches descriptive names! Some example branch names:
  • donation-button-redesign
  • markdown-package-update
  • fix#44 (fixes GitHub issue #44 in this repository)
• Open a pull request early! In fact, feel free to open a pull request as soon as you start working on a new feature or bugfix. GitHub's pull request pages make it easy to see progress that's been made on an issue, and it's a great way to start an open and ongoing discussion with the project's maintainers and other contributors about your work.

For some additional tips for different scenarios, such as if you've forgotten to make your commits in a named feature branch and need to rewind your master, see below

Public Lab Software

Additional workflows

Rewinding the master branch

Sometimes you forget to make your commits on a named feature branch, and add commits to your master branch. You want to rewind the master branch back so you can pull in the latest changes from others, but you don't want to lose your work! It's all right, though -- you can follow these steps to rewind, update, and rebase your changes on top of the latest commits to Public Lab's master branch (shown here for the plots2 repository):

1. git checkout master - go back to your master branch (your work is saved in the feature branch)
2. git reset --hard 123456 -- rewind your master branch to a state before it diverged from our master (where 123456 is the commit hash just before your commits -- the latest one your history has in common with the publiclab/plots repository's history)
3. git pull https://github.com/publiclab/plots2.git master -- fetch publiclab's latest master
4. git checkout feature-branch-name -- go back to your saved feature branch, named something more descriptive than feature-branch-name
5. git rebase master -- this just detaches your latest changes (minus the deleted one) and reattaches or "replays" them onto the latest master
6. git push origin feature-branch-name -- push up your newly re-based changes! (you can use git push -f origin feature-branch-name forces, to overwrite a PR if you've already opened one)
7. Go to https://github.com/publiclab/plots2 to look for the prompt to open a PR if you haven't already.

Public Lab welcomes and encourages community contributions to our open source software!

This page is intended to:

1. List software projects that Public Lab has incubated and provide links to source code.
2. Collect software development guidelines and best practices for Public Lab projects.
3. Help newcomers figure out how and where to start contributing!

Getting started

For an excellent overview of contributing to open source projects in general, check out How to contribute to an open source project on Github.

Quick tips for getting involved with the Public Lab codebases:

1. Set up a GitHub account and install git.

   If you're not familiar with git, a popular version control software, you can try it out at https://try.github.io.

   Speaking of GitHub...right now, all of Public Lab's open source code is located on GitHub, a website which hosts git repositories. Setting up a GitHub account is the first step to getting involved with Public Lab's code (and lots of other code).

2. Join the Public Lab developers mailing list

Contribution Guidelines

Public Lab software is written in many languages, and each project may have its own guidelines for contributors. These broad guidelines should serve as general principles to guide your approach to a new Public Lab codebase.

Contributing using git

Check out this article on GitHub flow, a routine that works great on all git projects and makes Public Lab development super smooth.

A sample git workflow

Let's say that a developer and PublicLab community member named Susan decides that she wants to add a feature to plots2 (PublicLab.org). Here's what Susan's workflow might look like:

1. Susan forks the publiclab/plots2 repo on GitHub.
2. Susan clones the forked repository susan/plots2. This downloads a copy of Susan's version of plots2 to her computer.
3. She creates a branch for the new feature (a feature branch). Let's say that Susan wanted users to be able to tag maps. She might then create and checkout a new branch called add-map-tags with: git checkout -b add-map-tags.
4. Susan develops the new feature in the add-map-tags feature branch.
5. When Susan is done developing the new feature, she switches back to the master branch of her own repository: git checkout master, and then pulls the latest version of plots2 down from the publiclab repo with git pull https://github.com/publiclab/plots2.git master.
6. Susan applies her new feature on top of the latest version of plots2: From the add-map-tags branch, she runs git rebase master. This is the great strength of doing development in a feature branch - it allows Susan to merge her changes into the latest public version of plots2 on her own computer and to resolve any conflicts locally. Back in master (git checkout master), Susan runs git merge add-map-tags --ff-only to bring her master branch up to date.
7. After rebasing, Susan's local master branch contains the latest version of plots2 with her new feature added on top. The new feature is ready, so Susan submits a pull request on GitHub.
8. Susan discusses her code with others. After any questions or change requests have been resolved, Susan's request is merged in, and her contribution becomes part of PublicLab.org!

A few notes - some git best practices that will make all of our lives easier:

• Remember to pull from master before you start working. This helps keep your local repository in sync with the code that everyone else is working on. If you've forgotten to, see below for how to recover without losing your work.
• Always do development in a feature branch (again, see below if you've forgotten). This makes it much easier for project maintainers to merge your contributions into the trunk. The name of your branch is displayed when it is merged in to the main trunk, which means that it serves as built-in documentation for your feature. This works great when you give your feature branches descriptive names! Some example branch names:
  • donation-button-redesign
  • markdown-package-update
  • fix#44 (fixes GitHub issue #44 in this repository)
• Open a pull request early! In fact, feel free to open a pull request as soon as you start working on a new feature or bugfix. GitHub's pull request pages make it easy to see progress that's been made on an issue, and it's a great way to start an open and ongoing discussion with the project's maintainers and other contributors about your work.

For some additional tips for different scenarios, such as if you've forgotten to make your commits in a named feature branch and need to rewind your master, see below

Public Lab Software

Additional workflows

Rewinding the master branch

Sometimes you forget to make your commits on a named feature branch, and add commits to your master branch. You want to rewind the master branch back so you can pull in the latest changes from others, but you don't want to lose your work! It's all right, though -- you can follow these steps to rewind, update, and rebase your changes on top of the latest commits to Public Lab's master branch (shown here for the plots2 repository):

1. git checkout master - go back to your master branch (your work is saved in the feature branch)
2. git reset --hard 123456 -- rewind your master branch to a state before it diverged from our master (where 123456 is the commit hash just before your commits -- the latest one your history has in common with the publiclab/plots repository's history)
3. git pull https://github.com/publiclab/plots2.git master -- fetch publiclab's latest master
4. git checkout feature-branch-name -- go back to your saved feature branch, named something more descriptive than feature-branch-name
5. git rebase master -- this just detaches your latest changes (minus the deleted one) and reattaches or "replays" them onto the latest master
6. git push origin feature-branch-name -- push up your newly re-based changes! (you can use git push -f origin feature-branch-name forces, to overwrite a PR if you've already opened one)
7. Go to https://github.com/publiclab/plots2 to look for the prompt to open a PR if you haven't already.

Public Lab welcomes and encourages community contributions to our open source software!

This page is intended to:

1. List software projects that Public Lab has incubated and provide links to source code.
2. Collect software development guidelines and best practices for Public Lab projects.
3. Help newcomers figure out how and where to start contributing!

Getting started

For an excellent overview of contributing to open source projects in general, check out How to contribute to an open source project on Github.

Quick tips for getting involved with the Public Lab codebases:

1. Set up a GitHub account and install git.

   If you're not familiar with git, a popular version control software, you can try it out at https://try.github.io.

   Speaking of GitHub...right now, all of Public Lab's open source code is located on GitHub, a website which hosts git repositories. Setting up a GitHub account is the first step to getting involved with Public Lab's code (and lots of other code).

2. Join the Public Lab developers mailing list

Contribution Guidelines

Public Lab software is written in many languages, and each project may have its own guidelines for contributors. These broad guidelines should serve as general principles to guide your approach to a new Public Lab codebase.

Contributing using git

Check out this article on GitHub flow, a routine that works great on all git projects and makes Public Lab development super smooth.

A sample git workflow

Let's say that a developer and PublicLab community member named Susan decides that she wants to add a feature to plots2 (PublicLab.org). Here's what Susan's workflow might look like:

1. Susan forks the publiclab/plots2 repo on GitHub.
2. Susan clones the forked repository susan/plots2. This downloads a copy of Susan's version of plots2 to her computer.
3. She creates a branch for the new feature (a feature branch). Let's say that Susan wanted users to be able to tag maps. She might then create and checkout a new branch called add-map-tags with: git checkout -b add-map-tags.
4. Susan develops the new feature in the add-map-tags feature branch.
5. When Susan is done developing the new feature, she switches back to the master branch of her own repository: git checkout master, and then pulls the latest version of plots2 down from the publiclab repo with git pull https://github.com/publiclab/plots2.git master.
6. Susan applies her new feature on top of the latest version of plots2: From the add-map-tags branch, she runs git rebase master. This is the great strength of doing development in a feature branch - it allows Susan to merge her changes into the latest public version of plots2 on her own computer and to resolve any conflicts locally. Back in master (git checkout master), Susan runs git merge add-map-tags --ff-only to bring her master branch up to date.
7. After rebasing, Susan's local master branch contains the latest version of plots2 with her new feature added on top. The new feature is ready, so Susan submits a pull request on GitHub.
8. Susan discusses her code with others. After any questions or change requests have been resolved, Susan's request is merged in, and her contribution becomes part of PublicLab.org!

A few notes - some git best practices that will make all of our lives easier:

• Remember to pull from master before you start working. This helps keep your local repository in sync with the code that everyone else is working on. If you've forgotten to, see below for how to recover without losing your work.
• Always do development in a feature branch (again, see below if you've forgotten). This makes it much easier for project maintainers to merge your contributions into the trunk. The name of your branch is displayed when it is merged in to the main trunk, which means that it serves as built-in documentation for your feature. This works great when you give your feature branches descriptive names! Some example branch names:
  • donation-button-redesign
  • markdown-package-update
  • fix#44 (fixes GitHub issue #44 in this repository)
• Open a pull request early! In fact, feel free to open a pull request as soon as you start working on a new feature or bugfix. GitHub's pull request pages make it easy to see progress that's been made on an issue, and it's a great way to start an open and ongoing discussion with the project's maintainers and other contributors about your work.

For some additional tips for different scenarios, such as if you've forgotten to make your commits in a named feature branch and need to rewind your master, see below

Public Lab Software

Additional workflows

Rewinding the master branch

Sometimes you forget to make your commits on a named feature branch, and add commits to your master branch. You want to rewind the master branch back so you can pull in the latest changes from others, but you don't want to lose your work! It's all right, though -- you can follow these steps to rewind, update, and rebase your changes on top of the latest commits to Public Lab's master branch (shown here for the plots2 repository):

1. git checkout master - go back to your master branch (your work is saved in the feature branch)
2. git reset --hard 123456 -- rewind your master branch to a state before it diverged from our master (where 123456 is the commit hash just before your commits -- the latest one your history has in common with the publiclab/plots repository's history)
3. git pull https://github.com/publiclab/plots2.git master -- fetch publiclab's latest master
4. git checkout feature-branch-name -- go back to your saved feature branch, named something more descriptive than feature-branch-name
5. git rebase master -- this just detaches your latest changes (minus the deleted one) and reattaches or "replays" them onto the latest master
6. git push origin feature-branch-name -- push up your newly re-based changes! (you can use git push -f origin feature-branch-name forces, to overwrite a PR if you've already opened one)
7. Go to https://github.com/publiclab/plots2 to look for the prompt to open a PR if you haven't already.

Public Lab welcomes and encourages community contributions to our open source software!

This page is intended to:

1. List software projects that Public Lab has incubated and provide links to source code.
2. Collect software development guidelines and best practices for Public Lab projects.
3. Help newcomers figure out how and where to start contributing!

Getting started

For an excellent overview of contributing to open source projects in general, check out How to contribute to an open source project on Github.

Quick tips for getting involved with the Public Lab codebases:

1. Set up a GitHub account and install git.

   If you're not familiar with git, a popular version control software, you can try it out at https://try.github.io.

   Speaking of GitHub...right now, all of Public Lab's open source code is located on GitHub, a website which hosts git repositories. Setting up a GitHub account is the first step to getting involved with Public Lab's code (and lots of other code).

2. Join the Public Lab developers mailing list

Contribution Guidelines

Public Lab software is written in many languages, and each project may have its own guidelines for contributors. These broad guidelines should serve as general principles to guide your approach to a new Public Lab codebase.

Contributing using git

Check out this article on GitHub flow, a routine that works great on all git projects and makes Public Lab development super smooth.

A sample git workflow

Let's say that a developer and PublicLab community member named Susan decides that she wants to add a feature to MapKnitter. Here's what Susan's workflow might look like:

1. Susan forks the publiclab/mapknitter repo on GitHub.
2. Susan clones the forked repository susan/mapknitter. This downloads a copy of Susan's version of mapknitter to her computer.
3. She creates a branch for the new feature (a feature branch). Let's say that Susan wanted users to be able to tag maps. She might then create and checkout a new branch called add-map-tags with: git checkout -b add-map-tags.
4. Susan develops the new feature in the add-map-tags feature branch.
5. When Susan is done developing the new feature, she switches back to the master branch of her own repository: git checkout master, and then pulls the latest version of mapknitter down from the publiclab repo with git pull https://github.com/publiclab/plots2.git master.
6. Susan applies her new feature on top of the latest version of mapknitter: From the add-map-tags branch, she runs git rebase master. This is the great strength of doing development in a feature branch - it allows Susan to merge her changes into the latest public version of mapknitter on her own computer and to resolve any conflicts locally. Back in master (git checkout master), Susan runs git merge add-map-tags --ff-only to bring her master branch up to date.
7. After rebasing, Susan's local master branch contains the latest version of mapknitter with her new feature added on top. The new feature is ready, so Susan submits a pull request on GitHub.
8. Susan discusses her code with others. After any questions or change requests have been resolved, Susan's request is merged in, and her contribution becomes part of MapKnitter!

A few notes - some git best practices that will make all of our lives easier:

• Remember to pull from master before you start working. This helps keep your local repository in sync with the code that everyone else is working on.
• Always do development in a feature branch. This makes it much easier for project maintainers to merge your contributions into the trunk. The name of your branch is displayed when it is merged in to the main trunk, which means that it serves as built-in documentation for your feature. This works great when you give your feature branches descriptive names! Some example branch names:
  • donation-button-redesign
  • markdown-package-update
  • fix#44 (fixes GitHub issue #44 in this repository)
• Open a pull request early! In fact, feel free to open a pull request as soon as you start working on a new feature or bugfix. GitHub's pull request pages make it easy to see progress that's been made on an issue, and it's a great way to start an open and ongoing discussion with the project's maintainers and other contributors about your work.

Contributing to Ruby projects

Contributing to JavaScript projects

Public Lab Software

Public Lab welcomes and encourages community contributions to our open source software!

This page is intended to:

1. List software projects that Public Lab has incubated and provide links to source code.
2. Collect software development guidelines and best practices for Public Lab projects.
3. Help newcomers figure out how and where to start contributing!

Getting started

For an excellent overview of contributing to open source projects in general, check out How to contribute to an open source project on Github.

Quick tips for getting involved with the Public Lab codebases:

1. Set up a GitHub account and install git.

   If you're not familiar with git, a popular version control software, you can try it out at https://try.github.io.

   Speaking of GitHub...right now, all of Public Lab's open source code is located on GitHub, a website which hosts git repositories. Setting up a GitHub account is the first step to getting involved with Public Lab's code (and lots of other code).

2. Join the Public Lab developers mailing list

Contribution Guidelines

Public Lab software is written in many languages, and each project may have its own guidelines for contributors. These broad guidelines should serve as general principles to guide your approach to a new Public Lab codebase.

Contributing using git

Check out this article on GitHub flow, a routine that works great on all git projects and makes Public Lab development super smooth.

A sample git workflow

Let's say that a developer and PublicLab community member named Susan decides that she wants to add a feature to MapKnitter. Here's what Susan's workflow might look like:

1. Susan forks the publiclab/mapknitter repo on GitHub.
2. Susan clones the forked repository susan/mapknitter. This downloads a copy of Susan's version of mapknitter to her computer.
3. She creates a branch for the new feature (a feature branch). Let's say that Susan wanted users to be able to tag maps. She might then create and checkout a new branch called add-map-tags with: git checkout -b add-map-tags.
4. Susan develops the new feature in the add-map-tags feature branch.
5. When Susan is done developing the new feature, she switches back to the master branch of her own repository: git checkout master, and then pulls the latest version of mapknitter down from the publiclab repo with git pull publiclab master.
6. Susan applies her new feature on top of the latest version of mapknitter: From the add-map-tags branch, she runs git rebase master. This is the great strength of doing development in a feature branch - it allows Susan to merge her changes into the latest public version of mapknitter on her own computer and to resolve any conflicts locally. Back in master (git checkout master), Susan runs git merge add-map-tags --ff-only to bring her master branch up to date.
7. After rebasing, Susan's local master branch contains the latest version of mapknitter with her new feature added on top. The new feature is ready, so Susan submits a pull request on GitHub.
8. Susan discusses her code with others. After any questions or change requests have been resolved, Susan's request is merged in, and her contribution becomes part of MapKnitter!

A few notes - some git best practices that will make all of our lives easier:

• Remember to pull from master before you start working. This helps keep your local repository in sync with the code that everyone else is working on.
• Always do development in a feature branch. This makes it much easier for project maintainers to merge your contributions into the trunk. The name of your branch is displayed when it is merged in to the main trunk, which means that it serves as built-in documentation for your feature. This works great when you give your feature branches descriptive names! Some example branch names:
  • donation-button-redesign
  • markdown-package-update
  • fix#44 (fixes GitHub issue #44 in this repository)
• Open a pull request early! In fact, feel free to open a pull request as soon as you start working on a new feature or bugfix. GitHub's pull request pages make it easy to see progress that's been made on an issue, and it's a great way to start an open and ongoing discussion with the project's maintainers and other contributors about your work.

Contributing to Ruby projects

Contributing to JavaScript projects

Public Lab Software

Public Lab welcomes and encourages community contributions to our open source software!

This page is intended to:

1. List software projects that Public Lab has incubated and provide links to source code.
2. Collect software development guidelines and best practices for Public Lab projects.
3. Help newcomers figure out how and where to start contributing!

Getting started

Quick tips for getting involved with the Public Lab codebases:

1. Set up a GitHub account and install git.

   If you're not familiar with git, a popular version control software, you can try it out at https://try.github.io.

   Speaking of GitHub...right now, all of Public Lab's open source code is located on GitHub, a website which hosts git repositories. Setting up a GitHub account is the first step to getting involved with Public Lab's code (and lots of other code).

2. Join the Public Lab developers mailing list

Contribution Guidelines

Public Lab software is written in many languages, and each project may have its own guidelines for contributors. These broad guidelines should serve as general principles to guide your approach to a new Public Lab codebase.

Contributing using git

Check out this article on GitHub flow, a routine that works great on all git projects and makes Public Lab development super smooth.

A sample git workflow

Let's say that a developer and PublicLab community member named Susan decides that she wants to add a feature to MapKnitter. Here's what Susan's workflow might look like:

1. Susan forks the publiclab/mapknitter repo on GitHub.
2. Susan clones the forked repository susan/mapknitter. This downloads a copy of Susan's version of mapknitter to her computer.
3. She creates a branch for the new feature (a feature branch). Let's say that Susan wanted users to be able to tag maps. She might then create and checkout a new branch called add-map-tags with: git checkout -b add-map-tags.
4. Susan develops the new feature in the add-map-tags feature branch.
5. When Susan is done developing the new feature, she switches back to the master branch of her own repository: git checkout master, and then pulls the latest version of mapknitter down from the publiclab repo with git pull publiclab master.
6. Susan applies her new feature on top of the latest version of mapknitter: From the add-map-tags branch, she runs git rebase master. This is the great strength of doing development in a feature branch - it allows Susan to merge her changes into the latest public version of mapknitter on her own computer and to resolve any conflicts locally. Back in master (git checkout master), Susan runs git merge add-map-tags --ff-only to bring her master branch up to date.
7. After rebasing, Susan's local master branch contains the latest version of mapknitter with her new feature added on top. The new feature is ready, so Susan submits a pull request on GitHub.
8. Susan discusses her code with others. After any questions or change requests have been resolved, Susan's request is merged in, and her contribution becomes part of MapKnitter!

A few notes - some git best practices that will make all of our lives easier:

• Remember to pull from master before you start working. This helps keep your local repository in sync with the code that everyone else is working on.
• Always do development in a feature branch. This makes it much easier for project maintainers to merge your contributions into the trunk. The name of your branch is displayed when it is merged in to the main trunk, which means that it serves as built-in documentation for your feature. This works great when you give your feature branches descriptive names! Some example branch names:
  • donation-button-redesign
  • markdown-package-update
  • fix#44 (fixes GitHub issue #44 in this repository)
• Open a pull request early! In fact, feel free to open a pull request as soon as you start working on a new feature or bugfix. GitHub's pull request pages make it easy to see progress that's been made on an issue, and it's a great way to start an open and ongoing discussion with the project's maintainers and other contributors about your work.

Contributing to Ruby projects

Contributing to JavaScript projects

Public Lab Software

Public Lab welcomes and encourages community contributions to our open source software!

This page is intended to:

1. List software projects that Public Lab has incubated and provide links to source code.
2. Collect software development guidelines and best practices for Public Lab projects.
3. Help newcomers figure out how and where to start contributing!

Getting started

Quick tips for getting involved with the Public Lab codebases:

1. Set up a GitHub account and install git.

   If you're not familiar with git, a popular version control software, you can try it out at https://try.github.io.

   Speaking of GitHub...right now, all of Public Lab's open source code is located on GitHub, a website which hosts git repositories. Setting up a GitHub account is the first step to getting involved with Public Lab's code (and lots of other code).

2. Join the Public Lab developers mailing list

Contribution Guidelines

Public Lab software is written in many languages, and each project may have its own guidelines for contributors. These broad guidelines should serve as general principles to guide your approach to a new Public Lab codebase.

Contributing using git

Check out this article on GitHub flow, a routine that works great on all git projects and makes Public Lab development super smooth.

A sample git workflow

Let's say that a developer and PublicLab community member named Susan decides that she wants to add a feature to MapKnitter. Here's what Susan's workflow might look like:

1. Susan forks the publiclab/mapknitter repo on GitHub.
2. Susan clones the forked repository susan/mapknitter. This downloads a copy of Susan's version of mapknitter to her computer.
3. She creates a branch for the new feature (a feature branch). Let's say that Susan wanted users to be able to tag maps. She might then create and checkout a new branch called add-map-tags with: git checkout -b add-map-tags.
4. Susan develops the new feature in the add-map-tags feature branch.
5. When Susan is done developing the new feature, she switches back to the master branch of her own repository: git checkout master, and then pulls the latest version of mapknitter down from the publiclab repo with git pull publiclab master.
6. Susan applies her new feature on top of the latest version of mapknitter: git rebase add-map-tags --onto master. This is the great strength of doing development in a feature branch - it allows Susan to merge her changes into the latest public version of mapknitter on her own computer and to resolve any conflicts locally..
7. After rebasing, Susan's local master branch contains the latest version of mapknitter with her new feature added on top. The new feature is ready, so Susan submits a pull request on GitHub.
8. Susan discusses her code with others. After any questions or change requests have been resolved, Susan's request is merged in, and her contribution becomes part of MapKnitter!

A few notes - some git best practices that will make all of our lives easier:

• Remember to pull from master before you start working. This helps keep your local repository in sync with the code that everyone else is working on.
• Always do development in a feature branch. This makes it much easier for project maintainers to merge your contributions into the trunk. The name of your branch is displayed when it is merged in to the main trunk, which means that it serves as built-in documentation for your feature. This works great when you give your feature branches descriptive names! Some example branch names:
  • donation-button-redesign
  • markdown-package-update
  • fix#44 (fixes GitHub issue #44 in this repository)
• Open a pull request early! In fact, feel free to open a pull request as soon as you start working on a new feature or bugfix. GitHub's pull request pages make it easy to see progress that's been made on an issue, and it's a great way to start an open and ongoing discussion with the project's maintainers and other contributors about your work.

Contributing to Ruby projects

Contributing to JavaScript projects

Public Lab Software

Public Lab welcomes and encourages community contributions to our open source software!

This page is intended to:

1. List software projects that Public Lab has incubated and provide links to source code.
2. Collect software development guidelines and best practices for Public Lab projects.
3. Help newcomers figure out how and where to start contributing!

Getting started

Quick tips for getting involved with the Public Lab codebases:

1. Set up a GitHub account and install git.

   If you're not familiar with git, a popular version control software, you can try it out at https://try.github.io.

   Speaking of GitHub...right now, all of Public Lab's open source code is located on GitHub, a website which hosts git repositories. Setting up a GitHub account is the first step to getting involved with Public Lab's code (and lots of other code).

2. Join the Public Lab developers mailing list

Contribution Guidelines

Public Lab software is written in many languages, and each project may have its own guidelines for contributors. These broad guidelines should serve as general principles to guide your approach to a new Public Lab codebase.

Contributing using git

Check out this article on GitHub flow, a routine that works great on all git projects and makes Public Lab development super smooth.

A sample git workflow

Let's say that a developer and PublicLab community member named Susan decides that she wants to add a feature to MapKnitter. Here's what Susan's workflow might look like:

1. Susan forks the publiclab/mapknitter repo on GitHub.
2. Susan clones the forked repository susan/mapknitter. This downloads a copy of Susan's version of mapknitter to her computer.
3. She creates a branch for the new feature (a feature branch). Let's say that Susan wanted users to be able to tag maps. She might then create and checkout a new branch called add-map-tags with: git checkout -b add-map-tags.
4. Susan develops the new feature in the add-map-tags feature branch.
5. When Susan is done developing the new feature, she switches back to the master branch of her own repository: git checkout master, and then pulls the latest version of mapknitter down from the publiclab repo with git pull publiclab master.
6. Susan applies her new feature on top of the latest version of mapknitter: git rebase add-map-tags --onto master. This is the great strength of doing development in a feature branch - it allows Susan to merge her changes into the latest public version of mapknitter on her own computer and to resolve any conflicts locally..
7. After rebasing, Susan's local master branch contains the latest version of mapknitter with her new feature added on top. The new feature is ready, so Susan submits a pull request on GitHub.
8. Susan discusses her code with others. After any questions or change requests have been resolved, Susan's request is merged in, and her contribution becomes part of MapKnitter!

A few notes - some git best practices that will make all of our lives easier:

• Remember to pull from master before you start working. This helps keep your local repository in sync with the code that everyone else is working on.
• Always do development in a feature branch. This makes it much easier for project maintainers to merge your contributions into the trunk. The name of your branch is displayed when it is merged in to the main trunk, which means that it serves as built-in documentation for your feature. This works great when you give your feature branches descriptive names! Some example branch names:
  • donation-button-redesign
  • markdown-package-update
  • fix#44 (fixes GitHub issue #44 in this repository)
• Open a pull request early! In fact, feel free to open a pull request as soon as you start working on a new feature or bugfix. GitHub's pull request pages make it easy to see progress that's been made on an issue, and it's a great way to start an open and ongoing discussion with the project's maintainers and other contributors about your work.

Contributing to Ruby projects

Contributing to JavaScript projects

Public Lab Software

Public Lab welcomes and encourages community contributions to our open source software!

This page is intended to:

1. List software projects that Public Lab has incubated and provide links to source code.
2. Collect software development guidelines and best practices for Public Lab projects.
3. Help newcomers figure out how and where to start contributing!

Getting started

Quick tips for getting involved with the Public Lab codebases:

1. Set up a GitHub account and install git.

   If you're not familiar with git, a popular version control software, you can try it out at https://try.github.io.

   Speaking of GitHub...right now, all of Public Lab's open source code is located on GitHub, a website which hosts git repositories. Setting up a GitHub account is the first step to getting involved with Public Lab's code (and lots of other code).

2. Join the Public Lab developers mailing list

Contribution Guidelines

Public Lab software is written in many languages, and each project may have its own guidelines for contributors. These broad guidelines should serve as general principles to guide your approach to a new Public Lab codebase.

Contributing using git

Check out this article on GitHub flow, a routine that works great on all git projects and makes Public Lab development super smooth.

A sample git workflow

Let's say that a developer and PublicLab community member named Susan decides that she wants to add a feature to MapKnitter. Here's what Susan's workflow might look like:

1. Susan forks the publiclab/mapknitter repo on GitHub.
2. Susan clones the forked repository susan/mapknitter. This downloads a copy of Susan's version of mapknitter to her computer.
3. She creates a branch for the new feature (a feature branch). Let's say that Susan wanted users to be able to tag maps. She might then create and checkout a new branch called add-map-tags with: git checkout -b add-map-tags.
4. Susan develops the new feature in the add-map-tags feature branch.
5. When Susan is done developing the new feature, she switches back to the master branch of her own repository: git checkout master, and then pulls the latest version of mapknitter down from the publiclab repo with git pull publiclab master.
6. Susan applies her new feature on top of the latest version of mapknitter: git rebase add-map-tags --onto master. This is the great strength of doing development in a feature branch - it allows Susan to merge her changes into the latest public version of mapknitter on her own computer and to resolve any conflicts locally..
7. After rebasing, Susan's local master branch contains the latest version of mapknitter with her new feature added on top. The new feature is ready, so Susan submits a pull request on GitHub.
8. Susan discusses her code with others. After any questions or change requests have been resolved, Susan's request is merged in, and her contribution becomes part of MapKnitter!

A few notes - some git best practices that will make all of our lives easier:

• Remember to pull from master before you start working. This helps keep your local repository in sync with the code that everyone else is working on.
• Always do development in a feature branch. This makes it much easier for project maintainers to merge your contributions into the trunk. The name of your branch is displayed when it is merged in to the main trunk, which means that it serves as built-in documentation for your feature. This works great when you give your feature branches descriptive names! Some example branch names:
  • donation-button-redesign
  • markdown-package-update
  • fix#44 (fixes GitHub issue #44 in this repository)
• Open a pull request early! In fact, feel free to open a pull request as soon as you start working on a new feature or bugfix. GitHub's pull request pages make it easy to see progress that's been made on an issue, and it's a great way to start an open and ongoing discussion with the project's maintainers and other contributors about your work.

Contributing to Ruby projects

Contributing to JavaScript projects

Public Lab Software

Public Lab welcomes and encourages community contributions to our open source software!

This page is intended to:

1. List software projects that Public Lab has incubated and provide links to source code.
2. Collect software development guidelines and best practices for Public Lab projects.
3. Help newcomers figure out how and where to start contributing!

Getting started

Quick tips for getting involved with the Public Lab codebases:

1. Set up a GitHub account and install git.

   If you're not familiar with git, a popular version control software, you can try it out at https://try.github.io.

   Speaking of GitHub...right now, all of Public Lab's open source code is located on GitHub, a website which hosts git repositories. Setting up a GitHub account is the first step to getting involved with Public Lab's code (and lots of other code).

2. Join the Public Lab developers mailing list

Contribution Guidelines

Public Lab software is written in many languages, and each project may have its own guidelines for contributors. These broad guidelines should serve as general principles to guide your approach to a new Public Lab codebase.

Contributing using git

Check out this article on GitHub flow, a routine that works great on all git projects and makes Public Lab development super smooth.

A sample git workflow

Let's say that a developer and PublicLab community member named Susan decides that she wants to add a feature to MapKnitter. Here's what Susan's workflow might look like:

1. Susan forks the publiclab/mapknitter repo.
2. Susan clones the forked repository susan/mapknitter. This downloads a copy of Susan's version of mapknitter to her computer.
3. She creates a branch for the new feature (a feature branch). Let's say that Susan wanted users to be able to tag maps. She might then create and checkout a new branch called add-map-tags with: git checkout -b add-map-tags.
4. Susan develops the new feature in the add-map-tags feature branch.
5. When Susan is done developing the new feature, she switches back to the master branch of her own repository: git checkout master, and then pulls the latest version of mapknitter down from the publiclab repo with git pull publiclab master.
6. Susan applies her new feature on top of the latest version of mapknitter: git rebase add-map-tags --onto master. This is the great strength of doing development in a feature branch - it allows Susan to merge her changes into the latest public version of mapknitter on her own computer and to resolve any conflicts locally..
7. After rebasing, Susan's local master branch contains the latest version of mapknitter with her new feature added on top. The new feature is ready, so Susan submits a pull request on GitHub.
8. Susan discusses her code with others. After any questions or change requests have been resolved, Susan's request is merged in, and her contribution becomes part of MapKnitter!

A few notes - some git best practices that will make all of our lives easier:

• Remember to pull from master before you start working. This helps keep your local repository in sync with the code that everyone else is working on.
• Always do development in a feature branch. This makes it much easier for project maintainers to merge your contributions into the trunk. The name of your branch is displayed when it is merged in to the main trunk, which means that it serves as built-in documentation for your feature. This works great when you give your feature branches descriptive names! Some example branch names:
  • donation-button-redesign
  • markdown-package-update
  • fix#44 (fixes GitHub issue #44 in this repository)
• Open a pull request early! In fact, feel free to open a pull request as soon as you start working on a new feature or bugfix. GitHub's pull request pages make it easy to see progress that's been made on an issue, and it's a great way to start an open and ongoing discussion with the project's maintainers and other contributors about your work.

Contributing to Ruby projects

Contributing to JavaScript projects

Public Lab Software

Public Lab welcomes and encourages community contributions to our open source software!

This page is intended to:

1. List software projects that Public Lab has incubated and provide links to source code.
2. Collect software development guidelines and best practices for Public Lab projects.
3. Help newcomers figure out how and where to start contributing!

Getting started

Quick tips for getting involved with the Public Lab codebases:

1. Set up a GitHub account and install git.

   If you're not familiar with git, a popular version control software, you can try it out at https://try.github.io.

   Speaking of GitHub...right now, all of Public Lab's open source code is located on GitHub, a website which hosts git repositories. Setting up a GitHub account is the first step to getting involved with Public Lab's code (and lots of other code).

2. Join the Public Lab developers mailing list

Contribution Guidelines

Public Lab software is written in many languages, and each project may have its own guidelines for contributors. These broad guidelines should serve as general principles to guide your approach to a new Public Lab codebase.

Contributing using git

Check out this article on GitHub flow, a routine that works great on all git projects and makes Public Lab development super smooth.

A sample git workflow

Let's say that a developer and PublicLab community member named Susan decides that she wants to add a feature to MapKnitter. Here's what Susan's workflow might look like:

1. Fork the publiclab/mapknitter repo.
2. Clone the forked repository susan/mapknitter. This downloads a copy of Susan's version of mapknitter to her computer.
3. Create a branch for the new feature (a feature branch). Let's say that Susan wanted users to be able to tag maps. She might then create and checkout a new branch called add-map-tags with: git checkout -b add-map-tags.
4. Develop the new feature in the add-map-tags feature branch.
5. When Susan is done developing the new feature, she switches back to the master branch of her own repository: git checkout master, and then pulls the latest version of mapknitter down from the publiclab repo with git pull publiclab master.
6. Susan applies her new feature on top of the latest version of mapknitter: git rebase add-map-tags --onto master. This is the great strength of doing development in a feature branch - it allows Susan to merge her changes into the latest public version of mapknitter on her own computer and to resolve any conflicts locally..
7. After rebasing, Susan's local master branch contains the latest version of mapknitter with her new feature added on top. The new feature is ready, so Susan submits a pull request on GitHub.
8. Susan discusses her code with others. After any questions or change requests have been resolved, Susan's request is merged in, and her contribution becomes part of MapKnitter!

A few notes - some git best practices that will make all of our lives easier:

• Remember to pull from master before you start working. This helps keep your local repository in sync with the code that everyone else is working on.
• Always do development in a feature branch. This makes it much easier for project maintainers to merge your contributions into the trunk. The name of your branch is displayed when it is merged in to the main trunk, which means that it serves as built-in documentation for your feature. This works great when you give your feature branches descriptive names! Some example branch names:
  • donation-button-redesign
  • markdown-package-update
  • fix#44 (fixes GitHub issue #44 in this repository)
• Open a pull request early! In fact, feel free to open a pull request as soon as you start working on a new feature or bugfix. GitHub's pull request pages make it easy to see progress that's been made on an issue, and it's a great way to start an open and ongoing discussion with the project's maintainers and other contributors about your work.

Contributing to Ruby projects

Contributing to JavaScript projects

Public Lab Software

Public Lab welcomes and encourages community contributions to our open source software!

This page is intended to:

1. List software projects that Public Lab has incubated and provide links to source code.
2. Collect software development guidelines and best practices for Public Lab projects.
3. Help newcomers figure out how and where to start contributing!

Getting started

Quick tips for getting involved with the Public Lab codebases:

1. Set up a GitHub account and install git.

   If you're not familiar with git, a popular version control software, you can try it out at https://try.github.io.

   Speaking of GitHub...right now, all of Public Lab's open source code is located on GitHub, a website which hosts git repositories. Setting up a GitHub account is the first step to getting involved with Public Lab's code (and lots of other code).

2. Join the Public Lab developers mailing list

Contribution Guidelines

Public Lab software is written in many languages, and each project may have its own guidelines for contributors. These broad guidelines should serve as general principles to guide your approach to a new Public Lab codebase.

Contributing using git

Check out this article on GitHub flow, a routine that works great on all git projects and makes Public Lab development super smooth. For example, let's say that a developer and PublicLab community member named Susan decides that she wants to add a feature to MapKnitter. Here's what Susan's workflow might look like:

1. Fork the publiclab/mapknitter repo.
2. Clone the forked repository susan/mapknitter. This downloads a copy of Susan's version of mapknitter to her computer.
3. Create a branch for the new feature (a feature branch). Let's say that Susan wanted users to be able to tag maps. She might then create and checkout a new branch called add-map-tags with: git checkout -b add-map-tags.
4. Develop the new feature in the add-map-tags feature branch.
5. When Susan is done developing the new feature, she switches back to the master branch of her own repository: git checkout master, and then pulls the latest version of mapknitter down from the publiclab repo with git pull publiclab master.
6. Susan applies her new feature on top of the latest version of mapknitter: git rebase add-map-tags --onto master. This is the great strength of doing development in a feature branch - it allows Susan to merge her changes into the latest public version of mapknitter on her own computer and to resolve any conflicts locally..
7. After rebasing, Susan's local master branch contains the latest version of mapknitter with her new feature added on top. The new feature is ready, so Susan submits a pull request on GitHub.
8. Susan discusses her code with others. After any questions or change requests have been resolved, Susan's request is merged in, and her contribution becomes part of MapKnitter!

A few notes - some git best practices that will make all of our lives easier:

• Remember to pull from master before you start working. This helps keep your local repository in sync with the code that everyone else is working on.
• Always do development in a feature branch. This makes it much easier for project maintainers to merge your contributions into the trunk. The name of your branch is displayed when it is merged in to the main trunk, which means that it serves as built-in documentation for your feature. This works great when you give your feature branches descriptive names! Some example branch names:
  • donation-button-redesign
  • markdown-package-update
  • fix#44 (fixes GitHub issue #44 in this repository)
• Open a pull request early! In fact, feel free to open a pull request as soon as you start working on a new feature or bugfix. GitHub's pull request pages make it easy to see progress that's been made on an issue, and it's a great way to start an open and ongoing discussion with the project's maintainers and other contributors about your work.

Contributing to Ruby projects

Contributing to JavaScript projects

Public Lab Software