Create issue_template.md

[kdelee]

Add an issue template to encourage us to document the link between camayoc issues and rho or quipucords issues

[coveralls]

Coverage remained the same at 69.565% when pulling 5c788a8 on kdelee/issue_template into 780257d on master.

[jlprevatt-zz]

Approve; added specific recommendations to doc section with boilerplate guidance text.

[jlprevatt-zz]

Suggested boilerplate text for the ###Documentation section (if my assumptions about the intended usage are correct):
Provide a summary of the documentation changes/additions required for each affected part of the documentation. For example, installation, config/administration, user, troubleshooting. If practical/possible, include more specific information, e.g., the locations of the required changes.

[elyezer]

I like the idea for the documentation, but I am wondering if the changes about quipucords documentation should go into quipucords issues. I think it does not make sense to have quipucords documentation changes listed on camayoc's repository.

IMO quipucords user stories could have a section called Acceptance Criteria which would include a check list or some items to make that user story accepted. For example:

• Update section X of Y Document stating that feature A will now have a new option called new option. This option can accept the following values 1, 2, 3.
• The CLI should expose the option new option for the command qpc command and only accept the valid values (listed on the above item)
• The UI should present a new form field which will be a a choice field with the values listed on the first item.

So each item in the acceptance criteria could link to an issue where the related work to that is/will be tracked.

With that information, the QE team can pull the latest changes and if that user story is closed we can check if docs are updated, CLI and UI interfaces are updated and say we are ready to ship that user story.

[kdelee]

I guess I meant the documentation section to be links to related docs about the features we were testing.

I did update the quipucords issue template to have acceptance criteria:
https://github.com/quipucords/quipucords/blob/master/.github/issue_template.md#acceptance-criteria

[elyezer]

Since I don't have context from where this come from, I think each section in this document could provide information about what is expected to go into that. Something like suggested by @jlprevatt for the Documentation section.

For issue type I see the following types:

• Bug: when Camayoc framework is not behaving as it should be (e.g. CLI client is not running a CLI command)
• Test Case: new test case for a new feature or request to update already existing test cases to adapt to new changes on quipucords.
• Enhancement: improve camayoc framework. For example add a JSON output handler for the API client.
• Other: leave this option and if it is used, check if a new type will be necessary

I like the idea of having the issue template, thank you for bringing this up.

[elyezer]

I think this can just Bug.

[elyezer]

Here you are using level 3 header, to make more meaningful use either level 2 or update the other headers to have all upper levels before.

[elyezer]

I like the idea for the documentation, but I am wondering if the changes about quipucords documentation should go into quipucords issues. I think it does not make sense to have quipucords documentation changes listed on camayoc's repository.

IMO quipucords user stories could have a section called Acceptance Criteria which would include a check list or some items to make that user story accepted. For example:

• Update section X of Y Document stating that feature A will now have a new option called new option. This option can accept the following values 1, 2, 3.
• The CLI should expose the option new option for the command qpc command and only accept the valid values (listed on the above item)
• The UI should present a new form field which will be a a choice field with the values listed on the first item.

So each item in the acceptance criteria could link to an issue where the related work to that is/will be tracked.

With that information, the QE team can pull the latest changes and if that user story is closed we can check if docs are updated, CLI and UI interfaces are updated and say we are ready to ship that user story.

[jlprevatt-zz]

@elyezer Perhaps my assumption here was that these would be issues found by of the QE team and its testing process that might affect other functional areas, such as dev or doc. If that isn't quite what this issue template is used for, and it is more narrowly focused (to camayoc setup/management?), then perhaps a one-liner to define the intent of this template should be the first line in the template.

So perhaps the intent of the other functional areas sections listed in the template is to list any related quipucords issues discovered during the course of figuring out the camayoc problem, for tracking/informational purposes. So then the boilerplate text could come before those other functional areas and could say something like "List/link to any related issues or user stories" without the need for specific usage info for each section.

It would be nice to have the boilerplate documentation instructions live on in the quipucords issue templates. Asking for that type of enhancement to the templates has been on my mind but not my highest priority.

For your suggestion about morphing what I added to the documentation section into some boilerplate acceptance criteria in user stories, I like that just fine. Asking for section X of document Y specificity has been what I have been used to in defect templates in former projects with a product that is beyond its first release.

[elyezer]

LGTM, thank you for the updates