Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Threaded Messaging #2349

Open
ajvsol opened this issue Sep 24, 2016 · 98 comments

Comments

Projects
None yet
@ajvsol
Copy link

commented Sep 24, 2016

Extending the Quote functionality to allow for threaded messaging.

This could be a simple 'Quote 2.0'-style like WhatsApp where the quoted text is hyperlinked and when clicked makes you scroll up to their message:
WhatsApp Quote-Reply

Or the more sophisticated Threaded Messages panel like Mattermost:
Mattermost Threaded Messaging

Perhaps allowing for both could be done by having the Threaded Messages panel open when you left-click on the 'reply' part of the Quote 2.0 message:
WhatsApp Quote-Reply

Or by having 'Message Thread' popup as an option in the context menu to allow opening the Threaded Messages panel:
WhatsApp Quote-Reply

@ara4n

This comment has been minimized.

Copy link
Member

commented Sep 24, 2016

The plan is to do REALLY good threading in Riot. There's a lot of work on this currently on the Matrix spec, backend, and we're starting work on the frontend next week. #1792 is the design bug for this (although there's nothing there yet). I'll keep this one around too. Thanks for the overview of what other folks are up to here!

@ajvsol

This comment has been minimized.

Copy link
Author

commented Jan 19, 2017

Looks like Slack have implemented this now as well.

Threaded messaging

Cool UI:

Threaded messaging

And an overview page:

Threaded messaging

@clopez

This comment has been minimized.

Copy link

commented Mar 31, 2017

flowdock also implements threaded conversations in a nice and very usable way

https://www.flowdock.com/help/chat

@ghost

This comment has been minimized.

Copy link

commented Aug 11, 2017

Twist from creators of Todoist uses the very interesting concept of threaded channels:

In these channels every message must be in a thread, and it makes conversations much more organised than a continuous stream of messages.

It's the modern version of forum, except you get the benefits of organisation and don't miss out on integrations, mentions, presence, bots etc.

@richvdh

This comment has been minimized.

Copy link
Member

commented Sep 21, 2017

this is not p1.

@richvdh richvdh added p3 p2 and removed p1 p3 labels Sep 21, 2017

@richvdh richvdh referenced this issue Sep 21, 2017

Closed

Threading UX #1792

@lampholder lampholder referenced this issue Sep 21, 2017

Open

Threading! #21

@markwooff

This comment has been minimized.

Copy link

commented Oct 5, 2017

I believe this should be a p1 issue, almost all other chat platforms have some sort of implementation of threaded messages. Would be happy to assist in the development of this!

@colans

This comment has been minimized.

Copy link

commented Oct 5, 2017

I see this as more of a nice-to-have. Slack didn't even have it for a while. I'd say #4406 is more important as there's currently no way to reset the message pointer, which most other systems have had for a while.

@britthurley

This comment has been minimized.

Copy link

commented Oct 10, 2017

I definitely see this as a p1, not a nice to have. Constant noise is a major complaint for utilizing chat platforms in business settings, and threading cuts down on that noise by grouping conversations and allowing a user to essentially ignore it. This was a major improvement in Slack, and most people who have used threaded messaging do not want to go backwards.

@tysonclugg

This comment has been minimized.

Copy link

commented Nov 22, 2017

I'm evaluating Riot.im for use at my work and with a couple of NPOs that I'm involved with, but sadly the answer is a firm NO until 1st class threading (like Flowdock, unlike Slack) is implemented. 1st class threading means each message can be it's own thread, and each reply has all chat features available. Slack screwed this up, you can't add attachments to thread replies etc.

@sunjam

This comment has been minimized.

Copy link

commented Dec 7, 2017

Hi, I just want to say that I am also evaulating Riot for an organization... this feature is critical in making the move to this cool software. I'll certainly be watching for updates. Cheers

@joshfleming

This comment has been minimized.

Copy link

commented Jan 21, 2018

Also, adding my experience, that when trying to convince groups to use Riot instead of Slack, threading was sited as the reason to stay with slack. And I can't disagree, noisy topics can be a real pain. But I'd really like to move to an open source option with end to end encryption like Riot

@andrewperry

This comment has been minimized.

Copy link

commented Jan 29, 2018

#metoo

@vlcek

This comment has been minimized.

Copy link

commented Feb 6, 2018

For our organization is also a very important feature. Without it is almost unusable for us.

@ptman

This comment has been minimized.

Copy link
Contributor

commented Feb 12, 2018

I've heard a lot of good about threading in Zulip, but it might be hard to implement in Matrix due to the focus on rooms instead of topics

@MurzNN

This comment has been minimized.

Copy link
Contributor

commented Feb 12, 2018

Yes, Zulip is interesting solution for threads in chat, but the problem that topic is obligatory field - this is not hard to implement, but this will got problems for people with free chatting (offtopic chats). Maybe good solution will be do this feature at per-room basis, to require all messages with topic only on specific rooms.
But as for me - Slack implementation of threads is more useful for base functional, because we can convert already posted message to thread, missing feature is only group/move several already posted messages to the thread.

@smacz42

This comment has been minimized.

Copy link

commented Mar 1, 2018

I'm surprised that no one has pointed to Microsoft Team's implementation of threaded conversations. It's nothing to write home about, but it's good to have to keep different conversations separate.

Just wanted to point out another competitor that has that implemented.

@dessalines

This comment has been minimized.

Copy link

commented Apr 26, 2018

So far mattermost has this down .

Has there been any movement on this?

@dessalines

This comment has been minimized.

Copy link

commented Mar 1, 2019

Basically the crux of the problem is that it's impossible to show comments by both time ( linear) and thread. If you plopped the entire parent chain of a new comment (lets say with 7 parents) to get the full context on a conversation, at the bottom, then the top parent would likely be older than a top-level comment just before this reply.

The reason I don't like slack's 2-pane version is that it's threaded, not linear, but limited to an arbitrary max depth of 2. Replies to older comments are not shown at the bottom, or as being new. You have to scroll up to see new info. So it gets around the problem by being threaded (but limiting it to an arbitrary limit), and isn't truly linear (since replies to old comments aren't shown as new, even though they might add new important info.)

The only way I could think of to show both of these, is to have two views, one that shows the new comments, and the other that shows the entire context / all the parents for either the newest comment, or one you've selected. Or even better, that context view has the entire chat as a tree, and just scrolls to the correct place in it. Or be able to easily switch between these views, one sorting by new comments, and the other sorting by active threads.

@homebeach

This comment has been minimized.

Copy link

commented Mar 10, 2019

How about having three views side by side? First view is the main chat, second one contains the threaded messages in main chat sorted by the last reply and third view contains the content of the selected thread.

@AndrewJDR

This comment has been minimized.

Copy link
Contributor

commented Mar 12, 2019

I'll weigh in with an unpopular opinion (at least based on my reading of the comments on this issue).

Some non-trivial percentage of people using chat systems think threading sucks and will want to be able to turn it off. Turn it off how, you ask? Let me count the ways... :)

  1. Per room, as a room admin.
  2. Homeserver-wide, inside of homeserver.yaml
  3. A a client user, on a per-room basis (user room prefs).
  4. A a client user, on a "my entire account" basis (user account prefs).

For evidence that I'm not the only one that dislikes threading and wants to turn it off, please see:
https://twitter.com/emilstahl/status/1054648816647979009
https://twitter.com/googleninja/status/1019978792180375553
https://twitter.com/_david_lang/status/958690745648545793
https://twitter.com/JirikNovy/status/935870198388752384
https://twitter.com/Liskni_si/status/1085229651688148994
etc.
Or search for: slack disable threading
On google and read around.

If anyone wants my personal exposition on why I think threading sucks, please ask. But given the amount of documented dislike toward threading readily available on the net, I'd rather not spend my time writing about it unless it seems necessary/useful. Please read that in a friendly tone, not meaning to be harsh or abrasive, just trying to save some time writing stuff :)

@AndrewJDR

This comment has been minimized.

Copy link
Contributor

commented Mar 12, 2019

Just to define what is meant by "Turn off threads":

Turning off threading should flatten the events such that all messages -- regardless of whether they are part of a thread or not -- are always displayed in chronological order, perhaps with each message having a small icon to look at the entire thread in context in some side-view or whatever.

This ability to turn off threading should not be solely an opt-in by the poster of a threaded message (as it is with slack), it should be possible to do this as a user such that it applies to all threads/messages.

Another way of thinking of this disabling feature would be it behaves something like slack threading with the "Always send to #x" checkbox checked (and uncheckable!) for every single threaded message ever posted.

This article also points out this particular usability issue:
https://medium.com/@brad.robertson/slack-threading-failure-threadfail-977859586d5a
(ctrl+f for "the wrong default")

The final thing I find REALLY awkward about threading (mentioned above) is that new messages in threads don’t cause any obvious activity in the channel they originated from by default. My assumption would be that a public thread within a channel would automatically also keep that channel up to date.
There is a checkbox to do this if you want to, but it’s off by default. Every single user has to purposefully update the main channel to keep that conversation relevant, which generally means most people won’t actually do that.

I agree with what he's saying here, but again I would take this even further -- server admins/users should be able to force this "new posts to a thread update the channel too" behavior even if the user that posted to that thread explicitly opted out of it, because users should have control over how they keep up-to-date with unread activity, and server/room admins should have control over whether they are okay with the reduced participation incentivization that can arise from chat threading.

@fallerOfFalls

This comment has been minimized.

Copy link

commented Mar 12, 2019

I don't want what you want, but I find this a meaningful contribution. The only thing I would caution against is allowing chat to be viewed differently by different users. If there are messages visible to some but not to others then you get some people replying and others confused because they don't see what's being replied to. Per room settings (admin) would be okay though.

There's another solution to not seeing all new messages (the problem in slack): an option to automatically follow all threads in a channel.

@AndrewJDR

This comment has been minimized.

Copy link
Contributor

commented Mar 12, 2019

I don't want what you want, but I find this a meaningful contribution. The only thing I would caution against is allowing chat to be viewed differently by different users. If there are messages visible to some but not to others then you get some people replying and others confused because they don't see what's being replied to. Per room settings (admin) would be okay though.

@fallerOfFalls I think the only way to add threading and still have a totally consistent view of all messages for all users (without pissing of people that don't like threading) is to basically default to the equivalent of slack thread's "Always send to #x" enabled, and don't even allow it to be disabled (And thus don't even show it as an option in the first place). The implication here is that any message sent to a thread will also send that message to the main channel at the same time; Therefore thread reply messages would always "live" in two places within the chat log: The thread that it is posted to, and in chronological order within the main, channel. All thread reply messages shown in the main channel can have a little link next to them to open them in a side panel within the full context of the thread.

Personally, I would be totally fine with this, since it minimizes any disruption to those that dislike threads -- they can just ignore the thread icons, don't subscribe to threads, and never open the thread panel, and go about their business consuming unread items linearly as if nothing had changed.

I believe this should also satisfy those server/room operators and users that do like and want threads, since they can start and follow only threads that interest them, which even I can admit can be useful when a channel's volume is very high. That said, a true thread enthusiast should chime in on this.

@dkasak

This comment has been minimized.

Copy link

commented Mar 12, 2019

The implication here is that any message sent to a thread will also send that message to the main channel at the same time; Threaded messages would always "live" in two places within the chat log: The thread that it is posted to, and in chronological order within the main, channel.

Actually, one of the main uses of threads I have in mind would be to spin off a thread in a room so that unrelated conversations in the room can continue as before, without interference from the thread. The thread is still logically related to the room and contains all the same participants, which is why we don't simply create a new room, an action that is often cumbersome. This is why the default should not be that thread messages are visible in the room as well.

I think this would be handled if the room before the creation of the thread is logically a kind of thread itself: the "main thread". A separate view combining events from all threads chronologically would be okay. Messages typed while in this combined view should go to the main thread, so users still need to be aware that not everyone might know what they're talking about (for instance, if they're just focusing on the main thread).

@AndrewJDR

This comment has been minimized.

Copy link
Contributor

commented Mar 12, 2019

Actually, one of the main uses of threads I have in mind would be to spin off a thread in a room so that unrelated conversations in the room can continue as before, without interference from the thread. The thread is still logically related to the room and contains all the same participants, which is why we don't simply create a new room, an action that is often cumbersome. This is why the default should not be that thread messages are visible in the room as well.

@dkasak My 2c: I don't have a problem with this, but I really think that if what you're describing above is something that matrix ends up having, users should be empowered, via a preference, to say:
"No, I don't want thread replies to hide in little pockets where I can't easily see them in a linear context in the main part of the room, and no I don't want to have to open up a 'followed threads' pane to find these messages.
Aka there should be a user-side "'Always show all threaded replies in main chat" option.

@fallerOfFalls Are you saying that you don't think this should be a user option? If so, I'm curious why? I didn't really understand your earlier explanation of "not allowing chat to be viewed differently by different users", since an individual user enabling "'Always show all threaded replies in main chat" (let's assume the default would be off) would only allow said user to see more references to messages, not more actual messages.
It just comes down to an individual's personal preference of how they consume (mostly unread, but to some extent all) content within a chat room. I see no good reason to disallow this as an option, especially if it's buried in a user option somewhere where novice users are not likely to mess with. Furthermore, if you really don't want it within your organization for some reason, deploy a custom riot build or whatever without the option, or change your HS to ignore the event that changes that option.

@dkasak

This comment has been minimized.

Copy link

commented Mar 12, 2019

Are you saying that you don't think this should be a user option?

I'm not.

I didn't really understand your earlier explanation of "not allowing chat to be viewed differently by different users" [...]

That wasn't me. I agree this should be an option for users. I imagined it not being a preference in the settings because that's harder to find, but instead something like a tab in the main conversation view called "Unified timeline" or "All threads" or something along those lines.

I was merely noting that there will be some UX tension between users wanting to use threads as completely separate conversation lines (so the main thread is less noisy) and those that exclusively want a unified view, with threads being nothing more than some additional information attached to an event ("belongs to threads T").

As an example, I'm in a casual room with a group of friends (about 15 of us). Sometimes it happens that one of us mentions something which only a few of us are interested in and we'd like to discuss this in more detail. However, we don't expect to continue talking about this for an indefinite time, so creating and joining a new room is not a particularly ergonomic option. We'd also like our discussion to be available to the other room members as well—even though they're not as likely to participate, perhaps they'll see or think of something interesting and decide to chip in. Meanwhile, casual banter continues in the main thread of the room without interference from our new thread.

In my mind, this is the perfect job for threads, but for this to work, there needs to be a way to tune in into "all messages belonging to the room, but not belonging to any of the explicitly created threads", which is what I was referring to as the "main thread" above.

The tension arises when we ask ourselves where messages sent to the unified (threadless) view end up. To me, the obvious answer is "the main thread". But since those using the unified view are able to see messages from other threads interposed with the messages from the main thread, they might end up referring to something from them. Users not using the unified view might therefore not know what that person is talking about.

I don't think this is such a big problem, though. It does mean that unified view users do have to keep in mind that threads exist, of course.

@AndrewJDR

This comment has been minimized.

Copy link
Contributor

commented Mar 12, 2019

@dkasak Yep, apologies... I got mixed up, It was @fallerOfFalls that may have suggested there not be an option (but I'm not actually sure so waiting on clarification).

Regarding your other points, I believe I understand your usecase, and might even use it myself in some contexts (e.g. high volume rooms like matrix hq where I ask something and just want to follow replies, so long as there's a preference like Always show all threaded replies in main chat that I can turn on globally on my own user account but disable on a per-room basis for my own user account.

@fallerOfFalls

This comment has been minimized.

Copy link

commented Mar 12, 2019

@AndrewJDR

Are you saying that you don't think this should be a user option?

Yes - because I think it would lead to chaos. However, if anyone thinks it could work, there could be an option in per-room admin settings to "allow users to view all message threads in channel", and then we see what actually happens.

would only allow said user to see more references to messages, not more actual messages.

I like this idea. I worry that some users might reply in the main channel, unless it's made REALLY CLEAR that not everyone can see those references. But it could work well.
Also if such a thing were implemented I'd want it to be alongside the "follow all threads" option, not instead of. Then people can decide how they want to be kept up-to-date. They could have one or the other or both, or neither.

especially if it's buried in a user option somewhere where novice users are not likely to mess with.

That sounds good actually. If it's buried in "advanced" and the UI makes it clear that it's not visible to everyone, I see no problem.

@dkasak

This comment has been minimized.

Copy link

commented Mar 12, 2019

Also if such a thing were implemented I'd want it to be alongside the "follow all threads" option, not instead of.

This is a really important point, I think, and it's also what I was trying to express but didn't form the thought as clearly. You need to retain the ability to view just the main thread, even if you usually follow a room in a unified view.

@AndrewJDR

This comment has been minimized.

Copy link
Contributor

commented Mar 13, 2019

Yes - because I think it would lead to chaos.

The amount of "chaos" it introduces will be only to the extent that users choose to:
a) Disable threading in their own client AND
b) Reply to the main channel rather than replying explicitly to a thread message

Keeping in mind that users that do a are probably going to be savvier users (since the hunted down an option in the user configuration), if you make it clear in the communities that you manage that you really prefer that people reply to threads to keep things organized in the way that your community prefers to organize things, that should be sufficient to keep chaos introduced to a minimum.

That said, I do think some additional chaos is a worthy tradeoff for avoiding the alienation of users that really just hate threading. In summary, I would urge anyone to reconsider any "Users shouldn't be able to turn off threaded display in their clients because it will lead to chaos"-like views that they may hold, because by allowing users view things the way they prefer, that (probably small) amount of chaos that might be introduced also allows us to avoid souring this subset of users to our communities / chat systems -- as happened with slack threads.

However, if anyone thinks it could work, there could be an option in per-room admin settings to "allow users to view all message threads in channel", and then we see what actually happens.

Just to be clear, If you're saying that option would be on by default, I think that's probably fine. But if you're saying that it would be off by default, I think that would be Very Bad, because in practice most admins will not do this, and we will just end up with a (for me and others, irritating) forced threaded system like slack. I still believe that users (not admins) should largely have control over the ability to view things in a linear non-threaded way vs. threaded way, by changing a user-level option within their client and a set of personal per-room options.

@dessalines

This comment has been minimized.

Copy link

commented Mar 13, 2019

@AndrewJDR How do you feel about the way riot is currently doing threading (the flip up way)? Seems like at least 30% of comments on big chats like #linux:matrix.org are threaded replies.

@AndrewJDR

This comment has been minimized.

Copy link
Contributor

commented Mar 13, 2019

@AndrewJDR How do you feel about the way riot is currently doing threading (the flip up way)? Seems like at least 30% of comments on big chats like #linux:matrix.org are threaded replies.

@dessalines As far as I can see, Riot's current "threading" is basically quotations that are expandable/contractable. I don't really have any big problem with it so far, since it still reads fine linearly. I'm not forced to open a threading pane or follow threads and new unread posts are not hidden in "thread pockets", etc.

That said, it might be good to explore options for keeping the reply quotations from taking up so much vertical real estate in cases when the reply is to something that was very recently posted. For example, the quotation here feels redundant/wasteful, and even hinders the quickness of readability just a bit:
Screenshot at 2019-03-12 19:02:14

I'm not sure how exactly to address that, but here is a rough idea offhand:
If a reply made to a message that is within x messages ago (let's say 4 for example -- the idea is that you will have very likely already read the OP if it had occurred within this number of messages, since that OP will also be onscreen), default to keeping the quotation for that reply in a contracted/minimal form. In the screenshot above, instead of

Levy
| Daniel
| and even the strings are quite usable
response here

It could instead read:

Levy
Daniel (...): response here

and the (...) is a button to expand the quotation to the full display.

@AxelPuerck

This comment has been minimized.

Copy link

commented Mar 13, 2019

As a newbie on this topic, I've looked at quite a few different messengers and find the zulip way the best one: Every stream (=room) contains topics, but only 5 topics are displayed in the overview (the topics with recent messages).
image
If you don't care about topics, you can also display the complete stream by clicking on it and the messages are sorted by time.
image

Everey stream contains a hello topic and if you view the complete stream by clicking on reply (to compose a new message) this topic is used, so you have a default topic.

I think this is a very clean and concise way.

@AxelPuerck

This comment has been minimized.

Copy link

commented Mar 13, 2019

In my opinion this resembles the real world: some people get together in a room. To talk about a specific topic a little group is formed (and in my experience there are no subgroups) and you can listen to all conversations (at least you can try) or you can focus on a group.

@aitorllj93

This comment has been minimized.

Copy link

commented Mar 28, 2019

What about Google Chat Room Threads UI?

Google Chat

@timeandtimeago

This comment has been minimized.

Copy link

commented Mar 28, 2019

For what my two cents are worth - my organization release heavily on slack-like threading where you can be very organized and structured about your conversations in a particular channel/topic.

For us the ability to sort through information and conversation on a specific thread without interruption from other concurrent conversations is really important for the information capture process.

We have been waiting for Riot to implement a more organized form the threading. We have been watching closely because we want to switch to Riot - but until the ability to have structured conversations exists - we can not.

It seems that the public is split over this. Half must have the limited nesting threading (slack like) and half seem to be very opposed to limiting the number of levels deep nesting can go.
It's the difference between a simple on-going constantly morphing conversation stream and the ability to organize those conversations into actual separate conversations.

as much extra work as it is - I believe that this is a case where both options should be offered as configurable features. If one direction is chosen over the other - either one inevitably alienates a whole base of users.

@kiliankoe

This comment has been minimized.

Copy link

commented Mar 28, 2019

On what level would that configuration happen though? On a community/room/user basis? And how would Riot represent those threads in both styles? Unfortunately I feel that would make things far more complicated still.

@jans23

This comment has been minimized.

Copy link

commented Mar 28, 2019

I don't see how configuration should be possible on a user level because in my understanding a "fully threated" mode would include subjects which to hide for some users doesn't sound wise.

@aitorllj93

This comment has been minimized.

Copy link

commented Mar 28, 2019

Maybe adding something like tagging messages and "default" tags and filterings/groupings could solve one part of the problem

@timeandtimeago

This comment has been minimized.

Copy link

commented Mar 28, 2019

I think on a room basis would make the most sense. Especially being rooms can be shared between servers. Basically the room admin would configure it.

And it could quite easily be done with metadata tagging without ever altering the chronology of messages.

My point here is that this is a highly polarized debate and going with either side over the other will leave a large user base displeased. This may be an area worth investing in flexibility.

It’s not that one method is better than the other - rather they each facilitate very different kind of conversation. Different groups have different needs when it comes to how conversation is organized.

@aitorllj93

This comment has been minimized.

Copy link

commented Mar 29, 2019

Another related thing I miss from Slack are "pinned" messages, that help too to highlight content at rooms

@ptman

This comment has been minimized.

Copy link
Contributor

commented Mar 29, 2019

@aitorllj93 pinned messages are in riot web labs

@donShakespeare

This comment has been minimized.

Copy link

commented Mar 30, 2019

@MurzNN

Yes, Zulip is interesting solution for threads in chat ...

Yes, Zulip seems to be ahead of everything else in this department. You can really really get real work done when the topics are just there, like a clickable TOC of a huge book.
With beautiful Slack, I am forced to stay fresh, to the ever auto-scrolling, attention-span-destroying chitchat of say, 600 people. I call it a wild market. Yes, if I pay $$$ I will be able to scroll up 900,000 pixels - 🦀 but I, unlike a crab, am slow in the reverse.

... but the problem that topic is obligatory field ....

actually it is optional - Organisation/Realm wide
image

At first, my drivel-filled slacking brain was so auto-conditioned scared of creating my first topic. I was so terribly afraid to constrain my banter with a heading. But I did it! And now, I have added to the easily found INDEX/TOC. I almost felt the golden buzzer 🎊 🎊 🎆

I must admit, I missed the flow, the mall-like nature of how all #general channels should resemble, where you are filled with glee, star gazing messages as they are lost into scroll oblivion. Oh! the fresh smell of forgettable new!

... but this will be problems for people with free chatting (offtopic chats). Maybe good solution will be do this feature at per-room basis, to require all messages with topic only on specific rooms.

Absolutely. My cravings for blabbing are still strong. I suggest have an optional admin-managed official Topic/Thread: Banter, per channel. And it can be pinned within said channel.

When Matrix/Riot gets this feature in solid place, as I am sure they will - for devs full of awesomeness (not awefull), can produce nothing short of what is their nature - then, I say, rest assured folks, game over (even if there was no competition)!

all bridges will lead to the Riot Zone
-Marcus Matrixuslus

@heyakyra

This comment has been minimized.

Copy link

commented Apr 23, 2019

Sad this didn't even make it on to the "later still" planning board! ):

https://medium.com/@RiotChat/whats-next-for-riot-web-be48f948c801

@sunshineo

This comment has been minimized.

Copy link

commented Apr 26, 2019

@fallerOfFalls I made a Github bot and a website similar to the https://freedomsponsors.org/ you are using. The Github bot can automatically add a comment to every new issue with a link to a website that encourages people to add reward. (It adds a link to existing open issues when you install). It automatically comments on the issue and tag people when anyone gives a reward, claim the rewards, and approve a reward. Automatically label issues with rewards so you know what is really important for your users.

I wonder if the owner of this repo would like to try it. It's in beta now, I'm looking for people to give it a try.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.