# Version Control/Public-Private-Versioning

The concept of Public-Private-Versioning combines
* a private branch (READ-ONLY) as a quality assured reference with
* one or many public branches (READ & WRITE) that can be altered by a community for adaptation to different requirements and constraints.
Public and private branches
* refer to each other
* share the same licencing model (so that mutal update and improvements are allowed) and
* share a joint evolutionary time line (that is visible in the private branch.

## Development Branches

In the evolution of digital content new versions of the content is generated by:
* removal of errors,
* adding new content elements,
* adapting the content to new requirements and constraints or
    e.g. new scientific or technical knowledge, that requires the update of the digital content.

### Main Types of Branches

The concept of Public-Private-Versioning (PPV) handles two main development branches for content:
* Private Development Branch (PrivB): represents a quality assured development branch by an institution.
* Public Development Branch (PubB): captures the community activities and open to public to read and contribute to the evolution of the content.

### Mutual Update of Main Branches

Update workflow from PrivB to PubB can be driven by new scientific results or recent technical development that requires an update of the public branch. Other update can be driven by quality assurance issues, in which the private branch authors act like any other community reviewers. If a special expertise in a certain topic is present the team of author could act like a Wiki Curators or Custodian,
Major improvement of the Public Branch (PubB) could lead to an update from PubB to PrivB. So innovation driven by open community has an impact on releases of PubB. Proper acknowledgement of community contributions are a compulsory part of an PubB to PrivB workflow.

## Objectives of Learning Resource

This learning resoure introduces to
* the concept of digital version control,
* the relevance of public and private development strains for the freedom of content evolution and trust in certain releases/versions because they were quality assured from a certain institution or agency.

## Version Control
### Wikiversity/Wikipedia and Version Control

In Wikiversity the software MediaWiki is used to manage the versions of articles.

### Non-Digital Version Control

Artists that create new versions of painting until the results satisfies his expectation about the composition and colors or the artist explore different light settings in many versions (see Paul Cezanne and the Hill Mont Saint Victoire ). The books have an enumeration of versions. New release are created for book editions, when new chapters are inserted or errors are removed. Especially technical standards change in time, so non-digital versions of handbooks are created in the non-digital times. The use of Information Systems transfered the publication workflows into a digital environment.

### Digital Version Control

Version/revision control allows
* checkout of current and old versions of digital media,
* branching of development,
* merging of different branches of development into a join branches (fork),
* discuss features and versions,
* create releases,
These concepts (see WIkipedia:revision control) can be applied on
* Software (Origine of Version Control Software),
* Text or
* digital media in general
Effective management and visualization of differences between versions is important especially for text documents in a non-binary format.

## Private Versioning

Private versioning are performed by a group of authors that
* allow public read access to the repository and
* write access is limited to the group of authors (e.g. working group in an agency like WHO).

### Private Version Control

trust in capacity building material is mainly the trust of prospective users in the quality assurance of the group of authors.

#### GitHub or GitLab used for Wikiversity Content

Private versioning can be realized e.g. in GitHub, GitLab, ... or any other version control system that allows public read-only access and write access to a team, that assures the quality of selected versions. Version control concept provides transparency for
* Who created, altered,
* what,
* when?
Just like a MediaWiki is allows a version control of content (e.g. wiki source content). Furthermore is allows different development strains/branches that can be merged or developed seperately and independently for different target groups of settings in which the content should be applied. Forking (create a new development branch) is possible but the quality assured version can be updated by the team members only.
The management of versions is more complicated due the available features than the version control in the MediaWiki (handle just one developement strain for a resouce). Nevertheless branching can be created by copy-and-paste in new Wikiversity resources.
GitHub, Bitbucket and co. can be used if a group authors want a transparent version control for the content, but do not want or do not have the capacity to setup their own git-Server infrastructure for version control.

#### Official Web-Portals for Quality Assured Content

It is not necessary that the quality assured versions are stored in GitHub as technical solution. Quality assured Capacity Building material can be published by an organization on the web portal e.g. WHO or UN-SPIDER. In turn public available resources need a OER license, so that the capacity building material can be adapted to local and regional requirements and constraints.

### Select Private or Public version?

If prospective users trust in a group of authors, organization or academic institution they might decide to use the latest quality assured version in the private versioning system in GitLab or the provided institutional versions instead the lasted version in Wikiversity. In general the public versions with community permissions to write or edit the data have included the latest information and changes, but the latest alteration in the version might not be quality assured already.
A public version might incorporate the latest scientific development or latest events in the learning resource. A general decision in favor or against the public or private version cannot be made. The decision is user-driven and dependent on the preferences and priority the user defines. Furthermore it is dependent on the trust a user has in the organization or individuals that provide the quality assured version.
Therefore references in the wikiversity content to quality assured private version or organizations are recommended to be inserted in the learning resource, if they exist. This can be applicable to Wikipedia and other Wiki products as well. It is important that the user can
* decide if wants use the lastest private or public version and
* is able to validate, that the resource is maintained by the group of authors. Trust can be supported by technical approaches like digital signature.

## Learning Task

* (Introduction) Learn about "Version Control" with an Github Example Youtube Video
* (Create a Repository) Create a private Online Repository (e.g. in BitBucket) Youtube Video
* (Work with Versioning in Teams) select an article in Wikiversity of your choice and add the file to your private repository. For learning purpose use version control system at your school or institution if possible. If not use e.g. BitBucket with free acount for a small team with has not more than 5 team members. Create a joint article or a school project jointly in your small team. It is recommended to use version control system at your school or institution if possible, that allows free private versions, because beginners do not want to expose their work and experiments to the public.
* (Create Versions in different Output Formats) Learn about PanDoc and about PanDocElectron to convert the Wikiversity content to other formats.
* (From update Data to new Versions of Documents) Learn about KnitR for dynamic content generation
* Explore the concept for KnitR working with markdown an analyse possibilities to integrate KnitR in Wikiversity. Combine a versioned
** data resource
** script resource integrated directly in wiki language or versioned separately (PrivB) in GitHub, Bitbucket or other institutional versioning systems, that already exist. For Wikiversity a version system must be established for R-script too, to have a public development branch for the scripts to. Furthermore an R-backend for Wikiversity is necessary so that graphs are not integrated as images but as dynamic graph output of R.
** text resource i.e. the source text of any article or learning resource in Wikiversity or Wikipedia.
* (Trust in Private Versions) Explore the document about the Original Research in Wikiversity. What are similarities between that document and a general approach of public-private-versioning and how does the individual trust in an author/instution affect the application of learning resource in an educational setting?
* (Vesion Identification across different Repositories)Compare Wikipedia and Scholarpedia and identify the role of public-private-versioning. What is missing to link public and private development branches? How could an Information System for authors be designed, that supports a cross domain development of branches, version and releases?
* (DOI-Document Object Identifier) Explain, what is a Document Object Index (DOI) as unique identifier for digital objects and how DOIs are issued! Describe how a DOI can be used for versions. Explain similaries and differences between DOIs and a primary key in a database.
Comment: Google places advertisments before the video. Please replace the video links above with Wikiversity videos as soon as they are available. This comment can be removed as soon as the wiki community has creative commons learning videos as available resources as advetisment independent learning resources. Wikiversity or the wiki-community does not get any financial resources for linking the videos mentioned above.