回复：[DISCUSS] Checking in: project status, roadmap, and bringing more discussions to the list

[windwheel <wi...@sina.cn>]

----- 原始邮件 -----
发件人：mingcheng <mi...@apache.org>
收件人：dev@geaflow.apache.org
主题：[DISCUSS] Checking in: project status, roadmap, and bringing more discussions to the list
日期：2026年08月13日 15点41分

Dear Chair and ASF colleagues,
I am kitalkuyo-gita, and I have recently been responsible for certain aspects of community governance.
I would like to share the proposed discussion agenda for the upcoming Apache GeaFlow community meeting, tentatively scheduled for Saturday, August 22, 2026, Asia/Shanghai time. This note is intended as a pre-meeting discussion brief rather than a decision record. All final decisions, owners, and timelines should be confirmed by the community during or after the meeting.
The proposed meeting theme is:
**GraphMemory roadmap alignment and issue/PR backlog governance for Apache GeaFlow.**
Based on the repository snapshot collected on August 15, 2026, the project appears to have two connected challenges. First, the community has attracted new contributors, but the issue and PR workflow does not yet give them enough clearly scoped, reviewable tasks. Second, the GraphMemory direction has strong potential, but it needs a more disciplined path from prototype capabilities toward a reproducible and maintainable reference implementation.
For backlog governance, we plan to discuss a two-week burn-down and triage effort. The August 15 snapshot showed 67 open issues and 88 open PRs, including 52 issues and 66 PRs that had not been updated for more than 90 days. It also showed that most open issues had no assignee or structured labels, and most non-bot PRs had no requested reviewer. The proposed governance work includes adding area/priority/status labels, assigning reviewers for active PRs, closing or refreshing stale items after notice, clarifying the v0.8.0 release status, and converging duplicate PRs through a single canonical PR per feature or bug.
For contributor onboarding, we propose a staged Contributor Issue Campaign. The meeting document currently identifies 72 candidate issues, but we do not intend to publish all of them at once. The recommended approach is to open the first 24 issues only after each has a clear scope, acceptance criteria, verification command, sponsor, backup reviewer, and review SLA. Later waves should be gated by actual maintainer capacity and contributor follow-through, not by the raw number of issues created.
For GraphMemory, the main proposal is to define Phase 1 as a verifiable reference implementation rather than a broad production claim. The current geaflow-ai work already contains useful building blocks such as an in-memory graph, keyword/vector search, session subgraphs, REST/CLI access, and early reasoning prototypes. However, the meeting document also records important gaps: embedding correctness, persistent backend behavior, lifecycle safety, tenant and deletion semantics, reproducible benchmarks, safe graph query generation, evidence tracing, and integration boundaries with the GeaFlow runtime.
The proposed Phase 1 roadmap is a 10 to 12 week effort, assuming stable participation from around 5 to 6 contributors. Its target is a user-visible GraphMemory loop:
1. Import raw or structured knowledge with schema-aware extraction and provenance.2. Persist events and make graph, text, and vector projections searchable with explicit watermarks.3. Support Basic, Vector, Graph, and Hybrid retrieval modes.4. Provide safe Text2GQL or bounded graph traversal fallback.5. Return evidence-based answers with traceable source references and abstention behavior.6. Validate the result through fixed benchmark data, negative security cases, recovery tests, and release gates.
The longer-term roadmap is intentionally separated from Phase 1. We propose to discuss an architecture direction that combines ontology and decision semantics, sparse parallel reasoning experts, event-sourced dynamic graphs, and 2D/3D spatial digital-twin projections. This includes use cases such as logistics/container pallet modeling, where spatial cells and cargo occupancy can be represented as graph state and updated through guarded actions. We should treat this as a future architecture track, not as a reason to overload the first GraphMemory release.
The key decisions requested from the meeting are:
1. Whether to approve the two-week backlog burn-down and triage rules.2. Which PRs should enter the immediate merge/review queue, especially correctness and release-related work.3. How to handle duplicate PRs and stale PR branches fairly while preserving contributor credit.4. How to close or restart the v0.8.0 release candidate discussion.5. Whether GraphMemory v0.1 should be positioned as a reproducible reference implementation with replaceable local and GeaFlow-backed storage.6. Whether to accept the proposed Phase 1 GraphMemory scope and release gates.7. Whether to start an ADR for the longer-term ontology, decision, parallel reasoning, and spatial graph architecture.8. Whether to launch the staged Contributor Issue Campaign with explicit reviewer capacity controls.
My own assessment is that the most important risk is not a lack of technical ideas. The greater risk is creating more issues, PRs, and roadmap promises than the current review process can absorb. For that reason, the proposed plan favors smaller reviewable tasks, explicit ownership, reproducible acceptance criteria, and cautious wording around production readiness. In particular, GraphMemory should earn stronger claims through benchmark, recovery, security, and governance evidence, rather than through architectural ambition alone.
Feedback is welcome before the meeting, especially on ASF process expectations around stale issue closure, duplicate PR handling, release-candidate communication, and contributor issue labeling. If the community agrees, we will publish the final meeting minutes, decision records, and follow-up tracking issues after the meeting.
Best regards,

xingyuan cheng
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@geaflow.apache.org
For additional commands, e-mail: dev-help@geaflow.apache.org

Re: [DISCUSS] Checking in: project status, roadmap, and bringing more discussions to the list

[Qiang Zhou <lo...@apache.org>]

Hi mingcheng,

Thank you for the valuable feedback. I truly appreciate your
perspective, especially the reminder that reviewer attention is our
scarcest resource. Your experience with the Answer project resonates
deeply with us.

We also want to thank Xingyuan for putting together the initial
detailed proposal. It was a necessary exercise to surface all the
pending issues, even if the resulting agenda was too heavy for a
single session.

We (the PPMC) fully agree with your suggestion to streamline the
discussion. Trying to resolve eight major decisions in one synchronous
meeting is indeed risky and may hinder effective community engagement.
Therefore, we will refactor the meeting agenda to focus strictly on
the critical blockers that unblock the rest:

1. Backlog triage rules (to stabilize our workflow).
2. The status of v0.8.0 (to clear release ambiguity).
3. The positioning of GraphMemory v0.1 (to set realistic expectations).

The remaining topics, such as the long-term architecture ADR and
detailed contributor campaigns, will be moved to separate asynchronous
threads on the dev@ list. This approach should encourage more detailed
discussions and higher participation from the broader community, as
you rightly pointed out.

And absolutely—Xingyuan and I will ensure that the meeting minutes and
decision records are posted to dev@ promptly after the session.
Transparency and archival are key to our growth in the Incubator.

Thanks again for helping us stay focused and aligned with Apache best practices.

Best regards,
loogn
PPMC Member, Apache GeaFlow (Incubating)

mingcheng <mi...@apache.org> 于2026年8月20日周四 10:54写道：
>
> Hi xingyuan,
>
> Thanks for writing this up on the list — that alone is worth a lot, and
> it's good to see the project's direction discussed here rather than only
> in DingTalk.
>
> Two thoughts, as an outsider just passing through.
>
> > My own assessment is that the most important risk is not a lack of
> > technical ideas. The greater risk is creating more issues, PRs, and
> > roadmap promises than the current review process can absorb.
>
> This is the sharpest line in your mail, and I fully agree. In Answer we
> learned the same thing the slow way: the limiting resource is reviewer
> attention, not ideas.
>
> > The key decisions requested from the meeting are: 1. ... 8. ...
>
> Which is why I'd gently apply your own conclusion to the agenda itself.
> Eight decisions in one meeting is a lot to absorb, and a plan that broad
> tends to get read, admired, and then not acted on. If it were me, I'd
> pick the two or three that unblock everything else, eg. backlog
> triage rules, the v0.8.0 status, and how GraphMemory v0.1 is positioned,
> and let the rest become their own threads later.
>
> Smaller threads also tend to get more replies here, which is really the
> outcome you want.
>
> Either way, please do post the meeting notes to dev@ afterwards, that's
> the part that compounds.
>
> Best regards,
> mingcheng
>
> On Wed, Aug 19, 2026 at 9:01 PM windwheel <wi...@sina.cn> wrote:
> >
> >
> > ----- 原始邮件 -----
> > 发件人：mingcheng <mi...@apache.org>
> > 收件人：dev@geaflow.apache.org
> > 主题：[DISCUSS] Checking in: project status, roadmap, and bringing more discussions to the list
> > 日期：2026年08月13日 15点41分
> >
> > Dear Chair and ASF colleagues,
> > I am kitalkuyo-gita, and I have recently been responsible for certain aspects of community governance.
> > I would like to share the proposed discussion agenda for the upcoming Apache GeaFlow community meeting, tentatively scheduled for Saturday, August 22, 2026, Asia/Shanghai time. This note is intended as a pre-meeting discussion brief rather than a decision record. All final decisions, owners, and timelines should be confirmed by the community during or after the meeting.
> > The proposed meeting theme is:
> > **GraphMemory roadmap alignment and issue/PR backlog governance for Apache GeaFlow.**
> > Based on the repository snapshot collected on August 15, 2026, the project appears to have two connected challenges. First, the community has attracted new contributors, but the issue and PR workflow does not yet give them enough clearly scoped, reviewable tasks. Second, the GraphMemory direction has strong potential, but it needs a more disciplined path from prototype capabilities toward a reproducible and maintainable reference implementation.
> > For backlog governance, we plan to discuss a two-week burn-down and triage effort. The August 15 snapshot showed 67 open issues and 88 open PRs, including 52 issues and 66 PRs that had not been updated for more than 90 days. It also showed that most open issues had no assignee or structured labels, and most non-bot PRs had no requested reviewer. The proposed governance work includes adding area/priority/status labels, assigning reviewers for active PRs, closing or refreshing stale items after notice, clarifying the v0.8.0 release status, and converging duplicate PRs through a single canonical PR per feature or bug.
> > For contributor onboarding, we propose a staged Contributor Issue Campaign. The meeting document currently identifies 72 candidate issues, but we do not intend to publish all of them at once. The recommended approach is to open the first 24 issues only after each has a clear scope, acceptance criteria, verification command, sponsor, backup reviewer, and review SLA. Later waves should be gated by actual maintainer capacity and contributor follow-through, not by the raw number of issues created.
> > For GraphMemory, the main proposal is to define Phase 1 as a verifiable reference implementation rather than a broad production claim. The current geaflow-ai work already contains useful building blocks such as an in-memory graph, keyword/vector search, session subgraphs, REST/CLI access, and early reasoning prototypes. However, the meeting document also records important gaps: embedding correctness, persistent backend behavior, lifecycle safety, tenant and deletion semantics, reproducible benchmarks, safe graph query generation, evidence tracing, and integration boundaries with the GeaFlow runtime.
> > The proposed Phase 1 roadmap is a 10 to 12 week effort, assuming stable participation from around 5 to 6 contributors. Its target is a user-visible GraphMemory loop:
> > 1. Import raw or structured knowledge with schema-aware extraction and provenance.2. Persist events and make graph, text, and vector projections searchable with explicit watermarks.3. Support Basic, Vector, Graph, and Hybrid retrieval modes.4. Provide safe Text2GQL or bounded graph traversal fallback.5. Return evidence-based answers with traceable source references and abstention behavior.6. Validate the result through fixed benchmark data, negative security cases, recovery tests, and release gates.
> > The longer-term roadmap is intentionally separated from Phase 1. We propose to discuss an architecture direction that combines ontology and decision semantics, sparse parallel reasoning experts, event-sourced dynamic graphs, and 2D/3D spatial digital-twin projections. This includes use cases such as logistics/container pallet modeling, where spatial cells and cargo occupancy can be represented as graph state and updated through guarded actions. We should treat this as a future architecture track, not as a reason to overload the first GraphMemory release.
> > The key decisions requested from the meeting are:
> > 1. Whether to approve the two-week backlog burn-down and triage rules.2. Which PRs should enter the immediate merge/review queue, especially correctness and release-related work.3. How to handle duplicate PRs and stale PR branches fairly while preserving contributor credit.4. How to close or restart the v0.8.0 release candidate discussion.5. Whether GraphMemory v0.1 should be positioned as a reproducible reference implementation with replaceable local and GeaFlow-backed storage.6. Whether to accept the proposed Phase 1 GraphMemory scope and release gates.7. Whether to start an ADR for the longer-term ontology, decision, parallel reasoning, and spatial graph architecture.8. Whether to launch the staged Contributor Issue Campaign with explicit reviewer capacity controls.
> > My own assessment is that the most important risk is not a lack of technical ideas. The greater risk is creating more issues, PRs, and roadmap promises than the current review process can absorb. For that reason, the proposed plan favors smaller reviewable tasks, explicit ownership, reproducible acceptance criteria, and cautious wording around production readiness. In particular, GraphMemory should earn stronger claims through benchmark, recovery, security, and governance evidence, rather than through architectural ambition alone.
> > Feedback is welcome before the meeting, especially on ASF process expectations around stale issue closure, duplicate PR handling, release-candidate communication, and contributor issue labeling. If the community agrees, we will publish the final meeting minutes, decision records, and follow-up tracking issues after the meeting.
> > Best regards,
> >
> > xingyuan cheng
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@geaflow.apache.org
> > For additional commands, e-mail: dev-help@geaflow.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@geaflow.apache.org
> For additional commands, e-mail: dev-help@geaflow.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@geaflow.apache.org
For additional commands, e-mail: dev-help@geaflow.apache.org

Re: [DISCUSS] Checking in: project status, roadmap, and bringing more discussions to the list

[mingcheng <mi...@apache.org>]

Hi xingyuan,

Thanks for writing this up on the list — that alone is worth a lot, and
it's good to see the project's direction discussed here rather than only
in DingTalk.

Two thoughts, as an outsider just passing through.

> My own assessment is that the most important risk is not a lack of
> technical ideas. The greater risk is creating more issues, PRs, and
> roadmap promises than the current review process can absorb.

This is the sharpest line in your mail, and I fully agree. In Answer we
learned the same thing the slow way: the limiting resource is reviewer
attention, not ideas.

> The key decisions requested from the meeting are: 1. ... 8. ...

Which is why I'd gently apply your own conclusion to the agenda itself.
Eight decisions in one meeting is a lot to absorb, and a plan that broad
tends to get read, admired, and then not acted on. If it were me, I'd
pick the two or three that unblock everything else, eg. backlog
triage rules, the v0.8.0 status, and how GraphMemory v0.1 is positioned,
and let the rest become their own threads later.

Smaller threads also tend to get more replies here, which is really the
outcome you want.

Either way, please do post the meeting notes to dev@ afterwards, that's
the part that compounds.

Best regards,
mingcheng

On Wed, Aug 19, 2026 at 9:01 PM windwheel <wi...@sina.cn> wrote:
>
>
> ----- 原始邮件 -----
> 发件人：mingcheng <mi...@apache.org>
> 收件人：dev@geaflow.apache.org
> 主题：[DISCUSS] Checking in: project status, roadmap, and bringing more discussions to the list
> 日期：2026年08月13日 15点41分
>
> Dear Chair and ASF colleagues,
> I am kitalkuyo-gita, and I have recently been responsible for certain aspects of community governance.
> I would like to share the proposed discussion agenda for the upcoming Apache GeaFlow community meeting, tentatively scheduled for Saturday, August 22, 2026, Asia/Shanghai time. This note is intended as a pre-meeting discussion brief rather than a decision record. All final decisions, owners, and timelines should be confirmed by the community during or after the meeting.
> The proposed meeting theme is:
> **GraphMemory roadmap alignment and issue/PR backlog governance for Apache GeaFlow.**
> Based on the repository snapshot collected on August 15, 2026, the project appears to have two connected challenges. First, the community has attracted new contributors, but the issue and PR workflow does not yet give them enough clearly scoped, reviewable tasks. Second, the GraphMemory direction has strong potential, but it needs a more disciplined path from prototype capabilities toward a reproducible and maintainable reference implementation.
> For backlog governance, we plan to discuss a two-week burn-down and triage effort. The August 15 snapshot showed 67 open issues and 88 open PRs, including 52 issues and 66 PRs that had not been updated for more than 90 days. It also showed that most open issues had no assignee or structured labels, and most non-bot PRs had no requested reviewer. The proposed governance work includes adding area/priority/status labels, assigning reviewers for active PRs, closing or refreshing stale items after notice, clarifying the v0.8.0 release status, and converging duplicate PRs through a single canonical PR per feature or bug.
> For contributor onboarding, we propose a staged Contributor Issue Campaign. The meeting document currently identifies 72 candidate issues, but we do not intend to publish all of them at once. The recommended approach is to open the first 24 issues only after each has a clear scope, acceptance criteria, verification command, sponsor, backup reviewer, and review SLA. Later waves should be gated by actual maintainer capacity and contributor follow-through, not by the raw number of issues created.
> For GraphMemory, the main proposal is to define Phase 1 as a verifiable reference implementation rather than a broad production claim. The current geaflow-ai work already contains useful building blocks such as an in-memory graph, keyword/vector search, session subgraphs, REST/CLI access, and early reasoning prototypes. However, the meeting document also records important gaps: embedding correctness, persistent backend behavior, lifecycle safety, tenant and deletion semantics, reproducible benchmarks, safe graph query generation, evidence tracing, and integration boundaries with the GeaFlow runtime.
> The proposed Phase 1 roadmap is a 10 to 12 week effort, assuming stable participation from around 5 to 6 contributors. Its target is a user-visible GraphMemory loop:
> 1. Import raw or structured knowledge with schema-aware extraction and provenance.2. Persist events and make graph, text, and vector projections searchable with explicit watermarks.3. Support Basic, Vector, Graph, and Hybrid retrieval modes.4. Provide safe Text2GQL or bounded graph traversal fallback.5. Return evidence-based answers with traceable source references and abstention behavior.6. Validate the result through fixed benchmark data, negative security cases, recovery tests, and release gates.
> The longer-term roadmap is intentionally separated from Phase 1. We propose to discuss an architecture direction that combines ontology and decision semantics, sparse parallel reasoning experts, event-sourced dynamic graphs, and 2D/3D spatial digital-twin projections. This includes use cases such as logistics/container pallet modeling, where spatial cells and cargo occupancy can be represented as graph state and updated through guarded actions. We should treat this as a future architecture track, not as a reason to overload the first GraphMemory release.
> The key decisions requested from the meeting are:
> 1. Whether to approve the two-week backlog burn-down and triage rules.2. Which PRs should enter the immediate merge/review queue, especially correctness and release-related work.3. How to handle duplicate PRs and stale PR branches fairly while preserving contributor credit.4. How to close or restart the v0.8.0 release candidate discussion.5. Whether GraphMemory v0.1 should be positioned as a reproducible reference implementation with replaceable local and GeaFlow-backed storage.6. Whether to accept the proposed Phase 1 GraphMemory scope and release gates.7. Whether to start an ADR for the longer-term ontology, decision, parallel reasoning, and spatial graph architecture.8. Whether to launch the staged Contributor Issue Campaign with explicit reviewer capacity controls.
> My own assessment is that the most important risk is not a lack of technical ideas. The greater risk is creating more issues, PRs, and roadmap promises than the current review process can absorb. For that reason, the proposed plan favors smaller reviewable tasks, explicit ownership, reproducible acceptance criteria, and cautious wording around production readiness. In particular, GraphMemory should earn stronger claims through benchmark, recovery, security, and governance evidence, rather than through architectural ambition alone.
> Feedback is welcome before the meeting, especially on ASF process expectations around stale issue closure, duplicate PR handling, release-candidate communication, and contributor issue labeling. If the community agrees, we will publish the final meeting minutes, decision records, and follow-up tracking issues after the meeting.
> Best regards,
>
> xingyuan cheng
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@geaflow.apache.org
> For additional commands, e-mail: dev-help@geaflow.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@geaflow.apache.org
For additional commands, e-mail: dev-help@geaflow.apache.org