Guidelines for Contributing to QB64

[SMcNeill]

My new philosophy is to let QB64 be what the community want it to be. Even if we end up with 1000s of commands that barely get used by the majority, it is better than QB64 not being used at all. And if someone implements something incredibly stupid/unnecessary (such as a _HELLOWORLD command) the beauty of a repository is that it can always be rolled back later. Because of this philosophy, you won't see me standing in the way of any changes.

This is the way.

This is the guiding philosophy which we've faithfully followed, as set down for us by Galleon about ten years ago now.  For some reason, Cory and the folks at the QB64 Official Team like to pretend that everything we do is all part of some "Steve Show", but that couldn't be further from the truth.  Our development model is based entirely upon the practice of:

Does your idea meet all of the above criteria? If so your next steps are...

1) Code it! (make sure you note any files you change and where for your own reference)
2) Submit it.
i) If you are a QB64 repository contributor, grab the latest version of the repository, make your changes and push them  (I and the community will test the next dirty build [which is automatically created from the repository] and as long as it works, job done!) or...

ii) Become a repository contributor by asking me on the Q&A forum

The only real change we've made over the years is that now we ask folks to make a Pull Request with any changes which they're interested in implementing, so that our developers -- who Galleon called "repository contributors" -- can review such changes for stability and bug fixes, before merging the changes into our repository.

At no point is there a case of some guy named "Steve" directing everyone to go out and do one thing or another.  Each contributor contributes with the time and changes which interests them, and which they work on voluntarily.  Those that have asked to join the long term "repository contributors", are welcome into the development channels and such -- not so that we can push work onto them and make them do what we wish -- but so that those of us with more experience with the layout and style of the source can help guide them to making whatever enhancements and fixes which they're interested in.

We're not an exclusive club of old timers.  Anyone is welcome to join us, if they're interested in contributing to the project and have some idea which they think they can implement to make things better for all, and which follows the loose guidelines as laid out for us oh-so-long ago.