Contributing

Anyone is welcome to submit a PR, there are no strong guidelines.

You do not need to get substantially involved in the project to contribute. That requirement, as seen in other projects, creates a huge burden on contributors to keep track of everything associated with the project. You do not need to be actively involved in the community to become a contributor, literally the only thing required is a pull request, where people can ask for changes if you break something.

One of the main problems with most large open source projects is censorship. It is usually not 'intentional' censorship but rather a side effect of a horrifyingly slow and painful system of manual approvals, which obfuscate hidden financial motives associated with for profit entities behind the projects. Whatever the underlying reason, there is a massive censoring effect that happens under the guise of peer review and approval. That's not to say the peer review process isn't important for catching non-obvious flaws or stylistic problems or determining major architectural decisions, but rather that it often becomes weaponized to exert arbitrary control over the project.

The problem here, is identical to the block censorship problem for regular transactions. The code exists as a series of commit hashes compounding to a single value, representing the latest version. Ideally, a strong enough protocol would be able to be implemented across an arbitrary number of different code hashes or different languages, representing any arbitrary functionality for a given node -- which would effectively help solve this problem -- as censorship would be unable to compete if everyone can simply use whatever code hash they want and still participate and draw in code and fixes from other people working on the project. This problem unfortunately, has not been properly solved, although many people have attempted to describe it. It's similar to the problem Unison as a language is trying to solve, by treating every operation or reference in an AST as a hash, you could pull in references from anywhere and only check for changes.

The reality of code as it exists now -- enforces this strict requirement upon a single AST / single compilation process. In the future, there might exist some magical utopia where you can have people working on independent code hashes that can determine, via AST hash lookup, which sections they have in common, and themselves determine which fragments to accept (by signing that data.) However, that is far too large of a project and too complicated to include as part of this project.

It should be kept in mind however, that that is the ideal to strive for, which means that anyone should essentially be allowed to contribute as much code as they would like, so long as it is reasonably within the scope of the project, and does not cause obvious problems. Obvious problems being things like making the binary 10GB in size, or breaking simple verification functions, or injecting malware, etc. etc.

It is far better to have a policy that strives towards open-ness and inclusion in small projects, especially at first because the goal is to demonstrate a valuable and useful solution, rather than exclude contributors.

Please attempt to keep the code complexity relatively simple. It is much easier to validate simple code than complex code.

Partial work is absolutely acceptable to contribute, so long as it does not break existing functionality. It is better to lower the cost of contribution as opposed to discouraging or excluding contributors.

As a general guideline, please avoid using complex language features. Dumb code is better than introducing excess or unnecessary complexity. For the same reason, avoid useless abstractions. For a feature which only has a single implementation, no abstraction is necessary. For simple variations on it, parameters should be used as opposed to abstractions. Reserve abstractions only for critical functionality with many implementations required.