The NeoForged project is split between GitHub and Discord. It is a community of volunteers, maintaining a free and open source ecosystem of modifications to the Minecraft game.
All contributors and team members are here for fun - our goal is to provide joy to the community, and to ourselves.
We are here because it is fun, so this document ensures that the Project doesn't become so bureaucratic or so much of a chore that the fun is removed for anybody.
This document is:
- A non-exhaustive list of the working principles of the project.
- Intended to help guide the project in times of uncertainty.
This document is built on the fundamental principle of "people generally want to help, so we should not get in the way of it".
The core ethic is "people over processes", so this document is intentionally light on processes - situations that come up are rarely one-size-fits-all, and should be treated on a case by case basis, with the best process to fit the person.
This document is not:
- Intended to enforce rules on all members.
- Intended to catch all possibilities.
- Intended to prevent "rules lawyering".
The Code of Conduct of the project is taken to be the content of the Contributor Covenant, so this document is not the Code of Conduct. However, this may be altered with a copy held and maintained by the Project, only with overwhelming majority support by the entire team.
Conflict resolution is a duty split between the Moderators and Steering Council; the former for interpersonal disputes in and with the community, and the latter for development-related disputes in the Project itself. Either team may wish to append a section to this document, but currently, this document is not conflict resolution.
Following are some core definitions that will be referred to in the later sections of the document.
"The Project" refers to The NeoForged project, with a presence on both GitHub and Discord, as noted at the start of this document. It does not refer to any specific repository or subproject.
Subprojects are large tasks that the Project itself is undergoing.
These may be:
- Repositories under the Project's GitHub.
- Large, multi-repository tasks that are being undertaken (ie. updating the API to a new version of the Game).
- Smaller, more targetted tasks that are being undertaken (ie. refactoring the Modloader or API to remove or replace or rework a feature).
The Project is split into three teams.
A team is a group of people with similar goals, and equal weighting in most decision making - with some exceptions, which will be explored later.
You may apply to join some teams, but some require appointment from within an existing team, or further voting after application.
The Steering Council is the overall management and oversight of the Project.
They “steer” the project to keep it aligned with the long-term vision, hence its secondary name of Vision Team.
The Council has at all times an odd number of active members, such that stalemates are not possible.
A member may choose to become inactive and appoint another in their place until they return.
At least one member of the Council is promoted from other teams via an annual internal vote, to ensure that the Council always has fresh insight from a new team member with a different view on situations, and thus does not stagnate over time.
Once a year, an internal voting process inspired by the process implemented in the Python ecosystem will determine the members that will be promoted to the Steering Council via the Helios voting system. All three members of the Council will be elected, at least one of which must be a member that has not been on the Council in the previous term.
The Council also serves double duty as a mediator for disagreements between other teams. These shall be resolved by discussion, rather than by unanimous applications of the rules, so this is not in the purview of this document.
However, the Council does not have all-encompassing powers. They are the avenue of last resort, and the vast majority of decisions should be made by the team in charge, not by the Steering Council.
The Council has these powers to resolve the 1% of exceptional situations, not the 99%.
The Maintainers team consists of all project developers who have push access or technical rights (Write permissions to a Project's GitHub repository, or access to the Project's servers) to the project's repositories or infrastructure.
They are the ones keeping the Project's repositories up to date, and ensuring the quality and standards of the Project are upheld, as well as adding new features as the community comes to require them.
Though Maintainers may individually or collectively have different access rights across the project's many repositories or infrastructure services, all Maintainers within the team are considered equal to each other with respect to their rights within the team's governance.
Maintainers may be appointed by other Maintainers, or by application from the person who wishes to join the team.
However, they have no jurisdiction or weight in moderating or managing the community, unless the Maintainer in question is also a Moderator.
The Moderation team is composed of all moderators of all community spaces (GitHub, Discord) under the purview of the project.
They have the responsibility of enforcing the policies and rules of each space, as well as the Code of Conduct, and applying disciplinary sanctions to people who violate said rules.
Moderators may be appointed by the Steering Council, or by application from the person who wishes to join the team.
Unless a Moderator is also a Maintainer, they cannot influence technical decisions, but they can still express their opinion, just as any other person.
Nobody is above the rules. All members of the team (even the Steering Council!) are to be held to these rules, with no exceptions granted for any individual or group.