move from acceptance to behavior#352
Merged
AlexLgn merged 5 commits intoQuantumFusion-network:mainfrom Jul 21, 2025
Merged
Conversation
AlexLgn
reviewed
Jul 4, 2025
Member
AlexLgn
left a comment
AlexLgn
left a comment
There was a problem hiding this comment.
I suggest to add embedded guidance on case writing rules and expand template with concrete examples
| @@ -10,30 +10,49 @@ assignees: '' | |||
| [Provide a concise description of the case, including its context and significance to the project] | |||
Member
There was a problem hiding this comment.
Suggested change
| [Provide a concise description of the case, including its context and significance to the project] | |
| [Case writing rules: | |
| - Product Focus: Define user value and experience, not technical implementation | |
| - User Priority: List stakeholders by % importance (even if similar to other cases) | |
| - System Boundaries: Explicitly state what's included/excluded from this case | |
| - Verifiable: Expected behaviors must be checkable by non-developers in 5-10 minutes | |
| - Basic English: Write for non-native speakers, avoid complex technical terms | |
| - Scope Limit: Target 3-6 month achievable milestones only | |
| - Hypothesis-Driven: Focus on user behavior and adoption, not system performance] | |
| [Section Description: Describe the product/system being built and its value to users. Focus on what problem this solves and why it matters to the project's success. Define clear system boundaries - what is included and what is not.] |
add general rules for creating case description
Comment on lines
12
to
18
| ## Objectives | ||
|
|
||
| [Briefly describe the case: context, goal, impact. Relate to user needs] | ||
|
|
||
| - [Objective 1] | ||
| - [Objective 2] | ||
| - [Objective 3] |
Member
There was a problem hiding this comment.
Suggested change
| ## Objectives | |
| [Briefly describe the case: context, goal, impact. Relate to user needs] | |
| - [Objective 1] | |
| - [Objective 2] | |
| - [Objective 3] | |
| ## Hypotheses | |
| [Section Description: Product hypotheses about user behavior, adoption, and value creation. Avoid specific technical metrics here.] | |
| [Focus: User adoption, business value, product success - NOT system performance] | |
| [Note: Specific numbers, technical metrics, and performance targets belong in Expected Behaviors section.] | |
| - We believe that [target users] will [adopt/use behavior] because [user value/pain point solved] | |
| - We believe that providing [product capability] will result in [user outcome/behavior change] | |
| - We believe that [system feature] will enable [user success scenario] |
since we changed the description to Hypothesis-Driven I suggest changing the section name too
added examples
Contributor
Author
There was a problem hiding this comment.
since we changed the description to Hypothesis-Driven
did we? This PR is about behaviour driven development.
Contributor
Author
There was a problem hiding this comment.
why did you call it Hypoteses? It's a case template
Comment on lines
+20
to
+22
| ## Stakeholders | ||
|
|
||
| [Explicitly list stakeholders (user personas / agents / actors) and their interests] |
Member
There was a problem hiding this comment.
Suggested change
| ## Stakeholders | |
| [Explicitly list stakeholders (user personas / agents / actors) and their interests] | |
| ## Stakeholders | |
| [Section Description: List stakeholders by priority/percentage] | |
| [Stakeholder Rule: Include percentages and priority levels in headings] | |
| [Note: Always enumerate users even if similar to other cases, as their relative importance and needs may change between cases] | |
| **Stakeholder Priority Overview**: [e.g., "Primary: 60% Solo Developers, Secondary: 30% Teams, Minimal: 10% Enterprise. Focus on solo developers because they represent our core adoption path and have the lowest barrier to entry."] | |
| [Optional: Include not only percentages but also evaluation/justification for why these priorities make sense for this case] |
Expand section description and add priority intro
Сonsider moving Stakeholders section higher, since it seems to be the one that primarily determines the appearance of the other sections
should other systems/parts of the blockchain be considered as stakeholders and mentioned in this section?
Contributor
Author
There was a problem hiding this comment.
Сonsider moving Stakeholders section higher, since it seems to be the one that primarily determines the appearance of the other sections
good point
should other systems/parts of the blockchain be considered as stakeholders and mentioned in this section?
there might be a technical dependency or some other system that uses the one being described. So yes, in this case it should be added to a description, but mentioned with the clear human end user and their interests.
Comment on lines
+24
to
+27
| - actor: [Stakeholder 1] | ||
| [interest/goal]: | ||
| - actor: [Stakeholder 2] | ||
| [interest/goal]: |
Member
There was a problem hiding this comment.
Suggested change
| - actor: [Stakeholder 1] | |
| [interest/goal]: | |
| - actor: [Stakeholder 2] | |
| [interest/goal]: | |
| ### [Stakeholder Name] ([X%] of users - [Priority Level: Primary/Secondary/Minimal]) | |
| [User Journey: Write from their perspective, what they want to accomplish] | |
| - [ ] **Flow**: [User action] → [Next user action] → [User outcome achieved] | |
| - [ ] **Needs**: [What they need to accomplish their goals] | |
| - [ ] **Success Indicators**: [How we measure their success with our product] | |
| ### [Secondary Stakeholder] ([Y%] of users - [Priority Level]) | |
| - [ ] **Flow**: [Complete user journey from their perspective] | |
| - [ ] **Needs**: [Their specific requirements and expectations] | |
| - [ ] **Success Indicators**: [Measurable success for this user type] | |
| ### [Continue pattern for all stakeholders, ordered by priority] |
add priority into heading and provide clear section structure
|
|
||
| ## Expected Behaviour | ||
|
|
||
| [Formulate in terms of the subject area, preferably in the form of user stories or flows. This should clarify the system's boundaries. Use `experiment` template in sub-issues] |
Member
There was a problem hiding this comment.
Suggested change
| [Formulate in terms of the subject area, preferably in the form of user stories or flows. This should clarify the system's boundaries. Use `experiment` template in sub-issues] | |
| [Section Description: How the product/system should behave from a user perspective to serve the prioritized stakeholders defined above. Include measurable criteria and checklists.] | |
| [Note: Behaviour priorities derive from Stakeholder Priority Overview above - no separate priority statement needed here] |
change a section description to support changes below
add a note to make explicit the dependency on stakeholder priorities
Comment on lines
37
to
38
| - [Link to related cases, experiments, or tasks] | ||
| - [Link to relevant documentation or research] |
Member
There was a problem hiding this comment.
Suggested change
| - [Link to related cases, experiments, or tasks] | |
| - [Link to relevant documentation or research] | |
| [Section Description: Product examples, competitive solutions, and user experience references that inform our approach.] | |
| [Product Research: Focus on user experience and competitive landscape] | |
| - [Competing products that solve similar user problems] | |
| - [User experience patterns and industry best practices] | |
| - [Industry standards that affect user expectations] | |
| - [Product examples that demonstrate successful approaches] | |
| - [Related cases, experiments, or tasks] |
|
|
||
| ## Constraints | ||
|
|
||
| - [List any known constraints or limitations] |
Member
There was a problem hiding this comment.
Suggested change
| - [List any known constraints or limitations] | |
| [Section Description: Product and business constraints that affect user experience and product decisions] | |
| [User Impact: How constraints affect what users can do] | |
| - Must provide [user experience requirement] for [specific user type] | |
| - Must integrate with [existing user workflows/tools they already use] | |
| - Must achieve [user-acceptable performance/reliability standard] | |
| - Must work within [business/regulatory constraints affecting users] |
provide examples and expand requirement
| ## Risks | ||
| - [Identify potential risks and their impact] | ||
|
|
||
| - Risk: [Identify potential risks and their impact] |
Member
There was a problem hiding this comment.
Suggested change
| - Risk: [Identify potential risks and their impact] | |
| [Section Description: Product and adoption risks with user-focused mitigation strategies.] | |
| [Business Risks: Focus on user adoption, product success, business impact] | |
| - Risk: [User adoption/experience risk that could prevent success] | |
| - Mitigation: [Product strategy to address user concerns] | |
| - Risk: [Business/market risk that affects product viability] | |
| - Mitigation: [Business approach to mitigate risk] | |
| - Risk: [Technical risk that would impact user experience] | |
| - Mitigation: [User-focused solution approach] |
Comment on lines
48
to
50
| ## Learning Outcomes | ||
|
|
||
| [To be filled during and after case completion] |
Member
There was a problem hiding this comment.
Suggested change
| ## Learning Outcomes | |
| [To be filled during and after case completion] | |
| ## Development Outcomes *(Optional - use only when needed)* | |
| [Section Description: Concrete working products/deliverables] | |
| [When to use this section: | |
| - Multiple technical approaches could satisfy the same user need | |
| - Deliverables serve different stakeholder groups with unclear prioritization | |
| - Complex systems require phased delivery not obvious from user flows] | |
| **High Priority Deliverables:** | |
| - [Working product/feature that directly serves primary stakeholders] | |
| - [User-facing capability that delivers core value] | |
| **Secondary Deliverables:** | |
| - [Supporting products/tools for secondary stakeholders] | |
| - [Documentation/guides that enable user success] |
change from Learning Outcomes to current approach to describing Development Outcomes
mark section optional to avoid duplication
provide recommendations for use
|
|
||
| ## Next Steps | ||
|
|
||
| [To be determined based on results] |
Member
There was a problem hiding this comment.
Suggested change
| [To be determined based on results] | |
| [To be determined based on results] | |
| [ | |
| Checklist Before Submitting: | |
| - [ ] Does this describe user value, not technical implementation? | |
| - [ ] Are stakeholders prioritized with clear percentages and justification? | |
| - [ ] Are system boundaries clearly defined? | |
| - [ ] Can expected behaviours be verified by non-developers in 5-10 minutes? | |
| - [ ] Is the language simple enough for non-native speakers? | |
| - [ ] Is the scope limited to 3-6 months of achievable work? | |
| - [ ] Do hypotheses focus on user behaviour, not system performance? | |
| ] |
optional - add checklist so that case author can check description when all notes from template have already been removed
Contributor
Author
There was a problem hiding this comment.
not technical implementation?
this is an experiment template - it should be in technical language
Contributor
Author
|
@AlexLgn let's also align on the vocabulary |
Member
|
Is this ready to be merged soon? |
AlexLgn
reviewed
Jul 21, 2025
Co-authored-by: AlexLgn <163022590+AlexLgn@users.noreply.github.com>
AlexLgn
approved these changes
Jul 21, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
An attempt to marry BDD and Systems Engineering.
The main idea is to write cases in more product language and leave technicalities to experiments.
I suggest describing models, hence we should talk about
Expected Behaviours. AddStakeholders` and their descriptions of their interactions with system - user flows or behaviours