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

Shut down Slack #144

Closed
wiz opened this issue Nov 21, 2019 · 14 comments
Closed

Shut down Slack #144

wiz opened this issue Nov 21, 2019 · 14 comments

Comments

@wiz
Copy link
Member

wiz commented Nov 21, 2019

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

It seems like almost everybody has migrated from Slack to Keybase - in the interests of security for Bisq's public channels and privacy for DMs between Bisq users chatting, I propose that we phase out Slack entirely as follows:

  1. November 30, 2019 - remove links to Bisq's Slack workspace from all public Bisq websites, docs, etc.
  2. December 31, 2019 - disable new user registration on Bisq's Slack workspace with a message pointing them to Keybase
  3. January 30, 2020 - lock down the workspace so nobody else chat there, with a message pointing to Keybase

This way if anything happens to Keybase, or we want to migrate back, we can always re-enable the Slack workspace, but we will force users to use E2E encrypted/signed/verified chat on Keybase within ~2 months.

Is there any reason why people still want to use Slack for some things and we shouldn't shut it down?

@thehapax
Copy link

I concur. The only thing worth keeping around the Slack would be its archival history, if needed, imho

@m52go
Copy link
Contributor

m52go commented Nov 22, 2019

Looks like Keybase has picked up sufficient momentum, so I think it's finally time to do this. The phased approach is good. I'll start readying PRs to achieve 1, so they can be merged when this proposal is approved, pending any objections.

@FKrauss
Copy link

FKrauss commented Nov 24, 2019

I concur. The only thing worth keeping around the Slack would be its archival history, if needed, imho

But that is also ethereal. Every new message posted deletes an old message, because we use the free version of it. So in reality we have a rolling archive with no control over the speed of it (private messages also count against that). We should just move out and give the proper notices wherever needed.

@FKrauss
Copy link

FKrauss commented Nov 26, 2019

I guess the only downside of keybase is that we can't do this:
parrot

But I think we can live without custom emojis

@m52go
Copy link
Contributor

m52go commented Nov 28, 2019

PRs are ready for review.

bisq-network/bisq-website#302
bisq-network/bisq-docs#182

@FKrauss are you aware of the /giphy command on Keybase? All we need to do is add some Bisq GIFs to giphy.com and that's a solved problem ;)

@beingindot
Copy link

Is it possible to know online/offline status of a user in keybase? that's one imp thing im missing.

@FKrauss
Copy link

FKrauss commented Dec 4, 2019 via email

@beingindot
Copy link

beingindot commented Dec 4, 2019

tried searching that green dot. not able to find.
keybase/keybase-issues#3080

@FKrauss
Copy link

FKrauss commented Dec 4, 2019 via email

@beingindot
Copy link

yeah. thanks. It was not explicit for me. though as you mentioned inactive not marked.

@FKrauss
Copy link

FKrauss commented Dec 4, 2019 via email

@mpolavieja
Copy link

Close as it got approved

@wiz
Copy link
Member Author

wiz commented Dec 16, 2019

@mpolavieja why you close this issue? approved does not mean close the issue, that's what the tag is for. we still have to finish the tasks inside the proposal before it can be completed 😅

@mpolavieja
Copy link

In theory the proposal should be closed once the discussion about executing or not the proposal is over and a decission about the proposal has been taken (accepted, rejected, ignored, invalid, etc) or the proposal stalls.

These are the rules about closing proposals (although I am being much more flexible than what is described here):

Step 3. Evaluate
After the two-week review period is over, a maintainer will evaluate reactions to and discussions about the proposal and will close the issue with a comment explaining that it is approved or rejected based on whether a rough consensus was achieved.

Approved proposals will be labeled with was:approved. Rejected proposals will be labeled with was:rejected.

If rough consensus has not been achieved, e.g. because discussion is still ongoing, dissenting concerns have not been addressed, or the proposal has turned out to be contentious, the maintainer will indicate that they cannot close the proposal, and that it is up to the submitter to take next steps to move the proposal forward. If the proposal does not move forward after another two weeks, the maintainer will close and label it was:stalled.

If there have been no or very few reactions to a proposal after the two-week period, the maintainer will close it and label it as was:ignored.

However, if you still think I should reopen the issue, I´ll do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants