Leaderboard

This is wrong. Athenian cavalry were almost always used for skirmishing, scouting, and chasing down routing enemy troops. Athenian cavalry was never used a shock troops in pitched battle. Oh, that's embarrassing. Thanks for pointing that out, I will correct it.

Having enjoyed the game a lot, I recently thought that I would look to jump in and start helping by picking up some issues and seeing if I could fix them. 0-AD is a fantastic game, and the amount of work that has gone into it is amazing. However, there are a few friction points that may not be obvious to those that have been working with the project for a while. Personally I cannot wait until decisions around git hosting and development workflow changes (many of which are impacted by work associated with this thread) are implemented. Some thoughts about the current process and the suggested changes from someone new to the project: Having read through this thread, I understand the requirement to self host. Gitea or https://forgejo.org are great alternatives, but there has to be a realisation that to attract and enable new developers the Github model is the "normal" workflow for your target future developers (me included). Any deviation will become a point of friction. And one more point to make on this...if GitHub were to disappear or become onerous from licensing point of view, due to its size and ubiquity transferring to another service would most likely be both automated and trivial for the services that are not already interoperable such as git (ie issue tracking, pages, CI etc). This, from my point of view, makes it a negligible and easily mitigated risk. The current approach (SVN, patch files on issues, trac etc) is such a _massive_ issue to attract and enable new developers. Many developers have _never_ used svn. They have spent their entire careers using Git and Github, PRs are normal, branching and forks are "the only way". I am originally from the rcs/cvs generation and have spent a lot of years as a build engineer, and it was jarring to have to find and download a bunch of patch files attached to Trac issues and apply them in an attempt to even build the code. PRs, a consistent git-based branching mechanism, issues alongside the code (not Trac) and frequent merges/CI builds would make things significantly simpler. git-lfs, from my experience, can solve a bunch of the issues with large files. It is mainstream, can be self hosted, and is seriously mature now. It really can be a significant part of the solution. The build process is problematic. If you can build it in CI, it should be possible to replicate locally...and ideally CI is a _very_ slim shim around default developer workflow. Jenkins is a great choice, but it would be awesome if developers could model a build environment on the CI process really easily. It should be (almost) as simple as checkout and run single file. Moving this front and centre to development process would again simplify the onboarding process. I have been trying to build 0-ad on multiple OSs (mainly Mac) for the best part of a week, and still hitting issues that require patches or workarounds. Really keen on seeing the project become much more accessible to other developers, and happy to help where I can!