Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable Proj GitHub Discussions #4037

Open
jidanni opened this issue Feb 6, 2024 · 9 comments
Open

Enable Proj GitHub Discussions #4037

jidanni opened this issue Feb 6, 2024 · 9 comments

Comments

@jidanni
Copy link
Contributor

jidanni commented Feb 6, 2024

In addition to the current channels,
https://proj.org/en/latest/community/channels.html
perhaps do like
https://github.com/GenericMappingTools/gmt/discussions
and enable
https://github.com/OSGeo/PROJ/discussions

@rouault
Copy link
Member

rouault commented Feb 21, 2024

More channels means the same number of people that can answer spread over more channels, so I'm -0 on this

@kbevers
Copy link
Member

kbevers commented Feb 21, 2024

so I'm -0 on this

Same. Maybe even -1. I believe the SAC-people are working on a forum-like frontend for the mailing lists which will offer an alternative way to join the discussions.

@jjimenezshaw
Copy link
Contributor

I agree with @rouault and @kbevers.

@snowman2
Copy link
Contributor

There are some benefits to discussions:

  • Can organize discussions better with tags/type
  • Code formatting & markdown for easier readability
  • You can unfollow discussions that are not relevant to you
  • searchability of discussions

I personally prefer discussions over a mailing list and would lean towards ending the mailing list and use discussions instead. That is what we did for rasterio & pyproj and it has worked great.

The main downside of that would be porting people over to discussions from the mailing list. But, it isn't too difficult to sign up for a GitHub account.

@hobu
Copy link
Contributor

hobu commented Feb 21, 2024

The PROJ mailing list is one of the most valuable collections of geodetic experts in the world. Some members have been active for nearly twenty years. Forcing them to migrate to a GitHub Discussions, which GitHub might get bored with one day and drop, would be detrimental to the project.

All of @snowman2's points about benefits of discussion boards are true, but they miss one key benefit of a mailing list – the serendipity it provides. That serendipity is extremely important when you're dealing with topics like geodesy and coordinate systems.

TLDR; PROJ mailing list is full of old people who know esoteric topics and forcing them to migrate will probably cause many to drop.

I would much rather suffer answer-my-question-now lazy ticket traffic than lose the culture of our mailing list. We're a 40 year old project, after all.

@snowman2
Copy link
Contributor

I think that a hybrid approach could provide some benefits:

  • Discussions: Q&A for PROJ usage general help (I believe that those answering most of these questions have a GitHub account already)
  • Mailing list: geodesy & coordinate system discussions as well as discussions needing more expertise

This would reduce traffic on the mailing list for general PROJ usage questions. This could increase engagement as experts would reduce how much they have to filter out threads that aren't relevant to them. It would become the place to discuss things where it's user base provides the most value.

I am probably biased because I have enjoyed the benefits of discussions. I support no changes if that is determined to be in the best interest of the PROJ community.

@rnanclares
Copy link

so I'm -0 on this

Same. Maybe even -1. I believe the SAC-people are working on a forum-like frontend for the mailing lists which will offer an alternative way to join the discussions.

Yep you can find it here: https://discourse.osgeo.org/
If you want to migrate the list to discourse (and keep all the mailing list messages) you just need to ask the SAC. For those that don't know Discourse, it can be used as a mailing list or a forum depending on your preferences, and it's currently used in a lot of foss projects (i.e. Gnome, Fedora, OpenDroneMap, etc).

@jidanni
Copy link
Contributor Author

jidanni commented Feb 22, 2024

Forcing?
Let's examine my original proposal,

In addition to the current channels,

See? I'm all about choice!

That way I could post my dumber questions to the future GitHub discussions, saving my smarter questions for the mailing list!

As far as Discourse goes, I'm not talking about that. I'm just talking about GitHub Discussions which could be enabled with a flip of a switch!

@busstoptaktik
Copy link
Member

See? I'm all about choice!

@jidanni in all respect of this, I nevertheless think that choice is not the optimum answer, when its all about the means to the ends: Spreading out the expertise thinner will just make you need to cross post heavily to even have a chance of getting your questions answered so your value proposition of:

I could post my dumber questions to the future GitHub discussions, saving my smarter questions for the mailing list!

doesn't really cut the mustard.

Also, I do not remember having seen you on the mailing list (which may be due to my deteriorating memory, so don't feel offended!), but I think you have demonstrated a lot of community-relevant stamina pushing on here on Github: I really appreciate your still ongoing efforts of improving the PROJ docs, even though your material often sit unreviewed until being closed for inactivity: This is not your fault, but just another symptom of the thinly spread expertise: You can only do so much during a week when $DAY_JOB interferes with "more important activities".

So thank you for taking time to being part of the team - don't stop, and please do what you can answering questions on the mailing list whenever you have relevant knowledge: As you have the geodetic oomph to improve the PROJ docs, you certainly also have something to give on the mailing list!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants