Adding Threads is great, they’re a useful organizational tool. But I don’t think they should be the only (or in fact the default) way of replying in Chat.
This may be very personality/preference-dependent. I personally find threads to be a very “heavy” solution and use them very seldom. But when they’re called for they’re super useful. Far, far more often I simply want to reply in-line to a previous message, and @-ing someone is not the same thing by any means. The purpose is less to notify a specific person than it is to establish a clear context for my message. AFAIK this used to be possible before Threads and I think it should be reintroduced as an option, i.e. “Reply in-line or Create New Thread”. When the only option is to create a new Thread then of course you’ll get lots of thread-use, and conversely if there is no option to reply in-line or quote-reply, well, how do you then gauge the potential use of that vs Threads?
I see plenty of situations where 1-2 in-line replies will address a topic of discussion without having to create a whole Thread which seems overkill for that. Discord handles this well by prompting users to create Threads when replies to each other starte to exceed a certain threshold. And (I think) unlike Discord, Discourse has the theoretical capability to actually (optionally) move all prior replies into a thread retroactively and automatically (i.e. not having to manually select them all).
Pretty much exactly what this person said
FWIW Discord supports all this very well and is IMO basically a model to emulate here. No need to reinvent this particular wheel, and the fact that Discord has deemed it worthwhile to have both Reply-in-Line and Reply-as-Thread feels supportive of the value of both. The use of these two approaches is more a personal and even cultural thing than a right/wrong/best way. There are Discord communities I’m in where hardly any Threads are used, and others where almost every reply is a Thread.
האירוניה שאני מוצא היא שנושאי דיסקورس נאבקים כל כך להיות לינאריים, לא מחוברים בשרשור, ולמרות זאת אני באמת רוצה את הסגנון הזה אפילו יותר בצ’אט, עם אפשרות של תגובה כציטוט כדי לספק הקשר מאוד מועיל. בתחילת צ’אט דיסקورس, אפילו יצרתי רכיב נושא כך שתגובות צ’אט ייראו ויתפקדו יותר כמו וואטסאפ/סיגנל.
אני בדרך כלל לא מצביע על Feature requests, אבל זו קיבלה את הצבעתי. תודה שהעלית את זה!
אני באמת מרגיש שיצירת שרשור שלם לתגובה לפעמים גורמת לזה להרגיש כאילו אתה מתנתק מהשיחה בשרשור הראשי. לפעמים, תגובה אחת להודעה פשוט לא מצדיקה פתיחת שרשור שלם, אבל אולי שיחה שלמה שמתפצלת כן מצדיקה זאת.
אני ממש אשמח שתגובות יהיו מוטמעות כברירת מחדל, או לפחות שתהיה דרך לבחור להגיב בצ’אט או בשרשור חדש.
Just to clarify, currently, a given channel may be configured with or without threads enabled.
When threads are not enabled, replying to a message creates a new message in the channel with a reply indicator.
When threads are enabled, all replies are threads.
I understand there still may be a case where supporting both within the same channel could be helpful, but the decision to make this a channel setting was made based on similar observations to this one:
(Sub)Communities that prefer threads can turn the setting on. Those that do not can leave it off.
תודה, זה הקשר מועיל! מנקודת מבטי, אני חושב שהגישה של דיסקורד כאן היא ללא ספק טובה יותר בכך שהיא עשויה למנוע את הצורך בהגדרה כלל. היא תומכת בגמישות בשתי הגישות. אני מניח שאם אתם רוצים להעצים מנהלים כדי לאלץ את כל התגובות להיות שרשורים, אז זה עדיין הכרחי (ואני סקרן אם יש לכם נתוני משתמשים המצביעים על כך שזה במיוחד היה רצוי), אבל אם הייתם מאפשרים גם שרשורים וגם תגובות בשורה, אז שני מקרי השימוש מוגשים לפחות במידה סבירה. אני לא יכול לחשוב על קהילת דיסקורד שאני חבר בה, שבה אנשים שלא משתמשים בשרשורים ומגיבים רק בשורה היווה בעיה. וה
Really just the same data you cited – the observation that channels tend to gravitate towards one preference or the other.
In my experience, it is sometimes a source of ongoing tension when the collective preference has to be continually reasserted by existing members “please use threads!” or “please don’t use threads!” (often without the “please” part).
That observation led to the idea that it may be better to encode that preference more explicitly.
That said, the idea of supporting both was considered at the time and put on the back shelf as something that may be revisited later.
I have occasionally wanted it myself, but until now, I haven’t heard any request for it.
