Communication platforms discussion
olzama opened this issue · comments
ah, i confess i was at best passively aware of GitHub discussions. i think @olzama is making an important point, and closing an issue does not at all seem like the best way of marking the solution, indeed. from my point of view, the previous extended uses of GitHub issues were essentially a todo list (for me), so closing was an attractive aspect of that :-). so, let me retract a little: maybe reserving issues for request-like communications is a good policy.
i had not thought of the various candidate contexts on GitHub either, where one could choose to create either issues or discussions. that seems like another important discussion to have, as spreading these out more than necessary feels potentially detrimental. presumably each repository (module, data, or code) needs its own issue tracker, but possibly we could postulate that there is one unified discussion space for all of DELPH-IN?
at this point, i am tacitly assuming that the developers list can be made inactive relatively soon. one option i had considered was replacing it with discussions among e.g. the participants team. we have recently tried on that strategy for the standing committee, and i think there is emerging consensus that we can leave our mailing list behind.
but preserving the twenty or so years of developers archive intact would seem very desirable to me. a cheap option would be to continue to host them through the DELPH-IN mailman site (which i expect to keep operational for the foreseeable future), but that interface is not especially good at e.g. search. it does, however, support navigation by thread.
i am not sure how difficult or hard it will be to import mailing list archives into the discourse site; the mailman mbox files are a pretty standard archiveformat? we are not the first to consider this kind of move, it seems:
Originally posted by @oepen in #30 (comment)
@oepen , to be honest, I don't know what exactly to do about porting the old developers list. I never could figure out how to do that with Discourse. I know it is possible theoretically but from what I can tell, nobody really succeeded in doing that, at least not with an existing forum. I think you can maybe start a fresh forum that way (base it off of the mailing list). But because it involves email addresses, I had decided awhile ago, when I was setting up the forum, that I wouldn't mess with that. So while this remains an important desideratum, I am not sure I can do that.
As for starting using Github discussions: it looks like they have the "solution" functionality, so, it would make sense if we moved there. And maybe one day there is functionality to import both mailing lists and forums there? I wouldn't rule it out, actually.
Funny that we are using an issue to discuss if issues are a good place for discussions! ;-)
My bias came from my interaction with the UD people. The UD community is using issues in the https://github.com/UniversalDependencies/docs, the mailing list hosted by Google groups is almost abandoned, used just for few official communications about releases and changes in the policies.
Nevertheless, using issues properly is not trivial and requires extra care. The most annoying limitation for me is that replies by email can't be formatted in markdown - even if the author later edits the message in the browser. The quote is also not trivial, we can’t select a fragment of a message to start a reply in the web interface, we need to do it manually. I personally don't like replies that maintain the old message completely quoted in the end. This is a waste of space and it is confusing, the same text fragment being repeated many times (hidden in the web interface, but still there and any future use of the data via API would have to deal with that). Issues are linear, we can branch discussions as a tree. But maybe it is a feature, not a limitation! ;-)
But we do have good things. We can link (and make links to them) to specific lines of code, other issues, commits, etc. I think issues are better integrated with GitHub than the discussions forums of the teams, but I may be wrong.
I guess that whatever channel we use if we want to maximize the communication efficiency, future maintenance, and acknowledge that discussions are documentation. We will need some policies and good practices in place. Even the forum is not always used in the best way (messages without category, code not formatted, links to unstable URLs, etc)
another limitation is that GitHub sends email notifications for the new messages in the discussion forums and issues, but does not notify editions of previous messages. That is why I tend to always read the messages in the browser, not in the email notification that I got. I did small fixes In my previous message, hope that others also read it in the browser! ;-)
Funny that we are using an issue to discuss if issues are a good place for discussions! ;-)
I only did this because I used the "Reference in new issue" functionality, when I copied Stephan's text :). I am not in favor of using issues for discussions; I am in favor of using something that has a "solved" functionality. Or rather, I am in favor of using that for Q&A; for general discussions, perhaps it doesn't matter much.
Oh, I didn't know about this functionality "reference in new issue"! We can also select a fragment before use the "quote reply", so I was wrong above, it is very useful.
If the mailing list is to be made inactive, then I would prefer either the Discourse site or GitHub repository discussions to be the place for Q&A, announcements, and other general conversations, rather than GitHub Issues (as we are doing here) or team discussions, which are more limited. Discourse and GitHub repository discussions allow for limited threading of messages, to mark posts as solutions, and other features relevant for that mode of communication.
I have some further thoughts on migrating to GitHub discussions below.
Migrating Mailing List and Discourse Content
It would be nice to migrate all our posts from the developers mailing list and the Discourse site so the history is all in one place. These two sites have different features so the process of migrating would look different. I'm not sure if anyone has written code to import, e.g., .mbox files into GitHub Discussions, but there is a GraphQL API, so it should be possible. When moving SVN repositories to GitHub, I was able to use GitHub's "noreply" email addresses to link commits to a user's profile without exposing their actual email address, and we might be able to do something similar with importing the mailing list, however the list archives were already public so it might not be a big deal? However, I doubt we can import discussions and present them as if they were created by the original author, even if we know their GitHub account, as it might count as impersonation.
Using GitHub Discussions
I haven't extensively used GitHub Discussions, so I'm not sure how well it works with large histories. We can get an idea by looking at a large, existing discussion space, like the one @oepen linked before: https://github.com/github/feedback/discussions. It generally looks nice but the filtering options are hidden. Notably, I cannot easily filter messages by date, although it is possible with search parameters, e.g., created:>=2021 (only those created this year) or updated:2021-03..2021-04 (only those updated between March and April, 2021). Those become URL parameters so we could create links for common queries to help people who don't remember the syntax, or even to make a custom search form as we did for the wiki.
Which Discussion Space?
I still think the DELPH-IN documentation, including the wiki, is a kind of DELPH-IN resource and therefore the docs repository (this one) is meant for working with that resource, so it seems somewhat odd for it to also host general discussions. We could create a repository only for discussions (no code, no wiki, etc.), much as the previously linked github/feedback repository does.
As will probably surprise no one, I am very much against the idea of abandoning the Discourse site in favor of anything on Github. (Though moving what was previously on 'participants' here might well be workable and I don't really feel like I have a horse in the race with respect to 'developers'.)
Among other things, I find the github interface insufferable. There's a huge hurdle it seems every time I try to do something even remotely new here, and think that's because github was designed with a specific type of user in mind, which I am not. So, I probably will not be very responsive to questions about analyses in the Matrix or other discussions of how to do things with our tools as a grammar engineer if they're all here.
Furthermore, I think it is also important that we keep the audience for those discussions in mind. If we have people new to grammar engineering who would like to communicate with us and get our input, my guess is that the Discourse site is a far more welcoming interface than having to wade through all the "you don't belong here" messages that the github interface throws up to someone not already familiar with it/not used to interacting with the world through pull requests yadda yadda.
I acknowledge that we sometimes have up-time issues with Discourse that are unlikely to appear here, but honestly, I don't think these are so severe that they outweigh the above.
I might not find GitHub insufferable, but I agree that Discourse is much more welcoming, and I would strongly prefer that we have discussions on Discourse. For GitHub, there is a quite a learning curve for a newcomer to understand repos, discussions, issues, etc.