• How to contribute to the OpenAnubis project
  • 0. Become a contributor
  • 1. Find something interesting to work on
  • 2. Discuss your intended change
  • 3. Submit a patch
  • 4. Work with your sponsor
  • 5. Know what to expect

How to contribute to the OpenAnubis project¶

This page describes the contribution process for the OpenAnubis project. This interim process will be used until an open governance model for the project is established.

0. Become a contributor¶

Like many other open-source projects, the OpenAnubis project requires contributors to jointly assign their copyright on contributed code. If you haven't yet signed the Constructive Mathematics Contributor Agreement (CMCA) then please do so and fax it to +33-9-5680-7733, or scan it and e-mail the result to cmca(at)anubis-language.com.

The CMCA gives Construtive Mathematics (CM) and the contributor joint copyright interests in the code. The contributor retains copyrights while also granting those rights to CM as the project sponsor. You only need to sign the CMCA once in order to cover all changes that you might contribute to any CM-sponsored open-source project including not just the OpenAnubis project but also, for example, PyramIDE, and all other libraries. If you've already signed the CMCA in order to contribute to some other CM-sponsored project then you do not need to sign it again in order to contribute to the OpenAnubis project. (You can learn more about the CMCA by consulting its FAQ.)

1. Find something interesting to work on¶

The most obvious thing to work on is a bug or enhancement (RFE) about which you are passionate. Please check the "Anubis" category of the online bug database to see if your idea is already described there, and if so then use that bug/RFE's id number when writing about your work.

If you're interested in a particular area but don't have any specific ideas about what to do then feel free to post a query to the appropriate development list to ask for suggestions that match your skills and knowledge.

2. Discuss your intended change¶

Before you invest time working on a change, discuss what you're trying to do with other engineers working on the same code. They're likely to be able to offer comments and suggestions that will result in a higher-quality change and a smoother submission process. Announcing that you're working on a particular item can also help to avoid wasted effort in case someone else is already working on it.

If you're thinking of working on an existing bug or RFE then the best way to start such a discussion is to post a message to the appropriate development list with a subject line of the form

6543210: My favorite bug

where 6543210 is replaced with the actual bug or RFE id number and My favorite bug is replaced with the bug or RFE's synopsis.

3. Submit a patch¶

When your change is ready, send a message to the appropriate development list with a subject line of the form

[PATCH] 6543210: My favorite bug

where 6543210 and My favorite bug are replaced as above. If no existing bug or RFE describes your change then omit the id number and one will be created and assigned.

The message should contain three things, either directly in the body or as attachments:

• A description of the change, including a rationale for your approach and a discussion of any alternative approaches that were considered, if relevant. If no existing bug or RFE describes your change then also include a description of the problem that it solves or the need that it addresses.
• The code change itself, relative to an existing changeset in the appropriate SVN repository. The preferred form is generated by SVN's diff command. But in the worst case traditional unified diffs (-u) are okay too, at least for simple changes.
• A unit test, written for the Anubis UnitTest library, that validates your change. The test should fail when run against a build without the change and succeed when run against a build with the change. Unit tests aren't always practical, especially for changes such as performance improvements or fixes to bugs that are highly platform-dependent, but if practical then a unit test is required.

4. Work with your sponsor¶

A CM engineer whose knowledge and skills are a good match for your proposed change will be assigned as your sponsor and will reply to your message.

You can generally expect a reply within about five working days; actual response times will vary due to factors such as impending product-release deadlines, contribution volume, and holiday schedules. You should also expect a longer response time if you haven't already discussed your proposed change on the appropriate development list, since it will take more time for your sponsor to come up to speed on what you're trying to do.

Your sponsor will first evaluate your patch for correctness, compatibility, stability, performance, coding style, and overall appropriateness to the current phase of development. If your change passes inspection then your sponsor will work with you to address any minor deficiencies and then guide you through the rest of the development process, navigating the relevant internal CM engineering processes on your behalf and ultimately, if all goes well, integrating your patch into OpenAnubis.

5. Know what to expect¶

Only the best patches submitted will actually make it all the way into OpenAnubis source base. CM's goal is not to accept the maximum number of contributions possible, but rather to accept only high-quality contributions that improve Anubis Language.

If you're relatively new to the Anubis platform then we recommend that you gain more experience writing Anubis applications before you attempt to work on OpenAnubis itself. CM's aim here is to bring developers who already have the skills required to work on OpenAnubis into the existing OpenAnubis development community. The members of that community have neither the time nor the patience required to teach basic Anubis programming skills or platform implementation techniques. (CM offers formal training if that's what you're looking for.)

Builds of OpenAnubis are, for now, only being promoted to testing and thence to the OpenAnubis download area and source repository about twice a month. This means that once your patch is integrated it might not show up in the OpenAnubis sources for two or three weeks. The frequency of promoted builds will increase as we get further into OpenAnubis development cycle.