Project Constitution

Version 1.0.20230207.0

This version of the Battle for Wesnoth Project Constitution was written by Iris Morelle (shadowm) and reviewed by Charles Dang (Vultraz), Soliton, and Pentarctagon.

Non-normative text is indented in quote blocks.

I. On the Project's Mission

Article 1. The Battle for Wesnoth Project is a game development organization that exists for the continued development, improvement, and maintenance of the The Battle for Wesnoth.

Rationale: The Battle for Wesnoth Project exists and this is its purpose.

Article 2. The Project's funds, intellectual property, and other assets will by held by Software in the Public Interest, Inc. (SPI). Interaction with SPI on the project's behalf will be done by the Board of Directors.

Rationale: The costs of having taxes done by the current (as of this writing) legal entity holding the Project's funds and other assets (Wesnoth, Inc) is the single largest cost for the Project by a large margin, and will be significantly reduced by joining SPI. Additionally, SPI is a 501(c)(3) organization, which provides guarantees to those donating that their money will be used for a proper purpose.

Article 3. The Battle for Wesnoth Project's product and all associated code it publishes is compliant with the Open Source Definition as published by the Open Source Initiative.

Rationale: It is imperative to guarantee that no decisions emanating from the Project Council can ever contradict Wesnoth's license or purpose as an Open Source Software development team.

II. On the Project's Structure

Article 4. The Battle for Wesnoth Project has a Development Team comprised of volunteers dedicated to the betterment of the game.

Rationale: Re-stating the volunteer-driven nature of the Project is paramount to settling any potential disputes surrounding people's responsibilities within the Project, but it is equally important to remind people that their ultimate purpose is the betterment of Wesnoth and not the aimless production of code for their own goals.

Article 5. Members of the Development Team have write access to the version control system repositories managed by the Project, as well as privileged access to their associated issue trackers. Persons eligible to become members of the Development Team are either: a) contributors who have either made at least three non-trivial contributions of code, graphics, sounds, music, or other resources used by the Project's product; b) contributors who perform housekeeping contributions or tasks at any level in a consistent and regular fashion; c) persons who on behalf of the Project run and manage computer systems used to support the Project's operations and its product; d) individuals appointed by the Wesnoth, Inc. Board to perform one or more specific roles that necessitate write access to the Version Control System repository or repositories.

Active developers are understood to be members of the Development Team who have produced tangible output under the terms of points (a) or (b) above at least once every three months within the last 12 calendar months, and have no stated reasons to be considered inactive or intent to become inactive within the next 12 months.

Rationale: In order to guarantee order in future decision-making, it must be made clear to all who qualifies as a member of the Development Team. It is equally important to grant Wesnoth's financial backer the ability to appoint new members of the Development Team for any purposes deemed crucial to the company and the Project's operations, such as iOS port development.

Article 6. The Battle for Wesnoth Project has a Wesnoth.org Staff Team which is a subset of the Development Team. It shall be exclusively comprised of persons considered under point (c) in the preceding article, or persons appointed by the Wesnoth, Inc. Board as per point (d) to perform the same functions.

Rationale: Wesnoth.org staff tend to take a background role most of the time but there are situations where their action or vote may be required, optional, unnecessary, or undesirable, therefore their existence must be defined in order to legitimize any such provisions.

Article 7. There shall be a Project Council, led by the Project Manager, presiding over the Development Team. The Project Council is also comprised of the Community Manager, the Release Team, and the Maintainers.

Rationale: Enumerates the leadership roles for the Project in advance of their definition. The primary goal of this Constitution is to decentralize the powers currently attributed to the Release Manager so that the chances of a single person overextending are significantly reduced.

Article 8. The Project Manager shall have the ability at all times to appoint or remove a Community Manager to handle public relations on behalf of the Project, including coordinating with the Moderators of the communications channels of the Project, managing social media accounts, and communications on the Steam store and Steam forums. If there is no designated Community Manager, or the Community Manager becomes temporarily or permanently absent, the Project Manager shall have the ability to perform their functions for the Project.

Rationale: Describes the Community Manager role, essential for the efficacy of the Project's communications and representation in the connected world of today.

Article 9. The Project Manager shall have the ability at all times to appoint members of the Development Team into a Release Team, as well as remove them from it. The purpose of the Release Team is to assist the Project Manager with technical or non-technical tasks associated to the process of releasing new Wesnoth versions, such as packaging the source distribution or binary distributions for tier 1 platforms (Windows, macOS, Steam-Windows, Steam-macOS and Steam-Linux) as well as distribution of the game on virtual or physical software stores.

Members of the Release Team may be directly appointed by the Board for the purpose of distributing or preparing the game for distribution through platforms that generate revenue for Wesnoth, Inc. In this case, only the Board shall have the ability to demote such members of the Release Team.

Rationale: Formally defines the roles of the packagers in the production of new releases, and grants the Board the ability to appoint packagers for platforms and distribution channels that provide it a revenue stream to support the Project's operations.

Article 10. The Project Manager shall have the ability at all times to appoint Maintainers of specific areas of Wesnoth's development, as well as remove them. The persons thus chosen by the Project Manager will be in charge of reviewing all issues and pull requests affecting or involving their respective areas. The Project has a minimum of three core development areas with distinct Maintainers, being the Project Manager's responsibility to narrow those areas further down and define additional ones according to the current needs of the Project. The core development areas for the Project are as follows: General Code, Mainline Content, Art Direction.

It is possible for there to be technical overlaps between different areas of development, in particular between areas defined by the Project Manager and the core areas defined by the preceding paragraph. Any areas that are not defined, have no appointed Maintainer or have an absent Maintainer, are understood to be the direct responsibility of the Project Manager. Notwithstanding this, it must be guaranteed at all times that there are at least three appointed Maintainers other than the Project Manager.

Rationale: A well-defined group of people who have the last say on their specific areas of expertise is essential when coordinating with new and old contributors alike, especially during the roadmap drafting phase described later on.

III. On Elections and Development Cycles

Article 11. The organization of elections held by the Project are the Board's responsibility. Before the start of an election, the Board shall choose a platform and publish clear instructions to vote, including a starting date and deadline for vote submissions, and any applicable requirements to be considered a voting party. Votes shall be cast by sending a message through the chosen platform and/or intermediaries, containing only clean and plain English and without leaving any room for ambiguity.

All votes cast are strictly private and shall not be disclosed to persons other than members of the Board and Wesnoth.org Staff Team members with direct access to any relevant technical facilities.

Any messages failing to clearly state a choice shall not be considered for the final vote count. Only the first vote from a particular individual shall be considered for the final tally.

Rationale: It must be the duty of Wesnoth, Inc. to establish a formal mechanism for elections any time they are needed. This is intended to guarantee that the Project Council and the Development Team at large cannot e.g. manipulate the elections to attain a specific outcome of a personal nature.

Article 12. The Project Manager shall be elected at the beginning of each development cycle by a voluntary majority vote by the Development Team, confirmed by the Board by a two thirds supermajority vote. Once confirmed, the elected Project Manager replaces the previous Project Manager immediately.

a) Only active developers are eligible for becoming candidates to the Project Manager position. For this particular point, their activity requirement is increased to 18 calendar months. It is possible for Project Managers to be re-elected at the end of their tenure.

b) Only votes from active developers or Wesnoth.org Staff Team members shall be counted. Members of the Board can participate directly in the elections if they also qualify within those groups, independently of their confirmation vote.

c) In the event of a tie, the Board shall choose one from the pool of candidates with the highest vote count.

d) Should the Board not confirm the new Project Manager, they are understood to be ineligible for the position for that development cycle and there must be a new and immediate call to elections.

Rationale: The voting system is intended to allow the Development Team to decide the Project's future based on the person they choose to lead their activities. For this purpose, only team members who have proven their dedication to the Project through their activity should be able to vote. This requirement becomes even more important for Project Manager eligibility for obvious reasons.

It is worth noting here that Wesnoth.org Staff Members are not eligible for the Project Manager position if they do not otherwise qualify as active developers. However, since they will be subject to the Project Manager's decisions as much as everyone else, it is essential that they have voting rights nevertheless. Additionally, the confirmation vote from the Board is intended primarily to state the Board's trust in the new Project Manager; a situation where the Board votes against the elected Project Manager should be extremely rare in a healthy Project, or not happen at all. The same goes for demotion requests.

Article 13. At the beginning of each development cycle and following Project Manager elections, the Project Manager shall consult with their appointed Maintainers, and in cooperation with the rest of the Development Team draft a Development Roadmap for that development cycle. Each task defined as part of the Roadmap shall have an issue associated to them on the Project's issue tracker with Blocker urgency for the next major stable version. After the first development version of the cycle is released, no more tasks may be added to the Roadmap without the express approval of the Project Manager.

Rationale: The Project needs a roadmap to define its course over a development cycle. The roadmap's existence and purpose must be defined by the Constitution to ensure that people participate in its drafting as well as follow up on the designated tasks. Devising a specific procedure to draft the roadmap is the Project Manager's responsibility.

Article 14. The Project Manager shall schedule Wesnoth releases following consultation with the Development Team, and tag them on Wesnoth's Version Control System repository or repositories. No other person may tag Wesnoth releases unless the Project Manager explicitly delegates this task given appropriate justification (absence, accident, illness, etc.).

Rationale: The Project Manager role supersedes the existing vaguely-defined Release Manager position. Forcing tags to be authored by the Project Manager is important to build trust, especially if at any point we opt for using cryptographically-signed tags.

Article 15. The Project Manager shall have the ability to block Wesnoth releases indefinitely pending the resolution of items labeled in the Project's issue tracker as Blocker, High Priority, or Security, or considered to be of high concern to them or to the Battle for Wesnoth Community at large.

Notwithstanding this, if at least two active developers or one Maintainer expressly request this action of them, the Project Manager shall have the last say on any decision related to Wesnoth's development. For the purpose of the preceding statement, the Project Manager is not counted as an active developer, but Wesnoth.org Staff Members are.

Rationale: Ultimately, the Project Manager must have the last word in any situations where the Development Team does not reach a natural consensus. Without this provision it would be possible for the game's development to completely stall forever.

Article 16. The Project Manager may call for new Project Manager elections as per Article 12 at any time should they deem it necessary, without forfeiting their right to being re-elected.

Alternatively, the Project Manager may be demoted under any of these circumstances, becoming ineligible for immediate re-election, and enabling the Board to immediately call for new Project Manager elections:

a) Voluntary resignation from their role.

b) Prolonged absence for longer than two calendar months.

c) Two or more members of the Project Council or active developers who previously held a Project Council position make an express request to the Board, confirmed by the latter by a two thirds supermajority vote.

Rationale: A formal procedure for replacing the Project Manager (willingly or otherwise) is essential to guaranteeing the Project's ability to keep moving forward at all times.

Article 17. In the absence of a definite Project Manager, the Board shall have the ability to appoint an Acting Project Manager from the Project Council or the Board itself. The Acting Project Manager shall not have any attributions pertaining to the Project Manager role beyond those granted by Article 14 and Article 15 paragraph 1.

Rationale: Some situations may require a person to represent the Project as the Open Source Software organization it is even if there is no elected Project Manager. Ultimately, the Board reserves the right to pick any particular candidate depending on the circumstances that led to this situation.

IV. On Changes to the Constitution

Article 18. Changes to this Project Constitution must be submitted by members of the Development Team to the Project Manager or the Board of Directors as formal proposals describing the rationale for said changes in as much detail as possible. It is the responsibility of the Project Manager and the Board of Directors to make each other aware of the proposal being considered.

Rationale: This Constitution should be open to future changes according to the evolving needs of the Project.

Article 19. A proposal that is considered valid by the Project Manager and the Board of Directors through unanimous agreement must then be voted in by the Development Team. This shall be done through the same process established by Articles 11 and 12 of this Constitution, with the exception of requiring a voluntary two thirds supermajority vote from active members of the Development Team and members of the Wesnoth.org Staff Team, as opposed to a simple majority vote.

Rationale: Due to the nature of the Project Constitution and its impact over everything else (including the Constitution itself), the requirements to pass changes to it should be much higher than those for replacing or re-electing a Project Manager.

Article 20. Once a change to the Constitution is approved by the Development Team, it shall come into effect immediately only if it does not affect the structure of the Project Council as per Articles 7, 8, 9, or 10; or the process for Project elections as per Articles 11 and 12. Otherwise, the change shall come into effect upon the end of the current development cycle and before Project Manager elections take place.

Rationale: This is the "no pulling the rug from under people's feet mid-development cycle" clause.

V. On the Board of Directors' structure

Article 21. The Board of Directors will consist of three members.

Rationale: An odd number of people makes it much more likely that a majority can make a decision when needed rather than becoming deadlocked indefinitely.

Article 22. There will be elections for the entire Board of Directors every other development cycle. This election will take place immediately after the election for Project Manager for development cycles where both elections take place. If a member of the Board resigns, then an election for the open position on the Board will be held within two weeks of their resignation. The people who are able to vote in the Board elections are the same as the people who are able to vote in the Project Manager elections. Anyone can be nominated to be a member of the Board by someone who is eligible to vote in the Board elections.

Rationale: There needs to be a structured way to change who is on the Board of Directors. Development experience is also not necessary to handle the responsibilities of being a member of the Board.

Article 23. Interacting with SPI on behalf of the Project will be done by the Board of Directors, which will designate one member of the Board to be the primary liason to SPI. The remaining members of the Board will be secondary liasons to SPI in case the primary liason is unable to fulfill their role. If that occurs, the Board will decide which of the secondary liasons will become the new primary liason. Whoever becomes the new primary liason will remain so until the Board decides otherwise.

Rationale: SPI requires we provide someone they can contact if needed, and the Project requires someone whose reponsibility it is to initiate contact if needed for any reason.

Transitory Provisions

I. This Constitution must be first accepted by the entirety of the active members of the Development Team as well as Wesnoth.org Staff Members as defined in Article 5. For this particular one-time purpose, Chapter IV does not apply. Once accepted, it shall come into effect immediately.

Rationale: Because of the impact this Constitution is expected to have on the Battle for Wesnoth Project in the long term, it is paramount to require unanimous approval of its first version.

II. For the first development cycle upon which this Constitution comes into effect and unless the current development version is already considered to be in the beta stage of development, there shall be an immediate call to elections for the Project Manager position per Articles 11 and 12, as well as the subsequent drafting of a Development Roadmap per Article 13.

Rationale: The state of affairs in the Project at the time this Constitution was first approved absolutely requires us to re-plan Wesnoth 1.16 with the newly elected Project Manager.

III. Until Wesnoth 2.0 is released, only Chapter I of this Constitution shall apply to Project Haldric, which may opt to have its own document defining its structure. The designation and release of Wesnoth 2.0 must be done through unanimous agreement between the Project Council, the Wesnoth, Inc. Board, and the Project Haldric development team.

Rationale: Project Haldric is its own special thing for the time being, with its development team considered separate from the rest of the Battle for Wesnoth Project minus overlaps.