Community
Participate
Working Groups
I know keeping source code documented can be a task consuming task. However, while making my own stand alone helper for epsilon I felt as if I was in the dark trying to figure out what exactly did each class or function. In the "How can I contribute to Epsilon?" section in the FAQs you express your willingness to accept bugs reports and fixes. Providing fixes or enhancements would be a tad easier if the code documentation was better.
Point taken. I'm not sure that this qualifies as a bug (i.e. I wouldn't know when we could close this as "resolved") so in the absence of a better solution, I'm inclined to close this as NOT_ECLIPSE.
We (Epsilon contributers) could 'agree' to document each new method/class/field we add/modify. So the 'API documentation' slowly becomes (more) mature. (As adding all documentation at once is an impossible (boring) task, I suppose)
Wouldn't it be better to put it under "IN_PROGRESS"? Probably statistics wise it might look "bad" that a bug is under progress for a long time. But, IMHO, it gives the sense that at least some work is being done towards it. Another idea would be to plan a plugin/package based approach, in which we could split this bug into multiple ones (one for each plugin) and thus it would be more realistic to tackle them and eventually resolve each of them.
I agree that this is something we should aim for in the long run, but given that realistically this can never be closed as long as there's even one method with no javadoc in the Epsilon source code, it doesn't seem to be a good fit for the bugzilla lifecycle. Having said this, if there are any particular classes/methods for which you feel that javadoc is essential (e.g. due to their high complexity), please feel free to file a new enhancement request.
