vmx
commented
6 years ago Will those mailing list public and open for everyone (also the archives)?
Closed daviddias closed 4 years ago
vmx
commented
6 years ago Will those mailing list public and open for everyone (also the archives)?
daviddias
commented
6 years ago @vmx up to the Working Group to decide. I recommend to default open
vmx
commented
6 years ago @diasdavid I fear things getting closed for convenience. I really hope we keep a "open by default" culture.
momack2
commented
5 years ago Currently, the IPFS project is made up of 10 working groups that focus on different areas of development, growth, and support of the project. In order to be able to communicate effectively within and between working groups, we need targeted communication channels that effectively reach working group participants without overwhelming all project comms.
Sometimes there is a time-sensitive group coordination task that all active working group contributors need to be notified of and have a way to collaborate on without dominating a more general forum or relying on IRC/Github notifications.
Some team-focused communications are uncomfortable or sensitive to make public on the internet, but all active team members should have visibility and be able to participate (like retrospectives, team meetup logistics/coordination, etc).
Some project focused documents (like how to edit our calls and events, notes from retrospectives to share across working groups, or private reports on partner needs) need to be easily shared with active project contributors so that everyone with "proof of work" in the project (current and future) has access - but for op-sec reasons can't be made publicly accessible/searchable by anyone. Ideally, documents with limited ACLs should only be discussed in channels where everyone can access the document.
Document permissioning should update as new individuals demonstrate "proof of work" and join the core project working groups, to ensure knowledge remains accessible.
We are very intentionally "open by default" and want to ensure that we maintain fully open, accessible channels as our main forum of communication. These open communication channels need to be searchable, flexible to configure, self-documenting, non-duplicative, and supportive of thoughtful participation. Using non-open channels should be an exception and discussion should be quickly routed back to open channels if the more focused forum isn't necessary.
Google Docs/Sheets/Slides can either be made "public to the world", "shared with a specific set of email addresses" (one of which could be a group mailing list), or "private to all accounts in an organization". It is error-prone and brittle to manually add many individual addresses to a single document
IPFS is an open source project that we intend to be around for many years. Therefore, leadership and membership in the project will naturally change over time and our sensitive communication channels should be resilient/configurable to changes in leadership. That means that private conversations should have some sort of expiration cadence such that privacy is maintained for sensitive communications.
Currently we use Github for most threaded issues / discussion and IRC for most real-time announcements, however we also use email and Google Docs/Sheets/Slides/Drive for some organizational communication that doesn't fit well on Github either for individual privacy reasons, format/extensibility reasons, or both.
The vast majority of communication takes place in channels (github and IRC) that are fully open and extensible to all working groups and the broader community - making it easy for everyone to have context and share their knowledge on important conversations. We also have work arounds to (mostly) enable more access controlled communications when they are needed (aka individual emails and doc shares).
Many folks turn off IRC notifications because they are overwhelming (or don't receive them because they aren't online period) and Github similarly doesn't have great notification control for issues/PRs on repositories you contribute to. When a team needs a responsive channel to get everyone on the same page we frequently fall back to email - however remembering the current set of emails for participants in a working groups can be non-trivial depending on team size. Similarly for documents or communications we want to reach all active working group members, we are falling back to email lists created for past events, which don't update as new members are added.
Create a group mailing list in ipfs.io for each of the ipfs working groups and make messages and membership fully open to the public. This wouldn't solve the need for private or sensitive communication (aka that would keep happening on existing, hacky channels), but it could be a good "push" mechanism for updates/asks for individual working groups.
Each working group captain is the gate keeper of their individual working group, and as individuals join their teams (as defined by them), they can approve requests to join the working group list (to be used for sensitive partner/retrospective communications). Messages and documents are only visibile to members of the working group. The project-wide list could be a collection of all captain-managed working group mailing lists, along with any additional members granted access by the project captain (currently David).
Same as proposal 2, but every 6 months we run a script to delete all message threads over 6 months old from the group history so as to avoid buildup of sensitive information.
We can turn off the google groups message history so that our mailing lists only behave as one-time information routers (though document permissioning would work appropriately). This prevents any sensitive information leakage - but would be less useful for helping new contributors gain recent context on sensitive communications/retrospectives.
There might be an edge case where a working group captain would add a core contributor to their project that shouldn't have access to some private communication that would normally be visible to all IPFS project members (ex members of two competing organizations both bulding on IPFS). To avoid that potential scenario, we could ask the IPFS project captain to explicitly ack every new member of the ipfs project mailing list before they are added to the aggregated mailing list (instead of automatically including all wg members).
High overhead without solving the individual working group communication needs.
I like proposal 2.1 the best for it's minimal-overhead, future-proof setup, and working group autonomy, however I'm interested to hear any additional Needs, Factors, or Proposals I didn't cover here to see if there's an even better solution not proposed yet.
mikeal
commented
5 years ago So, I'm -1 on creating more public mailing lists, but I'm +1 on each WG having a point of contact.
I'd be open to either a GitHub repo for discussion per WG or trying to accomplish this using https://discuss.ipfs.io/
Github issues are similar, however, one can't really make the opt-in/opt-out decision on Github (new repos get created, once tagged you get notifications forever, etc).
If you are on the org you can opt out of repos, if you are @ msg'd you can opt out of that individual issue :)
Mailing Lists, by comparison, are all or nothing. The issue you're describing is much worse with mailing lists, the only reason it seems like less is because it's less accessible and therefor has less traffic :)
Need: A way to share sensitive conversations within a working group
Can we clarify some of the use cases here outside of secuirty (which we already have a separate process for).
Need: A way to permission-share sensitive documents within the IPFS project
Doesn't Google Apps have group permissions for this? We tend to use the protocol.ai permission system but we could use the ipfs.io Google App permission system instead.
Need: A way for new core contributors to easily gain access to relevant documents / announcements when joining the project
This is certainly an issue, but I feel like this is a discovery and context problem much more than a transparency problem.
momack2
commented
5 years ago Need: A way to share sensitive conversations within a working group
Can we clarify some of the use cases here outside of secuirty (which we already have a separate process for).
The examples I included were quarterly retrospectives (which include self reflections that might be sensitive) and team meetup logistics/coordination - both of which we currently use direct emails to coordinate (and try not to forget anyone).
Need: A way to permission-share sensitive documents within the IPFS project
Doesn't Google Apps have group permissions for this? We tend to use the protocol.ai permission system but we could use the ipfs.io Google App permission system instead.
You need to have a google group or an organization where everyone has an email to do group permissions in Google Apps. Therefore we'd either need to create and keep updated wg google groups (proposal 2) or create all contributors ipfs.io emails to access permissioned docs (proposal 4).
mikeal
commented
5 years ago You need to have a google group or an organization where everyone has an email to do group permissions in Google Apps. Therefore we'd either need to create and keep updated wg google groups (proposal 2) or create all contributors ipfs.io emails to access permissioned docs (proposal 4).
Technical question: if you add emails that are not in the domain for the app to a group are they included in the permission scheme when you add them to documents? In Google Apps you pay per seat but that only applies to people you add to the org and get an in-domain email address.
BTW, I know that Google Apps makes a "Group" and a "Mailing List" effectively the same thing. I'm more concerned with how we treat them, if it's just a group email alias I have no objections, if we start treating it like a long term mailing list with lots of discussion that's when I grow concerned. The difference here is probably whether or not we open it up publicly.
momack2
commented
5 years ago Technical question: if you add emails that are not in the domain for the app to a group are they included in the permission scheme when you add them to documents?
Yes - if we create google groups with emails from a variety of organizations to properly reference working group contributors from many orgs, they will still be permissioned on docs accordingly.
I agree with the motivation - we want all conversation to be public that doesn't explicitly need access controls. Is a policy around that sufficient, or would you want to add anything to the proposal(s) specifically to enforce that? I think there are cases where the communication needed would be an email (ex about coordinating wg meetup logistics), so turning off list posting entirely seems counter productive.
mikeal
commented
5 years ago I agree with the motivation - we want all conversation to be public that doesn't explicitly need access controls. Is a policy around that sufficient, or would you want to add anything to the proposal(s) specifically to enforce that? I think there are cases where the communication needed would be an email (ex about coordinating wg meetup logistics), so turning off list posting entirely seems counter productive.
I'm not worried about people not on the list posting and interacting with the list when they are explicitly looped in via email.
I was mainly concerned that we were creating another fully open forum to manage. What you're proposing a specific tool for side channel conversations we do not want to make public, in which case this sounds perfect. And, as a bonus, we can include people out of the org in the WG list, so I think I'm totally on board.
momack2
commented
5 years ago @daviddias @vmx - sounds like Mikeal and I are onboard with proposal 2.1 (where mlist messages are only visible to group members). Any concerns? If not I'll take a pass at creating mlists for each wg (with captains as owners) in ipfs.io and add documentation to our team coordination toolkit re communication channels and membership.
vmx
commented
5 years ago sounds like Mikeal and I are onboard with proposal 2.1
@momack2 I'm fine with that, I saw my comment more as input rather than a blocker.
momack2
commented
5 years ago We are planning to prototype proposal 2 for the next ~month to evaluate the value of this solution and any pain points uncovered that we want to iterate on. We will reconvene EOJan to decide whether to amend the proposal or finalize the implementation. If finalized, we'll work to implement the "history deletion" element of proposal 2.1 on top of the current setup, and any additional systematization to keep these lists accurate and useful.
I have created a private working group google group for each of the IPFS working groups, and made the WG captain the owner and added all known WG members. Captains should feel free to update this group according to their understanding of working group members, and approve/deny any membership requests accordingly. There is also an "IPFS Core Contributors" group (ipfs-core-contributors@ipfs.io) that contains references to all working group lists and can be used for private/sensitive org-wide permissioning/conversation. @daviddias can add any additional members he considers part of the IPFS org.
All lists are in the form of [working group abbreviation]-wg@ipfs.io (see the 2019 OKR sheet for canonical abbreviations)
daviddias
commented
5 years ago @momack2 stellar work!! ✨✨✨
@ipfs/working-group-captains, can we count on you to:
daviddias
commented
5 years ago List of mlists for easy access:
daviddias
commented
5 years ago I've created a PR to add the mlits to the Team Structures doc https://github.com/ipfs/team-mgmt/pull/807
lidel
commented
5 years ago [..] can we count on you to:
- List the mlist in your entry-point repo
- Add your Working Group contributors to the mlist
@daviddias not sure if I got this right, but AFAIK only members can post to wb-wg list right now:
https://groups.google.com/a/ipfs.io/forum/#!groupsettings/wb-wg/postingpermissions:
IIUC having this setting makes listing it in README counter-intuitive (at best it will bounce, at worst it will fail silently). If the goal is to have list for internal/sensitive conversation, we should not list it in public repos.
momack2
commented
5 years ago @daviddias not sure if I got this right, but AFAIK only members can post to wb-wg list right now:
I can (and will!) change this! For sharing docs and stuff, it's actually really useful if non-wg members can post to these lists with private collab docs and such - thanks for catching this.
However, I don't think we want to route initial engagement to these lists - we want to keep doing our work in the open on github whenever possible! Putting this on our page seems like it's asking for us to either get spammed, or for people to route comms there that should actually just be github issues...
meiqimichelle
commented
5 years ago It would be great to close out this issue, but looking back, I think there's a point of confusion:
It seems like we converged on not publicizing these lists because we already have ways for the community to interact with the WGs, and we don't want to add yet another channel to maintain (and we want to keep most conversations in the open).
We merged a PR that makes those email addresses public as "email contact" on the Team Structure page.
Was that intentional, or a miscommunication? We may need to roll back that change.
Once that's resolved, I think we can consider this process improvement on a ship! Then @momack2 -- did you want to keep this open, or open a new repo for the review in January?
momack2
commented
5 years ago A side benefit that we didn't explicitly design for in that these lists are organically getting used for confidential information and private intros from the community directly to the working group participants. Right now I think that's just happening because we are using these lists ourselves to route that communication from other channels, but it could be that this fills a useful gap in our community we didn't know we had. I think I still lean toward not posting them as one of the core ways to reach out to a working group (aka reverting the PR) since it's hard to stop them being misused when presented in that context - but I think we should recognize and enable these lists being used by the wider community to coordinate privately with a working group when needed.
daviddias
commented
5 years ago I think I still lean toward not posting them as one of the core ways to reach out to a working group (aka reverting the PR) since it's hard to stop them being misused when presented in that context -
Something is not clicking for me with this proposal. We want to have IPFS Working Groups (Open to the Community) that have contributors from multiple orgs participating, to have mailing lists that are used to coordination with the Working Group, but we want those mailing lists to be private just to the contributors of the Working Group (that are composed by members of multiple orgs) but not available to a wider community to post to (posting doesn't translate to reading all the threads)??
What kind of communication do you expect to go in these mlists?
momack2
commented
5 years ago Desired communication by priority:
Non-desired communication (should come through github directly):
We can try having these mailing lists front-and-center for now and changing how we document them if we start getting a lot of non-desired comms, but it's harder to move people away from that channel once they start using it.
daviddias
commented
5 years ago @momack2: but I think we should recognize and enable these lists being used by the wider community to coordinate privately with a working group when needed.
@momack2: community members engaging on a private topic with a working group or initiating a personal introduction
This was what my expectation was and so, making them listed for people to reach out was a natural step of it.
momack2
commented
5 years ago I think folks are commenting on the way they are being portrayed - as a generic "email contact" that doesn't give a good sense of what sort of contact should go through the email list vs the github repo. That structure seems to lend itself to misuse.
daviddias
commented
5 years ago Would a rewording from Email contact to Mailing list do the trick for folks?
momack2
commented
5 years ago I'm more comfortable with "Mailing list" or "Working Group mlist" or something like that. @meiqimichelle @lidel - do either of those seem better to you?
daviddias
commented
5 years ago @momack2 got it. My bad for initially naming it "Contact". I know understand the resistance and I agree. "Mailing list" is indeed more useful term. Thank you for catching that!
momack2
commented
5 years ago Cool - I'll make a PR adding those back in. I suggest "Team Mailing List" or "Working Group Mailing List" (maybe "WG Mailing List"?) over plain "Mailing List" - since it's more clear that it's for core contributors within the working group, not a default place to send bugs/requests/feedback or a broadcast announce list for anyone interested in that working group's efforts.
I'll go with the longer/clearer one in my PR but feel free to add comments!
momack2
commented
5 years ago We discussed this in our Project WG meeting this week and decided to solidify this prototype - where they are being used, these mailing lists are adding value without any obvious pain points to iterate on. We will check back in around EOQ2 to evaluate if/how to implement content expiry.
Mailing lists are a great way to have a conversation with multiple stakeholders and at the same time, preserve the conversation for future selfs and future contributors. Github issues are similar, however, one can't really make the opt-in/opt-out decision on Github (new repos get created, once tagged you get notifications forever, etc).
Given this, would Working Groups like to have a mlist for their team? @ipfs/working-group-captains, if yes, comment on this thread.