samyoul-notes/archive/2024/2024-10.md

13 KiB
Raw Blame History

INDEX.md

2024-10-31

Schedule

Volo Call


2024-10-30

https://github.com/Masterminds/squirrel https://github.com/status-im/status-go/blob/develop/services/wallet/collectibles/filter.go


2024-10-29

https://www.notion.so/Mobile-planning-Oct-29-2024-Updates-12e8f96fb65c8005beb2ebbb91f792dd

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


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