WIP: github issue template

[dagar]

@LorenzMeier @mhkabir
Push to this branch and we'll squash it when ready.

Goals

• redirect questions to the right place and poing to resources that may already answer the question
• bug reports with logs and steps to reproduce
• feature requests with enough information to actually implement

[dagar]

@hamishwillee @mrpollo any suggestions? Feel free to edit.

[LorenzMeier]

Done!

[TSC21]

- Specifications like the version of the project, operating system, or hardware.
Should we subdivide this into more bullets with the info we are requiring, so we precise on what we need and not leave it as optional. Ex:

Vehicle type:
FCU board and version:
FW release/hash:
Development/ground station OS:
QGC version/hash:
(if used) Gazebo version:
(if used) ROS version:
(if used) MAVROS release/hash:
...

Just as examples...

[LorenzMeier]

@TSC21 While I find your proposal to make a lot of sense, I think it is too detailed and most people will just ignore.

[TSC21]

@TSC21 While I find your proposal to make a lot of sense, I think it is too detailed and most people will just ignore.

OK sure. This was mostly to avoid us to make some of the questions that we usually make to people while they are not aware of what they have to describe with detail in order to get their issues solved.

[LorenzMeier]

@dagar I'm merging this as its a good start. We can always iterate.

[dagar]

@TSC21 We'll get some of that if we push for log sharing. For things like ROS, MAVROS, and GCS version in general maybe we should be thinking of ways to share and log that information in the flight controller initially.

[TSC21]

For things like ROS, MAVROS, and GCS version in general maybe we should be thinking of ways to share and log that information in the flight controller initially.

I think that makes sense. Maybe a way of those same platforms share that info on Mavlink handshake and consequently publish that info on a log file?

[dagar]

Yes exactly.
There's PROTOCOL_VERSION (http://mavlink.org/messages/common#PROTOCOL_VERSION) and
AUTOPILOT_VERSION sent to the ground (http://mavlink.org/messages/common#AUTOPILOT_VERSION), but I'm not aware of an existing mechanism for the other end to identify itself.

[TSC21]

For MAVROS I can take care of that myself. For Gazebo, I suppose we should have a way of identify it using the POSIX fw or using MAVROS itself for the same purpose if we are using SITL with ROS. For QGC, maybe @dogmaphobic can give an hint? Should we create and use a similar msg for identifying the ground station side?

[TSC21]

@LorenzMeier @dagar do you think it would be feasible to add a feature to https://github.com/paulirish/git-open or https://github.com/node-gh/gh with a command line option where one writes a the problem description and the adds the associated log, and automatically the issue is created with the different fields that we are asking for?
I'm not talking about do this on the user/developer side but some script that can be added to PX4 Flight Review - the user uploads the file, adds the issue description on the Additional Feedback field, and then checks an option like Create Github issue on PX4/Firmware, popping up a Github login if the user is not logged in yet. I assume that the backbone of the Flight Review would have to include one of the options I presented on the first paragraph or similar and the binds between issue creation and the Flight Review capabilities. We could also iterate over this and present options for choosing what plots to show on the Github issue, parameter values, etc.
For example, for nodegh, would be something like a backscript that runs something like:

gh is --new --title <the_log_description_field> --message <the_additional_feedback_field> --user <the_github_user> --repo <master> --log <the_uploaded_log_file> --plots .... --parameters ...

We should check for a solution that can be integrated and as a BSD license I suppose (the two I presented are MIT).

[dagar]

I'm all in favor of expanding Flight Review to record any data that might be useful. Beyond that I would hope issue creation per flight isn't such a regular thing that it needs automation. Often the relationship should be 1 issue linking to N flights.

[TSC21]

Often the relationship should be 1 issue linking to N flights.

That's perfectly feasible, as we can add an option for link the flight log with the issue. For example, in nodegh, that would be something like:

gh is <issue_number_or_name> --comment <log_description> --log <the_uploaded_log_file> --others ...

In the Flight Review side, we can add an option Link log to Github isse, which pops a dropdown list of open issues and/or having the option to the user write the issue number, though I prefer the first option.

[TSC21]

I'll be moving this feature proposal to https://github.com/PX4/flight_review issue tracker so it doesn't get lost.

[hamishwillee]

@dagar Nice one!

I propose the variation below (minor improvement to English). You probably should update the linked guidelines for contributing to include this information as part of "posting a bug report".

I very much like the idea of including the "environment information" in the log, but I'd still keep it mentioned here because a) not everyone will have a log in all cases b) the system will not always know everything about itself. Would be good if there could be a separate panel in flight review site for displaying this info.

> This tracker is for **Bug Reports** or **Feature Requests** only! 
    >> [Please use [PX4 Discuss](http://discuss.px4.io/) or [Slack](slack.px4.io) for general questions and technical support] <<

Bug reports must contain the following information:

 - A link to a flight log showing the problem 
   - Download the flight log file from the vehicle ([tutorial](https://docs.px4.io/en/flight-reporting.html))
   - Upload the log to [PX4 Flight Review](http://logs.px4.io/)
   - Include the link to your flight log in this  report
 - A description of both expected and actual behavior
 - Test environment, e.g. autopilot/groundstation version, operating system, hardware used, etc.
 - Steps to reproduce the problem

Which renders as:

This tracker is for Bug Reports or Feature Requests only!
>> [Please use PX4 Discuss or Slack for general questions and technical support] <<

Bug reports must contain the following information:

• A link to a flight log showing the problem
  • Download the flight log file from the vehicle (tutorial)
  • Upload the log to PX4 Flight Review
  • Include the link to your flight log in this report
• A description of both expected and actual behavior
• Test environment, e.g. autopilot/groundstation version, operating system, hardware used, etc.
• Steps to reproduce the problem

---

[dagar]

Thanks @hamishwillee

I think we should drop the formatting though. People don't really see the rendered text unless they ignored it and submitted.

[hamishwillee]

Fair enough, though the indented bullets formatting make sense because they are "instructions". Also decide in text whether you're calling it an issue or a bug. So perhaps:

**Bug Reports** or **Feature Requests** only! 

Please use [PX4 Discuss](http://discuss.px4.io/) or [Slack](slack.px4.io) for general questions and technical support]

Bug reports must contain the following information:

 - A link to a flight log showing the problem 
   - Download the flight log file from the vehicle ([tutorial](https://docs.px4.io/en/flight-reporting.html))
   - Upload the log to [PX4 Flight Review](http://logs.px4.io/)
   - Include the link to your flight log in this  report
 - A description of both expected and actual behavior
 - Test environment, e.g. autopilot/GCS version, operating system, hardware used, etc.
 - Steps to reproduce the problem

With the text above you normally expect people to delete it and post in their own information. The other way that template text is sometimes used it to create placeholders/headings for the required information. This text is not deleted, but added to. So something like:

---

**Bug Reports** or **Feature Requests** only! 

Please use [PX4 Discuss](http://discuss.px4.io/) or [Slack](slack.px4.io) for general questions and technical support]

Please provide the information below:

## Link to flight log on http://logs.px4.io/

## Flight behaviour (actual and expected)

## Test environment (autopilot/GCS version, operating system, hardware used, etc.)

## Steps to reproduce the problem

Note that this only links to http://logs.px4.io/ - perhaps we should link from that site to information on how to download a log file?

[hamishwillee]

@dagar So any feelings re using headings vs "instructive text". I prefer the headings approach.