Forged Alliance Forever (FAF) is a community project of players and contributors who want to sustain and advance the game Supreme Commander: Forged Alliance.
The FAF Teams are groups of FAF contributors who are tasked with diffrent aspects of FAForever.
These are the current Team Leaders:
Trainer Team Leader
Promotions Team Leeader:
FAF Live Team Leader:
Tournament Team Leader:
Matchmaking Team Leader:
Balance Team Leader:
Games Team Leader:
Creative Team Leader:
Moderation Team Leader:
DevOps Team Leader:
Campaign Team Leader
We are a group of interested people in the development of the faf community. Our goals are providing opportunities to new players to develop their own skills and adapting them within the community.
This is the face of the team.
The team leader is elected by a team vote.
The team leader can be changed by the request of at least 50% of team members at any time.
The team leader is the default point of contact with the board and other teams.
If there is a team vote that results in a tie, that team leader acts as the tiebreaker.
This is the right arm of the team leader.
The person is elected by the team leader.
The deputy leader is also the point of contact if the team leader is absent.
The role given out by the FAFLive Manager in order to make managing the account as easy as
possible. This is typically given out to casters interested in helping the channel cover events but
may not have an interest in larger scope decisions regarding the channel. It can also be given to
serial event organizers that utilize the account or people interested in helping the channel
improve from a streaming setup point of view. The role can also be removed at the discretion of
This role is voted in by a majority of current Organizers. It represents people that have an
invested interest in improving the account across the variety of fields that FAFLive is used for
while also working to expand it beyond those fields.
It is not necessary to be an Associate first to be an Organizer, however it would definitely be the
norm. A person can apply to be part of the Organizers by speaking to the Manager of the team
who will then handle the logistics of a voting process.
Organizers vote for a new Manager on an annual basis after the annual FAF General Meeting.
In cases where a Manager must be replaced, 66% of the Organizers can submit a petition to the
TDs themselves do not hold any minimum responsibilities but are able to voice concerns and
input about tournament schedules and funding. They are free to participate in these discussions
as interest in making long term, consistent, and complex events run smoothly is the ultimate
division between a Senior TD and a standard TD.
Tournament Directors are given privileges over events as outlined by:
Senior Tournament Directors will be responsible for reviewing tournament formats and giving
advice on how to make events run optimally.
They will also be the ultimate decision body that
determines Official FAF Event Scheduling as well as working with the Board to allot funds for
these events through the Tournament Manager.
Senior TDs vote for a new Manager on an annual basis after the annual FAF General Meeting.
In cases where a Manager must be replaced, 66% of the Senior TDs can submit a petition to the Board
❖ Interested applicants apply by messaging the team lead.
❖ Applicants are discussed and voted on by the team members with a majority required to join, with the team leader being the tiebreak.
❖ If accepted new members become balance associates.
❖ Applicants are expected to have atleast one of the following: game design knowledge, LUA coding knowledge being familiar with fa repo or be an experienced player with a good understanding of the competitive gameplay.
❖ New members are accepted on a trial period that lasts up to 3 months.
❖ Team members may be removed, by the team leader or a majority vote, due to inactivity or being no longer suitable for the position.
❖ The team leader acts as the point of contact with the board and other teams.
❖ The team leader is elected by the balance members with a majority vote or by the previous team leader.
❖ Any team member can call for team lead election at any time with a 3 month cooldown period in normal situations.
❖ Member of the Balance team is expected to actively work towards team's goals and responsibilities. This is achieved by discussing balance matters with the team, creating and reviewing Pull requests in the repository, and taking part in meetings.
❖ Members of the Balance team, alongside the team lead, decide on individual balance changes as well as the general direction of balance.
❖ Members get a vote in all matters concerning the balance team: team membership, team leader election and the policy of the team.
❖ To become a member you have to actively contribute as a balance associate for at least 6 months and get an approval of the team lead and super majority (75%) of current members.
❖ Balance associates are either newer contributors or less experienced contributors.
❖ Balance associates are expected to contribute in at least one area of team's responsibilities.
❖ Balance associates don't get to vote on any matters concerning the balance team and they don't decide upon balance changes. That doesn't mean that their feedback isn't welcome nor that it won't impact what gets changed. It simply means they do not have a final say in those matters.
❖ Activity requirements are less strict for the associates compared to members.
❖ Honorary members are past members of the team. They provide their insights on balance matters however they don't have any voting powers and are not subject to any activity standards.
❖ The main goal of the Balance team is the continous balancing of FAF's gameplay to make it more fun, fair, and engaging.
❖ Roll-out patches to fix any bugs and introduce new features
❖ Prepare patchnotes and explain to the community the reasons behind changes made in the patch
❖ Engage with the community and collect feedback
Every team in the FAF community is required to have a mission statement. This was made mandatory at the general meeting of the 6th of March, 2022 when the
Governance structure proposal was accepted. The mission statement the game development team describes:
It is important to understand that all game team members and contributors are expected to act in accordance with the Code of Conduct of our community. This includes, but is not limited to:
The game development team consists of the following roles:
In the game repository there is a clear distinction between UI and simulation related code. They both require a different approach and are, from a code-perspective, unrelated to each other. It is important to understand that a contributor may not be equally equipped to solve each type of problem. We use the tags
area: sim and
area: ui to make this distinction for issues and pull requests.
The roles are tightly coupled with the interactions and permissions in the repository:
->Admin role on Github
->Maintain role on Github
->Write or Triage role on Github, part of the contributors list
->Triage role on Github
We'll now discuss each role and describe how someone can attain a role.
In addition to the responsibilities of a maintainer, the administrator is also responsible for the repository and the game development team as a whole:
(1) The administrator understands how Git and Github works, how we distribute the files to our users and what the consequences are of a release that is unstable. Unstable means anything that breaks the game or the immersion of the game towards the user. The administrator will do his best efforts to guarantee a stable release. An unstable release can damage the project.
(2) The administrator provides a clear vision to guide the contributions of the project. All projects requires some form of guidance - a common goal that we are trying to achieve. It allows for This creates a more stable development environment and allows for productive discussions.
(3) The administrator pro-actively responses to issues, pull requests and general questions of both contributors and the community in general. This is important to create an open and interactive development environment. There is nothing worse for a contributor than seeing his or her contribution being ignored for weeks on end.
(4) This is relevant for all teams, but the interactions between the Balance team and the Game development team is particularly critical. We share the same repository. The administrator is responsible to create and manage the work surrounding their release too.
And last but not least: the administrator has the ultimate veto pull requests and membership of the team.
Due to the required mindset, skillset and the burden of responsibilities the administrator is not elected in a democratic vote of the whole team, nor is its position restricted to a limited period of time. The administrator can be replaced with a constructive vote of no confidence. This requires:
Should the administrator resign then it is expected to be accompanied by a proposal for a new administrator. This can only be overruled by the same rules as a constructive vote of no confidence.
Should there be no successor the maintainers have to elect one from themselves with an absolute majority. If an absolute majority is not achieved in the first ballot, a run-off election is held.
In addition to the responsibilities of an associate, a maintainer has sufficient experience with Lua and the code base to have informed discussions and make informed decisions about a pull request. In particular, the following aspects need to be taken into account:
(1) At FAF we have the luxury of a vast amount of content that has to work with our repository. These include featured or unmaintained mods such as
BlackOps, maps that apply extensive scripting such as
DDDX Survival or
Genesis of the Order Survival and of course all of the co-op maps. These should not be broken unless there's a (very, very) good reason for it.
(2) Proper documentation is critical in weakly typed languages to understand what the arguments of a function and its return type means. We're dealing with programmers of varying technical backgrounds with varying experience. And as with any open source project, contributors can come and go - the documentation should be sufficiently detailed, yet concise to help the wide range of programmers understand and work with the code base.
(3) When possible, code should be written so that it can be tested. We do not have an extensive test suite because it is difficult if not impossible to mock the engine. We should however strive towards writing functions that are pure to their arguments. This allows the function in question to be more easily tested and, if applicable, re-used accordingly.
(4) This aspect is tightly coupled with documentation and testability, as they both increase maintainability. We mention it here specifically because it is important to write solutions that are both simple, yet complicated enough to solve the problem in question. Sometimes this may require some refactoring. This is a delicate balance as we're dealing with a lot of legacy code.
(5) This is more relevant for code related to the simulation then it is for code related to the UI. Any change we make needs to be weighted accordingly: is this change worth the cost to performance?
One burden of a maintainer is to make a decision that may be unpopular at times. As an example, when a pull request implements a widely requested feature but it is poorly implemented, untestable and undocumented then you may have to vote against it until the contributor responsible for the pull requests makes the required changes.
For an associate to become a maintainer he or she needs to be appointed by one of the team members. The associate is accepted with an approval of 1/2 of the maintainers, including the administrator.
An associate has no responsibilities. They likely either:
An associate has access to the development channels on Discord, if you do not have access you can ask access by contacting the administrator.
An associate is not a member of the game team.
With this role you'll help the community by providing insights on, and guarding the quality of what we develop. You'll have access to the Discord channels that are usually read-only for the rest of the community. There you can share your thoughts on bugs or features and participate in discussions with the game developers.
The team discussions happen on our official Discord channel, in particularly:
(1) This channel is accessible to anyone. It allows people to report issues to the game team without the requirement of having a Github account. Game team members can then make issues or pull requests accordingly.
(2) This channel can be read by everyone, but only written to by people associated with the game team. It allows us to have informed discussions without being interrupted.
A pull request should always be squashed. This makes it easier to trace back the reasoning behind the changes. All squashed pull requests should adhere to decent a commit-convention, as described for example on:
Do not take these guidelines too literally, you can take any commit on
deploy/fafdevelop as a source of inspiration.
The moderation team’s mission is to keep the community a healthy and pleasant place
for all users, on all FAF platforms, by enforcing the rules of the community.
The moderation team also determines the moderation policy and rules for the client,
discord, forum, and other FAF managed platforms.
We enable the promise of forever in Forged Alliance Forever.
This is achieved by following our key goals. Everything we do should be
This team is responsible for creating and developing campaign missions on FAF.
The campaign team has its own repository where it can make changes to the game. The campaign team maintains the repository - no change requires approval from either the game or the balance team.
The campaign team has its own repository with maps, that acts as a vault. The campaign team maintains the map repository and no change to the map repository requires approval from the creative team.
Campaign Team lead has the following responsibilities as it follows: