Development is currently driven by the needs and wishes of the various contributors.

Bug reports are collected through issues at github, but can also be sent to the FriCAS mailing list.

In fact, almost all public discussion currently happens on that list.

You can get the sources from the FriCAS git repository:

git clone

Better, press the fork button on the FriCAS git repository and send an ordinary Github pull request.

Code review policy

Normally patches go to the FriCAS mailing list for review or are reviewed in a Github pull request.

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.