-
Notifications
You must be signed in to change notification settings - Fork 1
FAQ: How to Contribute
I have a few suggestions; however, don’t feel limited by them. The team is bursting with ideas and they’re open to hearing more.
Some of the eternal suggestions include creating and improving documentation, and expanding test coverage. If you feel your C language mastery is weak, test writing might be a really great way to build that skill up and contribute at the same time.
Converting popular utilities, libraries, and even full-scale applications to use capabilities would certainly be handy. The first step is to ensure that they work well with CHERI C/C++, which is often straightforward and consists of helping older code better differentiate its integer types from capability types. There are some subtleties, and the CHERI developers will be happy to help out. There is a technical report documenting CHERI C/C++.
I’m so glad you asked! Please join us on the mailing list, slack, and github. The mailing list can be found at https://lists.cam.ac.uk/mailman/listinfo/cl-cheri-discuss and if you are not from Cambridge, please ignore the scary red box and treat it as a normal mailman list. For real-time chat, there is a slack instance, and please feel free to explore the channel list. The CHERI main github page is a bit overwhelming with 120+ repositories. The two you’ll probably want to start with are the CheriBSD repository and Cheribuild repository.
I’m afraid that is a luxury that this project does not yet have. However, what we lack in organization, we make up for in engagement. Ask in slack or on the mailing list with your interest and skills, and we’ll try to match you as best we can.
If you were interested in compiling and maintaining such a list as a project, that would be a nice gift to future contributors.
As of this writing, it’s the same friendly process as above. On the bright side, there is a high level of interpersonal interaction. There’s a good chance the whole team will know your name by the time your contribution lands.
We don’t have a formal mentorship program at this stage (also a luxury of bigger projects). That doesn’t mean folks aren’t interested in helping new contributors, yet it does mean that you’ll need to be a bit more proactive about asking for help. If it helps you, you can always ask someone to mentor you explicitly. I recommend slack over the mailing list for seeking a mentor. What are the development style requirements?
The style guide for CheriBSD is the venerable, cryptic style(9), as it is for FreeBSD. There is a top level clang format file in the source tree and there exist plugins for Vim & Emacs. If you prefer VScode, as far as I can tell you’re out of luck at this time.
The other style note worth mentioning, is that since CHERI is an acronym, it is usually capitalized. CheriBSD and Cheribuild are amongst the most prominent exceptions.
There is no formal process for asking for review or who should be assigned a given review. Ideally, whoever you’re working on changes with will be able to advise you or do the review. The github suggestions are generally good, and those folks can redirect you if the algorithm makes an incorrect recommendation. If all else fails, please ask in slack and/or make a Pull Request(PR). Mark it with ‘work in process’ and with a description as informative as possible to help things move smoothly. I think I found an issue, but I’m not sure.
If you think you found something amiss, you probably did. Please let us know either by filing an issue on the appropriate github repo, or asking in slack if you aren’t sure which repo it belongs in. Thanks!
If you found something sensitive or non public? Please reach out on slack instead of github. If it’s a flaw in an upstream source, that’s a bit more sensitive and should probably be treated as nonpublic at first to be safe. If you found something like a security flaw in FreeBSD, please reach out directly on slack to Brooks Davis.
The short answer is ‘not yet’. The team is working towards a proper CoC. It’s not an overnight process. The CheriBSD group will look over the new FreeBSD one, and if it checks out, may decide to adopt it.
There is no formal or official governance model. Originating as a small research project, decisions were made by the research team. There are now numerous private contracts between various organizations that are involved, and those details are nonpublic. I understand that currently much is still sorted in closed meetings and then disseminated around.
It’s not clear at this time how much influence a volunteer contributor outside that structure can have, or what recognition is possible. It is a question the community will need to resolve as it grows and expands beyond labs and corporate research groups.
The first version of this appeared on Allison Naaktgeboren's page.