OpenLRR Success

OpenLRR Success

One of the reasons OpenRCT2 and other similar projects succeeded is because of their popularity and accessibility. With more people hearing about it and giving it a try, more people were taken on board the open source project to help contribute.

User Accessibility

• Public (automated) builds should always be available for the end user.
• Builds should be easy for the end user to setup and instantly run.
• Consider making an installer/launcher programs.
  • Through it's lifetime, OpenRCT2 had a handful of these programs that would handle downloading/updating to the latest build version. This QoL feature alone waiting for the next update to fix pesky bugs, or get access to an up-and-coming feature.
• Stable builds should be planned and released at certain milestones in development. The goal is to remove as many bugs introduced by OpenLRR as possible and avoid risking introduction of new bugs as the stable milestone nears.
  • This also means limiting new feature additions or changes when the milestone nears.
• Useful error logging when a crash occurs is important, to make a CTD feel less hopeless for the end user, and also help crowdsource bug hunting.
• Compatibility for all game and save data is essential while OpenLRR is in its early stages. A user should be able to switch from OpenLRR back to LegoRR without any negative effects.

Programmer Accessibility

• The OpenLRR project should be well-documented so that a new programmer looking to contribute does not feel alienated, or unskilled enough to help.
  • CONTRIBUTING.md should be added for explicit instructions to guide the programmer to making their own contributions.
  • BUILDING.md should be added for explicit build instructions (in the scenario that external build steps are needed in the future).
  • A markdown document explaining the coding standards used by OpenLRR should be included to help the user decide on formatting.
  • Add wiki pages on the internal architecture and API's of LegoRR, to help explain what the programmer is looking at, and what LegoRR is doing.
• All changes should be performed through pull requests, using uniquely-named branches to describe the PR.
  • Choose and stick with a style for merging PRs (i.e. merge commit, rebasing, squashing, etc.)
• Individual help should be available when a contributor is stuck, or unsure what to do. This should extend to:
  • Coding standards and guidelines.
  • Walking the programmer through adding a new code module or function so that it is in an appropriate place.
  • Helping the programmer determine where certain functionality they are looking for is located. i.e.
    • If they need to get world 3D coordinates for the mouse, direct them to the appropriately labeled transform function.
    • If they want to re-implement the unfinished flood water, direct them to the Water module.
• Marking GitHub issues as "Good first issue" is important to help those that are lost and unsure how to contribute. (See Issues section for more)
• Debugging for the programmer is also important. Ways to help diagnose crashes, or determine why new code isn't working are essential.
  • Although print statements are reasonable, frameworks should be put in place for more advanced functionality that the programmer may commonly need.

GitHub Issues

• GitHub issues should be created for all known original bugs. When possible, these bugs should be described in explicit detail, if the cause is known.
• Issues should describe ways to reproduce the bug, even if it's not a 100% sure-fire method.