Page en instance de traduction...

  • I want to help with coding, what should I do?
The best is perhaps to start with fixing the bugs or very small enhancements so you get familiar with the code. The excited plans from newcomers about bigger things to implement are usually left unfinished, because the code of LyX is nowadays complex and hard to digest in short time window. ;)
  • On what bugs / enhancements should I work on?
Rule No. 1: fix the bugs you are personally frustrated from or the enhancements you are excited about. First contact with the code is usually tough and such impetus is able to overcome the problems. We don't have much documentation. You should also feel free to ask questions on the list about how things are organized. How much time people have to explain code will vary, but we do try to be helpful.
Another suggestion is to start by looking at bugs for which there are already patches, which are here. Working on these will often involve updating patches, and seeing how they work, which is a good way to get started with the code. Bugs marked with the "easyfix" keyword are also an obvious place to start.
  • How does the assignment of tasks/bugs occur?
We are not a formally organized group and people do what they feel like doing. Probably the most important is to read the development list. From here one usually knows who is working on which task. Other hints can be had from the comments in our bug tracker. The assign field in the bugs does not mean much, particularly it doesn't mean that somebody is working on a bug. But you can always ask on the list if unsure... ;)
  • Once I have a task to solve, is it locked to me, or do other people work in parallel?
There is no locking but naturally nobody will spent his time on the issue which is known to be tackled by somebody else. There are exceptions of course, but usually people work on their own and when the code becomes ripe they appear on list with message like "I have patch fixing/implementing this, do you have comments or objections?"
If you start working on a particular bug, though, and it is going to take some time, then you might add a comment to the bug, just so people know.
  • Is there a todo list where I can find bugs to be fixed and new features to be implemented?
Follow the developers' mailing list.
Our bug tracker collects the tasks and error reports from the users and is the main place to look.
We have some plans, but only approximate.
  • How do I commit code that I improved? Who checks it?
Newcomers should post patches on the devel list, and when a patch is approved somebody commits the code. In the beginning, be prepared for a lot of comments, especially including what may seem like trivial issues about coding style. (Read the files in development/coding for some of our rules, but otherwise try to follow the existing style!) When the newcomer has been around for some months, fixing bugs etc, and has gained the trust of the existing development team, then he or she will gain commit access and become one of the developers. No strict rules here.
If you want some kind of vcs for your own work, consider using git.
  • Is it possible to code in Python?
LyX is mostly C++ stuff, so most of the new features and bugfixing will involve C++ coding. However we have a few parts in Python if this is the area of your expertise. In particular you can search for lyx2lyx bugs here. Another part is our code for configuration and detection for external applications. The bugs to be solved are usually enhancement requests for detection of some 3rd party application or converter and are often flagged as easyfix.