Qtfred special points

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,27 @@
+# Code of Conduct
+
+## Our Standard
+
+OFP is a technical community. Participation is expected to be substantive, good-faith, and respectful. We are here to build software together.
+
+Specifically:
+
+- Engage with ideas, not people. Critique code and proposals, not contributors.
+- Document your reasoning. "No" without explanation is not a useful contribution.
+- Assume good faith until evidence says otherwise.
+- Recuse yourself when you have a personal stake in a decision.
+
+## What is not acceptable
+
+- Personal attacks, harassment, or sustained hostility toward any contributor.
+- Blocking contributions without documented technical reasoning.
+- Using contributor access to serve personal or project interests at the expense of the community queue.
+- Conduct that would make a reasonable person unwilling to participate.
+
+## Reporting
+
+Reports go to the active Maintainers via GitHub Discussion (public) or direct contact (private, if necessary). Maintainers respond with documented reasoning. A Maintainer who is the subject of a report recuses themselves from its handling.
+
+## Enforcement
+
+Consequences scale with severity and pattern: documented warning, temporary suspension of merge/approve authority, removal from the contributor ladder. All actions are documented publicly unless privacy requires otherwise.

.github/DISCUSSION_TEMPLATE/feature_request.yml

@@ -0,0 +1,21 @@
+title: "[Feature Request] "
+labels: ["feature-request"]
+body: |
+  ## Problem Statement
+
+  What problem does this solve? Describe the gap, limitation, or friction you or others are experiencing.
+  Be specific - who encounters this, and when?
+
+  ## Proposed Solution
+
+  What would you like to see implemented? Describe the behavior, not the implementation.
+  If you have implementation ideas, include them, but the problem statement is what gets the request accepted.
+
+  ## Mod and Player Impact
+
+  Which mods, campaigns, or players would benefit from this?
+  Links to existing discussions, forum threads, or community requests that support this are helpful here.
+
+  ## Additional Context
+
+  Anything else relevant - prior art in FSO or other engines, technical constraints you're aware of, related requests.

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,57 @@
+name: Bug Report
+description: Report a bug in the OFP engine build. Feature requests belong in Discussions, not here.
+labels: ["bug"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        **This tracker is for bugs only.** If something isn't broken (it's a feature request, a question, or a proposal) please open a [Discussion](../../discussions) instead.
+
+  - type: textarea
+    id: description
+    attributes:
+      label: What happened?
+      description: A clear description of the bug.
+      placeholder: Describe what went wrong.
+    validations:
+      required: true
+
+  - type: textarea
+    id: reproduction
+    attributes:
+      label: Steps to reproduce
+      description: How do we make this happen?
+      placeholder: |
+        1. Launch with mod X
+        2. Load mission Y
+        3. ...
+    validations:
+      required: true
+
+  - type: textarea
+    id: expected
+    attributes:
+      label: Expected behavior
+      description: What should have happened?
+    validations:
+      required: true
+
+  - type: textarea
+    id: environment
+    attributes:
+      label: Environment
+      description: OFP build version, OS, and any relevant mod or configuration details.
+      placeholder: |
+        OFP version:
+        OS:
+        Mods active:
+    validations:
+      required: true
+
+  - type: textarea
+    id: logs
+    attributes:
+      label: Logs or screenshots
+      description: Attach fs2_open.log or relevant screenshots if applicable.
+    validations:
+      required: false

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,8 @@
+blank_issues_enabled: false
+contact_links:
+  - name: Feature Request
+    url: https://github.com/ofp-fs2open/fs2open.github.com/discussions/new?category=feature-requests
+    about: Feature requests and proposals belong in Discussions, not Issues.
+  - name: General Discussion
+    url: https://github.com/ofp-fs2open/fs2open.github.com/discussions
+    about: Questions, roadmap discussion, and development conversation.

.github/workflows/build-release.yaml

@@ -9,6 +9,8 @@ jobs:
   create_release:
     name: Create GitHub release
     runs-on: ubuntu-latest
+    permissions:
+      contents: write   # required to create the GitHub release (repo default token is read-only)
     steps:
       - name: Create Release
         id: create_release
@@ -30,7 +32,8 @@ jobs:
           tag_name: ${{ github.ref }}
           release_name: Release ${{ github.ref }}
           draft: false
-          prerelease: false
+          # Any tag with a - suffix (RCs, date-stamped nightlies like 26_1_0-20260713) is a prerelease; a clean release_MM_mm_bb is a full release
+          prerelease: ${{ contains(github.ref_name, '-') }}
 
   build_linux:
     strategy:
@@ -98,6 +101,8 @@ jobs:
     needs: build_linux
     runs-on: ubuntu-latest
     container: ghcr.io/scp-fs2open/sftp_upload:sha-ab87451
+    permissions:
+      contents: write   # required to publish assets to the GitHub release
     strategy:
       matrix:
         arch: [x86_64, arm64]
@@ -273,6 +278,8 @@ jobs:
     needs: build_windows
     runs-on: ubuntu-latest
     container: ghcr.io/scp-fs2open/sftp_upload:sha-ab87451
+    permissions:
+      contents: write   # required to publish assets to the GitHub release
     strategy:
       fail-fast: false  # Run the other jobs in the matrix instead of failing them
       matrix:
@@ -412,6 +419,8 @@ jobs:
     needs: build_mac
     runs-on: ubuntu-latest
     container: ghcr.io/scp-fs2open/sftp_upload:sha-ab87451
+    permissions:
+      contents: write   # required to publish assets to the GitHub release
     strategy:
       matrix:
         arch: [x86_64, arm64]

.github/workflows/post-build-release.yaml

@@ -27,17 +27,15 @@ on:
 
 env:
   GITHUB_REPO: ${{ github.repository }} # repo this workflow was called from
-  INDIEGAMES_USER: ${{ secrets.INDIEGAMES_USER }}
-  INDIEGAMES_SSHPASS: ${{ secrets.INDIEGAMES_PASSWORD }}
   NEBULA_USER: ${{ secrets.NEBULA_USER }}
   NEBULA_PASSWORD: ${{ secrets.NEBULA_PASSWORD }}
-  HLP_API: ${{ secrets.HLP_API }}
-  HLP_KEY: ${{ secrets.HLP_KEY }}
+  NEBULA_PRIVATE: ${{ vars.NEBULA_PRIVATE }} # 'false' publishes publicly; unset/anything else = private
+  NEBULA_USE_URLS: ${{ vars.NEBULA_USE_URLS }} # 'true' registers GitHub URLs (needs URLS_FOR); else upload to Nebula
   RELEASE_TAG: ${{ inputs.releaseTag }}
 
 jobs:
   post_builds:
-    name: Post builds on Nebula and the forums
+    name: Post builds on Nebula
     runs-on: ubuntu-latest
     steps:
       - name: Caller
@@ -62,12 +60,10 @@ jobs:
           WINDOWS_RESULT: ${{ inputs.windows_result }}
           MAC_RESULT: ${{ inputs.mac_result }}
           GITHUB_REPO: ${{ github.repository }} # repo this workflow was called from
-          INDIEGAMES_USER: ${{ secrets.INDIEGAMES_USER }}
-          INDIEGAMES_SSHPASS: ${{ secrets.INDIEGAMES_PASSWORD }}
           NEBULA_USER: ${{ secrets.NEBULA_USER }}
           NEBULA_PASSWORD: ${{ secrets.NEBULA_PASSWORD }}
-          HLP_API: ${{ secrets.HLP_API }}
-          HLP_KEY: ${{ secrets.HLP_KEY }}
+          NEBULA_PRIVATE: ${{ vars.NEBULA_PRIVATE }}
+          NEBULA_USE_URLS: ${{ vars.NEBULA_USE_URLS }}
           RELEASE_TAG: ${{ inputs.releaseTag }}
         run: python ci/post/main.py release
 

COMMUNITY_QUEUE.md

@@ -0,0 +1,50 @@
+# Community Queue
+
+This is the canonical list of Queue-Accepted feature requests, ordered oldest-accepted first.
+
+Contributors implementing features should draw from this list, working from the top down. If you skip an item, document why in your PR description.
+
+---
+
+## How to read this list
+
+| Position | Discussion | Accepted | Status |
+|----------|------------|----------|--------|
+| 1 | [Title](#) | YYYY-MM-DD | Open |
+
+**Status values:**
+- **Open** — Available for any contributor to pick up
+- **In Progress** — Being actively worked; link to PR in the Discussion thread
+- **Merged** — Done. Will be removed from the active queue and noted in the relevant release milestone.
+
+---
+
+## When skipping ahead is fine
+
+Working top-down is the default, not a rule. Picking from anywhere in the queue is welcome when you have a good reason — just note it briefly in your PR description. Common acceptable reasons:
+
+- **Scale matches your availability.** You have a focused window (e.g. a few free days this week) and a lower-priority item is the right size to finish in that window, where a higher-priority item is not. Better to land a smaller item cleanly than to start a multi-day effort you can't see through.
+- **Mismatched skillset.** You're a graphics person and the top item is a netcode rewrite. Doing what you're good at lands faster and at higher quality than grinding through unfamiliar code.
+- **Code locality.** You're already deep in a subsystem for another PR and a lower queue item touches the same files. Bundling avoids re-paging-in the context later.
+- **Unblocks a higher-priority item.** A lower item is a real prerequisite for one above it. Doing it out of order is the correct order.
+- **New-contributor warmup.** First-time contributors picking a smaller item to learn the build, codebase conventions, and PR process before tackling something larger.
+- **External coordination.** A mod team or release is blocked on a specific item that isn't at the top.
+
+---
+
+## Active Queue
+
+*The queue populates as feature requests are reviewed and accepted. Check [Feature Requests](../discussions?category=feature-requests) for pending requests under review.*
+
+---
+
+## Notes for contributors
+
+- Pick up an Open item by commenting in its Discussion thread that you are working on it.
+- Update the Discussion thread with a link to your PR when you open one.
+- If you need to abandon an item, say so in the thread so it returns to Open status.
+- Questions about queue ordering or item eligibility go in the Discussion thread for that item, or in [General Development](../discussions?category=general-development).
+
+---
+
+*This list is maintained by OFP Maintainers. Last updated: see edit history.*

CONTRIBUTING.md

@@ -0,0 +1,94 @@
+# Contributing to the Open FreeSpace Project
+
+Welcome. OFP is a community-governed fork of FreeSpace Open. This document covers how to contribute code, how the Community Queue works, and what to expect from the review and merge process.
+
+---
+
+## Before You Start
+
+- **Bug fixes** are always welcome. Open a PR, get it merged. No prerequisites.
+- **Feature work** should draw from the Community Queue (see below). Personal features are allowed but subject to reviewer prioritization.
+- All contributions must be compatible with FSO licensing terms. New OFP-originated contributions are released under the Unlicense.
+
+---
+
+## The Community Queue
+
+Feature requests live in [GitHub Discussions](../../discussions). The Community Queue is the ordered list of accepted, active feature requests that contributors draw from when choosing what to implement.
+
+### How a request enters the Queue
+
+1. Open a Discussion using the Feature Request template (problem statement, proposed solution, mod/player impact).
+2. The community engages — upvotes, comments, refinements.
+3. A Reviewer or Maintainer marks it **Queue-Accepted** when it meets the bar: clearly defined, technically feasible, and demonstrably wanted by currently active community members.
+4. It enters the Queue ordered by the date it was accepted.
+
+### Working the Queue
+
+Draw from the Queue **oldest-accepted first**. If you skip ahead, document why in your PR description. Acceptable reasons are narrow: you lack the technical background for the oldest items, or your expertise is specifically needed elsewhere. Maintainers may push back if skips become a pattern.
+
+### Stale requests
+
+A request can be marked **Stale** if the original author and supporters have been inactive for over a year with no meaningful recent engagement. Stale requests move to a Stale Discussions category and can be reactivated by any active community member. Reactivated requests re-enter the Queue at the back.
+
+---
+
+## Code Review Matching
+
+OFP operates on community reciprocity. Review bandwidth is a shared resource. Contributors who consistently participate in reviews or Queue work may be prioritized when Maintainer bandwidth is limited.
+
+Community contribution means any combination of:
+- Meaningful code reviews on other contributors' PRs
+- Implementing features from the Community Queue
+
+There is no quota. Two Queue implementations and zero reviews is fine. Zero Queue implementations and several substantive reviews is also fine. Maintainers exercise judgment publicly and with documented reasoning.
+
+**Bug fixes are always exempt.**
+
+---
+
+## Contributor Ladder
+
+### Contributor
+**Eligibility:** One or more merged PRs.
+**How:** Self-nominate or be nominated in a public GitHub Discussion. Approved by Maintainer consensus.
+**Authority:** None beyond submitting PRs.
+
+### Reviewer
+**Eligibility:** 5 or more merged PRs, plus meaningful participation in at least 3 code reviews on other contributors' work.
+**How:** Self-nominate or be nominated in a public GitHub Discussion. Approved by Maintainer consensus.
+**Authority:** Can approve PRs. Cannot merge.
+
+### Maintainer
+**Eligibility:** Active Reviewer and code contributor for at least 6 months, demonstrated consistent good judgment in reviews, and active participation in RFC discussions.
+**How:** Self-nominate or be nominated in a public GitHub Discussion. Approved by Maintainer consensus.
+**Authority:** Can merge PRs. Responsible for Queue management and RFC rulings.
+
+Good judgment means: reviews that catch real issues, RFC feedback that is constructive and technically grounded, no pattern of blocking contributions without documented reasoning. The public record is the evidence.
+
+### Removal
+
+Any tier can be lost for inactivity (12 months with no activity, 30-day notice) or through a documented conduct or judgment process. The process is the same as promotion: public, reasoned, and on the record.
+
+### Recusal
+
+A Maintainer or Reviewer with a direct personal stake in a decision recuses themselves and says so publicly. Direct personal stake means: the PR or RFC primarily serves their own mod or project, there is documented ongoing conflict with the contributor involved, or they authored the code under review.
+
+A recused Maintainer may still comment technically but does not vote or merge. If recusal leaves fewer than two Maintainers able to rule, the decision opens to a community vote in the relevant Discussion thread. Any active Contributor or above may vote.
+
+---
+
+## Submitting a PR
+
+1. Fork the repo and create a branch from `main`.
+2. Write clear commit messages.
+3. If implementing a Queue item, reference the Discussion in your PR description.
+4. If skipping a Queue item, explain why in your PR description.
+5. Ensure CI passes on Linux, Windows, and macOS before requesting review.
+6. Request review from a Reviewer or Maintainer.
+
+---
+
+## Code of Conduct
+
+See [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md).

GOVERNANCE.md

@@ -0,0 +1,50 @@
+# OFP Governance
+
+This document describes how the Open FreeSpace Project makes decisions, manages its contributor ladder, and handles conflict.
+
+---
+
+## Principles
+
+- Trust and authority are earned through demonstrated contribution, not granted socially.
+- All decisions of consequence are made publicly and with documented reasoning.
+- The Community Queue represents accumulated community need. It can be thought of as a roadmap.
+
+---
+
+## Decision Making
+
+Most decisions happen in the open: PR reviews, Discussion threads, RFC discussions. The default process is lazy consensus. If no one objects with a documented reason within a reasonable window, the decision stands.
+
+Contested decisions escalate to a Maintainer vote in the relevant Discussion thread. Maintainers vote publicly. Majority rules. Ties go to community vote (any active Contributor or above may participate).
+
+---
+
+## RFCs
+
+Significant architectural changes, governance amendments, or anything that would affect the mod ecosystem broadly requires an RFC (Request for Comments) opened as a GitHub Discussion. RFCs stay open for a minimum of two weeks before a ruling. Maintainers are expected to participate and document their reasoning.
+
+---
+
+## Release Process
+
+OFP targets a regular release cadence. Proposed timelines are posted as GitHub Discussions at least six weeks before a feature freeze. Community members may comment on scope, timing, and what gets held versus shipped. Maintainers make final calls but explain decisions that go against stated community preference.
+
+Releases include:
+- Features from the Community Queue that are merged and stable
+- Bug fixes
+- Upstream FSO merges that have passed integration testing
+
+---
+
+## Upstream Sync
+
+OFP merges from FSO upstream weekly. Maintainers may defer a specific week's merge if upstream is mid-refactor, with a note posted in the sync thread. Deferred merges are picked up the following week.
+
+Changes that conflict with OFP's architectural decisions are evaluated case by case. The decision to accept, adapt, or exclude an upstream change is documented publicly in the sync thread.
+
+---
+
+## Amending This Document
+
+Governance changes require an RFC with at least two weeks of open comment and consensus among active Maintainers.