Greetings
Given that @martins - most understandably - may not have time to dedicate to constant development of Orbiter, I think it might be worth discussing whether and how the community itself may help the project to progress. I think everyone would agree that having a single person be a gate for all the pull requests is not an optimal usage of said person's time - as well as potential blocker for many new features
There are successful games which follow this model - FalconBMS, OpenRA - so there is precedent. And with a community as passionate as Orbiter's, I think this may work well too
@dbeachy1
@Xyon
@DaveS
@jarmonik
Given that @martins - most understandably - may not have time to dedicate to constant development of Orbiter, I think it might be worth discussing whether and how the community itself may help the project to progress. I think everyone would agree that having a single person be a gate for all the pull requests is not an optimal usage of said person's time - as well as potential blocker for many new features
There are successful games which follow this model - FalconBMS, OpenRA - so there is precedent. And with a community as passionate as Orbiter's, I think this may work well too
Proposal
- Nominate 5-7 people to form a "Council" which will take control of Orbiter Open Source repo - PRs, issues, etc.
- Use GitHub repository "Project"/"Issues" feature as the means of management
- Create a "Council" group in Orbiter repo with appropriate permissions (management of issues, projects, PRs etc) - to not give full admin access
Legal status
Current Orbiter sources are published under MIT license. This means that at the very least, a derivative product can be created and published using "forked" source code. Of course, ideally we'd have original author's permission to use the original repository and all of the materials - which seems to have been the intention (given creation of a separate organisaiton on GitHub), but an explicit confirmation would of course ease things a lotSuggested members
A few names which are already known well enough in the community (and of course, if they agree to participate)@dbeachy1
@Xyon
@DaveS
@jarmonik
Questions to discuss
- Cut the current state of 'master' branch into a separate "x86-release" branch, to facilitate "the last release™"
- Merge the current WIP branches - d3d9 etc. - into 'master' and continue developing from there
- Determine 2-3 most "painful" areas with the game currently and create tickets for them
- See where that takes us...
Last edited: