Enabling GitHub Discussions

[NikosAlexandris]

Dear GRASSers, please consider enabling GitHub Discussions. It will be a great 'resource' in improving GRASS GIS and serving the community that uses and supports GRASS GIS.

[wenzeslaus]

Hi Nikos, please, see the previous discussion we had about GitHub Discussion: grass-dev: Should we use GitHub Discussions?. The fact that you opened this as an issue on GitHub rather than sending it to the mailing is of course interesting!

[NikosAlexandris]

I have read that in the past (might have wanted to answer back then but didn't). I understand the concerns put (initially by @mlennert and @ninsbl). Nonetheless, I think sooner or later the community will (and has to) embrace modern technologies. This without cancelling the mailing lists (though, who knows what the future holds?).

Gentle reminder: it took some years for GRASS GIS to move to git(Hub) when other projects have shown providence. I personally think that GitHub Discussions and/or other tools and channels such as gitter or Slack or even Discord, will happen to GRASS GIS, same as git(hub)¹ happened to GRASS GIS. All of the respectable open source projects we know operate on many of these platforms. Since years ago already.

Pardon me: it appears as if GRASS GIS insists to remain grass-roots. But is this purposive? Is it meaningful? Is it the fear for fragmentation, is it the toll to pay to learn something new, is it the 'unknown' new territory? The lack of man-power alone? What about re-thinking the whole development model? Are there similarly sized projects (in terms of user-base and developers) from which strategies can be adopted/adapted? Is it all together?

For whatever my skepsis is worth, one more thing, which is technically off-topic here, yet so relevant from a philosophical point of view: in whitebox-python, import whitebox is all what is necessary to start. And overall John Lindsay's statement about the design philosophy in How does WhiteboxTools' design philosophy differ? is the right one. GRASS GIS still remains complex/complicated in this regard.

In my humble view, GRASS GIS needs to break its own ground with the move to ver. 8. It has to do so to keep up, to stay relevant, purposeful and awesome. If growing is wanted, opening up Discussions should be done without hesitation and second thoughts. Such a move will rather bring more users in. The question, again, is: is growing more important than trying to protect the development communications from fragmentation? Will growing actually benefit in the long run the development?

(Thoughts from the safe position of a non core-developer that obviously doesn't know the cost of, or/and how to do things, and/or cannot merge-in these ideas of simplicity, integrity and consistency to GRASS GIS' backbone.)

---

1 It could have been GitLab for all OSGeo, yet it is GitHub! ↩

[NikosAlexandris]

Example of Discussions in Miller's repository: https://github.com/johnkerl/miller/discussions.

[ninsbl]

Hi Nikos, by all means, people should feel free to talk about GRASS GIS on all plattforms they like, be it even facebook groups. And personally, I would not object against enabling github discussions. The example you link looks actually quite nice.

With deprecation of nabble, this probably deservse a second look. However, my concern would still be that enabling GitHub discussion in this repo as an "official" channels would require that there is sufficient commitment to maintain it in a proper way. Long term viability is still important to consider, I would stay, esp. if one wants to stay relevant.

One way could be have this explicity as an experimental feature and evaluate at one point if it does have the impact you suggest, and if it is worth maintaining...

[NikosAlexandris]

Hallo Stefan!

In the background of every discussion for a change, for something new, there is always -- and naturally so -- the question who is going to do it?. Well, one answer is everyone and altogether could/should. Step by step, the same way GRASS GIS made it till today. This means for all to embrace and dive-in. If it's not going to work, it's not and that is ok.

For the matter: do you find it easier to search in the e-mail archives to find an answer for a question around programming or else software use or science or anything similar than going through StackExchange? Isn't gitter offering an easy way to chat about development issues (both synchronous and asynchronous)? Do you use gitter's rooms to discuss stuff (both in public and in private) about https://gitter.im/matplotlib/matplotlib for example? What is there to maintain? Isn't it practically zero maintenance? Isn't this the purpose of the Q&A platforms, to take off the load of maintaining yet another big thing?

ps- If I will be given access, I will maintain Discussions. I can do this because I think there is nothing practically to maintain. I can setup a gitter channel or channels, link to repositories and let commit messages to arrive there-in, all in little time. There is not much to maintain.

[NikosAlexandris]

@OSGeo/grass-admins @OSGeo/grass-committers, I request access to:

• enable GitHub Discussions
• spend some time during the week to organize discussions
• and to moderate (see Promoting healthy conversations)

on my own or along with other contributors.

Please refer to the PSC/Election2016 page's history which is relevant for the evaluation of my commitment and voluntary contribution to the project's organisational/administrative tasks.

[mlennert]

@NikosAlexandris You seem to display the discussion that happened on the mailing list as some debate between modern and old technologies. If you read the posts carefully, that is not really true.

The biggest issue raised by most is that of dispersion of discussions. We already have this happening now where a lot of fundamental discussions are happening in PRs and (at least that is the feeling I get) less people are involved in these discussions compared to when everything went through the mailing list. So, the point here is not about old tech nostalgia, but about how to ensure coherence within the group of developers, something that I've seen as one of the big strengths of GRASS GIS development. I do concede, however, that this aim for coherence might be unrealistic if we have increasing numbers of contributors and especially since ways of contributing have fundamentally changed though the move to github and PRs. Personally, I don't have a religion concerning the tools, I just don't want to have to use 5 tools in parallel to make sure I'm informed about important issues discussed concerning GRASS GIS.

And for me (being old-school) email is still the best way of concentrating different information flows into one channel. We use Slack intensively at work, for example, but I do see the issue of high numbers of channels and the difficulty of following all important discussions. But I imagine there are ways to solve this issue with other tools than email, and I would just need guidance. Github does allow to respond to email notifications by email and so I imagine that this is also possible for github discussions, which would probably solve this issue for us (I still have difficulties finding the right filter settings to really see only important email notifications, and not every single interaction - but again that's me needing guidance, probably not linked to the tools).

If we agree that dispersal is an issue, but that mailing lists are not the way to go anymore as the central place of discussion, then let's discuss all available tools and chose among them, also taking into account issues such as dependency of a proprietary provider, etc. But please let's not just open new channels everywhere just because it's the cool thing to do ;-).

[mlennert]

See https://github.com/github/feedback/discussions/59 for a discussion on the difficulties of filtering github email notifications.

[NikosAlexandris]

Hi @mlennert, I read carefully what you wrote/write.

@NikosAlexandris You seem to display the discussion that happened on the mailing list as some debate between modern and old technologies. If you read the posts carefully, that is not really true.

I don't display any debate between old and new. If this is your interpretation, I respect it. But I don't accept it. I have a genuine interest in all about GRASS GIS and I do as possible (mostly behind the scenes) to contribute the way I think is best and can. It's all honest questions I share openly.

The biggest issue raised by most is that of dispersion of discussions. We already have this happening now where a lot of fundamental discussions are happening in PRs and (at least that is the feeling I get) less people are involved in these discussions compared to when everything went through the mailing list. So, the point here is not about old tech nostalgia, but about how to ensure coherence within the group of developers, something that I've seen as one of the big strengths of GRASS GIS development. I do concede, however, that this aim for coherence might be unrealistic if we have increasing numbers of contributors and especially since ways of contributing have fundamentally changed though the move to github and PRs. Personally, I don't have a religion concerning the tools, I just don't want to have to use 5 tools in parallel to make sure I'm informed about important issues discussed concerning GRASS GIS.

I am not a core-developer so I have no right to participate in a discussion on how the core dev-team coordinates internally. So, I have nothing to say about the dev-team. I do have a direct interest to participate in the project as an Addons contributor, as a long-year GRASS GIS user and OSGeo member. Discussions is the 'natural' place to discuss things about GRASS GIS from my perspective, indeed because of its natural integration with the repository.

I agree that fragmentation is not good overall -- except for when it's stimulating and leads to new forms. I would question 'why not keep dev-work related communication wherever the dev-team sees best fit?' and still activate Discussions for new users, for users like me and everything about GRASS-GIS except for what the dev-team is discussing? Sure, it's not that simple.-

And for me (being old-school) email is still the best way of concentrating different information flows into one channel. We use Slack intensively at work, for example, but I do see the issue of high numbers of channels and the difficulty of following all important discussions. But I imagine there are ways to solve this issue with other tools than email, and I would just need guidance. Github does allow to respond to email notifications by email and so I imagine that this is also possible for github discussions, which would probably solve this issue for us (I still have difficulties finding the right filter settings to really see only important email notifications, and not every single interaction - but again that's me needing guidance, probably not linked to the tools).

There is a natural 'old-school' vs. 'new-school' clustering, which you identify here in the beginning of your sentence. I want to note that I am also for e-mail to communicate! But one can simply not beat the efficacy of modern tools in searching for answers.

If we agree that dispersal is an issue, but that mailing lists are not the way to go anymore as the central place of discussion, then let's discuss all available tools and chose among them, also taking into account issues such as dependency of a proprietary provider, etc. But please let's not just open new channels everywhere just because it's the cool thing to do ;-).

In overview,

• I have well thought my request for enabling Discussions -- it's something I think will help, something I can contribute to, something that will save time in interacting as a user with other users and developers
• I am not participating in the coordination of the dev-team and I am not indirectly willing to influence anything
• I am not in favor to start using new tools simply because they are cool
• proprietary vs. open source: hmmm.... lots of open questions here (own git server maintenance?, OSGeo in GitHub, why not GitLab, why not elsewhere, etc.) but at the very minimum, the project should ensure it can pack its stuff and move elsewhere If it will be ever necessary (for example if Microsoft decides to charge each commit or similar!)

Cheers :-)

[wenzeslaus]

The discussion on grass-dev mentioned things like migrating our mailing list to mailman3, integrating with hyper kitty, promoting nabble on our GitHub repository and checking whether it would be feasible to sign up to nabble or mailing list with OAuth or GitHub. There was no report or activity regarding those. In the mean time, nabble is going down.

There was also a talk about encouraging all contributors to discuss/mention more significant changes on the mailing list. It seems this happening even without the encouragement. However, the response rate seems to be relatively low and some developers conclude that they "got only a bit of feedback" on mailing list.

Things like vendor lock-in and fragmentation are valid concerns. Vendor lock-in applies only partially here, we don't shut down the mailing list to avoid being trapped and nor we are replacing grass-dev mailing list as a place to officially reach all the core and highly involved developers and concerned users. This is similar to how we are mitigating vendor lock-in of having PRs on GitHub, besides having the benefits of Git, we capture the important pieces of discussion or decisions in the commit message (right everyone? :smile: ).

As for the fragmentation, I think the main purpose of GitHub Discussions is to reach people on GitHub who are maybe using 10 other projects on GitHub and need to ask this one question about GRASS GIS. Additionally, nothing goes to the source code unless there is a PR, so there is a one and only channel for that. Finally, we don't limit people in having private conversations about GRASS GIS nor we control what happens during community sprints, so there was always a need for self-discipline to share what is needed through the right channels at the right time. As far as seeing and participating in communication on GitHub, from the 10 people involved in the grass-dev discussion about GitHub Discussions which lasted for almost a month, 3 of us are already here after 6 days, so people do see it.

Given commitment by @NikosAlexandris to "spend some time during the week to organize discussions and to moderate" them, the lack of action in other areas since the last time this was brought up, and seconding from @petrasovaa (+1) and no objections from @ninsbl, I'm going to enable GitHub Discussions. Let's try it, see how it goes. We can evaluate it in a year.

[cmbarton]

I've had similar conversations in the CoMSES.Net community. How to facilitate communication while letting people 'tune out' non-relevant communication to as to not be overwhelmed. There is not an easy answer so far, and the increasing diversity of potential communication channels has not made this easier, but rather more complicated with greater potential for fragmentation and dilution of important information exchange.

I agree with Vaclav and Nikos that GitHub discussions is worth a try. BUT, here are some things to consider.

1. Is enabling GitHub discussions being done with the idea of possibly replacing email lists or for adding another communication channel?

   • This is part of the discussion so far. If it is the former, we might want to encourage migration by mirroring the structure of the current set of email lists in GitHub discussions--especially the user and dev list. Or perhaps just start with one list and see if people are encouraged to migrate. I don't yet know enough about GitHub discussions to know if we can have separate channels like our current mailing lists or not. But it is worth looking into.
   • Migrating to GitHub discussions might actually make my email overflow worse. This is something we need to consider if our goal is to have more efficient communication with less noise. The reason it could be worse is because of the way GitHub notifications are set up currently. As a member of the dev team, I'd like to hear about and follow issues that I find relevant, that I'm mentioned on, or where I've contributed to discussions (like here). But even though I've got 'participating and @mentions only' checked, I seem to get notifications in my email for every issue that comes up. In email, at least I can have it delivered as a digest. The 'custom' option is only if you want to add additional notification for different classes of communication (issues, PR, etc). Filtering this to the most relevant communication does not seem possible. But maybe there is a way to configure this.
   • Discussions seems like a good way to archive communication and be able to search it. The grass lists are very active. After a few years, how will this scale? The current email archive is very large. Maybe this is no problem in GitHub, but worth checking to see if it will scale OK.
   • One potential advantage is to more easily and directly link discussion to issues and PRs. If we could follow a standard best practice, this could be a real benefit: 1) start with a discussion, 2) if there is an action item proposed, it moves to an issue linked with the discussion, 3) if the issue is acted on by a PR, it is likewise cross-linked to the issue and discussion thread.

2. If GitHub discussions are not envisioned as ultimately replacing the mailing lists, I am worried about fragmentation like Morritz. We would need to have a well defined GitHub communication channel so that users would know where to post and search (email or GitHub).

3. If we want to be even more adventurous, an alternative communication channel to email or GitHub discussions that shows promise is Discord. I'm trying it for an international consortium initiative and it seems to work well. It can have multiple channels and channel groups, threaded discussions, and the potential of live audio/video rooms for live interaction. It also has the potential to link with GitHub and other media channels. Perhaps worth considering at some point.

[NikosAlexandris]

ps- If I will be given access, I will maintain Discussions. I can do this because I think there is nothing practically to maintain. I can setup a gitter channel or channels, link to repositories and let commit messages to arrive there-in, all in little time. There is not much to maintain.

By the way, moderation != maintenance. This is to support my argument that GitHub Discussions and other modern tech of the trade will save (maintenance) time. Moderation is something else.

[NikosAlexandris]

..

2. If we want to be even more adventurous, an alternative communication channel to email or GitHub discussions that shows promise is Discord. I'm trying it for an international consortium initiative and it seems to work well. It can have multiple channels and channel groups, threaded discussions, and the potential of live audio/video rooms for live interaction. It also has the potential to link with GitHub and other media channels. Perhaps worth considering at some point.

Awesome @cmbarton! Discord will be great!

[NikosAlexandris]

See github/feedback#59 for a discussion on the difficulties of filtering github email notifications.

@mlennert I have read it. Given the growing user-base of Discussions in GitHub's world, this should be rather fixed sooner or later and become easy to filter notifications. It would eventually become almost seamless to (old-school) e-mail users to interact with members using Discussions.

[wenzeslaus]

Discussions are enabled and tested. Closing the issue.