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

13 KiB
Raw Blame History

INDEX.md

2024-10-28

Ad Hoc

Review of Magnus's excellent documents:

Program

Shared the requirements first process with CCs

Schedule

Cross-Core sync call

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

Pops meeting

2024-10-23

Schedule

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

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

2024-10-15

Program

2024-10-10

Schedule

2024-10-09

Schedule

Program

IFT Buddy program

2024-10-08

Schedule

  • Mobile Core sync and planning:
    • MixPanel via proxy
    • Critical path errors should be reported via sentry.
    • Wallet integrations asking permissions like Gifs
    • Create feature request for ask permissions to expose IP addresses in wallet in GitHub. (✅ Added)
    • Set up a call with Waku to establish a process for requesting specific items: (✅ Added)
      • Stable test net
      • Store node:
        • See what is the connected node
        • have the option to select our own node
        • Why was it removed previously?
    • Set up some crews:
      • Get Volo involved and introduced
      • a quick and simple idea is to create teams in GH, that is crew teams. So that QAs or anybody can tag the crew in issues.

Program

Minor Update on Legal Docs in the Apps

2024-10-07

Schedule

  • James from Status Chain

Issues

2024-10-04

Schedule

  • Cross Mobile and Status Chain Sync
    • Cyp's bit:
      • AURA tokenomics
      • Some suggestions from me:
        • Niche use case a "Social L2 Network":
        • ENS+ - Identity attestations
        • Social badges
        • Steering Committee Synergy Log 2024-09 (page 17)
        • Content sharing monetisation
        • DAO out of the box, link with Status communities
        • Crowd funding and tipping
        • Tribute to talk (pay to get a highlighted message in someone's DMs)
        • Proof of membership / participation protocol
        • (Cyp said these were the focus of the L2)
      • Semi-Optimism bounties for projects building within a certain type:
        • Suggest this
        • (Don't do this, mercenary teams can just tick boxes and not add value)
        • Optimism bounties are the best as teams that add value can be rewarded only after their impact has been proven.
        • Social
        • Gaming
        • Identity
    • Legal document in 2.31:
      • We could do a content hash rather than a full file hash and that should create identical hash

2024-10-03

Schedule

  • Call with Volo
    • Discussed a number of topics:

2024-10-02

Schedule

  • Status-go Guild Weekly Sync

2024-10-01

Ad Hoc