Good day Cole, Thank you for the detailed response and for clarifying the project's rules and the importance of the devlist for consensus building. I have carefully considered the guidelines you outlined. Given that I have a developer hired whose sole responsibility is implementing the match step in Gremlin, I must consider the time constraints. A 72-hour delay for feedback on implementation details is not feasible for us.
Therefore, we will proceed with developing our own implementation of the match step in parallel. However, we will actively participate in the discussion of various parts of the specification, continuing the same incremental approach I have outlined above, but focusing on the mailing list threads as the primary tool for communication and achieving consensus. P.S. I am developing a very big proposal that I call "the philosophy of the TinkerPop project", which I hope all devlist participants will find interesting to read. Also, we are planning to open our vendor-independent implementation of LDCB SNB benchmarks for review by all interested parties in the upcoming week. I mentioned all the above to ensure you that we are very committed to TP development and have both big and small ideas to discuss further. Best regards, Andrii Lomakin YouTrackDB development lead. On Wed, Nov 26, 2025 at 9:27 PM Cole Greer <[email protected]> wrote: > 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 > > > -- Andrii Lomakin YouTrackDB development lead
