You could also generate documentation updates via query at each release. This would be a great feature, move the information close to the analysts hands, I love how that would work. (I think I remember some talk about extending sys.options to be self documenting as well.... )
On Tue, Feb 28, 2017 at 12:11 PM, Jinfeng Ni <[email protected]> wrote: > Regarding the list of functions (build-in or UDF), someone once > suggested that we make the functions self-documented by adding a > sys.functions table. > > select * from sys.functions where name like '%SPLIT%'; > > return function_name, parameter_list, description etc. > > This way, use could simply query sys.functions using Drill. > > > > > > > > On Tue, Feb 28, 2017 at 9:02 AM, Jinfeng Ni <[email protected]> wrote: > >> 4. I think as part of developer review and pull requests that add > >> functions/functionality should require a pull request to also provide a > >> documentation update. This helps to ensure that the docs keep up to > date, > >> as well as keeping users appraised of what is happening... i.e. it's a > good > >> "feeling" to see a great tool like Drill "improving" with new > >> functionality. > >> > >> Please, folks, we need to do some one time clean up (go back through > pull > >> requests to ensure all functions are documented up to now) and then then > >> get processes in place to ensure ongoing updates. > >> > > > > That's a good suggestion. We should try our best to keep the code and > > doc in sync. > > > > +1 >
