What are legitimate "Issues"?

[rgleason]

OpenCPN "Issues" are:

1. OpenCPN Issue (not Discussions and not Plugin Issues)
2. Exception for Internal Plugins (Chartdownloader, Dashboard, Grib & Wmm)
3. Actionable, concise and complete description using the following Prefix Titles
4. RFE - OpenCPN Request for Enhancement
5. BUG - OpenCPN Bug Issue
6. CI - Continuous Integration Issue
7. PIM - General Pl Manager Issue associated with OpenCPN operation.
8. PPA - Applies to Linux PPA Packages
   Note: Problems in the official Debian/Ubuntu package should be reported using the official Debian BTS or the Ubuntu bug reporting tools.

OpenCPN Issues are not:

1. OpenCPN "Discussions"
2. Plugin specific BUG or RFE to be filed in the specific Github Plugin Public Repository "Issues"
3. Plugin Catalog (xml) Issues filed in OpenCPN Plugins Catalog Issues.
4. Plugin Template Issues filed in respective template Shipdriver or Testplugin Issues.
5. Specific Plugin Issues which should be filed under the plugin's source or maintenance repository "Issues"

---

See the OpenCPN.org for supported OS
On linux we support debian packages for Debian/Ubuntu and Flatpak, primarily for other distros but it works also on Debian/Ubuntu.
The PPA is our own private build chain for Debian packages, so it co-exists with Flatpak.

Revised April 28, 2021
Revised April 27, 2021
Revised April 25,2021
Please ask questions and elaborate.

[rgleason]

There are a number of Issues tagged as "Enhancements"
https://github.com/OpenCPN/OpenCPN/issues?q=is%3Aopen+is%3Aissue+label%3Aenhancement
These are not "actionable bugs".
Does the definition of Legit Issues have to be broadened somehow?

[gromain]

I do not agree on two points.

• Issues can be feature requests in my opinion. This is almost the only way to actually track feature request and technical discussions around them (and then links with pull requests).

• User bug reports should not have to go through the forum. Mainly because this forces people to actually have two accounts, on two websites and there will always be something missing from somewhere. This just adds more hoops for the reporter to go through and will reduce engagement. I've already reported bugs here, if I had to go to the forum first, then remember to check later for answers, then come back here to write the bug report, I would probably not have gone through.

I understand the pain of having someone reporting something already reported, but this can be addressed in a number of ways, one of them being Issue Templates. You can create templates for several kind of issues or feature request that will help having a more thorough background on the request being made (and also to guide the user towards resources addressing all common issues or to search first the issues to see if something is already there).

[nohal]

Completely agree with @gromain

• Feature requests, given they are an actionable item and not (general "redo everything"), certainly can and should be tracked as issues.
• User bug reports don't need to be previously discussed anywhere and confirmed by anybody, they need to meet the common quality requirements to be actionable items.

If the issue is not resovable, it simply is to be rejected and closed.

[rgleason]

Ok, Then there will be greater volume in github Issues and what happens too existing tracker items.
I do not intend to transfer them and they need to be closed or resolved.
All plugins are using Tracker and we have many users (not programmers familiar with that.
--See my distinction between "programmer" feature request/enhancement and "user" feature request.
--Also bdbcat has asked that the 240 issues be reduced and clarified.
--Suggesting to the many many users to change to Github Issues is going to add to the volume significantly and you will have significantly more interface with Users. Not always a bad thing, but you have to take the bad with the good.
-- All Tracker bug reports 6 pages x 50 = 300
-- All tracker feature requests 8 pages x 50 = 400
--Vetted Feature Requests about 33 items. These could be transferred somehow.

Can't do much about this, busy with Plugins and Manuals.
However we could redirect All User Feature requests to Github Issues and furlough Tracker on the website. How many users have a github account?

[rgleason]

Are there some template examples we could refer to? Thanks.

[leamas]

I just did one: #2233.

There are more low-hanging fruits than reasonable RFEs to close. Note for example Dave's wordings about bugs which reflects different opinions between different devs, and the discussion is not going forward ("bug is beaten to death").

[gromain]

Some template examples are available here: https://github.com/stevemao/github-issue-templates

[rgleason]

Alec "RFE" designation is one technique that could be used (wish I knew what it meant),
but multiple templates may be more useful with some setup.., as illustrated in
https://github.com/rgleason/weather_routing_pi/issues
and Discussion #2237

[leamas]

RFE and Feature Request are more or less the same, although I dare to say that RFE is a (the?) accepted acronym. You might want to compare your Feature Request template with what I wrote in in #2233. They more or less match besides one point: I certainly don't know anything about the solution when the RFE is filed, so it's not meaningful to compare it to alternatives.

This is how it should be: A good RFE is open-ended, focused on the desired new functionality and not about implementation.

[rgleason]

@leamas, Well only @bdbcat and @nohal can implement this and they might not even do anything about it, even though Github has provided good tools to organize Issues in a meaningful way. I have an open mind about this, why don't you?

@nohal says we should host "Feature Requests" in Issues. (Sorry if I caused some confusion or misunderstanding about this) This would include feature requests from all users, I presume, assuming all users have Github accounts. Thus will quickly be many more "Issues" created in Issues than you can imagine, and they will have to be "managed" in a rational way. Without the proper tools to assign, sort and view it will become another mess to untangle.

PS: Can we at least agree that Plugin bugs and features must be posted into the respective plugin repository or if applicable to the Plugin Manager to opencpn/plugiins?

PSS: I have been trying to close Tracker bugs and feature requests prior to 2019 and also to inactivate tracker Opencpn version projects, prior to version 5, and inactivate all empty projects in particular plugins in an effort to close down tracker. When should we give notice that tracker will no longer be used? When should the links on the website change.

There are many issues associated with decisions and assumptions which we have not discussed.

[nohal]

We can of course agree that bugs not in OpenCPN do not belong here, yes :)

[rgleason]

Have revised the the first post accordingly.

[leamas]

The basic problem with the tags attached to bugs is that only admins can handle them. OTOH, the traditional way is to mark bugs with an acronym in the header can be used by the reporter. I can see the use of at least three:

• [RFE] - Has been discussed
• [CI] - Issues related to the CI system
• [PLUGINS] - While plugin-specific issues belongs to each plugin, there is a grey area for stuff in the plugin interface applicable to all plugins. We might need to live with these in opencpn since there is no other place.

Could we agree to use some tags like this?

[gromain]

I think that if you use issue templates, you can have predefined tags for those.

[leamas]

Possibly, but it might create a matrix, like "bug for the ci system", "bug applicable for PLUGINS" etc. Might be better to not connect this to whatever templates used. There are even cases of combined tags like [RFE,CI]...

[gromain]

No not really. Goal here is to have only one or two tags (like RFE and Needs Triage, or Bug and Needs Triage).
Because there is a tag that is there only to "mark" the new issues that have not yet been addressed by a maintainer to be either solved right away, lined up for a future version and more work, closed right away or asking for more information from OP.
It's this person's job to then fine tag the issue (like adding "good first issue" for example).

[leamas]

We already have four tags.

[rgleason]

We can do both things if agreed and Pavel or Dave can apply the templates. I would like to see
RFE
CI
PI (not specific plugins, only PI Manager issues) and these should be filed under OpenCPN/plugins!!!!

I would be happy to make the templates shorter and more concise after some specific discussion about the template.
See Discussion General Templates - Needed?
For an idea of how they work see https://github.com/rgleason/weather_routing_pi/issues

[rgleason]

How about "PIM" for Plugin Manager, so it is clearer that it is not for just any Plugin issue.

[leamas]

The notion of "only plugin manager" probably wont work anyway. We need to agree on somehting like above so we can put plugin issues where they belong. But in the end, if it's not a plugin, a template or a catalog issue it belongs to OpenCPN.

[gromain]

I agree that templates don't need to be very long. They should however cover the bases (What version of software/OS/hardware, have you searched about your issue, clear description with steps to reproduce and screenshots eventually if needed), so that 95% of all followup questions are already answered here.

[gromain]

And worst case scenario, if a bug is reported here but concern a specific plugin, we just redirect the user in the right place, and then close the issue.

[leamas]

Anyway, a first step is to ensure it's actually possible to file bugs against the plugins, see #2248

[rgleason]

What about "Internal Plugin" Issues?

• Chartdownloader
• Grib
• Dashboard
• WMM

Should they be filed with OpenCPN Issues? or with the plugin git repos Issues?

[leamas]

Obviously at OpenCPN, since the codebase is maintained within the OpenCPN source tree.

[Hakansv]

Agree with Alec.

[rgleason]

First entry modified accordingly.

[leamas]

We are closing in... Some add-ons:

• The tag [PPA] is already used by reporters and makes a lot of sense for issues related to our PPA packages.
• We should specify that problems in the official Debian/Ubuntu package should be reported using the official Debian BTS or the Ubuntu bug reporting tools.

[rgleason]

I thought PPA was no longer being maintained due to Flatpak

[leamas]

If anything should obsolete the PPA it would be the native package. Won't happen anytime soon, or ever.

On linux we support debian packages for Debian/Ubuntu and Flatpak, primarely for other distros but it works also on Debian/Ubuntu.

The PPA is our own private build chain for Debian packages, so it co-exists with Flatpak.

[rgleason]

Which PPA? Pavel's? bdbcat's?
Also what is the link to flatpak? is it just PIM?

[leamas]

Basically Dave's.

There is really no link to Flatpak, they are alternative solutions for Linux. For distros other than Debian/Ubuntu, Flatpak is the only alternative. You use either flatpak or .deb packages, not both. The .deb packages comes from the official package (i. e., from Debian or Ubuntu) or from the PPA

[rgleason]

Don't mind above, I linked to OpenCPN.org for supported OS