-
-
Notifications
You must be signed in to change notification settings - Fork 25
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
CFEP 23: Zulip migration #54
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a few details that need specifying or ironing out.
changes were made that address my comments
@conda-forge/core This PR falls under the CFEP Vote policy, please vote and/or comment on this PR. This PR needs 60% of core to vote yea to pass. To vote please leave a PR review according to
If you would like changes to the current language please leave a comment or push to this branch. This vote will end on 2024-10-31. |
I can't approve my own PR, so here's my vote: ✅ Yes. |
@conda-forge/core please vote! |
@conda-forge/core please vote! |
this vote ends tomorrow Oct 31 BTW |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Jaime and everyone who helped evaluate this proposal! 🙏
Approving
Did note a few suggestions below that would be good to include somehow
- Sensitive topics will NOT be discussed directly in the Zulip instance. Instead they will follow the protocol described below. | ||
- Some Element rooms related to conda-forge (e.g., rooms where we interact with other communities like bioconda) will remain unchanged as needed. We will however strive to move as much of the conda-forge Element space to Zulip as possible. | ||
|
||
Three months after the approval of this CFEP, the core team will consider the migration finished and the public rooms will become private and archived. If the core team estimates that there's still sufficient activity, another three months will be granted, with periodic reminders of the new Zulip instance. After that period, no more extensions will take place. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think we would want the history of the public room to remain readable. Would making it private hinder that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
## Sensitive communications protocol | ||
|
||
Since Zulip doesn't have end-to-end encryption, it is not the best place to discuss sensitive matters. Instead, we propose the following protocol. | ||
|
||
1. Core members will announce that a new sensitive topic needs to be discussed in the Zulip channel for `core`. A small description describing the situation without revealing sensitive details should be shared. | ||
2. A new private room will be created in Matrix and announced in the private topic. Interested core members can voluntarily join the room to participate or observe the conversation. | ||
3. When the issue has been addressed, a summary of the events and decisions taken will be captured in the secret vault. The notes document should contain the date, topic title, participants and any other necessary information. | ||
4. Once the summary has been safely stored, a short announcement should be posted to the Zulip topic informing about the publication of the relevant notes in the vault. | ||
5. After a short period has passed with no comments, the Element room will be deleted and the Zulip topic will be marked as solved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think it is worth noting that the proposed solution for handling sensitive topics relies on Matrix, which we have noted above has trouble validating keys periodically (to be clear Matrix is being overly secure here as opposed to not secure). Ideally we come up with a better solution than relying on Matrix for this
Admittedly there is not a clear alternative atm, but we should investigate moving sensitive communication off Matrix as well. This can be a follow on proposal once we have determined a clear path
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm hoping that the ephemeral aspect of the room reduces the usability problems. If that proves to be problematic, another CFEP amending this can be introduced to formalize our new preference, I'd say.
Co-authored-by: jakirkham <jakirkham@gmail.com>
This vote has passed. We have 20 yes, 0 no and 0 abstain. It exceeds the 60% quorum requirement of 60% (17 out of 28). Yay! |
As discussed internally, let's make a decision about this. I'll open an initial period of discussion of two weeks, but if there's good consensus before then, I won't wait before calling the vote.
If you are a @conda-forge/core member and you are reading this for the first time, don't hesitate to ask for more information. Invite links are available in the Element core room upon request.