Updated October to 2024-10-28
This commit is contained in:
Samuel Hawksby-Robinson
parent
2a1d163ab3
commit
7888e64cb9
190
README.md
190
README.md
|
|
@ -1,4 +1,194 @@
|
|||
[[INDEX.md]]
|
||||
# 2024-10-28
|
||||
|
||||
## Ad Hoc
|
||||
Review of Magnus's excellent documents:
|
||||
- [Releases](https://www.notion.so/101473f411fb4e998e62d14f0066ae01?v=1a9646e39e9648fab75fde484c13a33b)
|
||||
- [Projects / Epics / Initiatives](https://www.notion.so/424f67ea41cc46b9948c864efa3b9728?v=cca85af96a68475aa786d8ed6c4c89b6)
|
||||
- [Desktop release planning](https://www.notion.so/5a3ab0d83f0e4024aa76c89fc13bc929?v=561aabe4ae6b405080723d43bb0ebbfc)
|
||||
## Program
|
||||
Shared the requirements first process with CCs
|
||||
## Schedule
|
||||
Cross-Core sync call
|
||||
- [[Core Teams Sync 2024-10-28]]
|
||||
|
||||
---
|
||||
# 2024-10-25
|
||||
Mostly sick ... I caught it and just was getting worse over the week
|
||||
|
||||
---
|
||||
# 2024-10-24
|
||||
|
||||
## Schedule
|
||||
### Maya 1:1
|
||||
- 🦕
|
||||
### Volo 1:1
|
||||
- try to track down chandler's documentation or any work product
|
||||
- Discussed [NIP-2: Pseudonymous Contact Discovery](https://discuss.status.app/t/nip-2-pseudonymous-contact-discovery/4142)
|
||||
### Pops meeting
|
||||
- Ask other CCs what they want from a program like that
|
||||
- mechanisms for automating match making https://www.reddit.com/r/Discord_Bots/comments/iqilrh/asking_is_there_a_bot_for_discord_that_acts_like/
|
||||
-
|
||||
|
||||
---
|
||||
# 2024-10-23
|
||||
## Schedule
|
||||
- Status-go council meeting: [[️status-go guild Weekly Sync 2024-10-23]]
|
||||
- Status-go goals sync: [[status-go goals sync 2024-10-23]]
|
||||
|
||||
---
|
||||
# 2024-10-22
|
||||
Caring for the Sick
|
||||
|
||||
---
|
||||
# 2024-10-21
|
||||
Caring for the Sick
|
||||
|
||||
---
|
||||
# 2024-10-18
|
||||
### ♻ Status Feature Flow Exploratory Calls
|
||||
#### 📱🤘 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
|
||||
|
||||
---
|
||||
# 2024-10-17
|
||||
|
||||
## Schedule
|
||||
### Volo 1:1
|
||||
- [Planning Release Process](https://www.notion.so/Status-Apps-Planning-Releases-11e8f96fb65c801289c5e37099c4039b)
|
||||
- [Metrics for Metamask portfolio traffic](https://docs.google.com/spreadsheets/d/1GTIZWIowssdhXGg4r9Od-8c9_Q6US_ZvzyUIr55KeaM/edit?gid=1406324215#gid=1406324215)
|
||||
- [Revamp User Onboarding](https://www.notion.so/Product-Brief-Revamp-User-Onboarding-Initiative-11f8f96fb65c80059876ed69d2c267ca)
|
||||
- Re requirement process:
|
||||
- Nominate a point of contact that drives the feature.
|
||||
- Team lead should always know what is happening within a group.
|
||||
### Terry 1:1
|
||||
- Discussion of knitting teams back together
|
||||
- Difference between cross buddy scheme verse on boarding buddy scheme
|
||||
- How it can integrate with the skills-map initiative
|
||||
### ♻ Status Feature Flow Exploratory Calls
|
||||
#### 📱👛 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
|
||||
|
||||
---
|
||||
# 2024-10-16
|
||||
|
||||
## Schedule
|
||||
### ♻ Status Feature Flow Exploratory Calls
|
||||
#### 🎨 Design Team
|
||||
- Multiple platform directions are not helpful
|
||||
- Features across should be considered as close to simultaneously
|
||||
- Reduces efficiency of work to drop and re-pick up context with months apart
|
||||
- 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.
|
||||
### Status-go goals
|
||||
- https://www.notion.so/status-go-Goals-185a559b5e994573ad3f82c9975bccf9
|
||||
|
||||
---
|
||||
# 2024-10-15
|
||||
## Program
|
||||
- Finalised the basic flow for a requirements first development process
|
||||
- [[PROPOSAL - Requirements-First Development]]
|
||||
- Stored IFT Team Swap Program proposal
|
||||
- [[PROPOSAL - IFT Team Swap Program]]
|
||||
|
||||
---
|
||||
# 2024-10-10
|
||||
## Schedule
|
||||
|
||||
|
||||
---
|
||||
# 2024-10-09
|
||||
## Schedule
|
||||
- Status-go guild sync:
|
||||
|
|
|
|||
Loading…
Reference in New Issue