# Glossary

This glossary is intended to define the terminology used in Git Consensus.

Some of these terms may mirror established definitions in Open-Source Software, Git, and Ethereum ecosystems. Other terms may be used highlight the concepts that are used in Git Consensus specifically.

# Git Consensus

# Onboarding

The process of going from traditional project governance to Git Consensus governance.

This involves a one-time step of deploying a per-project Token and Governor contract pair. For details on this process see the onboarding Getting Started guide.

# Distribution

The token balance rewards to distribute. It is represented as the combination of a hashes/owner array and values array.

When used as an argument in a call to GitConsensus addRelease(tagData, hashes[], values[]), this will be an array of commit hashes hashes[] and an array of token balances to be given to each commit hash owner values[]. This allows the commits that are part of a release to be rewarded with different amounts.

When used as an argument in a call to TokenFactory createToken(..., owners[], values[], ...), this will be an array of addresses owners[] and an array of token balances to be given to each owner values[]. This allows an initial ownership distribution to be given to the existing project maintainers during project onboarding.

# Stakeholder

The catch-all term for anyone who has ownership in a project using Git Consensus. Instead of the traditional maintainer and contributor roles, Git Consensus allows the boundary between these roles to be removed with a variable amount of ownership.

Since ownership is represented with a token balance, anyone with a project token balanceOf() > 0 is considered a stakeholder.

# Open-Source

The terms relating to Open-Source may be generalized or simplified, because no strict standard for how participants come together to work on projects exist. The problem Git Consensus attempts to solve is not specific to one platform or pattern of behavior.

Working in Public: The Making and Maintenance of Open Source Software gives an overview about the different patterns that exist, with observations on communities seen on GitHub. It dedicates an entire chapter just addressing undefined user groups and usage patterns, and this documentation will be based off that.

# Project

A collaborative group that develops software to achieve a particular aim. One project may relate to multiple git repositories.

This structure may take the form of a Github Organization, where the same ownership applies across a wide range of related repositories.

An example project would be the NodeJS organization, which develops nodejs/node, nodejs/node-gyp, nodejs/llhttp, and many others. If this project was onboarded to Git Consensus, a user's NODE token balance would represent the voting power for these repositories.

# Governance

The variety of entities that can govern over a project. Governing tasks may include management of repositories, creation of releases, merging of PRs, etc.

Git Consensus converts the governance structure of a projects to be transparent, open, and trustless. With it's token reward mechanisms, governance can become completely distributed amongst any number of entities.

To achieve this for every project, Git Consensus makes use of the Ethereum blockchain standard of Token and Governor contracts.

# Maintainer

The established OSS role for someone who is responsible for guiding over the direction of the project. They usually have the highest level of privileges in the project's repositories. A maintainer is inherently a contributor to the project.

Another term for this role is Owner, which may be seen as a separate role just to refer to the elevated privileges without the guidance. For simplicity, these terms will be used synonymously.

Git Consensus allows the the hard boundary between maintainers and contributors to be removed by creating a path for maintainers to continuously distribute ownership of the project.

# Contributor

The established OSS role for someone who provides value to the project. This may in the form of writing code, reviewing code, opening issues, closing issues, responding to questions, moderating discussions, and much more.

Although contributors may promote the health of a project in a variety of ways, Git Consensus specifically target giving rewards for the writing/merging of code. These are due to technical reasons: only a commit can make a secure contribution -> wallet address mapping.

To get around the lack of support for non-commit based contributions, you may try to write this into the repository. For example, if you wanted to reward contributors for answering questions:

maintain a file in your repository ANSWERED.md
update this line every time a question is answered

This will create a commit, which is compatible with Git Consensus contracts (and may receive rewards).

Git Consensus allows the the hard boundary between maintainers and contributors to be removed by creating a path for maintainers to continuously distribute ownership of the project.

# Git

Git is a popular tool for software development and Open-Source in particular. Unlike the version control systems the came before it (Subversion, CVS), Git is a distributed VCS.

The specific internals of Git are not necassary to understand to use Git Consensus. You continue to develop software the same way you normally would, with small modifications to how you would write your commit and tag messages.

# Commit

Commits can be thought of as snapshots or milestones along the timeline of a Git project. Commits are created with the git commit command to capture the state of a project at that point in time.


Contents of a commit, with the generated SHA-1 hash in blue

Any code changes you write will be reflected the tree, and the previous commit that your changes are adding to reference the parent commit. In other words, the code you authored can be represented by this commit object.

Git Consensus utilizes the property that not just the code written is SHA-1'd but also the message. Any change in the message (e.g. amending commit with someone elses address) generates a new hash.


Embedding an address in the commit message creates a secure mapping between them.

To set up and your Ethereum address and make this address embedding automatic, see the Getting Started guide.

# Tag

Tags are references (refs) that point to specific commits in the git repository history. They are created with the git tag command.

In the process of tagging, you can choose to created either a lightweight and annotated. Only annotated tags are stored as full objects, and need to be used when creating releases with Git Consensus.


Tag with an address embedded in the `message`.

Git Consensus utilizes the that changes message to the method alter the generated SHA-1 hash (in blue). This creates a secure tag hash -> address mapping between them.

When creating tags, the embedded address should be the project's Token address. For more information on the creating tags that can go through the release process, see the release guide.

# Release

Although not technically a Git primitive, release is a term to package software and indicate that it is ready to be used. It is based on a specific tag.

In the Git Consensus release process, you reference a tag that you want to add on-chain, as well as a distribution to reward to the relevant commit owners in the release.

For more information. see the release guide.

# Ethereum

The official Ethereum Docs will always be recommended for newcomers to the ecosystem and those wishing to dive deeper. You do not need to know about cryptographic protocols or Ethereum specifics to take full advantage of Git Consensus.

# Address

There are two account types that exist in Ethereum: Externally Owned Accounts (EOAs) and Contracts. Both get referenced by an address.

EOAs are the user wallets. The address is a 42-character hexadecimal address derived from the last 20 bytes of the public key controlling the account, with 0x appended in front. This address is also the public reference that exists to to receive funds from another party.

In Git Consensus, contributors embed their wallet address in their commit message to receive rewards for their work. For more details on doing this, see the Getting Started guide.

# Token

ERC20 Tokens are the technical standard for fungible assets on Ethereum. The specification of ERC20 is useful as their are other token standards on Ethereum (e.g. ERC721 non-fungible tokens aka NFTs).

In Git Consensus, the usage is always referring to variations of the same ERC20 standard, so it is typically just denoted to Token.

Any contract that implements the IERC20 will be interoperable with any wallets or exchanges, meaning that they can all be traded for any other ERC20 Token, Ether, or national currencies like USD.


An exchange that trades ERC20 tokens

The Token contracts contain a mapping of balances, where each address has a particular balance. When terminology is used such as "Alice gives Bob 10 tokens", it is referring to the balances. With a Governor, the token balance is equivalent to the voting power.

Git Consensus deploys a fairly standard ERC20 Token contract clone for each project. The main differences is:

A mint() function that can only be called by the Git Consensus contracts.
A governor() function that maintains a reference to the project Governor.

# Governor

Governors take ERC20 Tokens a step further by giving balances voting power. With one, you can block executing functions only if a proposal to call it passes. Proposals only pass if majority of Token holders vote FOR it.

DAOs already use this pattern of a Token + Governor frequently. For example, the Ethereum Name Service allows ENS token holders to come to a vote to update the protocol.


An ENS proposal with a governor that uses $ENS token balances

In Git Consensus, each OSS project has it’s own governor, which brings distributed governance to each project.

# Contract

Smart contracts or simply, contracts, are programs that are hosted and executed on an Ethereum network. It's a collection of code (its fun) and data (its state) that resides at a specific address.

They are similar to any other program you would write and deploy, with two additional properties:

immutability - once the smart contract is deployed, it's code cannot change.
distributed - everyone on the blockchain network validates the contract’s output

Most protocols (Git Consensus included) use a set of contracts to establish their functionality. These are the contracts that Git Consensus uses:

# Clone

A minimal proxy contract. In simpler terms, a contract implantation that can be deployed with minimal gas fees.

Git Consensus uses Token and Governor clones to establish per-project governance. By deploying clones for onboarding (as opposed to DIY implementations of IToken and IGovernor), the gas cost is minimal and address prediction can be used to establish a 1:1 mapping between them.

These clones can be created by calling the create functions on ITokenFactory and IGovernorFactory.