zlacker

> Most of my open source work was in the pre-GitHub days when we used mailing lists, not pull requests, to build community. I do think there was something better about that for the project itself as it encouraged a lot more discussion and community building. PR's and Issues become silos and are not great for general discussion. I think they also encourage drive-by contributions which honestly are intoxicating initially but once you see people are not coming back become defeating.

Glad some said it. When things are too organised or categorised it just becomes another business/todo list.

>>vmfunc+(OP)
The problem *is not the organization/categorization*. Any larger project is completely unsustainable if it is a disorganized chaos, with issues falling through the cracks because they can't be kept track of as the scope and team grows. These tools are a great help there.

The problem is this tooling is used for the wrong job.

If the only "discussion" about an issue is the bug report/pull request, that's wrong. That should be only the first/last step. Unfortunately, for many projects there is no other communication channel anymore.

So then people use what exists and is available - PRs and issues on Github. Which are both very poorly adapted to any sort of discussion. But if all you have is a hammer ...

It used to be that the first things a new project got set up was a mailing list, then maybe an IRC channel, perhaps a shared code repository (likely CVS or Subversion) and only then an issue/bug tracker (usually Bugzilla, Track) when the project grew large enough to need it. In that order.

This culture of project community discussion has been largely lost with the younger generation of contributors that don't use e-mail and many don't even have an e-mail account (or don't use it except for signing up for services). Mailing lists have been seen as "old school" and poor UX, so have been largely replaced first by silos in the form of web forums and then later by Discord, Reddit, etc.

All that makes it great and easy for anyone to come in and post something there (the signal to noise ratio is usually not great) - and absolutely terrible to find anything, to actually coordinate work of a distributed team or to track multiple busy projects. E-mail comes to you and can be automated - forums, Reddit, Discord, etc. you have to actively seek out, follow and manage. Poor project maintainer having to deal with that ...

There are good reasons why projects like Linux kernel still use mailing lists for coordination or even sending patches (!), despite the huge size of the project - it simply makes the life of the maintainers (i.e. the people doing most of the actual work!) easier.

>>janoc+c9
Well said, this is what I was getting at as well. I think the barrier to contribution was too high in the old days, and that is where GitHub brought improvements, but it came with the loss of community. Everything becomes about PR's and Issues and Discussion was just lost. In the Apache community, the expectation used to be that everything had to happen on the mailing list. Even if someone created an issue, there was an expectation it had to come out of a mailing list thread.

I am not saying this was perfect or even better. Just that the side effects were different. Probably a lot of people did not bother contributing because the barrier was too high, but overall I think it created healthier community dynamics and it was not uncommon to see people begin as users asking questions, and evolve into users answering questions and eventually contributing to the development.