On issues, something of a "meta-issue"

[bdbcat]

All...
The github issues list has been out-of-control for some time. As it stands now, there are at least two classes of issue on the list:
a. Legitimate bugs or feature enhancements, mainly driven by the dev team. Actionable work here...
b. Free-form discussions of various programming topics, most of which relate to OpenPCN. Some of these issues look more like blogs, to me, as they fragment into all sorts of arcane subjects. In many cases, there is no possible "resolution" of such an "issue" short of a decision by DevLead.
At the moment, there are far more of class (b) than class(a).

I encourage all OP's to close their own issues, particularly older ones of type (b). Failing action here, I plan to close some issues summarily.

1. Those in class (b) that have more than two years inactivity without meaningful progress.
2. Those in class (b) that have been beaten to death due to honest differences of engineering opinion, but without resolution. In these cases, we should consider the "issue resolution" to be "status quo".
3. Those issues that have clearly been overtaken by actual events in the the codebase.

Understand, "closed" issues are not gone forever. They may be retrieved by filtering the query, without cluttering the actual work in front of us.

There may be other fora more suitable for free-form discussion of OpenCPN and its implementation, future plans, blue-sky, etc. Suggestions on this idea are welcome.
But let's migrate the github "issues" list into a more actionable format.

[rgleason]

is:issue is:open updated:<=2020-01-01 63 issues (154 open - 63 (?) = 91)
https://github.com/OpenCPN/OpenCPN/issues?q=is%3Aissue+is%3Aopen+updated%3A%3C%3D2020-01-01+

[leamas]

There may be other fora more suitable for free-form discussion of OpenCPN and its implementation, future plans, blue-sky, etc.

Open-source projects tends to use mailing lists. These are lightweight and easy to use tools which also, if archived, creates good searchable archives. Using for example sourceforge they are also easy to setup and maintain.

But this will only work if a critical mass of devs supports this idea.

The first question goes to @bdbcat, since without your support this idea is dead on arrival. Do you think a mailing list like opencpn-devel could be the tool we need to avoid "bugs" like #2204?

[bdbcat]

I have no experience with sourceforge mailing-lists for devs.
Tell us more....

[transmitterdan]

I don't know much about source forge except is used to be spammy with tons of smarmy click bait ads. Maybe it is better today.

The GitHub issues feature is pretty much like a mailing list. I think it works if we just make a little better use of tags and discipline in closing dead topics.

We could have tags for discussions vs. feature requests vs. bug fixes.

So for me, GitHub is ok but I agree with Dave that we need to manage the issues list better. Perhaps we could allow a couple more devs the ability to police/moderate the issues list?

Dan

[nohal]

For the developer chit-chat, there are Github Discussions, Slack-alikes or a mailinglist.

For the user discussion, the current CF forum is what everybody is used to (As much as I personally dislike it both technically and moderation-rule wise).

I would really love to see the issues here used to track work items, which what I strongly believe they were designed to do. Meaning keeping them atomic, to the point and free of the waterfall of irrelevant stuff that pretty much killed all the other communication channels we have used so far.
That, IMHO, needs some self discipline from everybody (= shutting up when you don't know what you talk about or have actually nothing to say that would help to get the very issue any closer to closed, or taking those 10 seconds to open a separate issue for the other, completely unrelated, topic you want to have addressed).

[Hakansv]

Agree with Pavel and Dan. The writer's discipline will not change while moving to another forum.
On other communities, like e.g. SignalK, the owners/moderators are more restrictive and closing an issue once it's:

• A question that's is answered.
• Not a problem/bug but more a future requests: > Pls race a tracker > closing.
• Not a problem/bug but more a general discussion/personal minds: > Pls use the Forum > closing.

It can be kind of a humiliation to close another's issue but, as Dave mentioned, it can be reopened.
For now please close what can be: b) 1, 2, 3
Håkan

[leamas]

I have no experience with sourceforge mailing-lists for devs.

Are you using any mailing list? They are basically all the same, hosted on sourceforge or not. (please disregard sourceforge in this context, it's not significant).

EDIT: Please disregard, see below

[leamas]

I agree with @Hakansv and others that we need more discipline and policing on the github issues if this should work. As bdbcat phrases it, issues should be actionable work items.

Perhaps the basic questions to search an agreement on are

1. Do we want to limit the issues to "actionable work items" in Dave's wordings (i. e., labeling discussion issues as such is not the solution)?
2. If yes, there is a need for an alternative forum for other developer issues. Could/should this then be the current CF forum, or something else?

My own answer to 1) is yes,. For 2) I think we need an alternative channel for what Pavel describes as developer chit-chat. But then again, that's just me.

[leamas]

Are you using any mailing list? They are basically all the same, hosted on sourceforge or not. (please disregard sourceforge in this context, it's not significant).

Answering myself: : Looking at other posts the mailing list issue is a bit premature. We first need to agree to if we need anything at all besides what we already have. And, if so, if we need a mailing list, a forum like Github Discussion or a chat tool like IRC/slack/whatever.

[rgleason]

The first goal is to manage issues. To do that all users should search by author and enter their username and review each issue. I think this should be less than 100 issues, but there are many old ones not addressed.

[leamas]

I wasn't aware of Github Discussions when I wrote my first posts here (thanks, Pavel). Looking at this it seems like the natural solution: it's light-weight, easy to setup and no new login is needed. So I revise my proposal to use a mailing list, Github Discussions (GD) seems like a better alternative.

If we use GD for anything not strictly being an "actionable work item" it should be possible to have a much more focused issue list. An example: the Vercel project at https://github.com/vercel/vercel/discussions.

Thoughts?

[Hakansv]

GD is OK with me. Especially if it can be a part of the project header like "Issues" and "Pull requests" as discussed in Alec's link above. Then it would be easily reach compared to external forums like e.g. Slack
All of the b) issues categorized by Dave would fit there.

[rgleason]

I agree with Hakan.
Does OP select the categories? General / Ideas / Help / Show & Tell
Process New / Answered / Unanswered looks good.
With the search tool this becomes a useful repository for people.
Who/How is this managed? Or is it rather automatic?
I think it will be very appropriate.
I will like this a lot better than Zulip I think, because the topics get somewhat impacted in Zulip

[rgleason]

Open Issues = 141 now

From the open issues - older items that were tagged
Old bugs Can any be closed now?
Old enhancements Are some done or outdated?
Old in progress Are these done now?
Old needs work ??
Old help wanted

Some of these items could be moved to the discussions part perhaps.

[rgleason]

Regarding Github "Discussions" (in Beta and subject to change).
I expect that Dave does not want to have to "manage" this, or to keep his management to a minimum.
The question is how to do that? Designate some volunteer moderators?

About Discussion

Enabling or disabling GitHub Discussions for a repository

Managing Discussions
"Moderators and collaborators can mark comments as answers, lock discussions, and convert issues to discussions."

Repository permission levels for an organization

[bdbcat]

Rick...
Setting up the GD environment won't require detailed O knowledge.
I have enable "Discussions", and have invited rgleason to the team with "triage" access.
Rick, you may accept the invitation, and proceed to "moderate". Set up categories, rules, etc.
Don't worry about the fine details. There will be no way to control what shows up here. We just have to learn as we go.

[transmitterdan]

@bdbcat I will volunteer to help moderate if you like.

[rgleason]

Thanks Dave. ..Tomorrow. TDan, that's would be wonderful. Thank you.

[bdbcat]

tDan...
You are invited.

[transmitterdan]

Got it. Apparently moderators cannot move issues to a discussion. I don't know if only an owner can do that or what.

We should move this "issue" to a discussion as a start.

[bdbcat]

IIUC, we can have "categories" in the Discussion.
If so, please setup some useful categories before we start populating the Discussion randomly.

[transmitterdan]

These are the default categories already set up.

[transmitterdan]

It looks as if "triage" has insufficient privilege to create new categories or to move issues->discussions.

[bdbcat]

OK, I guess those categories look fine.
So, where would you like to move this particular issue?

[Hakansv]

Wow, things happens while away for a while.
This is great!
Rick and Dan will be very fine to take care here. I'm proud to be mentioned but you two will make a good base. Whatever I can support or help I'll of course do my best.
Håkan

[transmitterdan]

@BDCat Ideas seems logical.

[gromain]

Also, just to add more on this, "someone" is bound to be moderating the issues.

I know this is asking someone in the community to do the job, but it's quite an important role albeit not very rewarding.

Other open source projects are very successful by having people managing the issues and also using Github project (to actually transform the issues to a Kanban style tracking of bugfixes to address or new development to take into account during the development cycle).
And it basically boils down to what others said before here: closing non-issues, redirecting users to more appropriate places if needed, or to the documentation, making sure stale issues are either being addressed some time in the future or closed if not further work is needed and filling/tagging feature requests, good first issues, etc...

This is something that I believe will help in having more people engaged in the development. Just like the documentation is quite fragmented, the issue tracking is also fragmented. I know there is Flyspray, but I don't know if it's for bug tracking or feature request, or just development tracking ? If Flyspray is the main bug tracker, just close issues on Github and redirect people to the tracker (or get a robot to transfer issues there when they are opened here). Or move everything here, whatever works for the people using it.
Also, is there a development plan somewhere ? A place where wannabe developers can see future new features, and which point in time they are planned to be released (it help to have a list of feature request for people who wants to help but don't know where to start).

Anyway, those were my thoughts!

[rgleason]

1. Dev Manual (updated/rewritten) and Plugin Manuals have/are being moved to antora/asciidocs on github.
2. User Manual and two Supplemental books will remain on Dokuwiki for now, to be updated.
3. Dokuwiki Dev Manual will be relabeled "Old Dev Manual" with a link at the top to the new Github Pages github.io (to be determined)
4. Tracker/Flyspray - We need to figure this out. It is definitely used for Feature Requests. We need to figure out what to do with the old bugs etc.

Thanks for the suggestions. Suggest we use Discussions.

[gromain]

Sure, this issue can be moved to discussions! ;-)

For old bugs, I would ping the bug reporter to ask if it's still an issue for them, after testing against latest version. No response after one or two months => closed, not an issue anymore => closed, still an issue port it here if Github Issues are going to be the main tracker from now on.

[rgleason]

Thanks Gromain. Its a lot of bugs and pinging. Perhaps work on it gradually.

RE: Possible opportunities for Issue Reduction

Plugin Manager - 36 Issues
Enhancements Are some done or outdated?
Bugs

[gromain]

Yes I know. Perhaps a bot can take care of the pinging? Not sure if any exists for Flyspray, I know that a lot exists for Github (for example https://github.com/marketplace/actions/close-stale-issues for stale issues).