Git Product home page Git Product logo

worldbrain-engineering's People

Contributors

kellective avatar poltak avatar shishkabab avatar

Stargazers

 avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Forkers

kellective feynon

worldbrain-engineering's Issues

Document UI guides (design systems, packages we use)

I'm working to document where we want to be moving to with the Storybook library, how we use styled-components, how we want to move towards consistency with icons, colours, type.

We will have the details of the designs inside the documentation of story book but this documentation here will outline our plan, packages, processes and current state.

Currently the documentation addon to Storybook breaks with our setup (typescript thing probably).

Document use of local storage in extension

Rebasing vs. merging

Two years ago, we agreed to rebase feature branches on develop before merging. There are advantages and disadvantages to both this approach, and merging develop into feature branches before merging. Let's collect those, reach a clear agreement on why we do what, and document that.

Document communication procedures around task preparation and implementation

We're using several tools to communicate from ideation of a task to the final implementation: Slack/Zoom, Notion and GitHub. Let's make this more explicit, so we can more easily discover ways to streamline the process and communicate it to contributors/followers.

One thing to still flesh out is the technical preparation of a task starts in a GitHub issue, and then when providing feedback on the implementation, the communication moves to a PR. Where to make this move from issue to PR is not always clear.

Document tracking new analytics events from different parts of the codebase

Analytics work is nearly done: WorldBrain/Memex#976

There will be lots of times in the future where we want to ensure some new (or existing) event is tracked.
Currently the analytics class instance can just be imported directly and used as-is. This is mainly to make things simple for really old parts of the codebase that still are yet to be set up nicely so that we can pass down dependencies like this - to post-pone the refactoring that will be needed.

To discourage any new uses like this it'd be nice to get some guidelines and examples on the recommended way to track an event from different parts of the codebase.

Start a glossary of Memex terms

We have the problem, both in the codebase and in our heads, that we have multiple names for different features or parts of the ext+app. Maybe it would be cool to have a little glossary with the terms we want to stick with and try to make any new changes adhere to that.

Some examples:

  • overview, dashboard
  • lists, collections, custom lists
  • annotations, comments, body, notes
  • highlighter, tooltip, content tooltip
  • toolbar, ribbon
  • bookmark, star

Document our git flow

A few years back we adopted the Gitflow branching model, and since then we've discussed and added further rules to our branching model such as updating minor or patch version, depending on branch type (hotfix vs release), and having certain CI checks autorun for certain branches.

There still seems to be a fair amount of confusion about how we do things with git, and I've discovered recently we often do things like build releases before CI checks pass and fork hotfix branches from develop. I feel these violations come from uncertainty about the whole process and differences in understanding among the team.

Having some simple instructions that are easy to follow and difficult to mess-up should help us avoid making these mistakes. We already have the CD pipeline instructions doc for the Memex Go repo, which is essentially a description of how the branching model works there:
https://www.notion.so/worldbrain/CD-Pipeline-instructions-2050caf8823948f6beb296129224f27a
I find these easy to follow, but that's probably because I wrote them. It would be good to expand on these for the Memex ext repo and get feedback from others on their ease-of-instruction and iterate

Document extension configuration variables

Things we don't directly want to compile into code, or should be configurable at build time, are passed in as environment variables. This is handled in build/env.js and there's a plugin which gets variables from the root .env file.

To document:

  • What things are controlled here?
  • What am I going to need in my day-to-day development?
  • Security-related concerns to not store keys in public

Document onboarding procedure for new devs working on Memex Go

  • yet to be documented
  • in particular, accessing and setting up of our shared iOS certificates and profiles is a bit of a pain, and has proved troublesome enough when trying to onboard Oliver and Felix
    • I personally have some uncertainties about this whole procedure that I'd like to clear up too

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.