Ted Dunning wrote:
... I think that we should have a rule that every class should have javadoc on the class.
Since it will take a long time to get to that state, we should probably start with whichever are the most important classes to document. That fuzzy set of "most important" classes probably includes: - classes relevant to using Drill's application-programming interfaces (e.g., Drill's driver JDBC now (which already has significant documentation), and, in the future, DrillClient/etc.) - classes relevant to developing plug-ins - most classes at the roots of big and/or significant hierarchies (since they specify methods, contracts, and protocols used by many other things) - other classes that methods, contracts, and protocols used by many other parts of Drill Daniel P.S. Speaking of documentation... Could a committer approve and merge my DRILL-3641 IterOutcome doc. pull request at https://github.com/apache/drill/pull/113? (Only one file to review! only an enum class's documentation!) (It should help avoid future bugs like DRILL-2288 and DRILL-3569.) Also, could anyone take a look at https://github.com/apache/drill/pull/118? It's mostly just Javadoc edits on code somewhat related to storage plug-ins (things I encountered in starting to explore how to write a storage plug-in). Thanks, Daniel -- Daniel Barclay MapR Technologies
