> HIVE-2085 Document GenericUD(A|T)F.
>
> This is the second ticket I have seen calling for "more
> documentation". All tickets like these should be closed instantly
> unless
>
> 1) User wants to write an xdoc or java doc and get it committed.
> Otherwise user can update the wiki. There are many things that could
> be documented "better" and having a ticket to remind us about each one
> is not practical.

This is not a case of "better" documentation because there is
virtually no documentation at all for this feature. And I can't create
a patch for this because I just don't know enough.

It is my opinion that if you close these kinds of tickets then every
new feature that gets committed should only be allowed with
accompanying documentation because otherwise all these features will
be useless to most people who learn about Hive from the documentation
and are unaware of them. In this case those issues should probably be
assigned to whoever implemented the feature.

> We need to be more aggressive in intercepting issues and not be afraid
> to close them as LATER, WONT FIX. Otherwise we are never going to be
> able to turn this around and the open issues are just going to keep
> growing. Suggest users to the wiki for ROAD map or the IRC. So they
> can discuss features before creating vague tickets.

I also don't agree here. Other projects encourage these kinds of
issues and are doing fine with them. It is always easy to filter out
Documentation issues once they are in the correct category. These
kinds of issues are also a helpful resource for those searching for
others having the same problem even if there's no fix available or no
one working on it.

I obviously say this as a non-committer and while I love the progress
Hive is making and I'm very thankful for all the work going on I as a
user would wish for more and better documentation over new features
sometimes. I firmly believe this would also help attracting new
developers to help out. The code base isn't the easiest to understand
either when starting from scratch.

Cheers,
Lars

Reply via email to