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]]
|
[[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
|
# 2024-10-09
|
||||||
## Schedule
|
## Schedule
|
||||||
- Status-go guild sync:
|
- Status-go guild sync:
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue