GitHub Discussions for Perl

[rwp0]

We already have a Wiki here in Perl GH space, why not enable Discussions too?

I know there's perl5-ports and other mailing lists, but why it can't exist in addition to them?

Please enable this feature as well, so many newcomers like me can enjoy perusing and conversing Perl topics right next to the code (perhaps with cross-references 🙂) using the convenience of GitHub.

---

Reddit thread

• https://www.reddit.com/r/perl/comments/16gq0xp/github_discussions_for_perl/

[Leont]

Please enable this feature as well, so many newcomers like me can enjoy perusing and conversing Perl topics right next to the code (perhaps with cross-references slightly_smiling_face) using the convenience of GitHub.

Why would we want to have that here? How would this help the development of of perl?

[rwp0]

Please enable this feature as well, so many newcomers like me can enjoy perusing and conversing Perl topics right next to the code (perhaps with cross-references slightly_smiling_face) using the convenience of GitHub.

Why would we want to have that here? How would this help the development of of perl?

Ok but where else to put this request since it's about GitHub?

It helps by extending and enhancing the usage of the GitHub platform.

[gugod]

How would this help the development of of perl?

Although I couldn't say by how much, for the following purposes, Github Discussion is likely a better alternative to perl5-porters (the mailing list):

1. accepting general inquires (alt to stackoverflow)
2. making it mentally easier for people who had never participate before to start participating perl project. By impression, "Discussion" seems to be less serious than "Issues".
3. a place for perl5 porters (the people) to respond to questions and be welcoming to new people

Hopefully it could serve people who are generally outside the realm of perl5-porters a little bit better. These days many people are just not into email mailing lists anymore...

my 2c.

[rwp0]

How would this help the development of of perl?

Although I couldn't say by how much, for the following purposes, Github Discussion is likely a better alternative to perl5-porters (the mailing list):

1. accepting general inquires (alt to stackoverflow)
2. making it mentally easier for people who had never participate before to start participating perl project. By impression, "Discussion" seems to be less serious than "Issues".
3. a place for perl5 porters (the people) to respond to questions and be welcoming to new people

Hopefully it could serve people who are generally outside the realm of perl5-porters a little bit better. These days many people are just not into email mailing lists anymore...

my 2c.

Thanks, I completely agree.

Mailing lists, their archives, and the NNTP articles nowadays feel like a hidden place unaccessible by the inexperienced users where the mystery behind Perl happens 😋

Without such efforts, we can't expect much new language contributors to appear, and the wider involvement in the language development discussions.

Of course, these traditional media can still remain primary, exist in parallel to the Discussions, or even be integrated with it somehow if possible (as with email and GH PR and Issues: since some comments there come by emailing without opening GitHub).

---

Another related issue is the GitHub Wiki, it's there but not much used (as a wiki), because very few people have write access to it.

[oalders]

It would be an interesting experiment to turn on discussions and see how they get used (if at all). It can always be disabled if the outcome is not an improvement.

[rwp0]

improvement

Great idea, but it will need some time for people to notice the availability threof.

[Leont]

How would this help the development of of perl?

Although I couldn't say by how much, for the following purposes, Github Discussion is likely a better alternative to perl5-porters (the mailing list):

1. accepting general inquires (alt to stackoverflow)

What kind of enquiries?

2. making it mentally easier for people who had never participate before to start participating perl project. By impression, "Discussion" seems to be less serious than "Issues".

Maybe, but I'm not sure splitting discussions over more places really makes the situation better.

3. a place for perl5 porters (the people) to respond to questions and be welcoming to new people

Who will do that?

[gugod]

How would this help the development of of perl?

Although I couldn't say by how much, for the following purposes, Github Discussion is likely a better alternative to perl5-porters (the mailing list):

1. accepting general inquires (alt to stackoverflow)

What kind of enquiries?

I could think of a few examples:

1. When do we need to call sv_2mortals and why isn't there sv_2immortls ? (or: what does this interesting thing in perl5.git mean)
2. perldoc POSIX tell me to use END instead of atexit, how do I add an END block but make it only run on a forked child process ? (or: How to use this core function / module to make it do the thing I want)
3. I wish to add a new entry to perlfaq, who should I be talking to for this matter ? (or, how do I navigate myself in this "office environment" before I get to know anyone at all)
4. I've made a draft PR with new changes mostly working, but I'm figuring out this difficult part that could use some insight from experienced hands (or, asking for code reviews)

( I'm actually interested in the 2nd question)

2. making it mentally easier for people who had never participate before to start participating perl project. By impression, "Discussion" seems to be less serious than "Issues".

Maybe, but I'm not sure splitting discussions over more places really makes the situation better.

Right, I too, am not sure that it will be better. It just could be, or not. I'm guessing that Discussion could diverse the kind of comments we have in this repo and ingest the ones that's different than the ones in Issues and slowly attract new people (people who already have some interests in this repo, but only has been lurking around). But is this potential outcome a good one for perl5.git ? I'm not sure.

There is also no prominent evidence saying that developers will just know where to categorize their posts. I've enabled Discussions on perlbrew repo, but Issues still gets most of the posts, even for topics that do not seems to be perlbrew issues in my eyes. Meanwhile, it does not gain much attention at all, so there, maybe a counter-example for this discussion (or issue). Arguably so because I've only made 1 post advertising its existence.

3. a place for perl5 porters (the people) to respond to questions and be welcoming to new people
   Who will do that?

I imagine that people who already spending their time making comments in Issues might be willing to spare a little bit of their time monitoring Discussions. Of course I'm not amending new responsibility to anyone (don't even want to do that to myself) -- this is all volunteer work after all.

[mauke]

2. perldoc POSIX tell me to use END instead of atexit, how do I add an END block but make it only run on a forked child process ? (or: How to use this core function / module to make it do the thing I want)

( I'm actually interested in the 2nd question)

my @atexit_handlers;
END {
    local $@;
    for my $fun (reverse splice @atexit_handlers) {
        eval { $fun->(); 1 } or warn $@;
    }
}
sub atexit($fun) {
    push @atexit_handlers, $fun;
}

Something like this should arguably be in POSIX.pm.

[leonerd]

1. When do we need to call sv_2mortals and why isn't there sv_2immortls ? (or: what does this interesting thing in perl5.git mean)

That's a perfectly fine question to go on the mailing list.

3. I wish to add a new entry to perlfaq, who should I be talking to for this matter ? (or, how do I navigate myself in this "office environment" before I get to know anyone at all)

This too.

4. I've made a draft PR with new changes mostly working, but I'm figuring out this difficult part that could use some insight from experienced hands (or, asking for code reviews)

This too.

These would all be great questions on perl5-porters@

[rwp0]

1. When do we need to call sv_2mortals and why isn't there sv_2immortls ? (or: what does this interesting thing in perl5.git mean)

That's a perfectly fine question to go on the mailing list.

3. I wish to add a new entry to perlfaq, who should I be talking to for this matter ? (or, how do I navigate myself in this "office environment" before I get to know anyone at all)

This too.

4. I've made a draft PR with new changes mostly working, but I'm figuring out this difficult part that could use some insight from experienced hands (or, asking for code reviews)

This too.

These would all be great questions on perl5-porters@

Those discussion made in the mailing lists are usually lost for many after they are made (usually with very few correspondents participating who are very rarely born in 90's and 00's), but GitHub Discussions is open, accessible, convenient (more than the archives), and moreover editable.

Besides there's no markdown, cross-linking with previews etc in such a plaintext environment.

GitHub as a single platform for all things Perl also makes it easy for the brain to go to when needed rather than chasing so many custom-made Perl websites and third-parties such as Reddit and Topicbox.

Also it's more social where one can track developer's profiles and work.

[Leont]

GitHub Discussions is open

[gugod]

These would all be great questions on perl5-porters@

Exactly -- I enumerated those examples because I imagine questions like these should have highest chance to be accurately answered on perl5-porters@ , or on any discussion platform where core / long-term experienced developers are available. Since GitHub is where perl5.git are hosted now, GitHub Discussion could be a viable choice.

[jkeenan]

Those discussion made in the mailing lists are usually lost for many after they are made (usually with very few corresponds participating who are very nearly born in 90's and 00's), but GitHub Discussions is open, accessible, convenient (more than the archives), and moreover editable.

Besides there's no markdown, cross-linking with previews etc in such a plaintext environment.

How did humanity ever survive in a plaintext environment? How did we get anything done without Markdown?

GitHub as a single platform for all things Perl also makes it easy for the brain to go to when needed rather than chasing so many custom-made Perl websites and third-parties such as Reddit and Topicbox.

So what we need to do is to entrust still more of our infrastructure to a subsidiary of Microsoft!

tl;dr: Perl 5 development has problems, but GitHub Discussions is not the solution.

Prelude

@rwp0, I've been very impressed with your work in the Perl 5 core distribution over the past year, particularly the fact that you take the time to code review many pull requests that touch the Perl guts written in C.

However, I don't find your arguments on behalf of GitHub Discussions very convincing. Let me touch upon some of the things you've mentioned over the past few days.

Policy Discussions Belong on the Mailing List

First of all, let me note that this is a discussion about the policy of the Perl 5 project (and more, as I will note further below). Such a policy discussion should have begun on the perl5-porters mailing list, not as a GH issue. But the die has been cast.

Analogy to Wikis Is Misleading

You wrote in your first post,

We already have a Wiki here in Perl GH space, why not enable Discussions too?

Ah, remember when wikis were cool? Remember the YAPC talk where Ingy was giving his presentation from a wiki, and audience members were editing his talk on that wiki even as he as giving it? Those were the days!

I myself used to put considerable effort into posting material on wikis for Perl conferences. Alas, once a given conference was over, its wiki was likely to suffer bitrot and neglect.

"But wait," you might say, "Perl 5 already has a wiki on GitHub." Unfortunately, it's a flop. AFAICT there has been exactly one entry on that wiki in this calendar year: a listing of the new Perl Steering Council (PSC) members elected this summer. There's also a page with summaries of PSC meetings -- but none after June 17 2022. To be quite blunt, if that wiki disappeared nobody would notice its absence.

The point I'm making is that, in order to lock users into its platform, GitHub will always be adding shiny new baubles to its product. There will always be a couple of contributors to a given project who will find the new shiny things appealing, but many will not, and in any event the new shiny things, like the old things from the Stone Ages of the 1990s, will need both maintenance and moderation. GitHub Discussions will be no different.

Are Mailing Lists Old Fashioned?

You wrote in a later post,

"Mailing lists, their archives, and the NNTP articles nowadays feel like a hidden place unaccessible by the inexperienced users where the mystery behind Perl happens[.]"

@gugod wrote along the same lines,

"These days many people are just not into email mailing lists anymore..."

This is really the essence of your argument: Mailing lists are no longer cool. They're no longer fashionable.

We should note, however, that the absence of GitHub Discussions does not seem to have been an impediment to your participation in the Perl 5 project. A simple search in my email client tells me that you have posted to perl5-porters 80 times since August 2021. I get email copies of all posts to our GH issues and pull request queues; you've posted there 495 times since May 2021. You're the author of 54 commits to blead.

Now, a couple of points should be noted. First, perl5-porters is not a mailing list for beginners; never has been, never will. It's not for help writing Perl code. There are other Perl mailing lists and Stack Exchange for that ... and now, I suppose, all that is being assimilated into the Borg of ChatGPT.

Second, there are people on our mailing list who are usually insightful and helpful but are intermittently arrogant, nasty and bullying. Those same people display the same mix of helpfulness and nastiness in GH issues and on IRC. With the demise of our pumpking system it appears that our list moderation functionality has fallen apart. But that's not a problem caused by the absence of GitHub Discussions and any project that implements GitHub Discussions will face the challenge of handling rude participants in that forum as well.

Excessive Dispersal of Locations for Discussion of Perl Language Development

The real problem your advocacy of the use of GitHub Discussions poses is the further fracturing of the terrain on which discussion of Perl's development proceeds. Up until October 2019 (@toddr or @atoomic, correct me if my dates are wrong) we used RT as our bug tracker, but every post to rt.perl.org was copied to the mailing list/news group. So the mailing list plus, perhaps, IRC was all you needed to keep up with core development. (And there have been many prominent contributors to the core codebase over the years (and still today) whom I have never seen on IRC.)

We began to use GH Issues in 2019. Then, once the pumpking system was replaced by the PSC system, we created the PPCs repository underneath the GitHub Perl organization as the place where the PSC would manage what was originally called the Requests For Comments (RFC). One more place for a core developer to keep track of!

As an example of the problem which excessive disperal of locations for discussion poses, I note that, if I really wanted to be thorough in discussing this proposal, I would not only have to compose posts in this GH issue thread -- but I would have to go to Reddit as well, where you have initiated a thread as well!

Experience of Other Perl-Related Projects with GitHub Discussions

For the most part, you have asserted that the Perl 5 project would be better off with GitHub Discussions, but you have not presented any data to back up that assertion. The one exception is that in your original Reddit post you link to the Discussions which are part of the Perl-Apollo organization led, I believe, by Curtis "Ovid" Poe. Ovid is one of the foremost Perl programmers in the world and probably has a better sense than anyone of what it might take for Perl to again be a viable choice in enterprise software development. Though the Perl-Apollo organization appears to be about two years old, the Corinna project's goal, "Bringing Modern OOP to the Perl Core," was introduced into the Perl community back in 2012. I don't follow this closely, but my impression is that these various locales for discussion could be described as follows:

• 0 to 1-1/2 years: Perl 5 Porters mailing list/newsgroup + GH Issues queue

• 1 to 3 years: PPCs: functionality we're considering to build into Perl but for which we don't have actual code proposals

• 2 to 15 years: Moonshots (Apollo!): Ideas that are not yet ready for PPCs.

I am glad that Ovid took over the Corinna process (which seemed to be mostly non-public in earlier years) and has established these separate repositories. I therefore defer to him as to his choice of discussion technologies. He's starting de novo; Perl 5 is not.

Summary

@rwp0, I'm glad that you are thinking about how to attract new people to Perl 5 development. This is a problem that we have faced repeatedly over the years, and we have from time to time overhauled our operations toward that goal. (Example: Conversion of our version control system in 2009 from the proprietary Perforce system to our self-managed Git repository.) However, I think are problems we face are more human than technological and that to expend a lot of energy encouraging people to use GitHub Discussions would simply be a distraction.

I'm in sympathy with what @leonerd wrote about this question in his comment on your Reddit thread.

Thank you very much.
Jim Keenan

[karenetheridge]

p5porters in GitHub discussions? no.

all the other topics previously on lists.perl.org on GitHub discussions? YES!

(you can insert the meme pic here; I'm too lazy to do one up)

The other lists have greatly stagnated of late, and I think the infra maintainers would rather see them all go away. I'd welcome seeing some of the old lists (module-authors, cpantesters, datetime etc) revived in GitHub discussions.

[jgamble]

Somewhat related: Am I missing something, or has the paragraph explaining how to join a mailing list been accidentally edited out of the lists pages? I've looked at both the list of lists page and the individual list pages, and I don't see a "how to join" explanation.

(I was looking because my former ISP has shut down.)

[jkeenan]

Somewhat related: Am I missing something, or has the paragraph explaining how to join a mailing list been accidentally edited out of the lists pages? I've looked at both the list of lists page and the individual list pages, and I don't see a "how to join" explanation.

(I was looking because my former ISP has shut down.)

Let's take the Perl 5 Porters mailing list as an example. When I go to https://lists.perl.org/list/perl5-porters.html, I see instructions such as this:

To subscribe to perl5-porters, send an email to perl5-porters-subscribe@perl.org

To unsubscribe from perl5-porters, send an email to perl5-porters-unsubscribe@perl.org

To get help regarding your subscription, send an email to perl5-porters-help@perl.org

Show advanced instructions...

Is that what you were looking for?

[Tux]

Catching up on mail.

You might gain people by using newer media, but you will also going to miss people (like me). I do not follow github at all! Too much noise, too much irritating HTML in mail and an interface I do not like

The ML is all I need. Nicely packed in plain text. It is only that I answer here because I read about it on the ML and thought my comment would at least represent the contras

my ¢2

[hakonhagland]

Please enable GitHub discussions. This will help draw newcomers into Perl development. The mailing list is not suited for newcomers that are used more modern ways of communicating. On the other side, I understand the arguments of those highly respected core developers that are used to the mailing list and have limited amount of time for learning and checking new communication channels. But without enabling GitHub discussions I think we can expect that the obstacles for communication will be too high for newcomers, and they will just move on to other (more modern) languages.