We have three goals with just a few tools of persuasion.
Goals:
1. Identify JIRA issues that need documentation.
2. Add doc notes or release notes to JIRA issues.
3. Document Hive code and procedures in the wiki. *(main goal)*
I've been helping with #1 and #2, adding ~17 TODOC labels &
Perhaps this should be a 2 stage process. One to approve the code and one to
approve the doc.
It seems odd to update the Wiki (which isn’t tracked using the same Git repo as
the code) before
the code changes have been agreed to. Both approvals would be required to
commit.
Eugene
On 12/3/17
+1 for Yetus integration to -1 patches without docs.
Thanks and Regards,
Prasanth Jayachandran
On Sat, Dec 2, 2017 at 3:04 AM, Klára Barna Zsombor
wrote:
> Could this be somehow integrated into the Yetus checks? I'm thinking that
> if the Jira being tested does not have one of the "Doc-Perfor
Could this be somehow integrated into the Yetus checks? I'm thinking that
if the Jira being tested does not have one of the "Doc-Performed",
"To-Doc", "Doc-Not-Needed" labels then it would get a -1 from Yetus.
Peter what do you think? Is Yetus extendable in this way?
On Thu, Nov 30, 2017 at 2:58 A
Hive contributors are responsible for documenting their own commits,
although many seem to be unaware of this or too busy with other tasks. How
can we boost the number of jiras that get documented?
Our current process is to put a TODOC** label on each committed
issue that needs wiki documentatio
