You are wrong. The first thread I’ve linked was started in Dezember 2016, so I’m having a hard time understanding how you can consider that “old”. Also, no, they are talking exactly about what you want to do: hide comments and hide reshares from ignored people.
This has nothing to do with being “pushy”. We have discourse so that we can talk about features. We try to keep it at one thread per specific feature so that if somebody wants to implement something, all information, all possible implementation details, all opinions, are in one place. It is not only annoying to have the same discussions over and over again, it is also harmful, since one discussion then lacks (maybe good) arguments made in another. There is no point to that.
Right. And discussing everything again, raising the same points over and over again, is a waste of time. Not only for us, but also for you, since you could have participated in either one of the existing discussions, or maybe read through the thread, pick existing issues and try figuring out a solution for them.
In your example, there is a valid concern about simply hiding comments, since it may completely destroy the context and the value of the discussion at whole for other people. I do not want to miss such concerns just because someone feels like opening a new discussion.
Some discussions (I’m thinking about the XMPP chat or the account export/import thing, for example), run for many years before all theoretical issues are sorted out, and then someone can start implementing the technical parts and use the Discourse thread as a reference. Without that single “thread of truth”, I am sure we’d miss a lot of edge cases that have been discussed (which happened way too often in the past).
Our statistics clearly show that quite a substantial amount of people actually do read those threads, and then start contributing to that existing thread with new ideas, new issues, and new spins.
I’ve said this many times before, but let me repeat myself: In diaspora*, implementing “simple” and “easy” features often turn out to be way more complex than one might think, and without thinking and talking about the complex parts first, trying to implement such feature ends in a disaster where no mergable code is being written, but many, many hours wasted. We do our best to keep the information density in such comment threads high and reduce the amount of noise (for example by deleting off-topic comments, encouraging people to stick to the case, …), so it’s as easy for someone to jump in as we can somehow provide the information.
If someone can’t be bothered to work through existing research and discussions, then, well, too bad. We can’t be a project where everyone can contribute without preparing themselves, so if a contributor is not willing to read prior work to a feature they want to implement (or improve), then, well, do not contribute.
You are right if you say that we might lose some contributions here. However, we’d also lose contributions (and, at the end of the day, feature quality) if we allow threads to split up.
