Usually, when checking a #FOSS project on GitHub, project Stars it's the first that draws attention, it could be a nice popularity ref. but, personally, the first info I look for is the project CONTRIBUTORS. I think it's a good sustainability indicator. Let's talk about it! 1/n
At the very end, to keep a #FOSS project alive you need people working on that project. It could be the creator, maintainers or contributors. Anyone putting some time and effort into improving the project is welcome... really? Here my experience with #raylib... 2/n
Contribution to a project usually imply following some rules, that's one reason why a CONTRIBUTING.md file is recommended to be included in the repo: github.com/raysan5/raylib…. That file could also be accompanied by a ROADMAP.md to define the project aim. 3/n
Those files try to define the original objective and intention for the project, the background, some technical aspects like code organization or naming conventions and even recommended procedures to follow when contributing to it. My experience: some people do not read it. 4/n
In many cases, it's just small bug fixes or improvements that I can happily review in some minutes... but from time to time I receive big chunks of code with new features or library redesigns... Here comes the dilemma: accept the PR or refuse it. Not an easy decision! 5/n
My rule of thumb is maintainability. Should I be able to maintain it? What would be the technical/time cost to do that? How much makes it grow the library? In what direction? PR creator is going to maintain it? How long? Sometimes I refused great PRs just for those reasons... 6/n
So, for #raylib the best contributions are always small fixes and improvements, maybe a self-contained code example, build system tweaks or even testing reports and showcases. From time to time I merged big changes (UWP, RPI4 backends) but it requires a maintenance effort! 7/7
• • •
Missing some Tweet in this thread? You can try to
force a refresh
