This repo is a reference and learning resource and everyone is invited to contribute.
There's a general development strategy that's driven by @EduardoPires / @BrunoHBrito, who chooses, or defines criteria for choosing, the issues to include in the codebase, given a bunch of constraints and other guidelines.
There are no explicit coding standards so pay attention to the general coding style, that's (mostly) used everywhere.
In order to help manage community contributions and avoid conflicts, there's a Issues Approved List so pick one to help us.
That's not too easy to define and there are no clear criteria right now but, probably, changing "a couple" lines of code in one file would not qualify while changing "a bunch" of files would.
We'll all be learning in the process so we'll figure it out somehow.
-
Issues are managed as usual with the regular issues list, just like any other repo.
-
Community members can propose themselves to code an issue.
-
Issues with the help wanted label is the best choice for you!
-
Before start coding use the issue to talk with the team and propose your solution.
There's not a tests policy in the project at this moment, but it'll be greatly appreciated if you include tests.
All contributions must be submitted as a Pull Request (PR) so you need to fork this repo on your GitHub account.
Since this is a learning resource, some design decisions have favored simplicity to convey a pattern, over production-grade robustness.
We hope this helps us all to work better and avoid some of the problems/frustrations of working in such a large community.
We'd also appreciate any comments or ideas to improve this.