Skip to content

Latest commit

 

History

History
35 lines (27 loc) · 2.56 KB

forking.md

File metadata and controls

35 lines (27 loc) · 2.56 KB
Raw

Forking

A fork is a copy of a project. Forking a project allows you to experiment with changes without affecting the original project. Forks are commonly used to propose changes to someone else's project or to use someone else's project as a starting point for your own.

Creating a fork

To fork a public project, click the menu in the upper left corner of the map and then click fork project (). This will:

  • Create a copy ("fork") of the entire project, including all views, maps and presentations
  • The fork will be created under your personal account with the same name as the original project
  • Only you will have access initially to the fork (but you can add other collaborators as needed)
  • All presentations in the fork revert to unpublished (even if they were published in the original)
  • Any links in the project will remain the same (so make sure to use relative links to have a fork-friendly project)

While public projects can be forked by anyone, private projects can only be forked by their owners.

If you would like to make a fork of a private project you don't own, follow these steps:

  1. Have the project owner make their own fork of the project.
  2. Have the project owner use the project admin menu to transfer the project to your account.

Intellectual property and forking

By giving others access to your project on Kumu, you agree to let them fork the project. This does not grant any rights beyond creating the initial fork.

To make it clear what others are permitted to do with your project, we encourage each project to include a license at the bottom of the default map's description. The license you use is up to you, but we hope many of you choose to share your projects generously with the community. We've released a new license called the Kokua License to make that even easier.

The future of forking

The ability to create a copy of a project is just the first step towards a more robust collaboration model. In the future, you'll be able to propose changes back to the original project owner based on work completed in your fork (hence why we've used the term "fork" instead of copy, duplicate, clone, etc.).

edit this page