Say you want to contribute to a project and find out the only way to do so is by discussing the issue on IRC or the mailing list, then submitting the patch per email.
IRC is fine for almost synchronous communication - but dealing with things that work on the timescale of days or weeks, IRC becomes difficult to maintain a discussion about a fix or feature over that timeframe that includes all the interested participants.
Mailing lists often come with an archive and a sufficiently large project will have multiple lists for different aspects of the project. Consider gcc ( https://gcc.gnu.org/lists.html )and you’ll see that bugs and patches are their own lists. Going into there you can also see the archives for the project… and if the mailing list software has support for it, viable by thread https://gcc.gnu.org/pipermail/gcc-bugs/
git has support for (and was originally used via) email. git send-email (docs) and git am (docs) are part of its original functionality and that workflow can make use if it.
I’m personally most comfortable with GitHub or GitLab, followed by email. An IRC or discord project lacks the ability to properly research the “why was this done that way back in 2016”… unless the project doesn’t aspire to be a long lived open source project.
Managing email is something that should be considered as part of this. Setting up a separate email address for that project, or using the + addressing as part of the email to make it so that your email filters can operate on them better (Exchange, gmail). This may require deeper familiarity with email clients than is common today - smart mailboxes in Mac Mail, client side rules in Exchange, or old school procmail with a shell account.
I totally agree longterm projects are better off using github or email.
Here is the crux for lively discussions using discord/IRC comes more natural. But whilst it facilitates easier flowing communication it fails to preserve it.
I think it’s super based. All these clowns talking about open source while using Discord and GitHub (yes, that’s me included). You want to submit a bug report to Git itself? Well, you gotta send a bug report to the mailing list. Then some guy will be like “oh shit can you fix it also?” and I’m like “haha no” so the dude submits a fix himselg within 4 hours, and obtains the raging hard boner of internet developer clout
Great system, pgp keys are actually useful. And everyone knows you have to be at least an 8/10 in handsomeness to be running an IRC server. Also, Matrix is trash, I’m serious, modern IRC is cool
Indeed. I wonder if LinuxNet / #linux is still around, actually. That was interesting back in the day, and later meeting many of the characters at conferences and meetups. IRC was great. Patches by email, otoh… Good that it is possible, but PRs/MRs are nicer.
Personally I am comfortable with that as long as there is a public git repo. An issue tracker is the one thing I’d miss the most. I think how well this goes down will greatly depend on the project’s target audience. notmuch is a project that I follow closely and very occasionally contribute to that works this way.
I never really used IRC, but in my experience contributing to projects which use mailing lists is very easy - you just send a mail with some code.
Of course you could use git-send-email, and you could create diffs and patches, but I actually think for a new contributor the mailing list workflow is the simplest since it doesn’t actually require knowledge of the various tools experienced developers use.
I write this from personal experience BTW - the first projects I contributed to used mailing lists, which allowed me to contribute even as a self taught programmer who had no experience with any VCS yet.
From a contributor point of view, mailing lists are definitely easier than pull/merge requests - you just send a patch which you can create in any way you want to an email address.
Following a discussion is easy - it’s just a list of messages. In fact, it is easier for me since I use Gnus as my email client, which gives me a threaded view of discussions on the list.
I participate in projects being developed on Github that have 5k+ open pull requests and the same amount of issues. At that volume of communication, the Github workflow of “clicking through stuff” is way inferior to an efficient email workflow. Essentially, your workflow turns into email anyways because its the only sane way to consume based on push, and yes, I know, you can reply to Github using email, but its not nearly as good as something made for email.
So, in my opinion, email is simpler to use that pull request. It is not easiser because it is not close to what people are used to.
At that volume of communication, the Github workflow of “clicking through stuff” is way inferior to an efficient email workflow. Essentially, your workflow turns into email anyways because its the only sane way to consume based on push (…)
I don’t agree. Any conversation on pull requests happens through issues/tickets, which already aggregate all related events and are trivially referenced through their permanent links, including through the Git repo’s history.
IRC is fine, so are mailing lists; I use both, plus various git forges, to contribute to open source projects.
IRC is still going strong on OFTC and Libera.chat
I get that the younger folks like discord, but seriously it’s a proprietary mess that locks everything behind a wall and tries to extract payment from each and every user.
Agree with many of the other comments here saying that they’d be very wary of such a project based on what these choices say about the project’s maintainers. Something else is that while I have real affection for email and particularly IRC based on past experience, I don’t think these two are without problems. Email is so asynchronous that many folks feel obligated to treat writing messages to a list more formally. This is not totally misguided since everyone subscribed gets this message delivered to them. IRC, on the other hand, is so synchronous that you should reasonably worry if anyone will be there to talk with, and about whether or not there are searchable archives.
Something (like GitHub) that can be quick but is also perfectly serviceable for asynchronous communication really does have advantages, imho.
These technologies, although archaic, clumsy and insecure, are not a fatal problem - these are still open and widely accessible anyway.
However, this case may indicate that the projects author is an autocratic hermit type, locked in a bubble with his ancient tech and not really welcoming outside contributors and bug reports, so these IRC and maillists come with worse things such as CVS, C89 code, build system handwritten in shell which only works on author’s machine, and complete unwillingness to discuss, fix, modernize and make the software more portable, so not only contribution attempt would be a waste of time, but simply using such project could pose risks.
Of course that’s not necessarily the case and it may be just good old IRC and maillists, and that should not be the problem for most people. For me personally though, for I contribute to hundreds of F/OSS projects, this is a show stopper, as I absolutely want to minimize routine tasks. One-two git/gh commands is what I’m used to, while installing extra software, going through registrations, copypasting patches, monitoring additional sites for feedback does not work. In the best case I would fire-and-forget, so if someone on some god forgotten self-hosted gitlab asks to fix a thing in my PR I will never see it. Or more likely, I would put such contributions into my contribution queue with lowest priority, and since the queue of what I want to improve is always growing and never shrinking, it effectively cancels them.
And I could add that you don’t really need realtime communication channels to contribute - technical stuff may and should be discussed in async mode as in issue/PR comments (or email reply thread in the worst case), where unrelated discussions don’t happen in parallel, message size is not limited, history is preserved, nobody is in rush to reply, you don’t need to actively wait for reply and cannot miss it because you’ve disconnected, someone forgot to tag you or it was just list in the chat.
Summarizing, the project should be on [the most popular VCS hosting at the moment], which is currently GitHub, any other choice makes it much less accessible and welcoming. For chat use whatever you want, for it’s not related to contributions. If you think otherwise, at least stick to open protocols.
It’s the year 2023.
I find it baffling that you think it’s OK to marginize and insult people like that just because they choose to spend their mostly free time communicating on a medium that you don’t agree with.
You are right a project author can do as they please, but so can a project contributor. Both spend their mostly free time on that project, so it should be comfortable for both to do so.
There is no need to automatically agree. We can have different styles and disagree, in which case people might prefer to contribute to some other project instead, or work with other contributors instead.
Stating that using these methods of organizing a project is indicative of “the projects author is an autocratic hermit type, locked in a bubble with his ancient tech and not really welcoming outside contributors and bug reports” is not an opinion, it’s nonsense and its insulting.
Right, I get now what you mean. In defense of the other person, they said this may be the case. Which implies that it also may not be the case. It’s a worry spoken out, maybe without thinking too much about how to word it in a way which does not come across as insulting.
I would frown at this in a direct conversation, but not so much in an indirect, general talk about opinions. In the current setting, I appreciated the opinion as open and direct. I don’t think anyone’s feelings have been hurt here, unless someone actively wants to feel offended.
I like IRC and still use it daily to keep up with other hobbyists. Then again, vintage computers are my main hobby horse and of course those circles are gonna lean towards platforms that remain usable on a VIC-20.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
IRC is fine for almost synchronous communication - but dealing with things that work on the timescale of days or weeks, IRC becomes difficult to maintain a discussion about a fix or feature over that timeframe that includes all the interested participants.
Mailing lists often come with an archive and a sufficiently large project will have multiple lists for different aspects of the project. Consider gcc ( https://gcc.gnu.org/lists.html )and you’ll see that bugs and patches are their own lists. Going into there you can also see the archives for the project… and if the mailing list software has support for it, viable by thread https://gcc.gnu.org/pipermail/gcc-bugs/
https://lkml.org/lkml/2013/11/25/519 is another fun read (that entire thread).
git has support for (and was originally used via) email.
git send-email(docs) andgit am(docs) are part of its original functionality and that workflow can make use if it.I’m personally most comfortable with GitHub or GitLab, followed by email. An IRC or discord project lacks the ability to properly research the “why was this done that way back in 2016”… unless the project doesn’t aspire to be a long lived open source project.
Managing email is something that should be considered as part of this. Setting up a separate email address for that project, or using the + addressing as part of the email to make it so that your email filters can operate on them better (Exchange, gmail). This may require deeper familiarity with email clients than is common today - smart mailboxes in Mac Mail, client side rules in Exchange, or old school procmail with a shell account.
I totally agree longterm projects are better off using github or email.
Here is the crux for lively discussions using discord/IRC comes more natural. But whilst it facilitates easier flowing communication it fails to preserve it.
I wouldn’t want a new project to be run that way, but contributing to older existing projects really isn’t that bad.
I think it’s super based. All these clowns talking about open source while using Discord and GitHub (yes, that’s me included). You want to submit a bug report to Git itself? Well, you gotta send a bug report to the mailing list. Then some guy will be like “oh shit can you fix it also?” and I’m like “haha no” so the dude submits a fix himselg within 4 hours, and obtains the raging hard boner of internet developer clout
Great system, pgp keys are actually useful. And everyone knows you have to be at least an 8/10 in handsomeness to be running an IRC server. Also, Matrix is trash, I’m serious, modern IRC is cool
What do you dislike about Matrix?
It would have to be a pretty niche project with an involved and dedicated community to get away with that these days.
Yeah super niche projects like the Linux Kernel and Git
To be fair, at least the kernel is super niche in terms of development.
deleted by creator
I think they meant new projects starting today, not currently existing ones.
Indeed. I wonder if LinuxNet / #linux is still around, actually. That was interesting back in the day, and later meeting many of the characters at conferences and meetups. IRC was great. Patches by email, otoh… Good that it is possible, but PRs/MRs are nicer.
Personally I am comfortable with that as long as there is a public git repo. An issue tracker is the one thing I’d miss the most. I think how well this goes down will greatly depend on the project’s target audience.
notmuch is a project that I follow closely and very occasionally contribute to that works this way.
I never really used IRC, but in my experience contributing to projects which use mailing lists is very easy - you just send a mail with some code.
Of course you could use git-send-email, and you could create diffs and patches, but I actually think for a new contributor the mailing list workflow is the simplest since it doesn’t actually require knowledge of the various tools experienced developers use.
I write this from personal experience BTW - the first projects I contributed to used mailing lists, which allowed me to contribute even as a self taught programmer who had no experience with any VCS yet.
Do you find mailing lists easier to use than pull requests / merge requests? And how do you find following a discussion in a mailing list?
From a contributor point of view, mailing lists are definitely easier than pull/merge requests - you just send a patch which you can create in any way you want to an email address.
Following a discussion is easy - it’s just a list of messages. In fact, it is easier for me since I use Gnus as my email client, which gives me a threaded view of discussions on the list.
For newer/inexperienced users mailing lists are definitely easier. Everyone can send an email.
Yes and it depends to both questions.
I participate in projects being developed on Github that have 5k+ open pull requests and the same amount of issues. At that volume of communication, the Github workflow of “clicking through stuff” is way inferior to an efficient email workflow. Essentially, your workflow turns into email anyways because its the only sane way to consume based on push, and yes, I know, you can reply to Github using email, but its not nearly as good as something made for email.
So, in my opinion, email is simpler to use that pull request. It is not easiser because it is not close to what people are used to.
I don’t agree. Any conversation on pull requests happens through issues/tickets, which already aggregate all related events and are trivially referenced through their permanent links, including through the Git repo’s history.
IRC is fine, so are mailing lists; I use both, plus various git forges, to contribute to open source projects.
IRC is still going strong on OFTC and Libera.chat
I get that the younger folks like discord, but seriously it’s a proprietary mess that locks everything behind a wall and tries to extract payment from each and every user.
If you host thelounge using IRC is quite cool. As you get a better experience with backed up messages and stuff.
Lounge looks pretty cool
To anyone interested, there is a comprehensive tutorial about how to use Git with email to contribute to projects like these.
https://git-send-email.io/
s/IRC/XMPP/or maybe mattermost instead of a mailing list?Agree with many of the other comments here saying that they’d be very wary of such a project based on what these choices say about the project’s maintainers. Something else is that while I have real affection for email and particularly IRC based on past experience, I don’t think these two are without problems. Email is so asynchronous that many folks feel obligated to treat writing messages to a list more formally. This is not totally misguided since everyone subscribed gets this message delivered to them. IRC, on the other hand, is so synchronous that you should reasonably worry if anyone will be there to talk with, and about whether or not there are searchable archives.
Something (like GitHub) that can be quick but is also perfectly serviceable for asynchronous communication really does have advantages, imho.
I’m still trying to figure out github. I am at the beginning of my computer learning journey.
Both are heavy targets of spamming and take considerable effort to maintain
True for everything on the open internet though.
Case and point: https://social.anoxinon.de/@Codeberg/111080409541766357
These technologies, although archaic, clumsy and insecure, are not a fatal problem - these are still open and widely accessible anyway.
However, this case may indicate that the projects author is an autocratic hermit type, locked in a bubble with his ancient tech and not really welcoming outside contributors and bug reports, so these IRC and maillists come with worse things such as CVS, C89 code, build system handwritten in shell which only works on author’s machine, and complete unwillingness to discuss, fix, modernize and make the software more portable, so not only contribution attempt would be a waste of time, but simply using such project could pose risks.
Of course that’s not necessarily the case and it may be just good old IRC and maillists, and that should not be the problem for most people. For me personally though, for I contribute to hundreds of F/OSS projects, this is a show stopper, as I absolutely want to minimize routine tasks. One-two
git/ghcommands is what I’m used to, while installing extra software, going through registrations, copypasting patches, monitoring additional sites for feedback does not work. In the best case I would fire-and-forget, so if someone on some god forgotten self-hosted gitlab asks to fix a thing in my PR I will never see it. Or more likely, I would put such contributions into my contribution queue with lowest priority, and since the queue of what I want to improve is always growing and never shrinking, it effectively cancels them.And I could add that you don’t really need realtime communication channels to contribute - technical stuff may and should be discussed in async mode as in issue/PR comments (or email reply thread in the worst case), where unrelated discussions don’t happen in parallel, message size is not limited, history is preserved, nobody is in rush to reply, you don’t need to actively wait for reply and cannot miss it because you’ve disconnected, someone forgot to tag you or it was just list in the chat.
Summarizing, the project should be on [the most popular VCS hosting at the moment], which is currently GitHub, any other choice makes it much less accessible and welcoming. For chat use whatever you want, for it’s not related to contributions. If you think otherwise, at least stick to open protocols.
It’s the year 2023. I find it baffling that you think it’s OK to marginize and insult people like that just because they choose to spend their mostly free time communicating on a medium that you don’t agree with.
OP asked for opinions, and that was an opinion.
You are right a project author can do as they please, but so can a project contributor. Both spend their mostly free time on that project, so it should be comfortable for both to do so.
There is no need to automatically agree. We can have different styles and disagree, in which case people might prefer to contribute to some other project instead, or work with other contributors instead.
Stating that using these methods of organizing a project is indicative of “the projects author is an autocratic hermit type, locked in a bubble with his ancient tech and not really welcoming outside contributors and bug reports” is not an opinion, it’s nonsense and its insulting.
Right, I get now what you mean. In defense of the other person, they said this may be the case. Which implies that it also may not be the case. It’s a worry spoken out, maybe without thinking too much about how to word it in a way which does not come across as insulting.
I would frown at this in a direct conversation, but not so much in an indirect, general talk about opinions. In the current setting, I appreciated the opinion as open and direct. I don’t think anyone’s feelings have been hurt here, unless someone actively wants to feel offended.
Like cars? Or phones? Those are also archaic, clumsy and insecure technologies.
IRC and email work fine for me. Leagues better than having it locked away behind Discord’s policies and whims.
An issue/patch tracker (and maybe a wiki) would be nice, but I don’t feel they’re necessary. The linux kernel manages without them, after all.
I like IRC and still use it daily to keep up with other hobbyists. Then again, vintage computers are my main hobby horse and of course those circles are gonna lean towards platforms that remain usable on a VIC-20.