---
# System prepended metadata

title: Internal Organisation Restructure

---

# Internal Organisation Restructure

## Table of Contents
1. [Introduction](#introduction)
   - [Preamble](#preamble)
   - [Motivations](#motivations)
   - [Goals](#goals)
   - [Non-Goals](#non-goals)
2. [Essence](#essence)
3. [Roles](#roles)
   - [Treasury Officer](#treasury-officer)
   - [Release Officer](#release-officer)
   - [Secretary](#secretary)
   - [Update Director](#update-director)
   - [Official Addon Officer](#official-addon-officer)
4. [Committees](#committees)
   - [Membership Committee](#membership-committee)
   - [Disciplinary Committee](#disciplinary-committee)
   - [Code Standards Committee](#code-standards-committee)
       - [Contribution Regulation Subcommittee](#contribution-regulation-subcommittee)
5. [Conclusion](#conclusion)
    - [Failure Standards](#addendum-1-failure-standards)

## Introduction

### Preamble

This document defines the internal structure of our organisation, the individual or group responsibilities we have identified that we feel need roles assigned, and the shortcomings that have led to these decisions.

This is not intended to be an exhaustive, official diagram of our team structure -- nor are the roles and their responsibilities expected to be ironclad -- but as a means of defining areas that suffer from being indistinct.

Plans for internal restructuring began in October 2022, were drafted in March 2024, with this being the final version agreed upon by the organisation's administrative group and approved by a quorum of the core team members.

### Motivations

For years, the organisation has largely been run on a whole-group participation model, where simple tasks (such as dealing with pull requests) are dealt with as-is by core members, and anything serious or involving the group was decided by approval of the whole team where possible, and then handled by one of the administrators. \
This model functioned well when we were a small group of active contributors who could discuss and decide things within a day.

Unfortunately, in recent years, this whole-group-vote model has created some trouble.
Firstly, it has caused roadblocks in development where feature proposals require several weeks of discussion before being implemented. Secondly, when adding new members to the team and deciding on team policies, we have needed to reach out and contact members on hiatus in order to gather their approval, which has slowed down our progress.
There has also been a noticeable lack of structure when it comes to common tasks (e.g. making sure the pre-release checklist is followed, making sure issues are marked and closed when their fix is published) and this has led to occasional administrative failures, such as a bug fix being released, but an unlinked historic issue for it remaining open since it wasn't initially linked to the pull request.
Sadly, there have also been occasional issues with discipline within the core team and peripheral contributors. If this ever occurs, it ought to be dealt with swiftly and appropriately, and waiting for a full group decision is simply unfeasible in such cases where immediate action may be required.

### Goals

The internal restructure aims to meet the following criteria:
- To enable a faster response to critical or time-sensitive issues.
- To ensure important administrative tasks are not neglected.
- To allow votes to be taken on team issues with a representative subset of the team.
- To create better direction and structure for reporting and discussion within the team.

### Non-Goals

The following are not objectives of this change:
- To remove our core concept of whole-group approval
- To remove authority from existing members or create a new general hierarchy
- To replace the existing organisation lead positions

## Essence

The core idea of the restructuring is that the team membership invests power in specific roles or groups to act on our behalf in select areas. \
Rather than removing authority from the team (or elevating certain positions with authority *over* the team) the proposal is to invest authority in these structured roles *by the means of* our whole-group approval.
In essence, we are electing representatives to take charge of issues on our behalf. 

## Roles

The following positions are created to make sure certain essential tasks are completed. \
The volunteers appointed to roles are 'overseers'. They are not wholly charged with doing all elements of the task, but are responsible for making sure it gets done and filling in any gaps.
For example, the Release Officer does not have to be the person to do every task necessary for a release cycle, but finishes the tasks that nobody else has done.

### Treasury Officer

The person who handles the adminstrative tasks surrounding donations and sponsorships, such as responding to queries, updating payment or contact details as required.

### Release Officer

The person who is in charge of making sure the "Release Day Checklist" is followed.
This includes, but is not limited to:
- updating the aliases submodule
- verifying the correct UTF encoding is used in the built jar
- making sure the correct language files are present in the jar
- making sure the changelog in the release notes is complete and accurate
- making sure the release announcement has been made

The Release Officer is not expected to do all these tasks by themselves for every version: they just make sure that said tasks have been done by somebody else and, if not, complete any missing checks.

### Secretary

The secretary is largely in charge of administrative tasks concerning the GitHub issue and pull request tracker.
This person is in charge of making sure issues have been properly marked, assigned or closed as necessary, as well as closing abandoned and stale pull requests, or notifying the team when pull requests have been missed by reviewers.

In addition, the secretary must maintain, personally or through delegation, a space for laying out the current goals and plans for Skript. This does not mean the secretary is in charge of these plans, simply that they must maintain an area for the plans. This is to ensure the team is kept aware of the plans and ideas of others and the long-term goals of the project.

### Update Director

For each major, feature update, an Update Director may volunteer to take charge of setting out the direction for the update.
This could include making a plan of what areas to focus on, or the major parts that require contributions or improvement, as well as the end goal of the update and the contributions that ought to be considered 'out of scope' and pushed back to a future version.

The idea behind having a nominative 'Update Director' is to make sure that important details are not lost in the scope of contributions; related or dependent pull requests are grouped together, and important changes are not forgotten about.
The Update Director should also be responsible for setting the timeline for testing and beta versions to be given to the testing group.


### Official Addon Officer

As the organisation now maintains three 'official' addons (extensions that are produced by us rather than third parties) it is important that these have clear management and direction.
Each addon has its own designated officer, who is in charge of managing its contributions, direction and scope.

## Committees

Committees are designed to act as representatives of the whole group for the purpose of addressing time-sensitive issues where it may be unfeasible or inappropriate to wait for responses from all team members, including those on hiatus.
Committees are invested with the authority of the whole-body quorum for their respective tasks (i.e. when a committee agrees on a decision, that decision is backed by the team).

Committees have a notional 'chair' -- a person selected among the committee members. The chair position is largely an administrative formality and does not need to be filled if the committee is capable of acting without a chair. The chair's only responsibilities are as follows:
 - To act as the deciding vote in the rare case of a tie
 - To notify all committee members of an official proceeding
 - To notify the wider group if an action is taken that requires special attention

Committee positions cannot be held by inactive team members or members on hiatus.

### Membership Committee

The membership committee discusses and votes whether to accept new team members, and makes a recommendation based on that. Acceptance requires the approval of every member of the membership committee. \
The recommendation is accepted by default, unless there is an immediate objection or some outstanding reason why the applicant *cannot* be accepted.

Ideally, the membership committee is made of all active team members and all members are encouraged to participate. However, participation is not mandatory and members of the team are not obligated to join.

### Disciplinary Committee

The disciplinary committee is responsible for ensuring standards of good behaviour in the organisation's public spaces, such as the issue tracker. \
Members of the disciplinary committee are authorised to immediately deal with bad actors or behavioural incidents that occur in the organisation's public discission forums or the GitHub tracker.

The disciplinary committee is also responsible for the team's internal discipline: if team members act poorly in a way that breaks the organisation's core values -- such as by acting in ways that bring the organisation into disrepute -- then the disciplinary committee may recommend a member's dismissal by unanimous vote. \
As in the case of membership the recommendation is accepted by default, unless there is an immediate objection or some outstanding reason why the member *cannot* be dismissed.

Members of the disciplinary committee are expected to be above reproach, for obvious reasons. Any kind of disciplinary action taken against a sitting member of the disciplinary committee is treated as an unthinkable exception and must be handled by the organisation lead directly.

### Code Standards Committee

The standards committee is responsible for fixing the project's code style, as well as the standards and regulations for contributing to the project.
This is a loosely-defined committee that all members are able to opt into, simply for the team approval of code-style-related pull requests.

#### Contribution Regulation Subcommittee

This subcommittee acts as part of the code standards committee, and has the special authority to reject suggestions or contributions that are not positive additions to the project, or are otherwise objectionable in some way. \
This treatment should be reserved for irreparable contributions; things that are realistically unable to be modified or fixed to meet an acceptable standard.

This group is created to address the issue of unwanted contributions sitting stale on the GitHub tracker until full team approval can be acquired to reject them.

## Conclusion

By delegating tasks and deputising members or subgroups responsible for them, this restructuring proposal aims to solve the chronic issue of unreasonable days in addressing important issues.

The range and flexibility of appointments aims to allow team members to involve themselves in these core tasks without placing too much responsibility on individuals or, equally, shutting out members of the group from participating.

By appointing these positions with the collective authority of the team, the possibility of future changes, restructure or dissolution is left possible.

### Addendum 1: Failure Standards

No proposal is complete without failure standards; this restructure can be deemed to have failed if, in two years' time:
1. There still exists a continual, unreasonable delay in responding to organisational issues.
2. The team as a whole abandons the model of roles and committees in favour of the previous whole-team-vote model.

Additionally, if this restructure is considered to have put an undue burden on the core development team, to the extent that it has hampered progress in a significant and measurable way, then it can be considered to have failed.