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

[PROPOSAL] Maintainers and admins communication channel #63

Closed
AmiStrn opened this issue Mar 31, 2022 · 12 comments · Fixed by #153
Closed

[PROPOSAL] Maintainers and admins communication channel #63

AmiStrn opened this issue Mar 31, 2022 · 12 comments · Fixed by #153

Comments

@AmiStrn
Copy link

AmiStrn commented Mar 31, 2022

Description
We should have a way to discuss different issues amongst maintainers and admins via either a mailing list or some other channel. Especially since there will be more and more maintainers from outside AWS - #59

What is the problem? What is preventing you from meeting the requirements?
Currently the discussions are all out in the open which is good for most cases. However, discussions regarding nominations and perhaps other types of discussions are the kind best had in a smaller forum.

What are you proposing? What do you suggest we do to solve the problem or improve the existing situation?
Mailing lists, or in todays forum. There could be many other ways to do this. I would prefer not to have these done in Chime since the time zones would be really hard to work around.

What are your assumptions or prerequisites?
Most discussions should be out in the open, this is only for issues that are by design best had in the maintainer - admins forum.

@rursprung
Copy link

in previous FOSS projects & co. we had two or three channels:

  • a forum: slow paced, longer conversations, "archived" (i.e. you find stuff again also a few years later)
    • 99% public
    • ~1% internal area for the team to discuss team-internal things
  • IRC (you know, the old-school, stable thing compared to these newfangled chat apps 😝) for faster flowing discussions
    • one (or more) public channels
    • one internal channel
  • sometimes also a voice chat (usually Team Speak)
    • public channel(s) for various discussions
    • internal channel for team meeting & co.

discussions would usually transition between these places, final decisions would be documented in the forum (internally or externally, depending on the decision). this tended to work pretty well, then again these were more informal things with no companies being involved, so a lot less red tape was involved 😄

@reta
Copy link

reta commented Mar 31, 2022

@rursprung Forum is already in place actually https://discuss.opendistrocommunity.dev/, it is not 100% maintainers and admins but could be used as such as well as for wider community reach.

I would favour mailing list among others for a few reasons (drawing some experience from ASF and OpenJDK):

  • asynchronous by default
  • less destruction, people answer when they have time to do so
  • easy to search and follow threads

IRC / Slack / Discord - at least one of those would be great for reaching people directly / have live conversations. In the same vein, I think it would be great to have once a week call (non mandatory participation) to share the ongoing issues / pain points / development.

@stockholmux
Copy link
Member

Mailing lists, or in todays forum. There could be many other ways to do this. I would prefer not to have these done in Chime since the time zones would be really hard to work around.

I tend to agree here. Sync chats or voice are tricky with timezones. (Also, I'd prefer anything but Chime for a variety of reasons.)

This has been a continually vexing problem for the project and I don't want to demand that people who want to contribute/participate work on North American timezones (or any specific one for that matter).

To add a little flavour to this problem: somewhere between 20-30% of the tweets that mention OpenSearch originate in time zones +5-+12 (India to New Zealand, with a large concentration in Japan). There a vanishingly small # of hours to have synchronous connections with people in say Tokyo, Tel Aviv, and Seattle:

Screen Shot 2022-03-31 at 9 51 10 AM

That being said, for the general sleep schedule of group and to not bias towards a particular part of the world, keeping it to a mailing list or forums seems rational.

@stockholmux
Copy link
Member

@reta I would be glad to setup a specific forum area just for maintainers if that's the right direction. It's literally 10 minutes of work to do so.

@reta
Copy link

reta commented Mar 31, 2022

@reta I would be glad to setup a specific forum area just for maintainers if that's the right direction. It's literally 10 minutes of work to do so.

Thanks @stockholmux, thinking loudly what could this area be used for:

  • announcements related to maintainers / projects changes
  • announcements from the teams
  • conclusions out of internal / non-public meetings
  • something else?

@jlprat
Copy link

jlprat commented Apr 1, 2022

Hi all,
Despite not directly being part of the OpenSearch community I wanted try to share my opinion on this topic.

I completely agree on the need of a private channel of communication to be able to discuss things like nominations, code of conduct infringement, or security issues report. All these need to be firstly discussed in a "closed door" environment before the proper final decision or outcome can be shared publicly.
If OpenSearch is open to shared governance (and it is according to what I'm seeing 🙂 - kudos to this!) all communication going now to internal AWS mailing lists should be replaced to something every maintainer has access. Also, I know some companies (financial sector) have really big restrictions on which tools they can use to communicate with others (some do not allow Google Docs, others do not allow Slack...). One thing that it seems all seem to allow is GitHub.
For this reason, I would propose the following:

  • Create a "maintainers" mailing list (something like [email protected]). This might be used only for "internal" use (only for maintainers to message maintainers) or also as a general inbox in case there are some questions the community might want to address privately with the maintainers
  • Replace the [email protected] mail with something like [email protected] where all maintainers have access to
  • Replace the [email protected] mail with something like [email protected] where all maintainers have access to
  • Create a private repository (called governance for example) in opensearch-project organization with discussions enabled. This could be the perfect place for maintainers to discuss sensitive topics. Every maintainer despite their affiliation should be able to access GitHub and discussions might be a bit more suited for these things than plain email
  • As already mentioned by others, all communication should be asynchronous first as people might be in different time zones

Other types of communication channels could be public and I think they are out of the scope of this issue.

These are my five cents on the matter.

@dblock
Copy link
Member

dblock commented Apr 1, 2022

  • Create a "maintainers" mailing list (something like [email protected]). This might be used only for "internal" use (only for maintainers to message maintainers) or also as a general inbox in case there are some questions the community might want to address privately with the maintainers

This assumes that OpenSearch is 1 big monolith maintained by one set of people, which I don't think we should do. So every project will need a separate way to communicate. I definitely wouldn't want to have dozens of maintainers on a single mailing list where someone is saying something not nice about a potential maintainer addition to a specific repo.

All maintainers is definitely way too big of a list for security vulnerabilities. Only maintainers of a given project that has a vulnerability should be in the loop. However routing of potential vulnerabilities may need a broader list. Thus today aws-security and opensource-codeofconduct are well oiled systems staffed 24/7 with highly specialized people that have the ability to page anyone globally at AWS. I know that's not "open", but it's also right now best for security. What could possibly replace that? Who is going to be paged in the middle of the night when there's a high severity security problem (I want someone to be paged)? Finally, we need to practice responsible disclosure and do our best to avoid having 0 day vulnerabilities in the wild, which requires more communication in private.

  • Create a private repository (called governance for example) in opensearch-project organization with discussions enabled. This could be the perfect place for maintainers to discuss sensitive topics. Every maintainer despite their affiliation should be able to access GitHub and discussions might be a bit more suited for these things than plain email

This could be on .github where maintainers of every project are added. Not sure whether GitHub lets you do that easily without having to add people to multiple places.

@jlprat
Copy link

jlprat commented Apr 1, 2022

Good points! Please take my original comment with a pinch of salt of course!

Regarding, "OpenSearch" is not a monolith" issue, this could be solved with several emails for each project / module. Maybe a bit complicated to manage?

For the other points, (CoC and mostly security) you make a really good point about being paged, definitely. But, as you point out, the consequence of the current solution is that is not "open" as in only AWS maintainers would have access to it.

@stockholmux
Copy link
Member

stockholmux commented Apr 1, 2022

@jlprat Yeah, CoC and Security are tough.

I do get your point - I'm not wild about them being amazon addresses either. FWIW, I was present in the original discussions about both of those contact addresses and them being amazon dot com - we wanted opensearch dot org addresses originally. The decision to use amazon dot com wasn't about ownership but rather red tape (and timeline) of having email at the domain and the approvals needed to do so. It's not impossible, it's just time/effort that will probably need to be bridged at some point.

However, with regards to how those are staffed, even if reporting at those addresses were handled potentially outside of AWS it seems like there would always be someone (or a group of someones) that would need to be trusted to distribute the information to the correct folks and not everyone. From where I see it, it's always a matter of trust, no matter if it's AWS or someone else.

@jlprat
Copy link

jlprat commented Apr 1, 2022

@stockholmux completely in agreement

@AmiStrn
Copy link
Author

AmiStrn commented Apr 4, 2022

I like the idea of enabling github discussions in the repo's it keeps things non monolithic as @dblock suggested. and is organic to the environment we are all part of.

@stockholmux
Copy link
Member

I'm very much less enthusiastic about GitHub Discussions, @AmiStrn. I evaluated it a few months ago and it definitely has downsides. Moderating Discourse (existing forums) is quite a bit easier and has a lot of tools to help you do so.

Additionally, having distinct permissions is a huge advantage vs having it integrated with GitHub. One of the goals I've had is to enable community moderators in the forums - I can give this out to anyone on Discourse and that's the only thing they get. In GitHub I have to tie it to other repo permissions.

Finally, I'm a little hesitant to centralize more on GitHub. I personally love GitHub but it's closed-source and a single-party service. The project could be kicked off GitHub (though unlikely). If the project had to, code, issues, and PRs could be ported to self-hosted GitLab or similar OSS solution. Discussions don't really have a good place to go as there isn't a good way to port-out for this feature. And it's also nice to have something that isn't reliant on the single source of failure (GitHub) should the project need to regroup.

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