Should we create JIRA for these so that the work to be done on these does
not get lost?
... or should we schedule a doc blitz to take care of as many as possible
right away? (Inclusive OR.)
-- Lefty
On Sat, Jun 14, 2014 at 10:35 PM, kulkarni.swar...@gmail.com
kulkarni.swar...@gmail.com
A few more from older releases:
*0.10*:
https://issues.apache.org/jira/browse/HIVE-2397?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC10%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
*0.11:*
One more question: what should we do after the documentation is done for a
JIRA ticket?
(a) Just remove the TODOC## label.
(b) Replace TODOC## with docdone (no caps, no version number).
(c) Add a docdone label but keep TODOC##.
(d) Something else.
-- Lefty
On Thu, Jun 12, 2014 at 12:54 PM,
Yea, I'd imagine the TODOC tag pollutes the query of TODOC's and confuses
the state of a JIRA, so its probably best to remove it.
The idea of docdone is to query what docs got produced and needs review?
It might be nice to have a tag for that, to easily signal to contributor
or interested
+1 on deleting the TODOC tag as I think it's assumed by default that once
an enhancement is done, it will be doc'ed. We may consider adding an
additional docdone tag but I think we can instead just wait for a +1 from
the contributor that the documentation is satisfactory (and assume a
implicit +1
Agreed, deleting TODOC## simplifies the labels field, so we should just use
comments to keep track of docs done.
Besides, doc tasks can get complicated -- my gmail inbox has a few messages
with simultaneous done and to-do labels -- so comments are best for
tracking progress. Also, as Szehon
Thank you guys! This is great work.
On Wed, Jun 11, 2014 at 6:20 PM, kulkarni.swar...@gmail.com
kulkarni.swar...@gmail.com wrote:
Going through the issues, I think overall Lefty did an awesome job catching
and documenting most of them in time. Following are some of the 0.13 and
0.14 ones
Feel free to label such jiras with this keyword and ask the contributors
for more information if you need any.
Cool. I'll start chugging through the queue today adding labels as apt.
On Tue, Jun 10, 2014 at 9:45 PM, Thejas Nair the...@hortonworks.com wrote:
Shall we lump 0.13.0 and 0.13.1
Going through the issues, I think overall Lefty did an awesome job catching
and documenting most of them in time. Following are some of the 0.13 and
0.14 ones which I found which either do not have documentation or have
outdated one and probably need one to be consumeable. Contributors, feel
free
Let's reopen this discussion. Brock asked in HIVE-7140
https://issues.apache.org/jira/browse/HIVE-7140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14025258#comment-14025258
how we can make sure the user docs get updated for jiras committed for
release
TODOC14 sounds good. But I think it should be a label in the labels
field of the jira (it would auto-complete and people are less likely
to use wrong keyword)
We should still ask developers to fill out the release notes section
with sufficient information for creating documentation for it. We
Thanks, Thejas.
TODOC14 sounds good. But I think it should be a label in the labels field
of the jira ...
An advantage of labels is that they won't show up in the published release
notes.
Also, I don't think we need to wait for end of the release cycle to start
documenting features for the
Also, I don't think we need to wait for end of the release cycle to start
documenting features for the next release.
Agreed, but I think we should wait until the next release is less than two
months away. What do other people think?
We have been releasing almost every 3-4 months. So that
Writing documentation sooner rather than later is likely to increases the
chances of things getting documented.
Big +1 on this. I think documentation contributes towards one of the major
technical debts(I personally have quite a bit for the patches I
contributed). IMHO committers may choose to
Slightly tangential but how we do choose on adding this to some of the
already resolved JIRAs that are missing documentation? I can volunteer to
dig through our JIRA queue and find some of these out but probably would
need some help from the contributors on these to be sure that they are
I can dig through my backlog and add TODOC13 or TODOC14 to a bunch of
issues. Some are even earlier than Hive 0.13 ... sigh!
If you're digging through the JIRA queue, I suggest starting with the
0.13.0 and 0.13.1 release lists. Check the end of the comments to see if I
(or anyone) said the doc
Shall we lump 0.13.0 and 0.13.1 doc tasks as TODOC13?
Sounds good to me.
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under
Well, if it works for Pig then let's give it a try for Hive. Unless
someone has a better idea, of course. (Nudge.) Both javadocs and wikidocs
should be strongly encouraged. Also hive-default.xml.template for new
config parameters. Anything else?
By the way here's another example of a JIRA
Could a new status such as Just needs doc be added? Or perhaps a
resolution such as Undocumented? Because folks who want to get their
hands on new features need a way to know when the code is ready, even if
the doc is missing.
Sometimes information is available if you know where to look for it
Another advantage of separate doc ticket is that when we are making a
release it's easier to tell what has been checked in already and what else
needs to be done and whether we should hold the release due to doc issues
or not. Release notes are only useful for people who already have a lot of
I am fine with a followup doc jira if the enough information to create
a document is there in the original jira (in form of release notes
section of jira, or jira description etc). There has to be enough
information so that people who don't know hive internals can also do
the follow up work of
What do other projects do?
-- Lefty
On Wed, Nov 6, 2013 at 3:07 PM, Thejas Nair the...@hortonworks.com wrote:
I am fine with a followup doc jira if the enough information to create
a document is there in the original jira (in form of release notes
section of jira, or jira description etc).
In case of pig, where the documentation is under same repository and
version controlled, the feature patch is expected to include the
documentation changes as well, or at least documentation in release
notes section that be used to create documentation.
On Wed, Nov 6, 2013 at 12:48 PM, Lefty
I think opening a separate doc ticket and making it a subtask of the dev
ticket works pretty well. The subtask can contain notes specific to
documentation.
Eugene
On Tue, Nov 5, 2013 at 12:16 AM, Lars Francke lars.fran...@gmail.comwrote:
Hi,
I wanted to ask how people feel about a policy
There is no guarantee that the subtask will ever get completed after
the feature goes in. There is no point of new features if users can't
actually figure how to use it.
I think we should either add sufficient documentation in the release
notes section of jira or add doc in wiki as upcoming
25 matches
Mail list logo
