Hi Stephen and Cole, Thank you for recognizing our efforts.
I would appreciate it if you could clarify your perspective on the development workflow. Given that our joint team is highly distributed across opposite time zones and operates with different work schedules, what organizational approach do you recommend for our development process? Best regards, Andrii Lomakin YouTrackDB development lead On Tue, Dec 2, 2025 at 1:36 AM Cole Greer <[email protected]> wrote: > Hi Andrii, > > I understand that waiting 3 days for each small decision may seem too slow > while your team is actively implementing the feature, but I agree with what > Stephen in that we are already very close to consensus regarding the match > step proposals. The work you are doing here offers tremendous value for the > TinkerPop community, I'm excited to see it completed and hope it will be > contributed back to TinkerPop. > > Regards, > Cole > > On 2025/11/30 08:13:23 Andrii Lomakin via dev wrote: > > 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 > > > -- Andrii Lomakin YouTrackDB development lead
