Contributing to Calendar is easy, and we really appreciate it. File bugs, attach patches, create mockups, and wait for review (ping the maintainers at #gnome-calendar if you think we took too long). There are no restrictions at all, and anyone can get involved with Calendar development. There are many ways to help:
DocumentationNot everyone want to code. Do you perform well with the English language? Calendar surely needs your writing skills for documentation and translation!
CodeHave good coding abilities? We need you too! Calendar is written in C, and uses EDS a lot. Clone the repository and start playing!
DesignThe Calendar team keeps constant contact with the Design team to ensure we always have a carefully crafted application. Sounds good? Help us with the design too!
TestFrom time to time, we have to ensure the quality of Calendar's code and behavior. Can you easily find bugs? We certainly need testers!
Getting in Touch
Calendar team is very receptive to new contributors. Don't be afraid to contact us!
You've successfully compiled Calendar (if not, see Compiling and running page) and your environment is correctly set. You've been using Calendar for some time, and found a bug, a crash, or you had an amazing idea. Here is the procedure:
Filling a bug
Backend: anything related to EDS. Also, "invisible" actions like syncronization issues.
Views: issues related to week, month and year views.
User interface: bugs that happen within the user interface, but are not related to the views. Bugs at edit dialog, calendar toggle menu et al fit here.
General: issues that doesn't fit any other categories.
Critical: bugs that may destroy user data, or even worse things.
Major: bugs that really annoys you and maybe screw some things up.
Normal: common bugs.
Minor: details that feels unpolished.
Trivial: bugs that can be solved quickly and easily. Good for new contributors to work on.
Enhancement: ideas and suggestions for making Calendar the best calendar application ever.
Summary: a small and clear description of the issue.
Description: a detailed explanation of the bug. A quick description model follows below:
Details: [a detailed explanation of the bug] Expected result: [a brief description of the expected result] Steps to reproduce: [a list of steps to reproduce the issue] Backtrace: [if possible, provide a backtrace of the issue to speed up the analysis]
If you wish to contribute with your coding skills, take a look at these coding conventions. Note that, while we try hard to follow these conventions, Calendar has a bunch of old code that doesn't follow it.
- The source file will keep and order of methods. The order will be as following:
- Private functions will go first.
- class_init and init will go second.
- interface init will go third.
- vfuncs implementations will go fourth.
- Public API will go in the end.
- Methods naming will be according to:
- Private methods will have no prefix.
- vfuncs and public API will have the right prefix.
- The methods prototype will always be placed at the top of the source, in the same order as their implementation below.
- Lines will have 120 chars of width.
- Line splitting will work accordingly to Gtk+ code style, adding the following:
- Pure mathematic calculation can extend over the 120 pixel line.
If you patch touch any autotools related files at all in any non trivial way, ensure that make distcheck pass before posting the patch.
Some links that you may find useful:
The informal design leader of the Calendar project is Lapo Calamandrei. You can see eventual discussion at #gnome-design channel at GNOME IRC server.
Also, you'd like to check the Calendar Design wiki page.