Hi Andrii, I agree that a high volume of disparate threads does make it hard to track the discussions and build consensus in the community. I think there is a role for both GitHub and the devlist in organizing discussion and development efforts. It's important given our project structure that development discussions, decision making, and consensus building take place here in the devlist. Once consensus has been reached in the devlist, that decision should be distilled into something more consumable (Typically a proposal to GitHub or a new JIRA).
The centrality of the devlist is a core principle of ASF project governance. It tends to be slower than other platforms such as Discord or GitHub, but this is by design, as it allows anyone to be involved in consensus building, even if they are unavailable at the date and time a discussion began.The devlist posts are also permanently archived by the ASF, which is has proved to be very useful at times where we end up reconsidering decisions made years ago, especially involving invididuals who are no longer active in the project. You can find more details of the ASF's stance on mailling lists here: https://community.apache.org/contributors/mailing-lists.html. It's quite normal accross ASF projects to expect up to 72 hours for responses in devlists. We typically try to respond faster than that, but response times still vary. We typically assume a lazy consensus on any discussions which have no objections after 3 days. This generally ensures that everyone has an equal opportunity to participate in any devlist discussion. If a discussion is particularly consequential or potentially controversial, I'll often leave the discussion open for up to a week to ensure everyone has more than enough time to participate. For the purposes of the match step discussion, decisions on the devlist should lead to proposal docs in GitHub, and these proposals should be the primary reference during development. It's normal to have minor disussions and changes through PR comments for a proposal, however these should remain relatively small as the proposal should reflect the consensus from the devlist. Given the current volume of devlist posts, we should be extra vigilant about keeping threads organized. Whenever possible, we should limit ourselves to a single thread for a given topic. It's prefered to reply to an existing thread instead of creating a new one if the context is related. By convention, any discussion threads should have a subject line beginning with [DISCUSS] to improve searchability in the devlist archive (https://lists.apache.org/[email protected]). > 2. Semantics PR First: We will begin with a Pull Request (PR) defining the > semantics of the match step. All discussions regarding semantics must occur > as review comments on this PR. Once resolved, this approved PR becomes the > official starting point. > 3. Iterative Development: We will proceed with iterative development by > providing small, incremental specifications for the GQL. > 5. Implement and Repeat: Once a specification is approved, implementation > will begin. The process will then repeat from item 3 with the next > incremental specification. Regarding your points 2, 3 and 5, I'm in agreement. Considering the general consensus achieved in the initial discussion (https://lists.apache.org/thread/m4yf6sq9hch933c7bc563ygpb72rkonm), the acceptance of the proposal summarizing that consensus (https://github.com/apache/tinkerpop/blob/044c7db24343754950b24cedc831229f64fd0fdf/docs/src/dev/future/proposal-declarative-match-step-9.asciidoc), and the lack of objections raised in the more recent devlist thread (https://lists.apache.org/thread/26fb152730q1gq2g8wk695v4ph3v1bqz), I think we're more than ready to proceed with a PR which more rigidly defines the new match step semantics. If the PR review turns up any major disagreements, we may need to return to the devlist, although we can most likely complete that review exclusively in GitHub. I agree that once a proposal is merged, implementation work can commence based on the proposed specifications. > 4. Specification PRs: Each incremental specification will be introduced via > a small, but complete PR that builds upon the previous one. All discussions > for each specification update will be conducted as review comments on its > respective PR. Regarding the iterative specification PRs described in point 4, if these PRs remain relatively small and uncontroversial, GitHub review may be enough. If the proposed changes are consequential enough, they may need to be decided via the devlist. I can help help determine on a case-by-case basis if each proposed change can fit into a simple PR or requires a devlist discussion. Once any of these discussions have reached consensus, they should make their way into a PR for future reference. Please let me know any thoughts you have regarding this. Thanks, Cole On 2025/11/25 08:11:45 Andrii Lomakin via dev wrote: > Dear Colleagues, > > I have received feedback that the team is finding it difficult to track the > ongoing implementation discussions for the match step due to the high > volume of disparate threads. > > I am concerned that if we do not improve the organization and collaboration > around this proposal, we risk entering "production hell," which could lead > to either low-quality implementation or a failure to deliver. > > Therefore, I propose the following organizational plan for all future > discussions and development: > > 1. Centralization on GitHub: All concurrent implementation attempts and > discussions will be consolidated on GitHub. > 2. Semantics PR First: We will begin with a Pull Request (PR) defining the > semantics of the match step. All discussions regarding semantics must occur > as review comments on this PR. Once resolved, this approved PR becomes the > official starting point. > 3. Iterative Development: We will proceed with iterative development by > providing small, incremental specifications for the GQL. > 4. Specification PRs: Each incremental specification will be introduced via > a small, but complete PR that builds upon the previous one. All discussions > for each specification update will be conducted as review comments on its > respective PR. > 5. Implement and Repeat: Once a specification is approved, implementation > will begin. The process will then repeat from item 3 with the next > incremental specification. > > I believe that adopting this iterative and centralized process is essential > to successfully deliver this initiative. > > Looking forward to reading your feedback. > > Best regards, > Andrii Lomakin > YouTrackDB development lead >
