Development is currently driven by the needs and wishes of the various contributors.
In fact, almost all public discussion currently happens on that list.
You can get the sources from the FriCAS git repository:
git clone http://github.com/fricas/fricas.git
Code review policy¶
A patch should go in as reviewed—if there is need for change new patch should be provided.
Obvious things can go in without review. Really minor changes to patches also can go without extra round of review.
Of course patches should satisfy technical requirements (pass test, update documentation when appropriate, contain tests for changes).
Patches should be logical unit of change. Do not join unrelated things unless it is a cleanup type patch that functionally should be a no-op.
Do not split patches that implement some functionalty into small steps—if several patches have a common purpose and there are dependencies between them, then they probably should go in as one patch. This is not a hard rule, it make sense to split really large patches (say more than thousend lines) and sometimes part of the functionality is ready and may be committed before the feature is complete.