There is a massive backlog of stuff needing to be developed, from unit testing to trying out the latest recurrent neural networks on the video OCR system (Tesseract OCR via CCExtractor). Many parts of the site and apps are ugly, so if you like design/UI work then there is lots to improve. If you are more admin/devops then the plan is for the server components to be able to deployed to new production environments with a few clicks straight from the CI (to a Kubernetes cluster).
The two main forms of communication are via issues on the relevant projects issue trackers, or on the development mailing list. If you are new, please make sure you have discussed with a regular committer/maintainer BEFORE you start working to avoid any time-wasting and frustration. Communicate early, communicate often.
At some point we may be forced to fork Anki (Python 3) and Ankidroid (Java) if the upstreams become incompatible with the server API. A great deal of work has been done to avoid this happening but there is no guarantee.
Work will soon start on a VLC plugin. If that is possible in Python 3 then that will be attemped first, otherwise probably C++.
Work will soon start on an e-book reader (plugin) for Android. That will be in Java.
The project uses Git and all development gets done on gitlab.com.
All code/git contributions should be signed with
git -s, which means you certify you have the right to contribute what you are contributing (see https://developercertificate.org/).
All code submissions need to have an associated issue on the relevant project. You should fork the project into your private space, do your stuff then submit a merge request, mentioning the issue.
The project has fast-forward merge activated for all repos. This presupposes a particular development style but makes for much, much nicer histories.
What should I work on?
There is heaps of cool stuff to do or, because you also probably want to use it to learn a language, just the stuff that you care about - it’s all good.
Please bear in mind that your code submissions MUST be accompanied by proper tests. Untested code will not be merged. Coverage is still poor, so if that means that you have to also write tests for someone else’s code then please accept that author’s apologies - tests are necessary and they gots to get wrote somehow… Someone will write tests for everything at some stage so you can also wait if you don’t want to write tests for someone else’s code. But please do! :-)
The build system
Transcrobes uses Gitlab for pretty much everything. Docker images are also pushed to Dockerhub but to be honest that is mainly because China’s GFW is currently blocking Gitlab’s IPs on Google Cloud for the registry. Everything that it’s possible to do on Gitlab is done there, including hosting this site, the distribution of the web extensions, the Helm chart repository.
A lot of stuff is already automated, and the remaining things will be automated soon. The lead maintainer worked for a quite a while as a Site Reliability Engineer. So anything that is not automated is like a splinter wedged in his mind :-).
Releasing is done automatically when ever a semver-compatible tag is pushed to the master branch for all projects. The docker images get built and pushed to Gitlab and Dockerhub, the browser extensions get built and copied to this static site, the chart repo gets built and a regenerated index published to the public charts repo. There are still a few rough edges but as time goes on the kinks will be ironed out.
Automate all the things!