This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (7)
- # announcements (3)
- # avi (1)
- # beginners (222)
- # boot (184)
- # braid-chat (75)
- # business (7)
- # cljs-dev (3)
- # cljsrn (9)
- # clojars (17)
- # clojure (131)
- # clojure-dev (1)
- # clojure-portugal (4)
- # clojure-russia (39)
- # clojure-sg (1)
- # clojurescript (140)
- # community-development (563)
- # datomic (5)
- # editors (1)
- # emacs (3)
- # events (3)
- # leiningen (4)
- # off-topic (31)
- # om (84)
- # omnext (1)
- # slack-help (3)
- # yada (5)
BTW, my aim this week is to push Braid’s implementation sufficiently forward to convince all those interested that (1) Braid’s design concept is better long-term for the clojurians community than Slack/IRC-style, and (2) that we can get to a polished experience faster with Braid than starting from scratch, and (3) that it’s better to rally behind a single application. …not sure my efforts will be a success, but it’s my goal.
I happen to share the same bias but for the Matrix project so hopefully we cancel each other out 😛
it isn't the highest priority for me right now (which is polishing the UX so that the potential of the concept is better understood), but I am pro-federation
if the community picks you, great. if not, you will still have a killer product that can be used elsewhere
I will cheerlead for each project while I'm wearing that projects hat and I will abstain from any voting or selection process
the jumping-around / inability to focus of the discussions on #C0CB40N8K is exactly what I hope Braid can solve, and I think it's a result of the rooms model
...eventually, progress will be made only because of some individual(s) who take it upon themselves to do work and not bikeshed
Well, the remark about rooms being a so-so abstraction due to topic meandering makes sense but a) is there any instance that can be tried out to see how it works in practice, b) how would that mesh with IRC/Matrix integration though? Both seem to use room abstraction. Would rooms then be tag feeds?
@gjnoonan: no waffle yet, will post here once i have something out; currently am using asana (and have my entire life there)... will work something out
@rafd: yeah, I'm interested to see how this scheme works in practice; would be nice to get an invite, even if just to lurk and observe.
@gjnoonan: do you think it reasonable for an OSS project to use Asana? i'm considering using http://unito.io/ and having some core contributors directly on asana, and everyone else via github
@rafd: I thnk it's reasonable for an OSS project to use whatever works for them as a consensus to get things done, whether that's GitHub Issues, Asana, Jira, or even org-mode. I have a some personal bias, but that's by-the-by. It's whats best for the team creating it
@jaen: you'll see new ones, but old ones you'd need to search for (not great ux, i know, but it WorkedForUsSoFarTM)
It kinda makes sense to not get overwhelmed at first, but also a way to let user know he can see this or that would be helpful probably.
in a community group, (1) likely lots of active conversations, so things wouldn't stay empty, and (2) i can do better at showing "Recent conversations"
i've been maintaining a list of projects 'similar' to Braid, or at least, ones I think have something interesting to offer to 'better online discussions', moved it to github: https://github.com/braidchat/braid/wiki/Similar-Projects
re: matrix compatibility, I have an idea (may be terrible): just have each group (ex. clojurians) be a room, and tags be meta-data on each message; slight bastardization of the matrix room concept, but it could work (it would then be up to each user's Braid server to filter out the messages they don't care about before sending to the client)
Hmm, I must say rooms as tag feeds (as in you get messages that match the room name) feel more intuitive to me than that.
@jaen so a message with multiple tags would be replicated across multiple rooms? (not against it)
And room-based clients would still be able to make some degree of sense of what is happening
sounds good to me; from my experience most messages end up with a single tag anyway, but with larger teams / groups that may change, either way, client deduping should be easy