# Minutes of the General Meeting Jan. 2025

### Introduction

Every major update is followed by a general meeting of the team. This is an opportunity for all members to bring their ideas to the table for discussion. An agenda is set in advance of the meeting based on the ideas contributed, and then each motion is discussed.

Traditionally, we make all decisions by vote. The initial vote most be unanimous to pass. Any member present at the meeting has the right to vote against a proposal, in which case we enter a second round of discussion to argue for our positions before taking a second vote. The second vote only needs a majority approval to pass.
If there is not a general consensus after the second vote, or the majority abstain, we table the idea and schedule a follow-up meeting for resolving the dispute.

## Feature Planning

### Experimentation

Skript 2.9 added the tools for creating opt-in syntax experiments. We agreed to make more use of these, in order to test more features and receive feedback from users.

We agreed to experiment more with new features and ideas. Feature flags essentially provide a free pass to trial unconventional syntax without impacting the average user.

We also agreed to be more permissive with future contributions for syntax that is un

## Housekeeping

### Coordinator for 2.11

One team member takes responsibility for organising each major update. This involves making sure the release is on time, the details and information for it are correct, and for following up with any contributions that were marked for release but have been delayed or have outstanding issues.
Several of the core members are taking a step back this season due to personal commitments.
Tud put his name forward to coordinate `2.11`. This was agreed by the others present.

### Official Process for Closing Contributions

From time to time, issues and contributions get marked as 'up for debate'.
This typically means that one or more of the team either object to the idea, or there is some internal dispute about how to implement the idea.
While we have an internal group for resolving these disputes, issues were not being forwarded to the group and so the disputes were generally slow to resolve.
We agreed upon the following:
1. Any team member has the right to object to a contribution.
2. Their objection should be forwarded to the conflict resolution group immediately.
3. The conflict resolution group must decide on the matter within one month: both the member who objected and the author of the contribution in question should be consulted on the decision, in order to defend their position or take feedback.

### Removal of Inactive Members

Some former members of the team have not been seen for multiple years.
As we take our major decisions, including recruiting new team members, by unanimous vote, it makes this process considerably slower if we have to specifically reach out to people no longer interested in the project.
Some of this problem was solved in the 2023 Spring season, when we set up subcommittees responsible for particular tasks.

We agreed to set up a more rigorous system of checking in with absent members after a period of unexplained inactivity, and to automatically remove members who we receive no contact from for a certain period of time.

### Adjustments to the Release Cycle

The most recent `2.10` update has been the largest update in recent history, with respect to its time scale.
There was a significant increase in the rate of activity during the `2.10` cycle, from August 2024 to January 2025.
We believe this was due to a combination of contributions from the new team members selected in 2024 and the activity of several new contriutors on the scene.

It is our aim to maintain a balance between
- releasing updates frequently enough that important changes are available to the user promptly,
- not releasing so many updates that users feel overwhelmed and stop bothering to install new versions,
- but releasing frequently enough that an excessive number of changes does not build up in a single update, overwhelming the user.

This third condition is important: a large portion of the user base did not update to version `2.3` on its release and waited an extra 18 months for `2.4`, because of the sheer quantity of breaking changes that required users to rewrite their scripts.
This is generally bad for the ecosystem: if users are not updating, then users are not receiving bug fixes and improvements. It has a knock-on effect of forcing addons, third-party resources and scripts to support more versions at a time, creating more work for developers in the community.
We felt that `2.10` reached a size where it risked having these issues, particularly as there were several internal changes to the addon and registration system.

We were also concerned that, with Minecraft's 'seasonal drops', it could take a long time for important changes to be reflected in Skript.
We have already taken some measures to allow us to combat this, but more work may be needed in future.

In the general meeting of July 2024, we agreed to run two additional feature releases in the months of April and October. Last season, the October release was skipped, since no major feature contributions were ready in time for it, and we did not have a clear plan for organising the release.

We have revised the plan for this year.
Feature releases will occur in July and January as they have for the past two years.
We will also run **two** additional -- but *smaller* -- feature releases in **April** and **October**. These are an opportunity for contributors to ship their work without having to wait for the Summer or Winter versions.

The April and October versions will try to avoid breaking changes where possible.
These will release on the **1st** of the month, i.e. without the same pre-release schedule that January and July have, but we reserve the possibility that a follow-up patch may be released on the 15th of April and October, in the case of any major issues.

The revised release schedule will look as follows:
|Date|Version|Type|
|:--|--|--|
| Jan 01 | `2.10.0` | pre-release |
| Jan 15 | `2.10.0` | release |
| Feb 01 | `2.10.1` | patch |
| Mar 01 | `2.10.2` | patch |
| Apr 01 | `2.11.0` | release |
| Apr 15 | `2.11.X` | patch (if necessary) |
| May 01 | `2.11.1` | patch |
| Jun 01 | `2.11.2` | patch |
| Jul 01 | `2.12.0` | pre-release |
| Jul 01 | `2.12.0` | release |
| Aug 01 | `2.12.1` | patch |
| Sep 01 | `2.12.2` | patch |
| Oct 01 | `2.13.0` | release |
| Oct 15 | `2.13.X` | patch (if necessary) |
| Nov 01 | `2.13.1` | patch |
| Dec 01 | `2.13.2` | patch |

This will mean the middle `2.X.0` version number increases more rapidly (i.e. 4 times per year instead of 2). The middle number is used to indicate new changes for the user.

We may revise this schedule in the next general meeting.

### Feature Milestones

As a team, we have become concerned that many changes are only being completed within the final weeks or days of a release.
This is, on the whole, leading to less time and opportunity for testing the changes, and reviews having to be rushed for the sake of getting the work completed on time.

Members present at the meeting suggested a number of reasons for this.
1. An overwhelming number of the team members are (computing) students, and universities are typically semestered with their breaks in the summer and winter. This is part of the reason the release cycle was originally dated as it was, but it also means the availability window for working on contributions is also limited to these seasons.
2. There is currently no real time constraint on finishing or responding to contributions, meaning the only time the contributor feels a sense of pressure to finish their work is when the release date approaches, and there is a possibility it may need to wait six months before being included.

In either case, we do not think this is healthy for the project, since it increases the risk that mistakes will be shipped to the user.

The proposed change to fix this was feature milestones: large-scale contributions should have fixed dates by which they ought to be 1) ready for review, 2) reviewed for the first time, 3) reviewed for the second time. These dates would be independent of release dates.

There were several objections to this idea from members present at the meeting.

The revised plan was to implement some kind of automation to make sure all contributions are reviewed in a timely manner going forward.

### Contingency Plans for the Paper/Spigot Hard Fork

Paper has completed its 'hard fork' from Spigot. While it aims not to purposefully break compatibility, we have concerns that changes to some internal classes might make it difficult to support both Paper and Spigot.
In the event that it becomes impossible to support both, we decided to support only Paper. An estimated 3% of current users are using Spigot.