-
Notifications
You must be signed in to change notification settings - Fork 304
Project Charter and Policies
The goal of this project is to implement the Pathfinder 2e (PF2e) ruleset on Foundry Virtual Tabletop (Foundry VTT) as written, while not unnecessarily impeding the ability of people to create additional homebrew content. Supporting official content is, however, the driving factor and the expectation is that the majority of the work volunteered is to that end. The project will not stop someone from extending the ruleset in a logical way that fits the project design, but evaluation and integration should be expected to be lower priority.
The goal of the system is to implement the core ruleset, include as much content as available under the Open Gaming License (OGL) and the Community Use Policy (CUP) licenses as is possible with the maximum amount of system-based quality of life (QoL) automation as defined below. The scope includes Adventure Paths, Adventures, Pathfinder Society (PFS) Quests, PFS Scenarios, Bounties, Paizo Blog Posts eligible under the CUP or OGL, Paizo Free Material, and Paizo material released specifically under the OGL and CUP. Localization and accessibility are considered part of scope and should be included, where practical, in design decision making to permit the maximum number of people to play the system, balanced with not overburdening volunteer developers.
The system is intended to be a community-based implementation. Paid compensation for work done under this project is not to be necessarily expected. Code ownership within this project is under the guidelines given in the license applied to the project. The expectation is that copyright of the code remains with the original author, but that the code can be used without compensation in other projects as outlined within the license. This paragraph is provided as plain-text and the actual terms of the license are expected implicitly to be read and understood by any contributor prior to committing code. The overall goal of the project is to enable, but not necessarily profit from, commercial material being published for PF2e on Foundry.
The project shall be steered overall by an elected group. These people will have the ability to merge code to the project and will be responsible as detailed below. The team will consist primarily of one Project Manager, two to three Coding Leads (with three preferred), two to three Data Entry Leads. Project decision-making will ultimately rest with the project manager, but the expectation is that they exist primarily to ensure that the spirit of the charter is maintained, that the project stays aligned with Paizo design intent, and that interests beyond the project are addressed. The majority of decision-making is expected to be by majority vote of the code and data entry leads, with the project manager breaking ties or exerting a veto authority.
Additionally, Foundry Gaming LLC and Paizo Inc will be invited to have one person each join the steering committee, at their option, as voting members.
Non-voting members: Ex Officio (non-voting) members of the project steering team, who are invited to discuss and influence, may include groups or organizations contracted to produce official licensed content for PF2e on Foundry VTT. These positions are appointed optionally and at invitation of the Project Manager. A representative of the module creation community and the translation community may also be invited at the invitation of the Project Manager. Other Ex Officio members may be appointed on majority vote of the project steering team.
Project Communications: Project business shall be accomplished primarily through the use of the repository and through the “Pathfinder 2e FoundryVTT Community Discord”. Official communication on behalf of the project is to be done by the Project Manager. This does not stop any member from offering a point of view publicly (on discord or in any other media), but if it is divergent with the position of the system they must state that they are speaking on their own behalf. Additionally, this does not bind either Foundry Gaming LLC nor Paizo Inc from commenting on the system as long as it is clear that any of their communications are similarly on their corporate behalf and not that of the project. Release messages may be done by any member of staff eligible to do the release on behalf of the project, and may be repeated on other discords or on social media as appropriate. A community member or other steering committee member may be delegated by the Project Manager to act as the official spokesperson for the project.
Removal of steering committee members: Membership to the Steering Committee shall be via democratic election over Discord in the case of members appointed from the community. Foundry Gaming LLC shall appoint and remove its own representative at their discretion. Paizo Inc shall appoint and remove its own representative at their discretion. Eligible voters for positions filled by members appointed from the community are those who hold the system contributor, data entry contributor, development coordinator, data entry coordinator or admin roles on the Discord. Anyone may be nominated. Members of the Steering committee serve the community at their leisure and may resign at any point. The project manager may be removed by supermajority vote of the remainder of the steering committee (66% of voting steering committee members concurring – The PM is ineligible and not counted in this vote). A code lead or data entry lead may be removed at the discretion of the project manager with concurrence of one other development coordinator, for the development coordinator position, and one other data entry coordinator, for the data entry coordinator position assuming that there is more than one person in each of those roles. Ex officio members who are appointed at the discretion of the committee may be removed at any time by the project manager.
Below are the standards expected for code submitted to the project. For any ambiguities, the standard shall be to request clarification from the respective lead or the project manager. Acceptance of any code into the repository is never guaranteed, and failing to meet with the standards or design philosophy is grounds for not accepting a merge request. The project will endeavour, in such cases, not to impede a module implementing out-of-scope projects from overriding a module, but compatibility or design changes to allow those are also not guaranteed, especially if they run contrary to Paizo PF2e rules as written(RAW).
Code Standards: The project will enforce standards via typescript and linting via prettier. Naming and coding conventions for the project will be detailed in a document written and maintained by the code leads. Data entry standards will be detailed in a document written and maintained by the Data Entry leads. Any merges that do not correspond to these requirements will be flagged, commented upon, and should action not be taken in a timely manner, closed.
Amendments to the Project Charter and Policies: Other than code and data entry standards, this document can be amended only by supermajority vote of the voting steering committee members.
Project Organizational Methodology: The project will be organized in two-week sprint cycles which will be referred to as iterations. For major book releases, the project may be realigned. Releases shall normally occur every two weeks on Friday (defined in Pacific time, as that is the location of Paizo Inc’s physical office). Deviations from the two-week cycle can only be approved by the Project Manager. Releases on GitLab should be appropriately tagged by either the code author (should they have permission) or the reviewer. Coding iterations are to be approached with a best-effort, not a mandatory requirement, and this is emphasized by using the term iteration instead of sprint. Merged code should be done in such a way that it does not intentionally block a release. The last two dates of the iteration cycle should normally be for bugfixes and data entry – not new features. Testing is expected to occur during this portion of the cycle. Any new features added in this window require approval of the project manager. Each iteration shall have goals and development or data entry coordinators assigned to them. This does not restrict any person from working in any capacity or on any portion – it is meant for organizational and informational reasons only.
Releases: Releases may be made to master after approval of the majority of the Steering Team by the steering team. No other person shall push a release update, even if they have the permissions available, although they may do so with explicit administrative oversight (such as in an urgent situation or as training on how to do so in case of future membership in the steering team). Update and release authority to the Foundry admin system rests solely with the project manager.
Merge Requests and Restrictions: The titles of merge requests will be done in a manner that completes the following sentence: “If this MR is accepted, it will...”. The title should be written so that it can be directly added to a change log. Failure to write in such a manner is grounds for closure without review, although every effort shall be made to contact the author. Merges to the system should be reviewed by an eligible reviewer (nominally defined as the development or data entry coordinators, although others may be granted this designation by the Project Manager) within 72 hours. Any MR that is stale for more than 72 hours (meaning no review or developer response) may be closed. Should there be a need to leave a MR open longer, the project manager may grant such a request. An example case would be a code merge that is delayed awaiting the next iteration or a data-entry or bugfix release. Merge requests other than a merge to master for release shall not normally be done by the Project Manager. Merge requests shall require approval of one development coordinator for code-based merges or data entry coordinator for data-entry based merges other than the person merging. Senior project members may be designated by the development or data entry coordinators to review code or data entry as an approver, but not as a merger and this shall satisfy the approval condition. A supermajority of the leads for an area (which may include the Project Manager if it is not possible to form a supermajority otherwise) must agree for someone to be added as an approver for the repository. Self-approval is not permitted, but merging code you wrote after approval is permissible. It is also acceptable for the approver to merge if the original author has the ability to approve code.
Feature Prioritization: As this is a volunteer project, people are free to work on what they believe benefits themselves most and contribute to the system as long as it meets with the system design goals. For the iterations, features will be prioritized based on current and future needs, including changes to the core Foundry VTT software, new material releases from Paizo, and commercial needs. The Project Manager is expected to be the gatekeeper on features for inclusion and exclusion, but shall develop the iteration plans and long term objectives in consultation with the development and data entry coordinators based on feasibility, difficulty and expected architecture changes. An effort will be made to maintain a list of goals, as well as a list of “new contributor” features that are not necessarily high priority, but that are low in difficulty. On request of a contributor, a decision on inclusion into the system or module can be made before authorship. New features may be requested to be made as modules until stable, and then added or rewritten for inclusion into the system and this should not be seen as abnormal.
Automation: The system automation is designed to be low-automation. By that it is meant that any action a player would take at a table, such as rolling dice or making a decision, is not automated by the core system. Automation that is acceptable causes gameplay to flow – so things that automatically adjust modifiers and math that is secondary to the roll action itself. Automating is only done when essentially 100% of the cases can be covered. Any automation that is wrong more than a fraction of a percentage of a time shall not be included. The baseline of automation in this system is informative: The automation will compute and tell you a result and display the relevant information on how it arrived at that result, but it will not enforce any result without input from the affected player or GM.
As an example, for automation for spells clicking cast should generate the ability to place a template, but the placement of the template should simply alert the users of the area of effect of the spell, not automate the action of rolling the save. The saves can be made easily rollable from the chat, or the display of the request to roll a save would be acceptable within the system instead. The saves can then display a degree of success, but any effects as a result of the roll or other change to the status of an actor would still need confirmation to be applied. The confirmation could be automated to do so in a single interaction, but should not be done automatically.
Pathfinder Society Entry: Pathfinder Society play requires strict adherence to non-player characters (NPCs) as-written. For NPCs in adventures or bestiaries, reasonable standards and interpretations can be made by the data entry team and approved by at least one of the data entry coordinators. For society-related NPCs, regardless of obvious error, unless an errata has been issued by the organized play team the NPC must be entered exactly as written without any interpretation.
Homebrew policy: Variants specifically stated in Paizo publications (Core rulebook, gamemastery guide, future books) are not considered homebrew and can be worked on or added to the core system. RAW is to be implemented as much as possible, but every attempt to reasonably allow for an individual or module to change RAW is desired, but not required, of the project. Essentially, the ruleset is provided and calculated but not rigidly enforced. Long term system goals do include facilitating homebrew with the intention of not including it in the base system. Should there be a case where rules as written are ambiguous (such as how runes are handled by Automatic Bonus Progression) the Project Manager shall be the arbiter of how this is to be implemented and if options can be provided within the RAW-mindset of the system framework.
Localization: As part of being an inclusive, international community and ensuring that PF2e can reach as many groups as possible, the project will endeavour to be as translation-friendly as possible on a best-effort basis. The project will not distribute any language other than English as Paizo provides products only in English.
As one of the goals of the system is that Paizo or an agent designated by them be able to produce Foundry VTT content commercially for the PF2e system, there exists the very real possibility of paid work. Any such, work on the system requires that the steering committee be advised, and that such paid work is compatible with the system if any code be included into the project. Additionally, any code committed must be done under the license restrictions of the project, cannot be more restrictive, and may be necessarily modified in future.
Assignment of Paid Work: Should work be offered publicly, a requirement of accepting paid work is a history of volunteer commitments to the system. This is done to ensure that anyone accepting paid work is knowledgeable of the code base and the data entry standards to maintain a uniform and positive experience on PF2e made for Foundry VTT. Should a decision need to be made, it will rest with the Project Manager. The Project Manager shall be ineligible to take paid work personally, with the exception of a 100% approval secret ballot vote by all voting members of the steering committee. Members may abstain from this vote, and are expected to abstain should there be a personal conflict of interest.
Paid Work by Contract: A community member or third party may want to commission a specific feature for the system that is either not a priority or not on the system roadmap. This is permissible, although there is no guarantee that they system will incorporate such a feature. As such, work like this should be framed as a module that may be integrated into the PF2e core software.
Community Donations: It is the policy of this project not to directly accept financial compensation. As such, should a community member wish to provide compensation to the project it is recommended that they donate to a local charity in the name of project, or support the project during periods of official fundraising such as Extra Life. Designation of an event as an officially supported fundraiser shall rest with the Project Manager.