Daniel (dB.) Doubrovkine

I like this. Let's turn it into something org-wide @joshuarrrr? Couple of thoughts: - The triage team is an internal team that lets org members move issues around. I think...

> @dblock do you think saying maintainers is too widely scoped? Anyone belonging to the OpenSearch-Project could be a potential for triaging issues no? That's a good point. In the...

I like to think of "experimental" features as "working, but we're not sure we will want to keep it", rather than "incomplete, a lot of work remains to be done"....

I think @wbeckler is onto something and experimental features should be product-specific, appear in https://github.com/opensearch-project/OpenSearch/blob/main/DEVELOPER_GUIDE.md, and user-facing documentation. We can add some high level approach for plugins to https://github.com/opensearch-project/opensearch-plugins/blob/main/CONVENTIONS.md, etc....

In some offline conversation we talked about the fact that experimental features should be 1) disabled by default 2) a user should not be able to enable them via some...

> I agree that experimental features need to be disabled by default, cannot be enabled via API. I also think that security should be an issue all along, but is...

> @hdhalter: I'll go update both templates for you. Start with .github and let's make sure those look A-OK. > @CEHENKLE and @dblock: Once the tweak to both templates is...

@Naarcha-AWS are you still working on this?

@nknize A lot of the mechanics exist at various degrees of thoroughness in https://github.com/opensearch-project/opensearch-build#releasing-opensearch and has been iterated upon incrementally. As an example, the top-level release process is codified through...

I feel like this would be a step backwards, as the apps significantly simplify deployment and maintenance, and are automatically enabled for new repos.