Ted, - I've heard from a number of people that Drill's documentation is one of the best of all Hadoop-related projects - There are--and will always be--places where the documentation could be improved. - The people working on documentation have always been very responsive to feedback and that shows in the docs
It is completely natural that as people use the documentation, they will identify areas for improvement. The community lists exists precisely to help people like Stefan. Your characterization of this as problematic rather than expected confuses me. Of course, we'd love to have perfect documentation (and bug-free code) from the start. However, we all know that reality intervenes. As such, making sure the process is in place is central to success. Here is my understanding of what happened: 1. Someone tried to do something. 2. They reviewed the documentation 3. They hit issues or were confused. 4. They asked for help. 5. They received help. 6. They completed their task. 7. They provided feedback to incorporate into the documentation, identifying what was missing. 8. The feedback is incorporated into the documentation. (pending) This pattern has occurred previously and will continue to occur. As long as the community continues to be responsive to people's challenges, we are in good shape. We know that sometimes people who are not as tenacious as Stefan will stop at #3 above. We can only do what we can do. Let's continue to improve things so that this becomes less likely over time. Jacques On Mon, Jul 20, 2015 at 8:32 AM, Ted Dunning <ted.dunn...@gmail.com> wrote: > We just had Stefan over on the user@drill list stick with us through thick > and thin to get a very simple UDF up. He isn't a dolt by any means, but > here is his signature on email describing his state of mind: > > Regards, > > -Stefan (*not the happiest camper*) > > > The only reason that this guy is still with us is that Jim Bates exchanged > quite a number of emails. The clear reason that he had problems is lack of > documentation and thus understanding of how to write a UDF. > > The current state of affairs is that it is unnecessarily hard to contribute > to Drill. This is clearly having a deleterious effect on building the > community of contributors. We need to fix this. > > There is a place on the web site that describes how to write a UDF, but it > is clearly failing to explain the big picture of what is happening and it > doesn't highlight the fact that you aren't really writing Java code when > writing a Drill UDF, but instead are using Java to write in a more limited > language. > > Stefan's recent experience should be a perfect opportunity to improve this > documentation by describing the process better. >
