Open nknize opened 5 months ago
Does this belong in https://github.com/opensearch-project/.github?
@nknize Thanks for finding the time to put this writing up, do you see any particular model appealing to you more than others? I personally have pretty good experience with ASF governance (PMCs) and I think it works pretty well, however that would require some changes to the governance model we have now.
@nknize Thanks for finding the time to put this writing up, do you see any particular model appealing to you more than others? I personally have pretty good experience with ASF governance (PMCs) and I think it works pretty well, however that would require some changes to the governance model we have now.
I realized I hadn't included the important part. I updated the text to include my proposed models in each of the decision categories and topics. The proposal doesn't require any changes to the LC model we have today. It only defines the process / criteria needed to make a decision.
Is your feature request related to a problem? Please describe
I realize this may be a bit controversial and spark a lot of opinions but an important topic to discuss civilly nonetheless.
I imagine this will get moved to another repo.I put itherein the core repo to get the eyes and thoughts from many of the day to day core developers that experience a lot of deadlock on core progress and key decisions that affect many downstream plugins. In no way does this devalue the thoughts and opinions of any downstream "first class" OpenSearch plugin. All are welcome to contribute their thoughts and opinions.Quick disclaimer: These are my (@nknize) personal thoughts and views on codifying an official decision making process to promote community progress on making technical and non-technical decisions on the project. They in no way reflect the official opinions of the Leadership Committee or any other stakeholder of the project. It is heavily adopted from The ASF Decision Making docs and Xen Project Governance documents as these have been some of the most enjoyable and productive projects I've had the privileged to collaborate with. Enjoy, discuss, converse, or ignore...
Decision making is critical to ensure progress of any group lead project. Without a clear well defined decision making process, that is agreed to by existing and adhered to by future members and maintainers of the project, the members will deadlock on decisions and inevitably stall or slow the advancement of the project or, worse, dissolve into chaos and fail without structure.
This document serves to propose an official decision making process for the OpenSearch Project. It defines the categories of decisions, types of decision making models, and selects appropriate models for the different categories to formally define how the decision makers on the project will make decisions in different areas of the project.
Describe the solution you'd like
Categories of Decisions
Because OpenSearch consists of a large bundle of team projects with different purposes, missions, and implementation level details, decision making is split into two fundamental categories: top level project decisions and team level (per-repository) decisions.
Top level project decisions
Top level project decisions are those that would typically fall in the purview of an organizational governing body. In a formal organization (e.g., non-profit, political, charitable, public, private), top level decisions are carried out by a board of directors and well defined in the by-laws which are created during the formation of the organization.
Since OpenSearch is not a formal organization it has not created or codified any formal processes for top level decisions (e.g., bylaws or operating agreements) nor has it defined the types of top level decisions under the purview of the project. As an AWS Vendor Controlled Open Source project, and absent membership to any neutral software foundation (e.g., Apache Software Foundation, Linux Foundation), AWS bears all the risk of the project, thus necessitating OpenSearch to follow the top level legal and security governance dictated by AWS with some freedom to create community lead operational processes on its own. The OpenSearch Leadership Committee has been formed to help answer the “who makes these decisions” question and guide the leadership of the project in the best interest of its community constituents.
The following categories (along with explicitly listed decisions) are identified as top level decision topics that fall under the purview of the formal Leadership Committee.
Team Level (sub project / per repository) decisions
Team level decisions are those that fall in the purview of the individual teams / repositories. These decisions are carried out by the Maintainers of the sub project which are defined in the MAINTAINERS.md file of each repository. While some Implementation details are shared across projects (e.g., bundled versions, core APIs, SDKs, developer operations and tooling) there are many team level decisions that need to be made during the day to day developer operations (devops).
The following three categories of decisions are identified as those made on a daily basis and may vary team to team:
Definitions
Prior to defining the decision making model proposed herin, the following terms are defined to ensure no ambiguity in their usage (leveraged from The ASF, Xen Project, and other general governing / legal practices):
Decision Making Models
There are many different types of Group Decision Making Methodologies and Models. Performing a comprehensive trade study with literature review would be quite extensive, elaborate, and overly burdensome, thus is left outside the scope of this proposal. Instead this proposal takes a “progress not perfection” approach and recommends following some of the best practices identified across existing software foundations, along with initial decision making processes already established in existing OpenSearch policies (e.g., Maintainer Nomination).
The following three types of decision making models proposed for OpenSearch are defined above and provided below. Their definitions are restated for completeness with some further clarification as applied to the project. Following their definitions are the proposal’s recommendation on which model should be applied to each top-level and team-level category.
"This change addresses issue #XYZABC; I have not received any explicit approval or feed back in X days. If there are no objections, I am going to assume lazy consensus and merge the change in three days."
Proposed Decision Making Process
Again following the “progress not perfection” and “bias for action” tenets, the proposal recommends adopting from the best practices outlined by several existing foundations. As such, the following proposes the decision making models be used:
Top Level Project
Team Level Per-Repository
Related component
Other
Describe alternatives you've considered
Continue as-is w/o any decision making process - continues to lead to stalled PRs, issues, etc. Adopt a pre-defined foundation process
Additional context
No response