Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Purpose:

The purpose of this document is to describe the GitHub roles used by the FIO protocol and how each role can be obtained by community members.

Roles:

GIT Organization

Owner – This roles can perform all admin and management of members, repositories, teams and other git information associated with the FIO organization. importantly owners can create and remove repositories within the organization. Owners can invite new members into the GitHub organization.

Member – A member is a pre existing git account that has been invited and accepted the invitation into the FIO organization. Members can be assigned to teams within the FIO protocol. Members can be provided permissions/repository roles (see below). Members can be private or public (this is the choice of the member).

Team – a team is a group of FIO protocol members. Teams can be provided permissions/repository roles (see below). teams can be secret or visible.

Repository – a repository is a set of content being source control managed by the FIO organization. Repositories can be public or private

Permissions/Repository Roles

These items apply to teams and individual members within the FIO protocol organization.

Read

Read and clone repositories. Open and comment on issues and pull requests.

Triage

Read permissions plus manage issues and pull requests.

Write

Triage permissions plus read, clone and push to repositories.

Maintain

Write permissions plus manage issues, pull requests and some repository settings.

Admin

Full access to one or more repositories including sensitive and destructive actions. Modify Admin Role

Branch names for organization

master – current operational baseline.

develop – development branch used to deliver projects deemed worthy of release.

release – release branches and release tags will be made at the discretion of the release manager from the develop branch.

feature – feature branches will be made for any dev efforts, names feature/<unique work task name>

Change requests (PR)

Reviewer/commenter – anyone with read access to the repo can comment on changes/PRs.

Approver – anyone with read access to the repo can approve or request further changes to a PR.

Code Owner – the repo admin will identify a set of organization members who are qualified to provide an approving review to enable merge of the PR (it is recommended at least 2 of these be identified per repo). it is recommended that GitHub Teams be used to identify code owners for related repositories on the GitHub.

Merger – once a PR has met approval requirements any organization member may merge the PR (this requires write access to the repo).

a process of change request will be used within FIO. By convention the FIO protocol repository admin will decide how many reviewers are required for pull requests to be merged into specific branches. it is recommended that for develop this number be at least 1, and for master it be at least 2. repositories should enable require review by code owners. a code owners file should be established in each repository.

How to obtain a role --

Owner, Admin

For FIO the roles of owner, and admin, these will be granted by majority agreement of the present organization owners. In order to gain these roles, a candidate will need to be a member “in good standing” within the organization. The member needs to request the role from one of the organization owners via any direct communication mechanism. The role of admin can be delegated by an existing owner to another member of their choosing. When delegating the owner should provide transparency of this delegation to the other owners before delegating the role. Owners are responsible to monitor their satisfaction with the performance of admins. When admins fall short of desired performance, owners may remove them from service and put into place a new admin member.

Code owner --

organization owners, and repository admin may identify organization members as qualified code reviewers. these individuals can be placed onto teams within the GitHub.

  • No labels