How to participate in the Jala project

Eeek, a bug!

If you should have found an error, a typo, any mistake somewhere in the Jala library code, documentation or wherever: please tell us about it.

We'd kindly ask you to take some time then, create a new ticket (to reduce spam this requires login / registration) and enter in the form as much detailed information as you can put in words:

• What did you intend to do?
• What happened / did not happen then?
• What did you expect to happen?
• How could we reproduce the problem?
• How urgent do you need a solution?

Your bug report will exceed excellency if you were to tackle down the troubling line number(s) in the code, to submit a patch with your ticket or to provide a URL where we can easily spot the problem.

If you need help with writing a ticket or general information about using trac please take a look at the extensive documentaion inside the TracGuide wiki page.

Come in, take a seat. But don't step on the cat.

Sharing our code is one reason why Jala was released to the open source community. Another, not less profound one, is to make our code better. Altogether our intention is to provide the finest code for Helma by putting our heads and strengths together with those of the best Helma programmers out there.

Thus, joining the Jala project is easy: Just let us know.

There's plenty to do for contributors, and we also intend to assign several maintainer roles to interested and enthusiastic people. (Of course including write access to Jala's Subversion repository and its trac installation!)

Nevertheless, we have our standards which we try to lay out to you by providing code and documentation that went through a lot of deliberate thinking and re-thinking, through cycles of quality checks and conceptual challenges. The result is far from being perfect. But it manifests what fulfilled our expectations at that very moment.

To keep up with these standards we need to ask contributors for courtesy:

• Coding is the easiest part. But it's not the only one.
• Documentation is a must-have. A good example, too.
• Please think about licensing issues.
• Application code is flexible. Library code is fragile. Namespaces have a reason.
• Team work deserves time, thought and good communication.
• It's all about solving real problems, not anticipated ones.
• Released code can provide relevant insights.

Whenever you decide to propose a solution, please keep the following in mind:

• Always propose first before starting to code. You will avoid the fruststration of having to start all over again because of conceptual or structural changes during essential discourse. It's better to propose an idea early, ideally together with a structural outline and some pseudo-code. Proposing a finished solution doesn't necessarily mean that your contribution will be accepted.
• Please add a detailed description of the problem your solution addresses or you'd like to see addressed by Jala. Don't expect others to distillate the problem out of your code.

Of course you soon will notice that sometimes, somewhere we do not meet our own approval ourselves. That's why we are looking for your help.

Questions, which questions?

Although there is the option of subscribing to the Jala developer’s mailing list we encourage you to post your questions as tickets. (Login / registration required.) This might sound unorthodox but actually helps us a lot trying to organise and remember your requests.