status-im
/
samyoul-notes
mirror of https://github.com/status-im/samyoul-notes.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Updated October attachments

This commit is contained in:
Samuel Hawksby-Robinson 2024-10-28 15:57:40 +00:00
parent 7888e64cb9
commit 0eb6bcfd52
No known key found for this signature in database
GPG Key ID: 0A38D3BB2983AE5B
7 changed files with 653 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
attachments/2024-10/Core Teams Sync 2024-10-28.md Normal file
View File

@ -0,0 +1,58 @@
# Overview
The Core Teams Sync meeting for Desktop and Mobile focused on several critical issues affecting project progress.
A significant delay in Mixpanel event tracking was identified, leading Jonathan to suggest testing with a new account while Ícaro volunteered to review the code for errors.
The mobile team has successfully completed 30% of the regression test suite, although they encountered new blockers; the desktop team faced minor issues related to logging improvements.
Discussions included simplifying the onboarding flow and username requirements, contemplating the use of public key alternatives.
Concerns about preserving protocol knowledge after Andrea's departure highlighted the need for updated documentation and better specs. Additionally, Igor announced an upcoming call with Jacek to discuss planning for Status Go's future, speculating on a possible rewrite in Nim.
The removal of ID verification code from the desktop was confirmed by Jonathan.
Proposal to enhance transparency through a migration of documentation from Notion to GitHub.
# Notes
## 🌟 Mixpanel Event Tracking Issue (00:03 - 06:51)
- Significant delay (40-50 minutes) in Mixpanel event tracking identified
- Team using free plan of Mixpanel, possibly causing throttling
- Jonathan suggested testing with a new account to isolate the issue
- Ícaro offered to review the code and check for logging errors
## 📊 Release Progress Update (06:57 - 17:11)
- Mobile team reached 30% of regression test suite
- New blocker identified on mobile side (not status go related)
- Desktop team reported multiple issues, but nothing crucial
- Get logger being replaced with sublogger in status go codebase
- Discussion on improving log analysis tools for better debugging
## 🔄 Onboarding Flow and Username Requirements (17:31 - 30:03)
- New simplified onboarding flow discussed
- Concern raised about status go potentially requiring display name
- Suggestion to use public key or compressed key characters as default username
- Debate on using three-word mnemonics vs. public key for default usernames
## 🧠 Protocol Knowledge and Documentation (30:03 - 40:15)
- Concern about loss of protocol knowledge after Andrea's departure
- Discussion on updating and maintaining documentation for double ratchet and other protocols
- Suggestion to reach out to Andrea for help in documenting some aspects
- Need for better specs to allow potential rebuilding of the entire system
## 📞 Upcoming Call with Jacek (40:15 - 46:43)
- Igor announced a call with Jacek to discuss Status Go's future
- Speculation about potential suggestions for rewriting in Nim
- Importance of having clear specs for any potential rewrite
## 🔒 ID Verification Code Removal (46:48 - 55:48)
- Jonathan removed ID verification code from desktop (1500 lines)
- Discussion on keeping only local trust state (trust/untrust button)
- Sam shared notes on feature lifecycle process changes
- Proposal to migrate from Notion to GitHub for better transparency
# Action items
## Tetiana
Create an issue regarding Mixpanel delay with logs (09:05)
## Ícaro
Review Mixpanel code and check for logging errors (08:37)
## Igor
Check if display name is necessary for status go (34:32)
## Jonathan
Wait for mobile team to remove ID verification code before cleaning up status go (49:25)
## All team members
Review and provide feedback on Sam's qshared call notes and analysis document (50:00)

46
attachments/2024-10/Feature Lifecycle - Team Feedback Analysis.md Normal file
View File

@ -0,0 +1,46 @@
Also see [[Feature Lifecycle - Team Requirements]]
Also see [Status Team Call Notes](https://www.notion.so/Status-Team-Call-Notes-12d8f96fb65c80028285dccc9a8106e7?pvs=21)
### Flexibility
- **🎨 Design Team**: Flexible in approach, especially the "3 Amigos" may sometimes be more than 3
- **📄 Docs Team**: Flexibility in documenting features and tracking changes.
- **🖥️🔍 Desktop QA Team**: Flexibility in when expert input is required and reducing formalities around user stories.
- **🌐👛 Wallet Teams**: Flexibility in feature flows and the documentation process.
- **🌐🤘 Core Teams**: Flexibility in technical specifications and iterating based on feedback. In many cases technical specs can't be written all at once and can only be discovered during development.
### Improved Documentation and Communication
- **📄 Docs Team**: Concerned about documentation gaps, tracking changes, and automation in documentation processes.
- **🖥️🔍 Desktop QA Team**: Wants entry points for features in the development lifecycle, especially tracking parity across platforms.
- **🌐🤘 Core Teams**: Ensure technical specs are evolving.
- **Volo**: Emphasises the importance of having a point of contact for any given feature, for clarity in communication.
- **📱👛 Mobile Wallet Team**: Moving documentation to GitHub for better tracking and closing issues.
### Decision Recording
- **📄 Docs Team**: Formalising the process of documenting features and highlighting feature changes.
- **🖥️🔍 Desktop QA Team**: Needs better visibility into development processes and decision tracking.
- **🌐🤘 Core Teams**: Focus on recording decisions, technical specifications, and using living documents.
- **📱🤘 Mobile Core Team**: Recording decisions related to exiting (terminating a feature before completion) features and rationale for changes.
### Feedback and Iteration
- **🎨 Design Team**: Features should be developed simultaneously across platforms to streamline feedback and iteration.
- **📄 Docs Team**: Focus on automating alerts when a feature reaches certain stages.
- **🖥️🔍 Desktop QA Team**: Ideation output and inputs from multiple teams should be visible and accessible.
- **🌐🤘 Core Teams**: Emphasise iterative development with feedback loops and continuous improvement of technical specs.
- **🖥️👛 Desktop Wallet Team**: Ensure feedback stages feed into ideation and roadmap planning.
### Cross-Team Visibility and Coordination
- **🖥️🔍 Desktop QA Team**: Visibility into upcoming features and reconciling different development styles.
- **🌐🤘 Core Teams**: Input from different teams at various stages of the process.
- **📱🤘 Mobile Core Team**: Involvement of multiple "3 Amigos" may be necessary for larger epics and feature ideas from multiple sources.
### Tools and Workspaces
- **📄 Docs Team**: Shared workspaces (e.g., Crews) and process automation.
- **🖥️🔍 Desktop QA Team**: Reconciling the use of GitHub and Notion.
- **🌐👛 Wallet Teams**: Moving to GitHub for better issue tracking and integration.
- **📱🤘 Mobile Core Team**: Considering tools like Notion with a voting system for feature prioritisation.

109
attachments/2024-10/Feature Lifecycle - Team Requirements.md Normal file
View File

@ -0,0 +1,109 @@
# ♻ Status Feature Flow Exploratory Calls
## 🎨 Design Team
- Multiple platform directions are not helpful
- Features across platforms should be considered and worked on as close to simultaneously as possible
- Reduces efficiency of work to drop and re-pick up context with months apart
- Having multiple CCs involved from an early stage has positive impact for marketing so that comms can be clearer
- 3 Amigos may need to be flexible on the "3" part
## 📄 Docs Team
- Concern about starting with a feature with a figma file
- It is uncertain what is implemented and what is not
- Developers write on github, doc team have to hunt down the epics or issues
- Also it is uncertain what will be included in what release
- Is there shared workspace for all of the activity that the CCs work on
- Consider Crews workspace template
- Formalise the process of share a screenshot of the feature in the documentation, and release articles
- Changes to features need to be documented somewhere
- Record somehow that a change decision was made.
- Explore automation process to highlight when feature changes are made
- When writing an article about a new feature identify who the developers are
- Automate alerting teams when certain stages of a feature lifecycle have been met.
- Possibly link into label inclusion for same with QA
## 🖥️🔍 Desktop QA
- The development process doesn't include user stories during a particular point
- Issues lack an entry point in the development lifecycle
- We should have some kind of business ownership of building processes
- Revenue needs to have specific goals from a particular role
- We should have processes that allow us to compete with small startup team in the web3 space.
- Sometimes a user story may be too formal and scary to interact with. It is too much / overkill
- Ideation output needs to be easy to access for anyone, less formal than user stories
- Experts should give input at the appropriate place.
- Different stages don't require everyone's input, but they should have visibility
- Who should be responsible for quality?
- Potential to move the QA bottleneck from the PR stage to the Acceptance Requirements stage.
- Requests for PR review on demand seriously damages the ability to plan work
- No visibility of what is up coming from the development team
- Currently QA time is not considered as part of the timeline.
- QA work is assumed to be doable within a day's work.
- Testing needs to be integrated into the whole workflow including in time estimations.
- We need to remedy the friction between using Github vs Notion for integrating user stories into the development process
- Reconciling the different styles of development between all teams.
- We need to decide and account for divergence in feature parity across platforms
- Some platforms are unsuitable for certain features
- But that decision needs to be made and recorded.
- We should have a pool of feature ideas that can be fed from multiple sources, but it is prioritised and organised.
- Inputs from:
- user feedback
- CC ideas
- Business considerations
- B2B relationships are a fertile ground for discovering feature improvements
## 🖥️👛 Desktop Wallet
- We need context on the document
- Do we need every stage of a process some things need to be flexibility.
- Flows need to be simple
- Feedback stages need to have an output that feeds into ideation (or roadmap), to ensure a proper cycle
- Iterative development needs to be considered
- Input from other teams such as legal to give
- At each stage the 3 Amigos should decide what should the next step should be and contain
- cycling back may be an option
## 🖥️🤘 Desktop Core
- At least integration tests should be included in feature
- Functional tests should be required
- Having tests in mind allow you to have good code.
- Technical specs are needed.
- Feedback loops should be required throughout the stages
- Technical specs are hard to produce in a single step
- But the specs shouldn't be done all at the end of the process
- Specs should exist at the beginning but not in there entirity
- Technical specs could be living documents that update as the implementation progresses.
- Flexibility is very important
- Declare that the proce
- spikes should be considered
- Document decisions
- https://www.industrialempathy.com/posts/design-docs-at-google/
- Features should be welcomed by everybody
- Possibly retrospective specifications based on the code, to build
## Volo
- Nominate a point of contact that drives the feature.
- Team lead should always know what is happening within a group.
## 📱👛 Mobile Wallet
- flexibility on flows should be considered
- some features do not require specific documents, flexibility is necessary
- Notion vs Github consideration
- Move to github
- we can have the ability to close issues of milestone / epic / user story types, which is not inherent in Notion.
- https://www.notion.so/Activity-Mobile-63d352b527844a48a296470340f5e445 A good feature to experiment with a new approach
## 📱🤘 Mobile Core
- Requirements are a gradually developing process
- Need the ability to loop back in the process when discovering
- Epics may like require multiple 3 amigos
- How do you measure success? Compare against OKRs.
- Assess success criteria measured against the OKRs.
- Develop a process of gathering feature ideas from:
- CCs
- Users
- Business
- Leads
- Voting system on a Notion page
- Anonymous
- Start simple.
- What stage does research occur
- We need to implement an exit phase for features that should be ended - Parvesh
- We need record rationale / decision making process

71
attachments/2024-10/PROPOSAL - IFT Team Swap Program.md Normal file
View File

@ -0,0 +1,71 @@
## Objective:
The Team Swap program is designed to increase Core Contributor (CC) mobility, collaboration, knowledge transfer, and team flexibility within the organisation. It allows CCs to temporarily dedicate a portion of their time to another team, promoting deep cross-team learning and fostering stronger interpersonal and inter-organisational connections.
## How It Works:
### **Maintenance and Management**:
- **Ownership**: Managed by an internal **Developer Relations** or **Cross-Team Collaboration Lead**. This role will oversee embedding of CCs into other teams, monitor progress, and gather feedback from CCs and team leads.
### **Logistics**:
- **By Request**: CCs voluntarily request to “team swap” with another team based their on skills and declared interests.
- **Time Allocation**: Participants dedicate 20-40% of their working hours to the new team, balancing between their current and adopted team responsibilities. This allows for a meaningful contribution without entirely leaving their original projects.
- **Duration**: Each swap lasts between 3-6 months, allowing enough time for CCs to fully integrate and contribute to the new team while ensuring that disruptions to both teams are minimised.
- **Approval:** CCs' request to “team swap” is subject to lead approval.
### **Mechanics**:
- **Skill and Project Matching**: CCs are embedded into with teams based on complementary skills or declared interest. The CC should request a specific team to swap with, or may wish to enquire if any teams match their skills or interest. This ensures effective integration and maximises the benefit for both the CC and the host team.
- **Hands-on Contributions**: CCs work directly on the new team's projects, gaining hands-on experience in areas they are less familiar with.
- **Regular Syncs**: CCs will participate in their host team’s regular syncs with to report progress, ask questions, and share insights. CCs are encouraged to share their progress in the host team with their original (home?) teams.
### **Improvement**:
- **Feedback Loops**: At the end of the swap, both teams provide feedback to the program coordinators on their experience, assessing the swap’s success, and offering suggestions for improvement to refine future swaps.
## Cost/Benefit Analysis:
### **Costs**:
1. **Initial CC Inefficiency**: As CCs adjust to new team environments and projects, there may be a temporary reduction in productivity during the transition phase.
2. **Potential CC Incompatibility**: Not every CC may seamlessly integrate into a new team or project, which could lead to mismatched expectations or lower efficiency in output.
3. **Coordination Time**: Both team leads and CCs will need to invest time in planning and coordinating the swap, balancing workload distribution across teams.
4. **Management Overhead**: Team leads and project leads may need to invest extra time in balancing swapped workloads across teams.
### **Benefits**:
1. **Increased CC Mobility**: The program allows CCs to diversify their experience and skills, making them more adaptable and capable of contributing to different areas of the organisation.
2. **Cross IFT Knowledge Sharing**: CCs working across teams facilitate knowledge transfer between different programs, improving organisational learning and preventing silos.
3. **Enhanced Team Bonds**: CCs from different teams build stronger working relationships, fostering collaboration and a more cohesive organisational culture.
4. **Synergy Discovery**: Working across teams can help identify new opportunities for collaboration or synergies between previously disconnected projects or teams, potentially leading to innovative solutions.
## Difference to Cross-IFT Buddy Program:
See [[PROPOSAL] Cross-IFT Buddy Program](https://www.notion.so/PROPOSAL-Cross-IFT-Buddy-Program-10b8f96fb65c8023a207e1438bd5ab64?pvs=21)
[[PROPOSAL Cross-IFT Buddy Program]]
- **Time Commitment**:
- **Cross-IFT Buddy Program**: CCs meet for 1 hour per week to share knowledge, lasting for 2 months.
- **Team Swap Program**: CCs dedicate 20-40% of their time for 3-6 months, fully integrating into another team.
- **Purpose**:
- **Cross-IFT Buddy Program**: Focuses on informal knowledge exchange and building social bonds through casual standups.
- **Team Swap Program**: Focuses on deeper involvement, allowing CCs to contribute meaningfully to a different team and gain hands-on experience.
- **Impact**:
- **Cross-IFT Buddy Program**: More lightweight, mainly exposing CCs to roles and responsibilities without direct contributions to other teams.
- **Team Swap Program**: Provides direct contributions to the new team and deeper integration, leading to stronger cross-team skill development and collaboration.
- **Upfront Cost**:
- **Team Swap Program**: Requires significantly greater upfront cost due to resource allocation, training, and integration efforts. As a result, it's not intended to be applied universally, but selectively where high-impact collaboration could be fruitful.
- **Scope**:
- **Cross-IFT Buddy Program**: Rotational pairing for broader exposure across teams with a short time frame.
- **Team Swap Program**: Long-term project involvement, providing comprehensive learning and potential for lasting organisational impact.
- **Outcomes**:
- **Cross-IFT Buddy Program**: Builds relationships and awareness across teams, with minimal disruption to daily tasks.
- **Team Swap Program**: Develops new skills, fosters collaboration, and brings back substantial knowledge for improved team flexibility.
## Implementation Plan:
- **Pilot Phase**: Start with a small, volunteer-driven pilot program. Monitor efficiency, coordination challenges, and outcomes over a defined period (e.g., 3 months).
- **Evaluation and Adjustment**: Gather feedback from participating CCs and leads to assess the program’s effectiveness and identify areas for improvement.
- **Full Rollout**: Based on pilot results, adjust the program structure as needed and gradually scale to allow broader participation.

231
attachments/2024-10/PROPOSAL - Requirements-First Development.md Normal file
View File

@ -0,0 +1,231 @@
<aside> 🚨
Work In Progress: Suggest any changes or ideas, you are welcome to participate.
Also some things may look messy, so please forgive that for now. Though feel free to point at it and complain 😭
</aside>
# Objective
The purpose of this policy is to establish a clear, open, collaborative, and structured approach for developing Status features. By engaging key stakeholders from the outset and ensuring consistent involvement throughout the feature’s lifecycle, this policy aims to improve quality, reduce rework, and align deliverables with business goals.
```mermaid
graph TD
A[📜 Requirements Document - User Stories]
subgraph DD [📃 Derivative Documents]
B(✅ Acceptance Requirements)
C(⚙️ Technical Specification)
D(🎨 Designs)
end
A --> DD
E[[💻 Implementation and Testing]]
F[[🧪 QA and Design Review]]
G[[🚀 Release]]
DD --> E
DD --> F
E --> F
F --> G
```
# Scope
This policy applies to all feature development projects within the Status organisation and covers the entire lifecycle of a feature, from ideation to maintenance.
# 🔑 Key Principles
## 📃 **Requirements-Driven Development**
Every feature begins with clearly defined requirements. These requirements serve as the foundation for all subsequent documentation, design, development, and testing activities.
### **Requirements Document with User Stories**
The **Requirements Document** serves as the foundation for each feature’s development. In the context of this process, user stories act as the primary way to define the requirements and communicate them across teams. By focusing on the actual needs of users, user stories provide a simple, iterative, and adaptable method of specifying and evolving requirements throughout the feature's lifecycle.
### **What is a Requirements Document?**
In this process, the **Requirements Document** is composed of a set of **user stories**, which describe the desired outcomes from the user's perspective.
### User Story
User stories follow a very simple format:
- As `<someone / something>`
- I want `<some feature>`
- so that `<the reason why>`
<aside> 📖 As **a tech professional** I want **a clear and concise description of a feature** so that **I can solve problems independently with confidence other teams share my understanding of the feature**.
</aside>
See [About implementing user stories](https://www.notion.so/About-implementing-user-stories-fc6bc6b81e54461c85cd1b793cae4e22?pvs=21)
This document also includes **acceptance criteria** and **other supporting documentation** such as designs and technical specifications to ensure clarity for the development, design, and QA teams.
### **Traceability to User Stories**
- Every **acceptance requirement**, **technical specification**, and **design** should be traceable back to its corresponding **user story**. This ensures that the feature being built aligns with the original intention and delivers the desired value to the end user.
## 🦸🦹🧛 **The Three Amigos**
A Three Amigos group is composed of a **developer**, **QA specialist**, and **designer**, responsible for a specific feature or set of features.
Multiple Three Amigos groups may operate simultaneously, each focusing on different features or components of a project. The key roles in each group are:
- **Developer**: Provides technical insights and feasibility assessments.
- **Quality Assurance (QA)**: Ensures that the requirements are testable and aligned with quality standards.
- **Designer**: Offers input on user experience and design considerations.
The Three Amigos group assigned to a feature is responsible for providing input and context throughout the feature’s lifecycle. Each group works collaboratively to ensure their feature aligns with business goals and technical requirements.
```mermaid
graph TD
subgraph 3ag [🦸🦹🧛 Three Amigos]
B[🧑💻 Developer]
C[🧑🧪 QA Specialist]
D[🧑🎨 Designer]
B o--o E[[Provides technical insights and feasibility assessments]]
C o--o F[[Ensures requirements are testable and aligned with quality standards]]
D o--o G[[Gives input on user experience and design considerations]]
end
3ag --> H[📦 Responsible for a specific feature or set of features]
H --> I[🔄 Provides input throughout the feature’s lifecycle]
H --> J[🎯 Ensures feature aligns with business goals and technical requirements]
```
### Multiple groups
- **Feature-specific**: Different features may require different combinations of developer, QA, and designer expertise. To accommodate this, multiple Three Amigos groups may operate concurrently, with each team focusing on specific features. This allows the organisation to scale development efforts and ensure that each feature receives focused attention from a dedicated team.
- **Contextual understanding**: Each Three Amigos group is responsible for maintaining a deep understanding of their assigned features. By involving the same team throughout the lifecycle, there is continuity in knowledge, reducing the risk of miscommunication or misunderstandings as features progress.
- **Cross-team collaboration**: If necessary, multiple Three Amigos groups can collaborate on interdependent features or provide support to each other. This ensures that all features are aligned with the overall product vision and technical roadmap.
# ♻️ Feature Development Lifecycle
Each feature follows a consistent, structured process with the involvement of the assigned Three Amigos group across the following phases:
As required and/or reasonable the Three Amigos will consult with subject experts and the program lead for input.
```mermaid
graph TD
subgraph 3ag [👥 Three Amigos Group]
X[💻 Developer]
Y[🧪 QA Specialist]
Z[🎨 Designer]
end
RM[🗺️ Roadmap]
subgraph fdl [♻️ Feature Development Lifecycle]
A[💭 Ideation]
B[📜 Requirements Document - User Stories]
subgraph DD [📃 Derivative Documents]
C(✅ Acceptance Requirements)
D(⚙️ Technical Specification)
E(🎨 Designs)
end
DD --> G[🔍 Review and Testing]
DD --> F[🏗️ Implementation]
F --> G
G --> H[🚀 Release]
H --> I[🎛️ Feedback and Maintenance]
end
RM --> A
A --> B
B --> DD
3ag --o|Participates in| A
3ag --o|Owns or supports with| B
3ag --o|Participates in and gives context for| DD
3ag --o|Participates in and/or give context for| F
3ag --o|Participates in and/or give context for| G
3ag --o|Participates in and/or give context for| I
```
## 1. 🗺️ **Roadmap to** 💭 **Ideation**
- **Phase**: Roadmap
- **Goal**: Identify key initiatives and high-level business objectives that will drive the creation of new features.
- **Three Amigos Role**: The Three Amigos will use the Roadmap as the initial input to begin a feature lifecycle.
- **Phase**: Ideation
- **Goal**: During ideation, the Status team(s) collaborates to outline the goals and objectives of the feature. The assigned Three Amigos provide context and input on feasibility, design impact, and testing considerations.
- **Three Amigos Role**: The Three Amigos group actively participates in this phase, consulting on technical, quality, and design concerns to shape the feature's initial concept.
## 2. 📜 **Requirements Definition**
- **Phase**: Requirements Document - User Stories
- **Goal**:
- The assigned Three Amigos group formalises the feature’s requirements through **user stories,** ensuring they are clear, complete, and aligned with business goals and technical constraints.
- These stories form the **Requirements Document** and serve as the foundation for subsequent documentation.
- **Three Amigos Role**: The group either owns or supports the creation of user stories, contributing their expertise to ensure the requirements are testable, user-centric, and technically feasible.
## 3. 📃 **Derivative Documents: Design and Technical Specification**
- **Phase**: Derivative Documents
- **✅ Acceptance Requirements**: Defined based on the user stories, these provide the basis for validating the feature.
- **⚙️ Technical Specification**: Created by the developer with input from QA and the designer, detailing the architecture and technical implementation plan.
- **🎨 Designs**: Visual guidelines prepared by the designer, aligned with the user stories and technical constraints.
- **Three Amigos Role**: The group participates in the creation and refinement of all derivative documents, providing context and ensuring they meet the overall objectives.
## 4. 🏗️ **Implementation**
- **Phase**: Implementation
- **Goal**: Developers begin coding the feature according to the technical specification, with QA preparing test plans based on the acceptance criteria, and the designer ensuring alignment with the designs.
- **Three Amigos Role**: The group provides ongoing input throughout the implementation phase, ensuring that development proceeds according to plan and that technical, design, and testing standards are met.
## 5. 🔍 **Review and Testing**
- **Phase**: Review and Testing
- **Goal**: After implementation, the feature undergoes a thorough review. Testing is performed based on the acceptance criteria, with the QA specialist and the design reviewer verifying that the feature meets the required quality standards.
- **Three Amigos Role**: The QA from The Three Amigos participate in the review process, ensuring that the feature aligns with the requirements, technical specifications, and design goals.
## 6. 🚀 **Release**
- **Phase**: Release
- **Goal**: Once testing is complete, the feature is prepared for release. The Three Amigos ensure that the release plan includes any necessary documentation and support resources.
- **Three Amigos Role**: The group oversees the final release preparation, verifying that all aspects of the feature are ready for deployment.
## 7. 🎛️ **Feedback and Maintenance**
- **Phase**: Feedback and Maintenance
- **Goal**: After release, the Three Amigos group monitors user feedback and addresses any issues that arise. Regular maintenance ensures the feature remains functional and continues to meet user needs.
- **Three Amigos Role**: The group remains involved post-release, managing any feedback, bug fixes, or enhancements required to maintain the feature's quality and performance.
# 📃 Documentation Structure
To support this process, the following documents are created and maintained for each feature:
- **Requirements Document**: Defines the feature’s functional and non-functional requirements, reviewed and refined by the assigned Three Amigos group.
- **Acceptance Requirements**: Derived from the initial requirements, these are used to guide testing and verification.
- **Technical Specification**: Details the implementation approach and architecture, created by the developer with input from QA and design.
- **Designs**: Visual representations and design guidelines that align with the feature’s requirements, created by the designer and reviewed by the team.
# Transparency and Continuous Context
By assigning a dedicated Three Amigos group to each feature, the process ensures that every team involved has the necessary context, reducing the likelihood of surprises or last-minute requests. This continuous involvement:
- **Reduces risk of miscommunication**: Since the same Three Amigos group is involved throughout the lifecycle of the feature, they maintain context and can make informed decisions quickly.
- **No unexpected work**: Developers, QA, and designers are fully aware of upcoming work since they are engaged from the beginning, eliminating the risk of sudden or unfamiliar tasks.
- **Cross-functional ownership**: Each Three Amigos group feels a sense of ownership over the feature, improving quality and accountability.
# Risks and Mitigation
With multiple Three Amigos groups working on various features, the following risks should be considered:
- **Risk of resource bottlenecks**: Some team members, particularly QA and designers, may be involved in several Three Amigos groups, which could overload them.
- **Mitigation**: Manage resources carefully and ensure that team members are not overcommitted.
- **Risk of inconsistency**: If different Three Amigos groups operate independently without coordination, there could be inconsistencies across features.
- **Mitigation**: Facilitate regular cross-team meetings or reviews to ensure alignment and maintain consistency.
Also see:
[Unified Spec Theory](https://www.notion.so/Unified-Spec-Theory-139c7d026fa04a50b310d259a7d27b21?pvs=21)
[About implementing user stories](https://www.notion.so/About-implementing-user-stories-fc6bc6b81e54461c85cd1b793cae4e22?pvs=21)

77
attachments/2024-10/status-go goals sync 2024-10-23.md Normal file
View File

@ -0,0 +1,77 @@
Overview
In the recent "status-go: goals sync" meeting, the team discussed several key initiatives and action items.
Igor introduced specific GitHub labels for differentiating desktop, status-go, and mobile goals, addressing concerns from Samuel regarding their complexity.
The group also reviewed logger improvements led by Patryk, who is working on a PR to enhance logging practices, while Samuel raised concerns about flexibility in handling loggers.
Additionally, Andrey provided updates on the rework of the RPC provider storage and emphasized the need for discussions on merge commit policies and integration with go-ethereum.
Igor is tasked with finalizing the Code Cov integration, while Patryk and Andrey will continue their respective developments on logging and RPC provider enhancements.
Dario has been assigned to explore the integration of network-dependent unit tests into the CI process in collaboration with Jakub.
Notes
️ GitHub Labels for Goals (00:00 - 11:58)
- Igor added GitHub labels for goals as agreed
- Labels were renamed to be more specific
- Labels distinguish between desktop, status-go, and mobile goals
- Samuel expressed concerns about the complexity of the labels
- Discussion on filtering and prioritization of issues using labels
- Dario mentioned a small update on a PR related to network-dependent tests
Logger Improvements (12:37 - 20:47)
- Patryk opened a PR to replace get logger usage with sublogger
- Plan to substitute the root engine and reverse the direction of logger proxying
- Goal to implement categorized logging after cleanup
- Samuel raised concerns about passing loggers around by interface
- Discussion on the flexibility of Zap logger and named instances
RPC Provider Rework and Merge Commits (20:50 - 28:07)
- Andrey working on reworking RPC provider storage in the network
- Removed upstream provider from RPC client
- Dario mentioned the need to discuss go-ethereum integration
- Andrey raised the importance of discussing merge commits policy
- Igor updating on Code Cov integration progress
Action items
Igor Sirotin
- Finalize Code Cov integration and configure it to fit team needs (27:09)
Patryk Osmaczko
- Continue work on replacing get logger usage with sublogger (12:42)
Andrey Bocharnikov
- Continue reworking RPC provider storage in the network (20:57)
Dario Lipicar
- Explore integration of network-dependent unit tests into CI with Jakub (11:39)

61
attachments/2024-10/️status-go guild Weekly Sync 2024-10-23.md Normal file
View File

@ -0,0 +1,61 @@
Overview
The weekly sync for the status-go guild focused on several key areas, starting with a discussion led by Samuel on refining a draft of a zero policy document, emphasizing the need for clarity and actionable steps for implementation. The team decided to maintain the policy's focus on status-go for now and create a README file to clarify the policy process.
Igor reported progress on the Banix linter and highlighted potential integration of Sentry for crash reporting, while addressing concerns regarding data privacy.
The meeting also touched upon code coverage, with Igor tasked with finalizing integration and setting thresholds to manage flaky results.
Lastly, the team agreed to restructure their meeting schedule to bi-weekly sessions lasting one hour. Action items were assigned to Samuel and Igor to address various aspects of the discussions.
Notes
📋 Policy Discussion (00:01 - 10:40)
- Samuel presented a draft of a zero policy document
- Discussion on making the policy more specific and actionable
- Agreed to include steps for policy implementation in the repository
- Suggestion to use GitHub PRs for policy discussions instead of Notion
Policy Refinement (12:46 - 22:26)
- Discussed making the policy applicable to other Status repositories
- Agreed to keep the policy focused on status-go for now
- Decided to create a README file explaining the policy process
- Discussed the need for clear steps and conditions in the policy document
️ Banix Linter and Sentry Integration (22:41 - 30:16)
- Igor completed work on the Banix linter for status-go
- Discussed potential implementation of Sentry for crash reporting
- Concerns raised about data leakage and privacy when implementing Sentry
Privacy and Data Leakage Concerns (30:19 - 37:47)
- Discussed the importance of preventing accidental data leakage
- Acknowledged the need to balance privacy with useful error reporting
- Considered the implications of implementing new features on user privacy
Code Coverage and Integration (37:49 - 48:44)
- Igor working on finalizing code coverage integration
- Discussed issues with flaky coverage results and the need for thresholds
- Agreed to monitor and report any issues with code coverage before making it a requirement
️ Meeting Structure Discussion (48:44 - 55:32)
- Discussed reintroducing a general status-go meeting
- Debated frequency (weekly vs bi-weekly) and duration of meetings
- Decided on bi-weekly meetings with a one-hour duration
Action items
Samuel
- Refine the zero policy document based on feedback (02:10)
- Create a README file explaining the policy process (22:26)
Igor
- Continue monitoring and refining code coverage integration (38:05)
- Implement thresholds for code coverage reporting (38:05)
- Reorganize meetings to bi-weekly one-hour sessions (54:17)
All
- Keep monitoring and reporting issues with code coverage before it becomes a requirement (40:56)