Proposal: Improving JavaDocs

I think the Operaton codebase could be improved by adding JavaDoc. There are some instances of JavaDoc in the code already, but my impression is, that it is far away from being complete.

The class names are rather technical (which is justified, of course), and contributing to the software would be easier, if classes and methods would be annotated with JavaDoc which explains what they are for and how they behave. This would also improve the API for end users, who could see vital information about the classes and methods directly from the IDE.

Additionally, this would be a nice category of issues for first-time-contributors.

What do you think? Is there any good way to structure this? One ticket with “Improve JavaDoc” would be a little too broad for my taste, maybe one ticket per module? Or starting with the engine and its modules themselves?

1 Like

Does anyone have real life experience on GPT/Copilot for generating JavDoc? Would it be any good? Would there be any legal issues with it?

Hey @datakurre, thanks for your reply! There shouldn’t be legal issues, as far as I am concerned. I have little experience with any Copilots, but I’d be surprised if they managed to derive the global context of a class, as the tools I used until now seem to have a very narrow scope in the codebase. If somebody managed to show a good proof of concept, I woulnd’t be opposed, though!

I suppose, Copilot would speed up javadoc creation. It still needs to be reviewed, though.

Maybe we could create a workflow / script for generating javadoc for a certain package / use case. Then first time contributors could pick a package, generate the javadoc and make a first review.

Maybe a plone based workflow for JavaDoc reviews, @datakurre :wink: Sounds like a good twitch stream topic :smiley:

1 Like

I thought more about picking the first available tool, run it through the code base, commit it in a branch and use pull request for review.

Did that. Run engine-dmn through GPT-4 for an example of generated javadoc by datakurre · Pull Request #4 · operaton/operaton · GitHub

Meh. Requires “prompt engineering” to get better results. Requires extra scripting after the initial run to revert changes to code lines.

About the greater context. I assume that C7 code is in the training sets of those models and therefore they might be able to guess the context of individual files when prompted to.

1 Like

Already looks very promising! Reagarding the costs (if this ever becomes an issue) We are a Microsoft Partner and have $100 worth of credits on Azure every month, that we’re not currently using ourselves. I can provide it to the project for Azure OpenAI access.