Canto Discussions

[kimrutherford]

Hi @ValWood @mah11 @jseager7

I noticed today that GitHub has a built in forum/discussion system. I have no idea how long it's been an option. Looks like it's a beta release.

Do you think it's any use for us for public questions or discussions?

Kim.

[ValWood]

I did some user experience for GitHub demoed a feature to me where you could separate the discussion and conversation in a ticket from the actions so it wouldn't be so hard to go through the long tickets (the ticket was split in. 12). Is this part of the feature? They said it would be available soon and that was about a year ago.

[kimrutherford]

Is this part of the feature?

I guess so.

I'm not sure yet how we would use discussions. Maybe it would be useful to use to spin-off a discussion from an issue? Not sure.

[ValWood]

Maybe we could have a play around on Thursday?

[jseager7]

I'm not really keen on GitHub Discussions, for the following reasons:

1. Makes discussion scattered: currently I only have to look at the Issues tab to see all of the activity and discussion related to Canto (and PHI-Canto, and FlyBase, etc). If we start using Discussions then that's two places I have to keep track of. As far as I can see, it's not even possible to force the Issue tracker to include Discussions (even if the is:issue filter is removed). GitHub might change this in future, but right now I'm not keen on the added obscurity.

2. Requires new policies: if we decide to use Discussions, then I suspect the next question will be when do we use discussions? At what point does an issue contain 'too much' discussion, such that it should be moved to an issue instead? It seems we can either decide to split immediately, in which case the documentation is always separate (as above), or we can decide to move only when there's 'too much' discussion, and presumably part of the discussion stays stuck in the issue. I'm not sure it will be easy to take a consistent approach.

   (Note also that if we decide to use Discussions to track discussion relevant to an issue, then we always have to remember to reference the number of the Discussions thread to link it to the relevant issue, otherwise it will be difficult to know where to look to follow the discussion.)

3. Doesn't seem necessary: I suspect that GitHub Discussions was invented to satisfy large open source projects (i.e. even larger than the Gene Ontology) that want to treat the Issue tracker as just that: a bug tracker. These projects typically don't want their tracker flooded with comments and suggestions from their thousands of users, and tend to use other methods for discussion, like a forum or mailing list. It doesn't seem relevant to relatively small projects like Canto with a fairly closed community of four or five people commenting on an issue at once. When was the last time somebody not known to the project opened an issue?

Having said that, I think the Discussions feature could be useful for the following things:

• Tracking feature suggestions that are truly speculative and may never deserve an issue – basically for establishing the feasibility of a feature before it becomes an action item – but this is probably already covered by your weekly meetings.

• For quick questions and requests that probably don't warrant an issue (but for this we also have email, and there doesn't seem to be any way to close a discussion thread as proof that the question was answered or the request resolved).

I'll still use Discussions if everyone else is in favour of it, but I'd like everyone to have a clear understanding of what we're going to use the Discussions tab for.

[mah11]

I endorse all of the points @jseager7 makes, especially about fragmenting (small-d) discussion and when-to-use-what policy. We already have trouble keeping track of the latter ...