Dashboard › institutional-transition-lab › Distillation
5d590975-7869-416f-86a0-3d0777f9643e["lore_tm_v1__dAKToolcK2LmlMY3TMHwO1dBgWlHlskA3pxPuD7nE4","lore_tm_v1_9C0nlZUAL4JjKvDq_oFb3g8Zcdjn19pGsZNcCZj-s_4","lore_tm_v1_k4O3QEuYQkQEtH2WalAo7AV349BUe5WyqLI_XmnH2qs","lore_tm_v1_2DQC7kfDGHrq4mPurtAgAwBnCK7pO1KvLq-PsUNqaso","lore_tm_v1_0wWNCodevj6mW7mjDX8kRtsM_8Alg3TwaZC_ZmjZWeE","lore_tm_v1_yQCJaGjZO_syyTcwy-h0KAxR7VfzSA-voy5iqyryfkU","lore_tm_v1_jlnqXxk1ZrdV3MW_u89OG8bexb45aHP07DWfsyw6SjE","lore_tm_v1_bIsLJbnae6NgivdDRrHuNP12bIaGMUmFn_FUHvlPSBE","lore_tm_v1_f2kBHlixw_AN_-EV1gjTaQyTCqwBMIlioBVvY1j98BM","lore_tm_v1_66wAJCvVAMzYavGTfxo43x63TRh79ky534UwRFumM7E"]
jsonschema reported version 4.10.3; accessing jsonschema.__version__ emitted a DeprecationWarning advising use of importlib.metadata because jsonschema.__version__ will be removed in a future release.valkey-github-issue-3289 selected terra_advisory: proposal_only, event_kind=control_rights, announced 2026-03-02, body_patch_relation=body_only, confidence 0.98; proposed addition gives “binding vote holders (active committers or TSC members)” a vote right in the VIP approval process over foundational changes to the project, grounded in the 2/3-majority body quotation.valkey-github-issue-3441 selected luna_b: proposal_only, event_kind=foundation_transfer, announced 2026-04-03, body_patch_relation=body_only, confidence 0.98; proposed addition gives valkey-io ownership of valkey-io/valkey-skills; ambiguity notes that multiple options are presented and the TSC is to decide, with no implementation or decision shown.valkey-github-issue-4508 selected terra_advisory: proposal_only, event_kind=control_rights, announced 2026-08-24, body_patch_relation=body_only, confidence 0.88; proposed addition gives valkey-io stewardship of the @langchain/valkey NPM package through a proposed valkey-io/langchain-valkey repository, with no approval, creation, or effective transfer evidenced.valkey-github-issue-4509 selected luna_b: proposal_only, event_kind=control_rights, announced 2026-08-24, body_patch_relation=body_only, confidence 0.98; proposed addition gives valkey-io stewardship over repository hosting and long-term maintenance of the n8n-nodes-valkey repository.valkey-github-pr-1390 selected terra_advisory: effective_institutional_change, event_kind=control_rights, announced 2024-12-04, effective 2024-12-09, body_patch_relation=consistent, confidence 0.88; effective edges add repository-code write rights for Harkrishn Patro (hpatro, Amazon) and Ran Shidlansik (ranshid, Amazon), and add for Maintainers an own right over repository governance. Ambiguity: the patch separates committers from maintainers but does not explicitly identify any rights removed from existing individuals.valkey-github-pr-345 selected luna_b: effective_institutional_change, event_kind=board_or_steering, announced 2024-04-21, effective 2024-04-30, body_patch_relation=consistent, confidence 0.99; effective rights added to the Technical Steering Committee were: (1) set_membership for TSC members via no less than a 2/3 affirmative vote, (2) appoint the Chair, (3) set_policy by amending the governance document via no less than a 2/3 affirmative vote, (4) delegate decision making for other Valkey-organization projects to their maintainers, and (5) override decisions by other projects within the Valkey organization.valkey-github-issue-2961, Luna A and Luna B coded a control_event/product proposal concerning Valkey kernel-level hot-key detection, while terra_advisory coded no_event with confidence 0.99; all three supplied no power_changes.valkey-github-issue-3289, Luna A, Luna B, and terra_advisory all coded a proposal_only control-rights event announced 2026-03-02, grounded in the proposed 2/3 vote for foundational changes. They differed in actor/scope/target wording: Luna A used actor active committers or TSC members, scope VIP approval process, target foundational changes to the project; Luna B used actor binding vote holders (active committers or TSC members), scope foundational changes to the project, target major changes to the Valkey project; Terra used the Luna B actor with scope VIP approval process and target foundational changes to the project.valkey-github-issue-4276, Luna A, Luna B, and terra_advisory all returned abstain, event_kind=control_rights, announced 2026-07-28, no power edges, because the frozen source was truncated within the proposed governance model and supplied neither complete rights provisions nor implementation evidence; confidences were respectively 0.90, 0.72, and 0.88.valkey-github-pr-1788, Luna A coded an effective control_event/license on 2025-02-27 with confidence 0.91, treating visible patches as standardized license headers; Luna B and terra_advisory abstained with confidences 0.55 and 0.38 because the patch selection was truncated and could not establish whether terms or licensing rights materially changed. All supplied no power_changes.valkey-github-pr-2927, all coders treated the merged governance patch as an effective institutional change announced 2025-12-11 and effective 2025-12-12. Luna A used event_kind=control_rights, body_patch_relation=patch_supersedes_body, confidence 0.96; Luna B used event_kind=board_or_steering, body_patch_relation=consistent, confidence 0.98; Terra used event_kind=board_or_steering, body_patch_relation=patch_supersedes_body, confidence 0.92.valkey-github-pr-2927 candidate edges agreed that the TSC’s approval process for technical major decisions was modified to simple majority, with a two-week no-negative-vote fallback allowing explicit +2 support from at least 2 TSC members; governance major decisions require a 2/3 affirmative vote of the entire TSC; involuntary TSC-member removal follows the governance-major-decision process; and TSC organization-affiliation composition is capped at one third (1/3). Candidate codings differed over whether the +2 fallback was a separate added edge and whether delegation of project decision making and the composition rule should be separately encoded.completed; (2) inspect complete frozen metadata, bodies, and patches for all 10 records—completed; (3) inspect named frozen model responses—completed; (4) construct final coding objects and graph-edge revisions—in_progress; (5) validate against schema and deliver compact JSON plus summary—pending.valkey-github-issue-4276 were files_listing_complete=null, patch_selection_truncated=false, patch_unavailable_count=0, and source_text_truncated=true; the frozen body ended during the Governance Model sentence stating that the repository has its own MAINTAINERS.md.4276, titled “[NEW] Valkey Samples Repository,” describes an RFC explicitly open for community comment before implementation; proposes a dedicated governed valkey-io/valkey-samples repository; defines three contribution types (cookbooks/, demos/, samples/); requires self-contained directories, pinned public dependencies, current stable Valkey/client libraries, README documentation, vendor neutrality, and CI validation on every PR; and proposes foundational files including README.md, CONTRIBUTING.md, LICENSE, MAINTAINERS.md, issue/PR templates, and workflows validate-samples.yml, lint-markdown.yml, and label-sync.yml.4276 as the only material frozen-source gap, stated that a separately verified GitHub issue body resolved its missing governance text, concluded that the frozen abstentions could not stand, and decided to label supplemental evidence with an explicit source_id rather than represent it as frozen evidence.valkey-io/valkey issue #4276 showed title [NEW] Valkey Samples Repository, author jbrinkman, label enhancement, state open, 2 comments, created 2026-07-28T00:52:23Z, updated 2026-08-10T16:03:48Z, no assignee or milestone, and URL https://github.com/valkey-io/valkey/issues/4276.4276 specifies governance rights: initial maintainers are appointed by the TSC; additional maintainers are nominated through the standard process; maintainers review PRs, enforce quality standards, and ensure vendor neutrality; a maintainer approves or requests changes to a new-sample proposal before implementation; at least one maintainer reviews each PR; and, once approved with CI green, a maintainer merges it.4276’s proposed contribution workflow is ordered: 1. contributor opens a new-sample issue describing the Valkey concept, target language, and expected scope; 2. a maintainer approves or requests changes before implementation; 3. contributor submits a PR under CONTRIBUTING.md; 4. at least one maintainer checks acceptance criteria, vendor neutrality, code quality/documentation completeness, and CI; 5. an approved, CI-green PR is merged by a maintainer.4276 proposes CI on every PR and weekly, covering Markdown linting, URL checking, per-sample dependency installation and code linting, execution against a Valkey Docker container, and a GitHub Actions matrix ensuring no broken builds.4276 proposes a clean-slate migration with no grandfathered content and a 3-phase launch: Phase 1—merge the RFC, revert existing content, and create governance/CI/template structure; Phase 2—submit 3-5 samples through proposal → approval → implementation → review → merge and validate CI end-to-end; Phase 3—announce guidelines, accept community contributions, and expand based on demand and Valkey releases.3289’s body proposes a Valkey Improvement Proposal (VIP) lifecycle: 1. create a numbered VIP; 2. complete required sections and add it to an index; 3. start a [DISCUSS] VIP-{number} {heading} thread in Valkey Contributors Slack; 4. call a [VOTE] after finalization, using lazy majority (3 binding +1 votes and more +1 than -1) for at least 72/96 hours; 5. update the VIP page/index with Accepted or Rejected status and report the outcome.3289 defines four proposed approval types in order: 1. Lazy Consensus—3 binding +1 votes and no binding vetoes; 2. Lazy Majority—3 binding +1 votes and more binding +1 than -1; 3. Lazy Approval—implicit unless a -1 triggers lazy majority or lazy consensus; 4. 2/3 Majority—at least 2/3 of binding vote holders, active committers or TSC members, vote +1, reserved for foundational changes.3289 says anyone may initiate a VIP if they intend to drive or contribute to implementation; defines a major change as a major new feature, subsystem, functionality, or public-interface change involving network protocol/API behavior, AOF/RDB format, or error/authentication log format; models the process on Apache Kafka’s KIP process; and says VIPs complement rather than replace lightweight workflows for minor changes and bug fixes.3289 considered and rejected three alternatives: (1) continue the informal RFC process—insufficient structure, visibility, and clear approval mechanisms; (2) GitHub Issues/Discussions only—lacks a numbered, indexed, lifecycle-tracked system for major architectural changes; (3) create a wholly custom process—more effort without clear benefit over adapting the proven Kafka KIP model.valkey-github-pr-2927 showed changed_files=1, draft=false, merged=true, state=closed, base SHA 5940dbfb0b601dfc565ca7f349a3a62f67d7e5ed, head SHA 8d92a6e1392df217d841b869f581aa0c49542cb2, merge commit SHA cd6faaa726791447f7adc196b6c77cc20658112d, and merge time 2025-12-12T16:53:50Z; the sole patch file was GOVERNANCE.md.GOVERNANCE.md patch in PR 2927 added a one-third (1/3) same-or-affiliated-organization cap for TSC members, required prompt remediation when exceeded, set a goal of resolving noncompliance within 30 days of notification, and permitted removal or reassignment under membership-termination procedures.2927 split major decisions into Technical Major Decisions and Governance Major Decisions. Technical decisions use simple majority when obtainable; after a two-week voting period with no negative TSC vote, explicit +2 support from at least 2 TSC members may approve, including the proposer’s +1 if the proposer is a TSC member. Any negative vote disables +2, and later concerns require a new major-decision process rather than direct retraction.2927 defines governance major decisions to include adding or involuntarily removing TSC members, modifying GOVERNANCE.md, delegating project maintainership or governance authority, creating/modifying/removing project roles, changing voting rules/TSC responsibilities/project oversight, and structural TSC changes including composition limits; these require a 2/3 affirmative vote of the entire TSC.2927 further specified that tied votes preserve the status quo; involuntary removal follows the Governance Major Decision process; unreachable members unresponsive for more than 6 months may still be removed by simple majority of remaining active members; delegation of decision making for another Valkey project is a Governance Major Decision; and the TSC retains discretion to overrule other Valkey-project decisions but “shall show restraint.”